Still don't understand why people prefer magic templated front-end frameworks. Reading non-standard HTML just sucks. What even is "$:" or why does Vue require non-standard javascript ref("") objects...
As for why we need $ or reactive is because JavaScript does not comes with a way to express reactivity. In the case of svelte this means having to come up with a syntax for the compiled language, for Vue means that you need to wrap your normal object in a proxy to let Vue know when you are accessing or setting a variable.
I guess this is just a difference in opinion then, haha. Not so different from Python vs Ruby.
If we talk about bundle size, then there might be more interesting discussion. Svelte claims to be pretty small - I wonder how that pans out compared to an "equivalent" app in Vue or even vanilla JS.
> Svelte claims to be pretty small - I wonder how that pans out compared to an "equivalent" app in Vue or even vanilla JS.
I don't have helpful benchmarks here, but can anecdotally confirm that the compiling and bundling magic that svelte does is... magical. They do some really smart tree-related things at build which are (imo) a major feature leading to this quick-and-small packaging of an app.
If you want a serious answer: because frameworks do a lot of work for you.
For example, they will keep state synchronised between your data model and components (and with some handy plugins, your server).
They allow encapsulation and reuse through a well thought out set of abstractions.
They provide functionality like routing and app-wide data stores with transactions.
If you’re just building a webpage no problem, use raw JS. But if you’re building a complex app, let a framework take care of as much incidental work as possible.
Same as with all (good) frameworks and libraries, they boost your productivity.
I think what snowl wanted to know was more technical than that - why such new syntax is necessary to achieve those things? Why exactly the same things cannot be achieved with existing syntax? For example, it's very understandable why JSX is preferable over vue's string syntax (<tr v-for="employee in employees" :key="employee.id">) in terms of "just use JS" argument. What exactly warrants this necessity for these weird looking and non-standard syntaxes and why it can't be done without them. Thank you.
With plain HTML+JS, it's very easy to get components to accidentally race each other when you have multiple inputs and outputs, like user interactions plus async API calls plus rerenders and UI state changes.
The syntactical sugar is often masking a lot of complexity behind the scenes, and the very idea of (say) React's props propagation within a component tree is an abstraction over having to write a bunch of separate event handlers and figuring out a way to manually share state between them.
If that is a problem you run into in your app, you can of course write your own system. But that's all these frameworks are... someone else had that same problem, decided to formally tackle it and make it a well-supported & documented system so that others facing the same problem can use that as a solution too. Over time the industry converges on a few (React, Vue, Svelte these days, Angular in the past). If you don't like any of them, well, that's how a new framework is made...
Vanilla HTML doesn't even have loops and conditionals, the basic features of any templating language from 10-20 years ago. It's glorified Gopher with JS shimmed in because Netscape was afraid of losing dominance. It was never intended to become the de facto language of software app distribution... the whole reliance on a "document" model is a poor fit for an entire class of web apps (like Google Maps or Gmail or Spotify or Netflix or Figma or Photopea).
IMO the better question in my mind is not "why do new JS frameworks and templates keep popping up?" (because HTML+JS sucks), but rather "why haven't native HTML+JS continued to evolve, creating a native solution for common pain points that the frameworks address -- like state, component trees, etc.?"
For what it's worth, at least the Web won, instead of (say) ActiveX or .NET or Flash or the Metaverse or whatever alternate ecosystem companies have tried. The JS frameworks offer some of the devex benefits of those other richer languages while still being able to compile down to HTML+JS for delivery to the enduser -- a huge benefit over a "cleaner" ecosystem that would require the enduser to install additional software. The ugliness of modern JS is because it's no longer trying to just handle basic documents, but trying to replace desktop apps altogether. And for many people, it already has.
Sure, you're right about that. It's just that everybody, for example, has the option to use React.createElement directly without JSX, as it's just a syntax sugar and people use it because they prefer it over the other option. Let's consider Vue's syntax:
Genuinely, do developers have the option to "just use JS" here (for looping and conditional)? I personally think this Vue example is very inferior to JS and I see it as an unnecessary complexity unless this "weird string magic" is what enables some nice-to-have feature which is not possible with plain JS.
I know you're probably asking it only rhetorically, but it's the way to mark something as reactive for the Svelte "compiler", cleverly using the existing JS label syntax.[1]
It's really not that bad. At least not in 2022. With the caveat that you can keep your UI (DOM manipulation) code from your business logic code. Which I'm sceptical of given the front-end code bases I've seen in the wild.
But no one writes blog posts about how Vanilla JS 2 is no longer supported so they had to migrate to Svelte :)
I see the point about abusing JS labels in Svelte being magic, but there's nothing magic or non-standard about Vue's ref(). It's just a reactive container, just plain JS.
All (widely used) modern frameworks have a degree of magic in them. Do you prefer not using any of them?
HTML and JS evolve very, very, very slowly compared to the needs of complex web apps.
If you're just building a simple page, sure, don't use a framework. But once you get into the realm of multi-screen async state sharing across components, a framework makes that a LOT easier to read and maintain.
At the end of the day the minor syntactic changes aren't much more complex than say, Markdown... they just facilitate component composition. The actual business logic is usually still written in plain JS. The templating language doesn't really matter all that much in the end, whether it's JSX or a Vue thing or a Shopify Liquid template or whatever.
HTML + JS isn't some golden standard that markup should aspire to... it is literally the lowest common denominator. It's historical baggage that everyone's forced to compile down to, and there's nothing magical or special about either writing in a framework or in pure HTML. Users don't care. Just make it work, and make it work within resource constraints. The latter is usually what drives framework usage... most teams don't have infinite time to reinvent everything in their own proprietary framework.
I'm not the one who wrote above but I see JSX as having fewer magic things than all other template languages I've seen. Take a look at Angular to see some complicated syntaxes examples. Vue and Svelte are better but, IMHO, not as easy as JSX.