5 ms·
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 n
by snowl 4y ago
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...
- yieldcrv 4y agoThe answer is because their websites are overly complicated system design take home rejects to begin with But these must be maintained now Very few sites need to be applications
- solardev 4y agoHTML 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.
- manmal 4y agoBecause in many cases, manipulating the DOM with vanilla JS sucks way more than writing declarative code with a framework.
- LAC-Tech 4y agoIt'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 :)
- deleted 4y ago[deleted]
- llanowarelves 4y agoI 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] [1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- tills13 4y ago"cleverly"
- doctor_eval 4y agoIt is clever. It’s just a named label with the name “$”. It’s perfectly standard JavaScript, and it’s super easy to remember.
- mejutoco 4y agoI like how jquery used $ to namespace all methods and now svelte does not repeat, but rhymes.
- pablopang 4y agoBecause writing code declaratively it's much more readable than imperatively. <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.
- resonious 4y ago> > Reading non-standard HTML just sucks > 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.
- for1nner 4y ago> 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.
- adlpz 4y agoI 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?
- swyx 4y agoand JSX somehow gets your blessing? let he who is without sin…
- jbergens 4y agoI'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.
- graftak 4y agoPlus jsx has unbeatable typescript support because it’s just a thin layer of sugar on top of js.
- snowl 4y agoJSX compiles down to standard JS
- kevinak 4y ago...so does Svelte?
- veidelis 4y agoJSX is basically just syntax sugar for: 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; } Isn't svelte much more than that?
- randomsearch 4y agoIf 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.
- veidelis 4y agoI 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.
- Tade0 4y agoJSX is not JavaScript, so if you're using it, you're wholly in the "new syntax" camp.
- veidelis 4y agoSure, 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: <template v-for="todo in todos"> <li v-if="!todo.isComplete"> {{ todo.name }} </li> </template> 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.