By having it's own templating language, Svelte is able to compile the templates to JavaScript in a way that addresses many of those concerns in a way that I think it easier to deal with as an end user of the framework.
If Svelte were using JSX, I don't know that it'd be possible to do everything else that it does so simply because you can write anything that's valid JavaScript in JSX whereas Svelte has just a couple of basic control structures that its compiler can parse and convert to runnable code.
When property changes, the fetch refires, loading appears until the fetch resolves then it displays whatever array someFetch resolved to.
I came from Vue and that plus the way Svelte does stores (literally nothing special about them) was a breath of fresh air.
<div>
{#await someFetch(property)}
<div>Loading...</div>
{:then data}
{#each data as item, index}
<div>{item}</div>
{/each}
{/await}
</div>Then explain what hooks do ;)
Hooks are decidedly not Javascript (even if they look like Javascript), and are a much more weird construct than {#await promise}
Javascript has no support for array-based programming.
So, hooks are not Javascript: they look like regular function calls, but:
- they can only be declared and called before rendering
- they can't be called out of order
- they cannot be called conditionally
- they have to be called a specific name to be handled correctly by React runtime
- some (but not all of them) require dependency lists that determine how they are invoked
> {#await promise} is more cryptic than any useHook function implementation.
usEffect documentation is something like 20 pages long. The use of {#await promise} is immediately understandable from the code example, and its entire documentation fits on a page and a half
I completely agree that learning them is a bit crazy, but ultimately every hook comes down to being a function execution.
How come they break Javascript semantics and execution flow?
> but ultimately every hook comes down to being a function execution.
That's really beside the point when it comes to understand what something is and using them.
{#await promise} is immediately understandable from its use.
Hooks are... well, I already said above.
wait what? since when do they break execution flow and javascript semantics?!
useEffect(function () { }); when exactly do you think the function will be called? - correct only the "framework" defines that, but that's completly normal javascript execution and semantic.
With JSX you can use native JS features instead, you only need to know the language.
For example, instead of looking up how to loop in the template syntax, you use an iterator.
div
Await promise={mypromise}
div Loading…
{res => res.map(…)}
div Error: {err => err.message}
Isn’t it easier in both react and vue to create Await component with children=(ifwaiting, ifresolved, ifrejected) than suffering all over the code?
Edit: I messed data flow up in the error handler, wontfix but you get the idea
That's a poor assumption that appears to be based on your personal preferences and what you're comfortable with. I personally find both require some learning, but prefer the svelte version.
This is already far more to learn than the handful of simple control structures Svelte introduces.
This is evident when comparing conditionals, loops, etc. Instead of learning template syntax you simply use JS syntax, albeit a declarative subset (no branches).
JSX is simply syntactical sugar for nested JS, you can use it without, but it's prettier with.
One could add this syntactical sugar natively to the language spec, in fact E4x (ECMAScript for XML) share some properties w/ JSX and was once proposed to the spec.
edit: instead of downvoting, please voice how you disagree with my assessment
<div className={red}>
{text}
</div>
import react
react.create_element("div", {"className":red}, text)
https://github.com/facebook/jsx
Example parser from Acorn:
https://github.com/acornjs/acorn-jsx/blob/master/index.js
No part of JSX uses the DOM, it doesn't share anything with HTML.
The JS engine itself would need the modification.
Also JSX doesn't have to be for the UI, it could be for dialogs for an NPC in a game, for configs, etc.
edit: I agree with @proxyon, I'm really disappointed with HN that this simple fact is downvoted without retort.
The common sentiment here is wrong, JSX is a small extension to the grammar of JS. It is JS.
https://en.wikipedia.org/wiki/ECMAScript_for_XML
>ECMAScript for XML (E4X) is the standard ISO/IEC 22537:2006 programming language extension that adds native XML support to ECMAScript (which includes ActionScript, JavaScript, and JScript). The goal is to provide an alternative to DOM interfaces that uses a simpler syntax for accessing XML documents. It also offers a new way of making XML visible. Before the release of E4X, XML was always accessed at an object level. E4X instead treats XML as a primitive (like characters, integers, and booleans). This implies faster access, better support, and acceptance as a building block (data structure) of a program.
>E4X is standardized by Ecma International in the ECMA-357 standard. The first edition was published in June 2004, the second edition in December 2005.
>The E4X standard was deprecated by the Mozilla Foundation in 2014.
https://bugzilla.mozilla.org/show_bug.cgi?id=695577#c1
>Mark S. Miller, 10 years ago
>"use strict" is currently our one real opt-in boundary for simplifying the language and reducing threats by dropping legacy complexity that is generally no longer needed. As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. Until we encountered this issues, it looked like SES could bring ocap security to ES5.1 without doing an accurate lex or parse. With this restriction, we could regain this economy.
>Besides, no one wants to upgrade the E4X semantics to be compatible with ES5 or ES.next, so this seems a good time to impose this opt-in restriction.
https://news.ycombinator.com/item?id=8266648
>bastawhiz on Sept 4, 2014 | parent | context | un‑favorite | on: JSX: XML-like syntax extension to ECMAScript – Dra...
>So..uh...this was a thing. And nobody wanted it. So it was deprecated and killed. See the "Prior Art" section at the bottom of the page.
http://en.wikipedia.org/wiki/ECMAScript_for_XML
>Brendan Eich was quoted as saying something along the lines of "E4X is crazyland". Parsing it is hard as hell to do right. Think of all the tooling that's out there for JavaScript right now that will either a.) not support JSX code or b.) bloat up beyond belief as it takes into account the suddenly absurd requirements necessary to deal with a similar-but-not-quite-XML-or-even-HTML-for-that-matter syntax. Oh, you want to lint that JavaScript? Bless your heart! You want to add syntax highlighting? Love will find a way. You want to use other static analysis tools, sweet.js macros, or anything else non-trivial? How cute!
>So essentially, it's a great way for Facebook to push React.js without making React.js a standard.
https://stackoverflow.com/questions/33642820/why-was-e4x-dep...
>It was deprecated and removed from the only browser that ever supported it because it was a poorly implemented language feature that was causing all sorts of problems.
>As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. — Mark S. Miller
>The only way for it to come back would be via a new edition of ECMA-357, which Adobe and Mozilla were going to work on. Until then, it's out. — Brendan Eich
>The idea behind it wasn't bad, but the way it was integrated into the language was. SpiderMonkey was the only JS engine that ever implemented it, and there were endless problems caused by that and severe complications of the engine's implementation required for this support. — Till Schneidereit
The word 'each' conveys the intent of this code way more explicitly.
Repeating it over and over again does not make it true.
The author is wrong. Most of his statements are about React, not JSX.
It's syntactical sugar for nested function calls, that's all. Brackets are turned into function statements, attributes are turned into object props.
The author conflates React properties with JSX, which is wrong. The author also confused JSX limitations, you cannot do statements because it's a single expression.
Please go read the JSX spec instead of some random blog post.
That should have been the end of this discussion and fight that you picked about your incorrect statement that "JSX is JavaScript". You just unwittingly undermined and terminated your own argument by linking to the JSX spec itself, which clearly and explicitly says you are wrong, in BIG BOLD WORDS.
As JimDabel said, "They wanted to be 100% clear about it." So stop repeating something that the JSX designers so insistent is not true that they put it in bold at the top of their design specification.
You already won this argument, for the "JSX is NOT JavaScript" side. It's over.
In the semantics debate you want to have I think it is JS because it all becomes JS bytecode and it's just nested function calls in the end, but that's subjective. If you want to be pedantic it's a JS extension, but in the future it could be JS if the spec is merged into engines not the compilers.
JS is an umbrella term, you're arguing it's not Ecmascript, okay, I never said that. I said it's JS, and you want to have a tussle about it instead of comparing templating systems.
Also you're very rude.
> JSX is an XML-like syntax extension to ECMAScript without any defined semantics. It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.
Further down:
> Why not just use that instead of inventing a syntax that's not part of ECMAScript?
It is not JavaScript.
It's syntactical sugar, unlike template syntax #if, ng-if, etc.
Your argument is it's not part of the current Ecmascript spec, I never said it was, but if a parser or engine adds these two new PrimaryExpressions and attributes, it is JS.
The entire point is JSX extends JS to allow templating via nested JS functions w/ pretty brackets instead of creating an entire templating system.
Under your reasoning nothing that isn't in the current accepted Ecmascript spec implemented by browsers is JS. Does that mean decorators aren't JS? Were async functions not JS before they were in browsers?
If you want to go around telling people it’s a non-standard extension to JavaScript or if you want to go around telling people it’s a superset of JavaScript, then by all means do that. But it is simply not JavaScript. Why do you insist on saying otherwise? All that does is start completely pointless arguments. What do you gain from insisting it is JavaScript when it isn’t?
The point is this small extension to JS grammar lets you do templating with normal JS, instead of #for you can use .forEach, .map and other array methods.
You can use JS instead of replacing tokens in a template.
It's not a superset of JS, that's not accurate, it's an extension of the spec.
I hope the JSX spec is added to the standard sometime to stop this stupid debate.
Until you realize what JSX is you don't realize the full potential it has over templates.
If that’s the point, why are you telling people it’s JavaScript? You can make that point just fine without starting arguments.
Saying “This is an extension to JavaScript” is fine. Saying “This is JavaScript” starts arguments. What is your goal here?
> I hope the JSX spec is added to the standard sometime to stop this stupid debate.
But you are starting this stupid debate by telling people it’s JavaScript when it isn’t. If you are tired of people pointing this out when you call it JavaScript, why do you do it? There seems to be absolutely nothing to gain from that except “a stupid debate”.
> Until you realize what JSX is
I know what JSX is. I’ve written plenty of JSX.
> you don't realize the full potential it has over templates.
We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.
First, I say it's JS because it is. Just as decorators are JS. By being an extension of JS it is JS. The two are mutually inclusive.
Second, I didn't want to start an argument, I wanted to call out the very wrong blog post, how it referenced React not JSX, how the spec is an extension of JS, explain the limitations, etc. Until now it was more of a debate. Now it's a bit more of a semantics debate unfortunately.
> But you are starting this stupid debate by telling people it’s JavaScript when it isn’t. If you are tired of people pointing this out when you call it JavaScript, why do you do it? There seems to be absolutely nothing to gain from that except “a stupid debate”.
Actually if you go up the comment chain you'll see I didn't start this debate. If you're tired, just don't participate.
> We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.
Oh but we are, again if you go up the comment chain, it's being compared to Svelte's template system, that's how it got brought up, and that's usually why this topic gets brought up. You don't have to create a whole template system. You just use nested functions. To use pretty brackets it needs a small extension of the spec. You don't have to come up with a loop system, a conditional system, etc.
This is absurd. If JSX were JavaScript, JavaScript wouldn’t need to be extended to include JSX. The whole point of it being an extension is that JavaScript doesn’t include it, therefore JSX extends it. If JSX were JavaScript, then JavaScript wouldn’t need to be extended. The two are mutually exclusive.
> > We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.
> Oh but we are, again if you go up the comment chain
In the context of “Is JSX JavaScript?”, the value of JSX is irrelevant. Whether JSX is useless, useful, or amazing makes zero difference to the question of whether JSX is JavaScript or not.
You can still go around telling people JSX is great. It doesn’t have to be JavaScript for you to do that. People telling you that it isn’t JavaScript aren’t telling you that it’s worthless. They are just telling you that it isn’t JavaScript.
We're talking in circles a bit so I'd like to drill that down first.
When the feature isn't in all browsers and only Babel doesn't make it not JS, similar to how async functions were JS before being natively in JS engines.
You're not being genuine when you say decorators aren't JS. No one looks at Angular 2 and says "whoa that's using some foreign language mixed with JS", they say it's using a JS experimental feature.
I'll concede that it's not "JS" it's an "experimental JS feature", I'll use that in the future to avoid this pedantic debate.
You don’t see why something not being included in JavaScript doesn’t make it JavaScript? Really?
> I'll concede that it's not "JS" it's an "experimental JS feature"
JSX is not an experimental JS feature. You’re trying to draw an equivalence between decorators and JSX, but they aren’t equivalent at all.
Decorators were submitted for inclusion into JavaScript. They have undergone a lot of review to determine whether they belong in JavaScript, and people agreed they did. The specification has been refined to make them suitable for inclusion into JavaScript. Everybody plans on decorators becoming part of JavaScript. Browsers will implement decorators.
JSX, on the other hand, is explicitly not proposed for inclusion into JavaScript. The second and third sentences of the JSX specification read:
> It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself.
The second sentence is even bolded in the specification. They wanted to be 100% clear about it.
The standards committee isn’t reviewing JSX for suitability for inclusion into JavaScript. Nobody is planning on JSX becoming part of JavaScript. No browsers are planning on implementing JSX.
These are two entirely different situations. Decorators being on the cusp of becoming JavaScript does not mean that JSX is JavaScript.
Since he's working from his own definition of the word "is", and his own definition of the JavaScript standard, there's no way he's going to admit what he said is wrong, even though it is, and the JSX designers were 100% clear in their documentation about shooting down his mistaken idea that JSX is JavaScript.
Now that you've made that point, he's probably just going to try to derail and change the subject again, like he was just trying to do by diverting the discussion to decorators.
edit: I'll expand for you...
I'm sorry you wanted to get sucked into "is an experimental feature JS feature JS or not". That was not my intent. The entire intent was you can use JS by using the JSX extension. Instead of #for you use JS iterator functions. You can use non experimental JS features in JSX instead of conditionals or loop systems you roll yourself. Your only argument is "oh it's not included yet" okay, no shit.
Anytime someone says JSX is JS they don't mean it's currently in the standard spec, no one is arguing that, they're arguing you can use JS language features instead of a custom template system.
If you want to say something that is different than "JSX is JS" then use different words than "JSX is JS". Nobody is misunderstanding you. You're simply wrong, and insisting on saying something that's not true.
It's possible in the English Language to put together a different sentence using different words that is not incorrect, so do that, instead of saying "JSX is JS", if you want the words you say to not be wrong.
But you don't get to unilaterally redefine the meaning of the word "is", or the JavaScript language definition, and then act rude and angry and frustrated when people disagree with you and get tired of your infinite looping and mindless repetition of things that simply aren't true.
So try this: next time you feel the urge to repeat the false statement "JSX is JS", and find yourself looping infinitely picking arguments with knowledgeable people who disagree with you, instead say something completely different, that actually means what you're trying to say and is true, like "You can use JS language features instead of a custom template system", which means something totally different than "JSX is JS".
Then you won't be saying something that is wrong, and you won't feel so sad that people are misunderstanding you, and you won't get sucked into an infinite loop and keep going around in circles, because you're not simply saying what you mean, and instead inexplicably saying something that's not true instead.
But then React is much more than just "small extension".
Hooks alone are less of a Javascript than any Svelte template syntax.
Svelte has a lot more going on than it's template language as well.
We're only comparing the templating system to JSX.
Special attributes, events, etc. are React specific and not related to JSX.
Basically it's a clean way to represent nested function calls, that's it. It has nothing to do with React nor does it need React.
<tag prop="value"/> gets turned into React.createElement('tag', {prop: "value"})
That's all. Period. The special props React introduces has nothing to do with JSX.
Also you can customize JSX to change the functions it generates. (i.e. swapping out React.createElement)
At this point the "is JSX just javascript" discussion has gone on a little to long imho. It feels like "is html a programming language". We all have strong convictions about the answer but it doesn‘t matter, really.
It‘s interesting that fans all of 3 frameworks constantly claim that it’s "just“ or "closer to vanilla" html or js. Should we really care anymore?
const a = <div prop={expression()} />
const a = factory('div', {prop: expression()})
Svelte bypasses the whole problem for the most part. https://youtu.be/AdNJ3fydeao?t=247
Keys are a hugely leaking abstraction, but are inevitable when you bridge a declarative immediate mode rendering into a stateful one.