Hacker News new | past | comments | ask | show | jobs | submit login

I'm tired of having to learn yet another templating language without a very compelling reason.

Why do I have to learn, what is essentially, a new programming language for each of these frameworks (Angular, Svelte, Vue, React... Do I really need to learn yet another language construct for stuff like `loops`, `if/else`, event handlers...etc.

Why must all of these frameworks re-invent the wheel?

At least with React it is most close to the languages we already have learned, JavaScript, and HTML.

From what I can tell Svelte looks similar handlebars templating with it's own unique syntax variations... I can't count how many different versions of the same thing I've had to relearn again, and again.




For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code.

And the reason these things change is because that's what needed changing. One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't think unfamiliarity is that damning a criticism.

Maybe I'm just used to switching up languages on a regular basis, but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.


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.


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


Not 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>


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


> The thing I like most about react is that it’s just executing plain Javascript most of the time.

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}


No, they are JavaScript, it is array based programming wrapped in a reactive functional-declarative approach. Simply array of objects cascading with state. {#await promise} is more cryptic than any useHook function implementation.


> No, they are JavaScript, it is array based programming wrapped

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


They are definitely javascript. I can click to definition of the useEffect function and see exactly what it is doing.

I completely agree that learning them is a bit crazy, but ultimately every hook comes down to being a function execution.


> They are definitely javascript.

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.


> How come they break Javascript semantics and execution flow?

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.


https://svelte.dev/tutorial/await-blocks Explains it better.


His point is you don't have to read some project's documentation to know how some "await blocks" work.

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.


Not just most of the time — all of the time! JSX is converted to plain JS (react.createElement) before it gets to the browser.


Isn't it actually the opposite? Svelte code is compiled to plain JS whereas React has a large runtime.


Nah, JSX also gets converted to Javascript. The difference is in that the React runtime re-renders whole components every time something changes, and Svelte is more granular about it even during the compilation step.


I’m neither of (react, vue, svelte) guy, but isn’t that snippet equivalent to some:

  div
    Await promise={mypromise}
      div Loading…
      {res => res.map(…)}
      div Error: {err => err.message}
(writing in pug-like because I can’t stand closing these tags on the phone)

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


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


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


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


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


Come on… If you know JavaScript and HTML you are 95% of the way to being fluent in JSX. It’s basically just JavaScript expressions.


And if you know javascript and html you are 100% fluent in any sort of hyperscript, which is just js expressions.


JSX 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


Jsx is not js, it’s python!

  <div className={red}>
    {text}
  </div>

  import react
  react.create_element("div", {"className":red}, text)
By the same logic we could call any structured format “is js”, because it is homomorphic to some js expressions. Are xml, pug, plist, dbf, all js? Nope, it’s all python.


I agree 100%... Adding JSX to the language spec would be interesting. It might be too heavy to include within the language spec as many JS applications do not involve the DOM at all, so then you have to essentially bundle DOM functions into every application... or common.js would omit this subset of the language.


It's actually a fairly small change (two new PrimaryExpressions), the spec is here:

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.


One nice thing about JSX is that it is pretty straightforward to write the function (React.createElement replacement) that it transforms to, so you can use it to construct any complex tree-like structure. No DOM stuff is needed. For example writing a JSX factory to output a static html string is maybe 20 lines of code.


Mozilla Xulrunner and Rhino (a JavaScript interpreter implemented in Java) used to support E4X: ECMAScript for XML, the ISO/IEC standard 22537:2006, and it was removed in 2014.

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


At least it's pretty much only built up of J's and html instead of something entirely different.


JSX is just JS with brackets instead of nested function calls. I expected more from this community than this kind of commentary.


I grant that it isn't Javascript and you have to get familiar with it. But at least it's not Hugo templating.


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


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


> literally just javascript

Repeating it over and over again does not make it true.

https://linkedlist.ch/jsx_is_not_just_javascript_39/


Repeating 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


Thank you for that definitive link. Note that first boldfaced sentence in that JSX specification is as follows: "It's NOT a proposal to incorporate JSX into the ECMAScript spec itself."

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.


You're arguing the wrong thing. You're arguing a semantics debate about whether an extension is JS. I'm arguing that it allows you to use JS features instead of a custom template system.

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.


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


We'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?


We’re not splitting hairs. It is, quite literally, not JavaScript in a fundamental way.

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?


I think you're getting a little too worked up.

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.


> The point is this small extension to JS grammar lets you…

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.


> If that’s the point, why are you telling people it’s JavaScript? You can make that point just fine without starting arguments.

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.


> By being an extension of JS it is JS. The two are mutually inclusive.

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.


Are decorators JS? Answer that question and I'll respond to the rest of your comment.

We're talking in circles a bit so I'd like to drill that down first.


Decorators are a stage two proposal. This means that they are not yet JavaScript, but are expected to be soon.


The point of all of this is it's a JS feature, not a system written on top of JS. A few syntax changes unlocks the rest of JS instead of having to reinvent the wheel, making your own loop and conditional systems. I don't see why the semantics of it not being included yet doesn't make it JS.

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.


> I don't see why the semantics of it not being included yet doesn't make it JS.

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.


So far he's ignored instead of addressing all the valid points you've made, and now he's trying to derail the conversation by bringing up experimental features, which, as you say, have nothing to do with anything else.

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.


https://news.ycombinator.com/item?id=29195015#29208291


[flagged]


Please see the reply I posted to @JimDabell, I didn't answer you due to your rudeness, but my reply applies to your points as well, your wall of text was the same as his two sentences.

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.


Anytime someone says JSX is JS, what they said means what those words mean, and what those words mean is wrong. JSX is not JS.

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.


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

But then React is much more than just "small extension".

Hooks alone are less of a Javascript than any Svelte template syntax.


We're not talking about React we're talking about JSX.

Svelte has a lot more going on than it's template language as well.

We're only comparing the templating system to JSX.


Let's compare to JSX then: https://news.ycombinator.com/item?id=29194287


That's still React. JSX is only turning brackets, tag names, and attributes into function calls and object properties.

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)


https://news.ycombinator.com/item?id=29206956


Those are all features of React or the React JSX transform, not JSX. Other JSX transforms or frameworks using them may or may not share any or all of them. (JSX is not only used in React.)


Ah. So we're comparing a specific templating language (Svelte) with an idealized and nonexistent version of JSX (JSX is a non-standard extension that has different flavors depending on what underlying framework, and versions of a framework, you use).


and if you really want to use statements, you can, using an IIFE for example. It’s not pretty but you can because… ehm… it‘s just javascript.

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?


Objectively, the Svelte example is cleaner and easier to read.


The 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).


Subjectively, I’d say. But since I agree that it’s cleaner and easier to read- I upvote you


By what metric are you measuring it objectively?


density.


Saying it is objective but not mentioning the reason really makes your statement subjective.


Yeah, 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.


Seems like svelte is superior for not needing a key.


Both Svelte[0] and React[1] are the same in this regard, the key is there as an optimization and isn't required in either framework. The only difference is that React's key is on the element whereas Svelte is as part of the each expression.

[0] https://svelte.dev/tutorial/keyed-each-blocks

[1] https://reactjs.org/docs/lists-and-keys.html


The key is used by the shadow Dom for update performance; the is no shadow Dom in svelte


List diffing is done even in svelte at runtime. Keys are used the same way as any other frameworks or frontend libraries, virtual DOM or reactive.


And yet Svelte is faster than React in pretty much every benchmark I’ve seen.


That makes sense though right? One would assume that shadow dom and dom would be slower than direct dom manipulation.


I'm not sure that's a fair assumption, one of the original sells of a shadow dom was that manipulting the dom directly is extremely slow, so doing as much work away from it is faster.


Because React's model requires tracking the entire DOM tree for changes and rewriting whole branches where a change is detected.

Svelte bypasses the whole problem for the most part. https://youtu.be/AdNJ3fydeao?t=247


fair criticism I wonder how svelte optimizes for rerendering of long component lists. React uses keys to avoid rerendering the entire list.


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


I believe you can specify a key in Svelte as well, but perhaps it's used slightly differently than react.


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


Neither of those are JavaScript..


> but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.

I agree. As long as you understand the basic concepts, it's only a matter of learning the syntax, which is really not as big of a deal as the person you replied to is making it out to be.


It's not a herculean task... I agree, until you've learned 10+ (angular, vue, svelte, wordpress/php, jade templates, laravel, underscore/lodash, handlebars/mustache, hugo, etc..) of these "super simple templating languages"! And keep them all straight. I have no problem learning a new language if there is a compelling reason. But If it's just additional shit I have to remember for no clear reason... No thanks...

We can have a debate on unidirectional data flow vs 2-way binding, how each framework manages state changes, how opinionated each framework is... How mature and vibrant each developer community is... etc. These are all another discussion though. My question is why must we reinvent the wheel again and again.


You need to stop insisting that a wheel has been reinvented with Svelte. It shares 95% of the same DNA as other frameworks, with multiple improvements over them. So with that in mind, what you're actually suggesting is that the existing offerings were somehow perfect, and we don't ever need to improve on anything again. That is an absurd notion, especially given that the other frameworks have gone through MASSIVE changes since launch -- sometimes even complete rewrites, because they acknowledged they got it wrong the first time.


100% agree !


>It's not a herculean task... I agree, until you've learned 10+ (angular, vue, svelte, wordpress/php, jade templates, laravel, underscore/lodash, handlebars/mustache, hugo, etc..)

So you want all of these to be a universal-template-language - (D)HTML ?


100% - Common guys we are programmers in a field that is know for changing consistently (probably a lot faster than other careers). If you see learning new "syntax" for the basics (loops,conditionals etc) then you going to have problems down the road. Weather you use svelte, or some other new tech. If you really never want to learn another syntax.. learn LISP and be done with it.

You are a programmer, you will need to learn new syntax a few times in your career.

If some of the "biggest" complaints are "oh no I have to learn how to write for-loops again" - I guess svelte is doing the important stuff right.

Wayyyy back in the day(ok not that long ago - 80/90's) when I was learning a new lang (Pascal,C, C++) I used to tell myself If I can get an working example of:

1) "user-input (readline,scanf etc)"

2) "printing input/output"

3) "calling functions/procedures"

4) "Do the loops + conditionals"

5) "file I/O"

6) "Memory schematics"

You basically mastered the "building blocks/mrk(min-req-knowledge)" of the new lang and like maths you only need now practice or a good project.

TL;DR If you are a professional-career-programmer, learning "new syntax (we used to call them keywords)" is a requirement.


Oh but it‘s not just about the syntax, it‘s also about the semantics, scope rules etc. This is the reason I still like JSX best, because I have a fairly deep understanding of that stuff in javascript while vue templates still leave me scratching my head sometimes. But I can see the appeal either way.


What boilerplate does React have? Do you mean Babel?


I know...

This comment had no context...

You don't have to even

    import React from 'react';
anymore


useMemo and useCallback do feel a little boilerplate-y. Something is slow, I wrap it in the thing, I let eslint fill the dependencies and there‘s no big downside to doing it all the time anyway. Feels like something I maybe don‘t need to be typing?

useState is also something svelte eliminates, though I personally prefer to keep that explicit.


As a backend guy who moved away from frontend long ago for these very reasons, I have to ask: why are people downvoting this? Is it wrong? I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.


It might be true, but it's a rant that just barely touches the actual topic, which is mostly: a company will pay somebody to work full time on an open source project that is still independent. And I think it's pretty nice. And also I think Rich Harris has given a lot to people for free and I'm happy for him that he will be paid to work on something that he loves.

So all in all it would be nice if we would for once be spared of rants how tiring, immature, half baked whatever whatever the JavaScript world is. Show us maybe how it should be really done, but maybe in a separate post please.


I didn't downvote, but I'll speak to my experience.

First off, you don't have to go learning every framework out there. Pick one and stick with it, or just go vanilla. That said, The features these frameworks provide gives a boost in productivity that far outweighs the low learning curve.

My pick was VueJS and I'm very happy with it. Using Single File Components is pretty similar to vanilla HTML/JS/CSS. Beginners that were under my guidance (with only HTML/CSS/JS experience) usually pick it up and were productive in the same day.

I disagree that React (JSX) is most similar to vanilla JS/HTML at all (I don't prefer it, but to each their own). Vue and Svelte are much further on the side of a vanilla-ish approach.


[flagged]


> Frontend developers like to change frameworks every week it seems like

This sentiment is so old and played out.


Is it false though? If it’s true, then maybe we need to look at why it’s true.

It’s not just front end developers though. I think other domains and their frameworks went through the same thing. This is just the time for front end.


Yes, it is false. Anyone in the space can tell you how stable things have been for years now.

Plus, there are a lot of people writing JS. It’s not a tiny community fracturing itself over different ways of doing things, and becoming destined for obscurity. It’s tens or hundreds of thousands of developers. In a community this big I’d say having a few choices is a sign of health.


Indeed, it’s false. React is 8 years old, and when React was first released jQuery was only 7 years old. I follow this stuff pretty closely and I can only think of maybe 10 JS UI frameworks that have attracted remotely significant use and active development at any point in the past 15 years.


Java is 26. Spring is 19. Struts 2 is 15.

Python is 30. Django is 16.

I’m just picking a few frameworks and languages I’ve used in the past and are still used. Obviously there are still new frameworks and libraries that come out for these languages. But sometimes the big projects fold those in. Or they write their own or whatever. I can pick the popular names and do pretty much what I need.

JavaScript is 25. But most of that time we weren’t doing what we can now. And most frameworks are fairly young. Angular is 11. But most people (and jobs) have jumped ship to React(8) and now there is Svelte(4) which also looks good. And I think there will be more changes to come.

These JS frameworks aren’t exactly veterans that are impossible to supplant. Not yet anyway.


It is false. Companies that adopt a certain framework tend to stick with it, and it's verifiable from seeing job offers.


Why is no complaining that there more than one way to build a php app? Perhaps because like JS it's a huge ecosystem with a giant user base and millions of use cases. Front end dev has lots of room to support the dozen or so mainstream frameworks we've used over the past decade-plus


Agree, and it’s nice to see this worn-out trope getting downvoted for once. Sneering at JS / Frontend developers is one of the more distasteful tendencies of HN.


Probably because it's an entire industry that is self-sustaining, without really a reason for it to exist. Most software can be built with regular HTML / JS / CSS without some convoluted framework. Even better, let's make a desktop application (when was the last time we had those?!), and we can get all kinds of performance and security gains without having to tack everything on to the web as a platform.


The "just build a desktop app" trope is even more played out.

Plus you know all these front end frameworks are "just HTML/ JS/CSS" right?


> Frontend developers like to change frameworks every week it seems like

Most of the popular frontend frameworks (Vue, React, Angular, Svelte) have been around for years at this point. It is like arguing Ruby on Rails vs Spring Boot.


> Frontend developers like to change frameworks every week

React is 8 years old

Vue is 8 years old

Svelte is the relative newcomer, at 4 years (and the major third version at ~2 years).

The idea of "frameworks are changing every week" hasn't been true in a very long time


'Frontend developers' like who exactly?

Anyone that's worked in a reasonably sized FE codebase can very clearly understand that changing your framework is essentially migrating a huge production DB but on steroids.

Where exactly have you seen a team of developers change their front end framework every week?


> Frontend developers like to change frameworks every week it seems like

React is now 8 years old… so is Vue. What are these new frontend frameworks you keep seeing?


It is wrong because it has slowed down to a crawl compared to what we had from 2010-2014.

Most companies have settled on either React or Vue, which are extremely similar. Angular is used in some niches, almost always because teams already knew it.

Those three are responsible for almost 99% of the frontend positions you'll see.

Svelte is getting popular but so far it's still niche. It's more of an inspiration for others, but also a contender. And really, what's so wrong about having more options and more competition? Even if you want to stop learning new things, there'll be no shortage of job vacancies for the three frameworks above.

Also, since you're a backend dev, there are much more backend languages in use today than frontend frameworks, to give an example. And it's not hard to find companies using more than one.


It's a false truth that anyone has to learn yet another one of these. Even Angular 1 and Backbone.js are still in production.


So is Joomla - yet I wouldn't recommend people learn it today. Might as well learn COBOL and Zend Framework too.


Ah, Zend - the only framework to out-boilerplate Spring MVC.


Naw, the Python/Zope/ZODB/CMF/Plone/TAL/MeTAL/TALES stack can out-boilerplate the yin-yang out of Zend.

Each of those Dagwood Sandwich layers has its own special purpose object system that leaks abstracts to all of the other layers, and its own domain specific languages for writing boilerplate that sprays those abstraction leaks all over the place. ;)

https://en.wikipedia.org/wiki/Dagwood_sandwich


Well in this case, it's more that svelte is the least of all evils when it comes to this. React and Vue have way more boilerplate and React in particular has the most framework-specific stuff of them all. Svelte is much closer to pure html/css, or so I'm told.


The comment is negative and incorrect

all of the js frameworks mentioned are view layer libraries. i.e. they create html. Hence they need a DSL for writing templated html, which will be used for generating final html

Hence, it is completely natural for them to offer a custom DSL as html does not have standard way of expressing those concepts.

Since each js framework has its own idiosyncrasies and motivations, custom DSLs reflect it.

If you were to go around and make a new js framework, you too are going to create a new DSL


I've used react for some years now and it's very very hard to do animation and event-driven operations with pure react render. You'll need extensive lifecycle events or hooks and refs to get animation or handle focus, etc well. It's due to how react render the components.

It doesn't make react bad but I guess some newer frameworks (vue, svelte, I haven't learned those yet) try to tackle this from different approach.


> I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.

Perhaps not in the "frontend community", no it hasn't slowed down. There will always be new frameworks coming and going, and people will work on them as fun open source projects or use them in their side projects or whatever. But people doing real work are almost unanimously settled upon React as an industry standard at this point. There's still a decent sized faction of contrarian Vue holdouts, but by and large the JS framework wars are over.


Didn't downvote either. Almost consider upvoting for visibility of the hilarity displayed.

"There are too many frameworks! Why does everyone keep re-inventing the wheel? Why can't everyone just use the one that I like?"


I never asked anyone not to use svelte... I said why should I be compelled to learn this new language, other than it being the hot new UI framework of the day.

It doesn't have a virtual DOM? It doesn't have synthetic events? Ok why not just use web components which provide their own encapsulation and vanilla JS. I don't have to learn a new language which may or may not be around/supported a few years from now... Also I'm continuing to grok web standards.


You’re right, you don’t have to! Who is forcing you to?

Rich Harris is going to work for Vercel, who are arguably most famous for Next.js, which is… React.


No, it's not wrong, it's absolutely correct. There's a lot of flexing around who can come up with the most elegant abstraction which ignores the important point: making sure what's necessary to understand the framework, use it long-term, and move away from it after is focusing on the core technologies of the web (HTML, CSS, and JavaScript).

The abstractions are cool, but completely unnecessary (see link to my framework above where I circumvent that problem entirely).


The parenthetical makes the comment!


I applaud your sarcasm and award it 10 points.


I assume because there's no value to it. What's the opposite side of the argument? You have an area with a lot of growth and many problems with the way we're solving these problems and something like svelte is not"completely reinventing the wheel" as the OP positions it, by nature it's try to solve specific problems using our existing tooling whenever possible. The original post is a shallow, feel-good rant


I don’t know about “wrong,” but my opinion on the overall theme of that first comment is that the requirement to learn is not at all a bad thing. I enjoy learning new things even when that is in some sense a “requirement.”


It sounds like you'd be better off with something like Ruby's Hotwire/Stimulus, ASP.Net Core/Blazor or Elixir/Phoenix Live View.


IMHO, syntax is the easiest part. Semantics are the tricky part. One very clear example of this is how Svelte and React deal with async stuff.

The Svelte approach follows the handlebar approach of having semantics be represented by DSL constructs - which is a very reasonable approach IMHO.

The Suspense semantics are so far off left field that someone literally wrote a whole framework specifically in response to its complexity[0].

And that complexity permeates every language construct used within a React component. Why can't we call hooks from inside if statements? Aren't if statements just JS? If you have to bring up React's internal implementation to explain, that's no longer "just Javascript", it's also a healthy chunk of very React-specific knowledge that you need to be aware of.

Vue is another example that provides a successful story of a very large algorithmic migration from a reactive system to virtual dom with virtually no disruption to consumers, thanks to the abstraction provided by its DSL. In contrast, try telling my wife (who's learning about class components in her React course) that functional components and hooks "are just JS, what's the big deal", and see how far that takes you :)

[0] https://crank.js.org/blog/introducing-crank


I completely agree with you, and I've yet to see a compelling argument against this. I've been doing this since the rise of the SPA, all the way from vanilla, jQuery, Backbone, Angular 1.0, Ember and React and after reading your comment all I can think of is "great, we're going back to handlebars templating again".

There is no net-gain in re-inventing the wheel. It just becomes yet another thing to master to stay relevant. In a decade of doing JS front-end applications things have only gotten more complex and more time-consuming.

Thankfully I've found a sweet spot where complexity, velocity and quality are in balance using technologies considered no longer cool and that's fine with me. I get to focus on the actual problem at hand instead of trying to figure out the inner workings of this new shiny thing.


The youngest framework of your list is 8 years old already. Svelte itself is gonna be 5 years old in a couple weeks, and there's absolutely no need to pick it up right now.

The meme that there are new frontends daily is extremely tired and has been totally false for several years now.

Also the only thing those baseless complaints achieve are flamewars and shitting in other people's work.


We moved on. Now there is a new javascript build tool written in a faster language daily (and I love them all).


I think the pendulum may be swinging back with options like Rails/Hotwire, ASP.Net Core/Blazor and Elixir/Phoenix Live View. Let's hope so.


For me Vue 3 with <script setup> get's pretty close to pure JavaScript/TypeScript. 90% of the code will be exactly like JS code, the only difference being the use of computed(), ref() and reactive() to achieve (something JS simply doesn't provide but is necessary for every non-trivial application). Your HTML code and CSS code are not mixed with JS and look and feel like the real thing as well. Other than the reactivity indication and the occasional onMounted(), etc. Vue 3 with <script setup> does away with all boilerplate and unidiomatic parts of Vue 2 and imo is the framework that most closely resembles pure HTML/CSS/JS while allowing for far greater productivity.


Are we still taking about vue <template>? I don‘t see how that is any way close to html when it has: custom conditional and loop syntax and semantics, arbitrary js expressions and a unique concept of scope?


It does have extra non-native features but the overarching

  <template />
  <script />
  <style />
format for single file components is plain HTML which makes it feel closer to vanilla than React.


Yeah I never really understood this benefit. The file structure is irrelevant to me after 15 minutes, the nitty-gritty semantics of my code are causing me headaches and bugs forever.

(I like working with all 3 current frontend frameworks btw, not trying to start a flamewar)


I like it because it separates layout, styling, and scripting while still collating them in the same file.


You don't need to know every framework. And that little bit of custom syntax is peanuts compared to how the rest of these differ.

Even if Angular and React shared the same templating syntax, you'd still be left with 95% of work ahead of you.


I don’t love that aspect myself, but I have to point out that in Svelte’s case it is definitely not “without a very compelling reason”. The special build-time processing is the entire point of Svelte.

Though personally I’d almost prefer it was a whole new language than a “kind of JS but with some (necessarily) new syntax”


100% no more js frankensteins...

Id prefer to learn a new language altogether


Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.


SolidJS[https://www.solidjs.com/] does exactly that. That ability is more about fine grained reactivity than it is about templates. The use of templates and single file components is a stylistic choice by the Svelte team. You could argue Solid has poor ergonomic compared to Svelte I guess.


> I don't know how you could implement such a thing (with good ergonomics) without a template language.

Parse Javascript? I don’t see how it would be any different, except you have more constructs to work through.


The "more constructs to work through" is precisely the problem. Without restricting JavaScript to some subset, you're not going to be able to statically determine the behavior of any given program.


React is a free for all, you can render pretty much anything you want at any time. With templating languages, the DOM output can be statically analyzed at build time, so the amount of work needed to diff the HTML output when things change at runtime can be dramatically shortened.


I used to be full stack before the re-invention of wheel phenomenon got way out of hand in the js world. Keeping up with what’s going on with the ecosystem and employing the best practices became a huge chore that took time away from solving actual business problems.

Turning away from front end let me concentrate time on learning devops, cloud, ml and other things that aren’t as volatile in terms of design patterns and that lets me design more high level solutions to problems and create more overall value.

Maybe people just differ in how wide or deep information they could handle but I certainly can’t keep up with such a wide array of patterns and tools that do the same thing.


The problem with each of these frameworks is that they make the mistake of surfacing the underlying standards like HTML and the DOM. This is why they look remarkably similar and can only possibly be incrementally better, at best.

HTML and the DOM are still essentially modeled on static documents. Building apps that deal directly with these standards is an impedance mismatch that, remarkably, people keep trying to solve by adhering to those same standards, but in a slightly different way.

Why should we know or care about HTML or the DOM?

A robust, event-driven, component-based framework that manages the low level Web standards could offer true advancement.


What would that look like for you? Something like SwiftUI or Flutter (which feel React inspired) or a totally different thing?


Yes, these are moving in the right direction, but have a ways to go and are heavy for what they do. Visual Basic of old may actually be a better example.

Even reactive models are built around matching data to the DOM, essentially. And there's still too much wiring that's required.

I think where we'll see the innovation here is in the no-code and low-code platforms, which will move away from the model of code frameworks to better componentize and abstract away the low-level details. They'll surface high-level interactions via an elegant event model, and automatically handle reactivity through easy to specify component-to-database bindings.

The concept of a lower-level code framework will be replaced by that of a simplified abstract "environment" in which devs work.


I like the database-to-component binding idea. If you squint, that‘s what a GraphQL/React app simulates (with mountains of boilerplate).

I‘m not so sure about moving up the level of abstraction in the direction of no code tools. You can make it super easy to build the 1000s of CRUD apps we need today, but a dominant UI toolkit needs to be low-level enough so we can also build the kinds of apps we don‘t know about yet and the no code tools to make those apps. I think the component model popularized by react is here to stay for a while, especially because it fits in perfectly with the low/no-code tools, but everything around I can see improving.


perhaps you are right about DOM but isn't HTML/XML just a way of representing an object tree... I don't see anything inherently wrong with this?


Yes, but while great for telling a browser how to render that tree, it's not an efficient way of mentally representing a frequently-updating app-driven UI.

What devs are really rendering is a tree of components, laid out on a canvas. There's no reason they should have to think in terms of how those components are managed or represented in lower-level HTML, any more than in binary.


The templating language is the easiest thing to learn. The hardest is architecture.


I just don't get people complaining of trivial or superficial stuff such as how to do ifs, loops or binding handlers. When the most important part of these tools are the architecture, the trade offs, the state managements, the tools, the libraries and the ecosystem.

Complaining just because of the syntax is just trying to convince yourself you don't like it.

It's like when people just discard tailwind because they don't like how ugly many classes together look on the html, ignoring everything behind it which is what really matters (and that you can still like or dislike).


Because if we do not keep constantly learning and get better, we would be stuck writing COBOL and BASIC.


haha fair enough!

But I think, I'd rather learn an entirely new technology or language instead of every year having to learn a JS Frankenstein language!

I kind of regret posting my OP now... as its turned into a bit of a flame war. It was not my intent.

And I applaud people try and build anything new. I'm just ranting a bit about how it feels like UI development has a new framework/language/ecosystem every year or that is touted as the next big thing to supersede the rest! But then ends up reinventing much of the same constructs only with subtly different syntaxes.


You're getting flamed on Twitter for this comment lol: https://twitter.com/dancow/status/1458906853488967684


This is very overdramatic and isn't actually based on reality. Svelte is far closer to vanilla JS/HTML than any other framework, while also using extremely similar patterns from the other modern frameworks. Yeah, it has some sugar, but it's not just some templating system any more than React is just some templating system, and the only "unique syntax" you could be referring to is the auto-subscription to stores using $, which is super convenient.

You're acting incredibly disinformative, and have no legitimate basis for your assertions.


You'd like https://github.com/cheatcode/joystick.

No special languages or syntax. Plain HTML, CSS, and JavaScript with the same reactive UI stuff in all the other frameworks. It's also part of a full-stack framework so you can whip up lightweight, fast apps.

The best part is your skills are transferrable as I'm not introducing any domain-specific abstractions. You can go from learning HTML, CSS, and JS to this without any "gotcha" in the process.


Any new language/framework trying to sell me on it's improved ergonomics should not bother showing me syntax and instead show me a stack trace. Vue is really concise and expressive but seeing a pile of node internals on every typo is infuriating.


Very true... How can I debug this thing when it breaks that's a great question. I wonder how sourcemaps work with svelte


No one says you have to learn new languages or frameworks. It's really your own choice.


Agreed, I thought we were past this with the 4th generation of these frameworks, this is like knockoutjs all over again.

The moment the penny dropped for me was when I read something like this about React:

"We realised that inventing our own Yet Another Binding Language that was less expressive than javascript was harder and worse than doing the work to put the relatively simple HTML constructs into Javascript"


And then you have ended up with shadow DOM.


They are all just trying to replicate XSLT - but by mixing imperative with declarative syntaxes.


This is why I have focused on backend for the last decade.


My solution is pretty easy to this problem: I don't.


JSX is syntactic sugar for `React.createElement(...)` (most commonly), so React pretty much is plain JavaScript.


Yeah, It‘s my favorite templating abstraction because I could convert it by hand and so I don‘t really need to mentally model it as an additional layer.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: