Comment by erokar | Hacker News Reader

Comment by erokar | Hacker News Reader

> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript.

TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript. If anything, TypeScript is a bonus.

> React mixes both JSX/HTML with JS code which I just don’t like since I strongly believe in separation of concerns and it looks ugly IMHO.

This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function.

In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern. From Vue.js' documentation: "One important thing to note is that separation of concerns is not equal to separation of file types." [1]

> Coding speed was an area Vue.js won by far, not having to learn JSX was of huge help.

It should take no more than 20 minutes to learn JSX.

1. https://vuejs.org/v2/guide/single-file-components.html#What-...

> It should take no more than 20 minutes to learn JSX.

it should, but in practicality, for most front-end devs especially junior ones, it's not. Moving Angular 1 devs to Vue gets actual work going 3-4 times (anecdotal experience) quicker than with React. For most smaller shops/startups Vue is almost always a better idea - it's much easier finding devs (especially remote/<100k comp ones) with previous Angular 1 experience and the learning curve is alot nicer. React is overengineering for most web apps.

You are probably right that Angular 1.x devs will ramp up a bit faster in Vue than React. Angular and Vue both add template syntax to HTML, which will be more familiar to Angular devs. However, I do not think initial ramp up time should matter that much, at least not for long running projects. More important questions are: How will the project scale? How easy will it be to maintain?

> React is overengineering for most web apps.

This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.

> This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.

This 'simplicity leading to complexity' issue reminds me of the many articles that argue why Lisps aren't more popular precisely because they're so powerful/simple.

I'm not experienced enough to know if the argument has merit, but I have noticed that my React projects often end up rather complex because I need so many extra packages to even get a basic app going (beyond the simple Todo demo apps anyways).

The moment I add an extra package, it's yet another choice to make, and yet another thing that makes my project less accessible to others. Where I might use Redux, others might only have experience with Baobab, Fluxt, Nuxxor, FlimFlam, or whatnot.

This situation does seem to be improving: Redux seems relatively 'safe' and standard enough, for example, and then there's stuff like create-react-app. However using Vue.js is still 'simpler' by having a more standardized ecosystem.

While personally I've always preferred simplicity and love React conceptually, I've definitely become more aware of the drawbacks of having a less standardizes ecosystem to work with. And I can definitely confirm that getting people new to front-end development started is much easier with Vue.js.

I even have a suspicion that the logic-in-template stuff, my reasons for avoiding Vue and Angular in the past, is much easier to 'get' by those who are new to front-end development. I'm not entirely sure why, but it's what I've experienced with all my 'students'.

If you know only JS, JSX is much easier to pick up than some proprietary templating language. How do I do an if, a loop, a map, ... any code at all? In JSX, the answer is squiggly-brackets and regular old JS code. In Angular's templating system and Vue's, you've got to relearn all of these and more.

You can use JSX without trouble with Vue

Here's a link for anyone wanting to read more about it: https://vuejs.org/v2/guide/render-function.html#JSX

> proprietary templating language

Isn't that exactly what JSX is?

No. JSX is a small domain-specific language for expressing a hierarchy of virtual DOM nodes. Angular is a template language in that it eschews JavaScript compatibility in favor of its own directives that try to emulate basic iteration and conditional expression evaluation.

I wish you could write non string based jsx in angular. Or at least make aot fast enough for the regular webpack watch / recompile workflow.

No it's a standard. You can use JSX with Vue 2.0 now, as well as Preact and others.

JSX has nothing to do with 'templates', it's an alternative javascript notation. When you write JSX code you write javascript code, using JSX syntax.

I think he meant that in vue.js/angular you have to learn a bunch of proprietary tags for each construct (if, foreach, etc.), whereas in JSX all you need is plain old javascript.

This is probably true, but it's a really poor rationale for choosing a templating* solution. Sure, JSX is slightly easier to pick up than a pure templating solution would be, but that doesn't mean learning modern templating tools is hard. Making already easy things easier isn't much of a win in my book.

On the other hand, JSX is extremely difficult to read. I can glance at a relatively complex handlebars template I wrote two years ago and instantly understand what it renders. To do the same with a similar JSX component requires spending ten minutes to trace the control flow, understand all the helpers, and mentally re-inline all the loops and conditionals. It's conceptually simple, which is attractive, but in practice that seems to lead to noisy, nonlinear render functions that have little to no structural similarity to their final rendered DOM.

It's also worth noting that JSX is easy to pick up for javascript developers. It's next to impossible for the kind of design-focused frontend people who know HTML and CSS inside and out but only ever needed enough JS to write the occasional jQuery selector. If you're certain your project will never have any styling input from people who aren't first and foremost programmers then JSX might be a great fit, but the rest of us actually have to work with our teams.

* Yes, I know, JSX is technically not a template.

> It's also worth noting that JSX is easy to pick up for javascript developers. It's next to impossible for the kind of design-focused frontend people who know HTML and CSS

This seems more like a meme than reality. Design is hard. Someone that was able to credentialize in CSS of all things can learn some JS/JSX. Give them some professional courtesy and credit.

Saying that it's "next to impossible" seems kinda toot-my-own-horn dismissive.

Ramp up time shouldn't be the only consideration, in any moderately sized project ramp up time will be dwarfed by other concerns like ease of development. In general, ramp up time is one of the weakest arguments in favor of anything you can make and should only be taken into consideration after all other concerns have been shown to be moot. Likewise the argument about "finding devs". Any competent developer should be able to come up to speed with most anything mainstream relatively quickly, and in the case of junior devs they're often far more willing to invest in learning whatever niche technology you've selected. The quality of developers you hire should be a much larger concern, not the quantity.

As one data point, a number of years back when we needed to hire some frontend developers we actually advertised for Java developers because when we looked for JS devs the quality of candidates we got was abysmal. For another data point, when one company I worked for needed to hire Flex developers (this was a number of years ago) they once again advertised for Java developers, and when I responded asked if I was familiar with and/or willing to learn Flex, which I was. It took me about a month to fully come up to speed with Flex, and I was productive in it within a week.

Is that still true to this day? JS has exploded in popularity and utility in the last few years. Even Stanford and other high quality CS schools are teaching JS now.

Yes, it's in many ways exactly that popularity that's the problem. The ratio of good to mediocre programmers hasn't really changed any, but now there's a whole lot more JS devs out there, so finding the good ones is an exercise in wading through a sea of mediocrity. For better of worse, the Java developer ecosystem does a better job of filtering out the mediocre devs, and generally once you reach a certain level of experience picking up something like JS becomes a trivial exercise. We tend to favor candidates that have experience in multiple languages because it's a strong signal that they're a quality developer, and you tend to find more of that in your backend developer pool, where the frontend developer pool tends to have a lot of experience with a ton of frameworks, but they're all almost exclusively pure javascript focused.

The problem I tend to see there though is back end developers often lack good UI skills.

It's a fair point, but by the same token it's usually easier to teach a backend dev good UI design principles, than it is to teach a mediocre frontend dev good programming principles. There's also the fact that for a lot of the kinds of work we're hiring for, there's a creative team producing design documents that the developers are working against, so they don't actually need good UI skills generally (although it certainly can help, particularly when the designers produce things that don't actually work in practice).

If a dev cannot pick up JSX in a day they should be let go. I don't feel this is extreme at all. I'm not saying that React is always the best choice, but JSX is absurdly simple, if it can't be understand very quickly that is a red flag.

> This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function.

I see this so much as an argument against React/JSX. I can not never figure out how putting the display logic in the display template is some how going away from separation of concerns.

As for JXF being hard to learn, that is just silly. Sure there are a few quirks but nothing in comparison to a learning a new templating tag language.

Without arguing one way or the other:

- Traditional SoC: template, styling, and logic for my app are separated

- React/ractive/vue/preact SoC: parts of my app - login boxes, payment areas, order displays - are separated. They may further be separated by template, styling, and logic or not.

You're slicing something vertically vs horizontally.

In practice I prefer one of these but saying which one wouldn't help illustrate the concept.

> Traditional SoC: template, styling, and logic for my app are separated

No, they are not. There is no real difference (other then syntax) between

{ rows.map(r=>(<Row data={r} />)) }

and

<div ng-repeat="r in rows"><Row data={{n}}/></div>

These are both logic that have to be run to display your page. The only real difference is that with JSX, it is easy and powerful enough to use that you could stick some non-display logic in there. Easy and powerful should not be an argument against it.

We went from anything like JSX getting you laughed out of the room (LOL 'onclick' properties, hello, 1998 called! Also code doesn't belong in markup, so markup certainly doesn't belong in code, are you insane? Templates! Separate style!) and sensible, healthy skepticism of workflows like "compiling" not-html to still-not-HTML to eventually generate HTML at runtime, to all of that being just fine and anyone not immediately on board with it being called a moron seemingly overnight, I guess because Facebook says it's fine?

Some people have a little whiplash from all that, and I think it's understandable.

It's because it flew in the face of commonly accepted best practices. It felt like a return to PHP/ASP days of old. But in reality, once you use it, you realize it's not that. It's a good abstraction. It puts concerns in the right place. Now, when I have to write something in any .erb file, it's like pulling teeth. JSX + React is a very good view-layer and component abstraction.

I'm not even saying it's a bad idea, just that I think it's entirely understandable that people are a little confused and upset that a decade plus of best practices suddenly did a 180 and they're being looked down on for even taking a second to go, "wait, what?"

I guess these arguments feel a bit dated at this point. React has been out for four years now.

Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic.

It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.

This is the unfortunate result of people following "best practices" only because that's what other people do, and not because of some justifiable benefit of said practice.

> It's because it flew in the face of commonly accepted best practices.

People need to stop blindly following current "best practices" because they change all the time. Weigh up the pros and cons yourself. I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes.

Best practices for web app UIs have changed dramatically as we've went from e.g. server side only logic -> jQuery/AJAX based UIs -> Backbone -> Angular 1 -> React. This clearly shows we've no idea what the "best" way to do things is yet.

> I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes.

Don't do that. Perform loops outside of the final template. People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you'd obviously not do that when looking at raw code.

    const MyComponent = (props) => {
        const itemList = props.itemData.map((itemData) => {
            return <Item data={itemData}/>;
        }

        return <div><h1>List of items</h1><br/>{itemList}</div>;
    }

It's as simple as that. There is never a reason to mix logic into the "template" part of the component.

I'm not seeing a huge difference. It's a bit cleaner, similar to how it would look if you did a similar refactor of plain JavaScript code, but it's still very similar. If the logic is short, it's cleaner to inline it sometimes. Going back to my comment, what are the pros and cons or is this just separation based on principle?

Do you have any specific reasons for why `items.map` should not be inside a jsx tag? Your comment doesn't make it clear why you think this.

> People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you'd obviously not do that when looking at raw code.

Basically what I'm saying is, if you were just writing React.createElement function calls, it'd be more obvious that the items.map should kept out of the rendering code, e.g.

    const MyComponent = function MyComponent(props) {
        return React.createElement(
            "div",
            null,
            React.createElement(
                "h1",
                null,
                "List of items"
            ),
           React.createElement("br", null),
           props.itemData.map(function (itemData) {
               return React.createElement(Item, { data: itemData });
           });
        );
    };

Of course, this is a simplified example, but the more complex the template (i.e. the deeper the nesting) the more the code benefits from having loops and other control structures extracted from the final template.

When a programming expression is made significantly more concise via some abstraction, it can be used in new ways that weren't reasonable before.

JSX makes expressing dynamic, declarative DOM markup concise enough that a short expression such as: `items.map(item => <FooItem item={item}/>` is no longer overly obtuse/obfuscating.

If the `map` expression becomes much larger, it might make sense to refactor it out in some way. But I would argue that the important guiding principle here is readability and modularity. Drawing a hard line between flow/control structures and "template code" is not useful, in my mind.

As others have stated in this thread, the more useful distinction is between business logic and presentation. Loops rightfully exist in both of those domains.

JSX is not html. JSX is not a templating language. The similarity between JSX syntax and the equivalent virtual DOM node names is the reason it exists. When you write JSX code you are writing javascript code using the JSX DSL to generate the virtual dom. 'HTML templates embedded in code' is simply not what happens when you use JSX. The fact that you got fooled into thinking that is the opposite of a DSL problem.

> The fact that you got fooled into thinking that is the opposite of a DSL problem.

Which part of what I wrote makes you think I think JSX is an HTML template? The part where I specifically called it "not-html" and the react.createElement code it's translated to "still-not-html"?

That it's kind-of-HTML-but-not, turned into Javascript, turned into shadow-DOM transformations, turned into HTML, is Rube-Goldbergian enough to warrant skepticism. No need to misunderstand it to feel that it's an indication that something somewhere has gone deeply, fundamentally wrong.

And actually I think it'd be fair and consistent to call it a template language, were I inclined to press that point. That it becomes Javascript doesn't change the form it takes when you're writing it. Looks and quacks enough like a duck that insisting it's totally not a duck at all is untenable. Sure, it's translated into shadow-DOM-transforming JS. So? It's not like HTML itself doesn't go through some intermediary representations before becoming different colored glowing pixels on your screen.

> TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript.

If you code in TypeScript and extensively use plain objects and "any" types then you don't get a point of TypeScript and so you better don't use it at all.

> It makes more sense to group code based on function.

The idea of code layers and separation of concern comes form the improving code maintainability and testability ideas. Generally if you code has no layers, then it won't be convenient to unit test it. So it makes sense to group the files based on the function, so you can for example switch the entire function easily, but not putting all the function related sources code to the single file.

> In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern.

Single file components is a term, it's more like junction point for the component's parts, as it allows to reference separate/external files into the component file instead of putting everything inside a single file.

Reply on news.ycombinator.com