Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hm, doesn't seem that much of a win for React users.

The performance is compareable, but they went for templates instead of the "it's just JS"-philosophy of React. Reminds me of "the fear of turing complete templates"[0]

Also, they mention their bindings are similar to MobX. I had the feeling MobX was a step back in the React eco-system, if I think about what Facebook wanted to achieve with Flux.

But yes, overall it seems like a much simpler approach than React or Angular, not to mention Angluar 2, lol. But it seems to come at the cost of the points I mentioned, which were really a pain back in the days and got solved with Flux and JSX.

It also doesn't seem to solve some problems that React didn't solve, like realtime asynchronous data or fractal state.

[0] http://lhorie.github.io/mithril-blog/getting-over-a-fear-of-...



You can use JSX to write your render functions in Vue [0]. It's opt-in as the Vue community views them as overkill in the usual case.

Personally, I appreciate having the intuitive approach for templating as the default for people who don't share my encyclopedic knowledge of web development. They can more easily follow along and contribute.

[0] https://vuejs.org/v2/guide/render-function#JSX


I see :)

> I appreciate having the intuitive approach for templating as the default for people who don't share my encyclopedic knowledge of web development

I always saw it the other way around, haha :) Why should I learn some template language, when JS can do the job and I already know it.


JSX is not JavaScript. If its not in a spec that is ever going to be implemented by a JS runtime, like a browser or Node.js, then it's not JavaScript. It's a superset of JavaScript.

If you admit that JSX is a superset of JS then the downsides become readily apparent. Many will still choose JSX and there's nothing wrong with that, but the argument isn't "why would I use X when Y is better".


IMO JSX is such a simple syntactic sugar around javascript that you can unfold it in your head.

> <element someProp={prop} /> = React.createElement('elment', {someProp: prop}, null)

Its such a simple transformation and adheres to javascript standard behavior. JSX doesn't add anything new, it just adds a way to do something old.

Its a shortcut to 1 transformation and thats it. You can unpack it in your head.

So while I agree with you that it isn't "standard javascript", if you look past the visual differences, there is no difference between JSX and javascript.

This is in stark contrast to the Vue.js (and other) template systems which, while they compile to javascript, the amount of transformations makes it impossible to extend the template system easily without touching the internals of the template engine.

JSX is just syntax, other template systems are entire secondary languages.


> Its such a simple transformation and adheres to javascript standard behavior. JSX doesn't add anything new, it just adds a way to do something old.

I don't understand your point, to be honest. A lot of language features are just syntactic sugar for lower-level language functionality. ES6 getter/setters are just syntactic sugar for Object.defineProperty. Does this mean that ES6 and ES5 are the "same"?

No, of course not, but ES6 getter/setters are specified in ECMA-262 and JSX is not, so ES6 gets to be called JavaScript and JSX doesn't. It's really as simple as that.

My point is that because JSX is not JavaScript it then requires a ton of complexity to use it. Whether that complexity is justified is up to each person, but we can't ignore that complexity exists when arguing it vs. alternatives.


It's literally as complex as transpiling ES6 to ES5.

And although JSX is not in the ECMA-262 spec, it does have a spec, so there's that.


Transpiling is complexity. You don't have to transpile if you just use web technologies (JavaScript, HTML, CSS).


Of course it is, but saying it's "a ton of complexity" to use JSX, while not saying the same for transpiling current and future ECMA-262 syntax into what browsers support right now is disingenuous.


No it's not, transpiling future ECMA-262 is not within the scope of this discussion. We are compared browser-native language features JS (non transpiled), HTML, CSS, to non-native features, namely JSX.


The whole point wasn't about this syntax, but about the fact that React templates are just simple nested function. But maybe this would have been more obvious if I used hyperscript instead of JSX as an example.


You can't ignore syntax, hyperscript isn't very popular.


If you like JSX, please stick with React.


I think it's okay, makes finding markup in .js files much easier.

But I think I prefer t7, because it works 'native'




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: