Comment by cphoover

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.

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.

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.

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.

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”

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.

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.

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.

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.

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"

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.