8 ms·
What how can you say that??? <ul>{myItems.map({id, title}) => <li key={id}>{title}</li> }</ul> vs... svelte <ul>{#each myItems as
by cphoover 5y ago
What how can you say that???
<ul>{myItems.map({id, title}) =>
<li key={id}>{title}</li>
}</ul>
vs... svelte
<ul>{#each myItems as item}
<li>{item.title}</li>
{/each}</ul>
One is literally just javascript and html the other is an entirely different template language. You might say... JSX is not HTML... well it's very very similar... If you know HTML you JSX is very intuitive.
- pier25 5y agoObjectively, the Svelte example is cleaner and easier to read.
- spoils19 5y agoBy what metric are you measuring it objectively?
- pineconewarrior 5y agodensity.
- kosolam 5y agoSubjectively, I’d say. But since I agree that it’s cleaner and easier to read- I upvote you
- diegof79 5y agoThe issue is not only the syntax, but the semantics. What happens to the scope when you nest #each expressions? Does it work with iterables (like for..of), or it behaves like for..in? I don't use Svelte, and I don't know those differences by reading the code. To me the nice thing about JSX is that is straight forward with JS semantics: const a = <div prop={expression()} /> is a DSL for: const a = factory('div', {prop: expression()}) is only a DSL to create tree structures (React is another story, you can use JSX without React).
- epolanski 5y agoSaying it is objective but not mentioning the reason really makes your statement subjective.
- makeramen 5y ago> If you know HTML you JSX is very intuitive. 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.
- DonHopkins 5y agoAnd JSX isn't JavaScript and it isn't HTML, and if you know JavaScript and HTML you still don't know JSX, so you're still using "yet another language" in addition to JavaScript and HTML.
- alvarlagerlof 5y agoAt least it's pretty much only built up of J's and html instead of something entirely different.
- Ambroos 5y agoJSX is easy to summarize as: HTML where everything in curly brackets is a JS expression that gets evaluated. There are some additions (prop spreading) and restrictions (curly brackets apply to whole attribute values and element bodies only), but they're very simple.
- ricardobeat 5y agoAnd custom event handling attributes, camel casing, special cases like htmlFor and className, non-standard attributes being ignored except for custom elements, the style attribute, the special case of checked/selected properties vs attrs for form elements, key and ref properties. Plus all the semantics of component updates, memoizing and so on. This is already far more to learn than the handful of simple control structures Svelte introduces.
- hunterb123 5y agoJSX is JS. Nested brackets are simply converted to nested function calls & objects, attributes convert to properties. 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
- subpixel 5y agoI grant that it isn't Javascript and you have to get familiar with it. But at least it's not Hugo templating.
- benmccann 5y agoBut React isn't just JSX. It's also the entire runtime library, hooks, event handling, forms, state handling, etc. The example you shared is a bit too simple to understand where Svelte shines because it doesn't introduce any of those concerns. 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.
- deleted 5y ago[deleted]
- noir_lord 5y agoNot to mention it takes reactivity to new heights while adding amazingly little actual syntax. 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>
- Aeolun 5y agoBut what does ‘#await someFetch’ actually do? The thing I like most about react is that it’s just executing plain Javascript most of the time.
- noahtallen 5y agoNot just most of the time — all of the time! JSX is converted to plain JS (react.createElement) before it gets to the browser.
- ksdnjweusdnkl21 5y agoSeems like svelte is superior for not needing a key.
- cphoover 5y agofair criticism I wonder how svelte optimizes for rerendering of long component lists. React uses keys to avoid rerendering the entire list.
- Mavvie 5y agoI believe you can specify a key in Svelte as well, but perhaps it's used slightly differently than react.
- bdougherty 5y agoYeah it's not strictly necessary, but if you are updating the list (adding/removing especially), Svelte can know how to reuse elements properly if they are keyed. You also need keys for animations to work properly.
- wruza 5y agoKeys are also essential to retaining an element identity, which is structurally more important than performance, because 1) code may have a reference to an element and think that it relates to some data, 2) an element may have an explicit state (like focused, animating, etc). Keys are a hugely leaking abstraction, but are inevitable when you bridge a declarative immediate mode rendering into a stateful one.
- winphone1974 5y agoThe key is used by the shadow Dom for update performance; the is no shadow Dom in svelte
- afavour 5y agoAnd yet Svelte is faster than React in pretty much every benchmark I’ve seen.
- uallo 5y ago> literally just javascript Repeating it over and over again does not make it true. https://linkedlist.ch/jsx_is_not_just_javascript_39/ https://linkedlist.ch/jsx_is_not_just_javascript_39/
- hunterb123 5y agoRepeating a blog post over and over doesn't 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. https://github.com/facebook/jsx https://github.com/facebook/jsx
- JimDabell 5y agoRight from the very top of your source: > 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.
- hunterb123 5y agoWe're splitting hairs now. It's an extension of the JS spec. Once a parser adds this grammar it is JS. 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?
- bGl2YW5j 5y agoThis JSX syntax is a perfect example of one of its subtleties: map() creates an array, and an array of elements is automatically expanded to single elements. I know that when I learnt JSX, this was not intuitive. The word 'each' conveys the intent of this code way more explicitly.
- wruza 5y agoAnd this subtlety is based on a difference in React.createElement() interface. If you pass an array among its children, it automatically requires all of its items to be keyed, and if you pass it as …array, i.e. variadic arguments, it doesn’t. But I believe you either can’t do {…array.map()} in jsx or its creators decided that it is not tasty enough.
- tflinton 5y agoNeither of those are JavaScript..
- deleted 5y ago[deleted]
- midrus 5y agoYeah, now add state management, event handling, side effects and performance optimizations and come back with your example. You're just comparing syntax. This is very naive.