Hacker News Reader

Comment by meathook | Hacker News Reader

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

View on HN

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".

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.

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.

Reply on news.ycombinator.com