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...
<h1>{name}</h1>
clearly state that you want name inside h1, it's colocated and faster to write than
const h1=document.querySelector("h1"); h1.innerText=name;
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.
> it's much more readable
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.
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.
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.
<template v-for="todo in todos">
<li v-if="!todo.isComplete">
{{ todo.name }}
</li>
</template>
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.
[1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But no one writes blog posts about how Vanilla JS 2 is no longer supported so they had to migrate to Svelte :)
All (widely used) modern frameworks have a degree of magic in them. Do you prefer not using any of them?
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.
createElement(
"div", {
className: ["recipeTile", { lastRow: options.lastRow, lastColumn: options.lastColumn }],
onclick: function () { showHideRecipe(recipe.name) }
}, [
createElement("img", { src: "./static/images/" + recipe.name + ".jpg" }),
createElement("div", { className: "details" }, [
createElement("div", { className: "name" }, capitalize(recipe.name)),
createElement("div", { className: "ingredients", }, Object.keys(recipe.ingredients).map(function(ingredientName) {
return capitalize(ingredientName);
}).join(", "))
])
]
);
function createElement(type, attributes, children) {
var element = document.createElement(type);
Object.keys(attributes).forEach(function(key) {
if (key === "className") {
classNames(attributes[key]).forEach(function (className) {
element.classList.add(className);
});
} else if (key.indexOf("on") === 0) {
element.addEventListener(key.replace("on", ""), attributes[key], false);
} else {
element.setAttribute(key, attributes[key]);
}
});
if (Array.isArray(children)) {
children.forEach(function(child) {
child && element.appendChild(child);
});
} else if (typeof children === "string") {
element.textContent = children;
} else if (children) {
element.appendChild(children);
}
return element;
}
But these must be maintained now
Very few sites need to be applications