Hacker News new | past | comments | ask | show | jobs | submit login
Virtual DOM is pure overhead (2018) (svelte.dev)
322 points by rob 33 days ago | hide | past | favorite | 289 comments



Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works.

If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead.

Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here. In practice. So Svelte has a lot to prove to get people to try to move. And this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” (while simultaneously admitting that plenty of frameworks were slower at the time.) That’s not going to work. That’s going to classify you as “insane person” to many people. It reminds me of the claims G-WAN made: over-exaggerations in a smarmy tone based on micro-benchmark wins.

I’m not saying there’s anything wrong with Svelte. But, this is not how you sell something. React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. It delivered exactly that. And yet:

> the alternative is to do something no-one actually does

Somehow this article manages to contradict itself in pursuit of unnecessary smarminess.

I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion.

The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.


>The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning.

Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code. In this way, whether you go with Vue or React or Angular, it makes no effin difference to performance.

But yes, there is overhead in managing the virtual DOM and yes, you can get yourself in trouble if you don't structure your application in line with how the framework expects you too.

>React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day.

React made a stronger claim. It wasn't just about React vs some Templating framework. React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim.

>Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead.

And it's not a bad argument. The DOM is an abstraction and the underlying implementation is highly optimized. DOM mutations are not the expensive thing, it's the final render, and that part has had an enormous amount of work done to make it smart and fast. By the way, Flash had a great built-in rendering model. The Flash display list hierarchy was very well architected and it wouldn't re-render the entire page if only a part of it changed.

>But this isn’t how you sell a framework to programmers, in my opinion.

Claiming your framework is faster than the other guys IS how you sell a framework to programmers. That's how React and Vue were/are being sold.


> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim.

My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars.

Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you're manually manipulating the DOM then you're liable to just swap out entire chunks of the tree rather than making surgical manipulations. Because manually managing all those surgical manipulations would quickly become a fiddly, unmaintainable mess. But, if you do it that way, you're asking the browser to do a lot more re-rendering, and that would be costly.

I worry that this conversation falls into the same trap that most performance discussions fall into, where we quickly become focused on what things would be like if people had unlimited time to chase the best-case scenario, rather than what things are like for the 99% of us who are just trying to get something that works acceptably by the next deadline.


no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read too much damn code where a dev wants to do something straightforward but either because of ignorance or some cultural pressure reaches for a complicated library way to do it, finds that said library doesn't solve the problem well, and then misuses that library or exploits one of its escape hatches in the solving of the problem just to say that their code used the new shiny library. As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.


This feels like a tangential point about JS dev culture or engineering skill level rather than a point about the technical merits of React vs Svelte or whatever.

> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

I'm not sure I agree with this. Basically, it requires a much higher degree of experience and skill to write DOM manip well. There aren't really great resources that I've seen, because it's all very context dependent and something you learn over time. We used to send people straight into the DOM when they wanted to make a simple app, and the result was a lot of huge unmaintainable messes, security nightmares, and poor performance.

The value of React is that you can just follow the docs on reactjs.org that will give you a mediocre default. If your needs go beyond that, you can get a more skilled person to come in and improve the critical parts. The world's need for web apps outstrips the supply of highly-skilled, highly-experienced developers, so it makes sense to have libraries that lower the bar.


For my part, I actually wonder if there's also a certain gatekeeping element that also fuels the popularity of frameworks like React?

Turning things into JavaScript-heavy single-page applications has, I would assume, an effect of shutting out people who are good at HTML+CSS, but less so at JavaScript. I don't know how likely a profile that is nowadays because I'm buried deep deep deep in backend-type work, but it used to be fairly common to have front-end people like that who were stronger on design than programming.

Is this a form of unwitting rent-seeking behavior? Has the profession created an artificial supply-and-demand problem by convincing the managers of the world that they need expensive single-page applications built by Software Engineers™, when a (less expensive, I'm assuming) Wordpress site developed by a web designer would have sufficed?

For context on where I'm coming from: I've mostly been a back-end developer for a couple decades. I've known HTML and CSS since the '90s, of course, I'm just now starting to learn Web development in earnest, mostly as a hobby. I'm finding React's learning curve to be just incredibly steep. For the stuff I've been doing, I've had a much easier time getting acceptable (to me) results out of a more oldschool-flavored tech stack, with server-side templating and a moderate sprinkle of vanilla JS. No, it's not fancy, but I'm not looking to flex; I'm just looking to whack together a website that looks nice.


I'm not sure I'd go down that road. I totally agree that for websites, Wordpress, SquareSpace, Gatsby, Hugo, and a host of other static sites work just fine. Where I find it hard to make the stretch is, these are not the type of sites your average JavaScript app developer wants to work on. They'd probably be just fine NOT touching that. I know the past few places I've worked, I've never touched the slick "brochure/marketing sites". I think that type of thing is better left to someone who has really honed their HTML/CSS skills. I don't see a whole lot of reason why anyone would want to turn that type of site into an SPA.

I'm not saying developers don't have an attitude problem. We often do. I just think you might be assuming malice where there might be none.


Definitely not trying to assume malice. I meant it when I said, "unwitting".


> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

As a bootcamper who came from a philosophy background to frontend, you will be surprised how many 15 year "veterans" in web dev can't write coherent code without a framework, couldn't tell you how designing data one way or another impacts their code design, and when you confront them on this, bring it to their attention, they find any which way to dismiss the problem with "do we really need that"/"why do we need that" as if their's virtue in pretending to be the Product team in the face of shoddy engineering. Enterprise agile largely enable this fairly low floor. Engineers can handwaive anything in the name of the holy right now.


> but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.


Adding and removing nodes from a tree doesn't require a phd.

I don't particularly like React and I never used it, but I can see how it improves performance over naive use of browser APIs, because you can easily do things that are really bad for performance and require needless layout calculations when updating DOM manually, while tools like React will sort the updates in more optimal way without too much thinking.


> reaches for a complicated library way to do it

This is neither here nor there. Some people write awful React code too.

> having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer

I mean, knowing how to do it is good and all, but knowing how to do it well is a rare skill. There's a ton of random performance gotchas to be aware of (like, reading a property in the middle of a bunch of writes causing double repaints) and frameworks do consistently apply optimizations that you as a regular dev would probably not ever think of (sorting optimizations being some of the least trivial ones).


> But, in the big picture, if you're manually manipulating the DOM then you're liable to just swap out entire chunks of the tree rather than making surgical manipulations

"Swapping out entire chunks of the tree" is in fact a very sensible choice given that the browser rendering pipeline is highly optimized and can run in parallel, whereas any v-diffing step has to be done in single-threaded, non-native JS. You also save on the overhead of storing the vDOM itself, which will be quite significant.


I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone.

Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on stuff, some lists that elements can be added/removed to/from), but those sorts of things seem fairly typical.

I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.


>I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.

I've been hard on React in other places in this thread because I agree with the premise of the article that VDOM is not free and that the value of React is not in performance over raw DOM manipulations, but rather in code organization.

Having said that, React isn't bad either. That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React. It's been a few years since I did any meaningful React development, but back when I did, React code was simple enough that it wasn't hard to understand and trace trough, or profile. I guess I'm curious, what the bottleneck was.


> React code was simple enough that it wasn't hard to understand and trace trough, or profile

Interestingly enough, this was the opposite of my experience. For my next project I used Mithril because it was far easier for me to debug, trace, and profile through.

> That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React.

I had on the order of 100 inputs with two-way binding. My code was structured along the lines of the existing react tutorial of the day (maybe 10ish years ago?). Per suggestions of members of the react community, I restructured it to use ImmutableJS to allow for faster VDOM diffing, which did cause a noticeable speedup, but was still dog slow.


It's hard to say for certain, but it sounds as if you may have been doing things that caused lots unnecessary re-renders. React has some pitfalls for beginners, but I've built highly complex frequently updating webapps without the degree of slowness you're speaking of.


Vivaldi browser is made using React. Frantic pointless UI DOM manipulations (deleting nodes just to recreate them back etc) are one of the main sources of performance degradation. https://news.ycombinator.com/item?id=27449736


I just read that and chuckled. Someone must have been under pressure and just said fuck it, this works.


I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?


Tons of DOM mutations in a hot loop are slow.

One DOM mutation is faster than one VDOM-to-DOM flow, though, of course, since the latter's doing the same thing plus more. The latter also uses a lot more memory, and keeps it around indefinitely unless you want to risk performance-killing deallocs and allocs later (I'm making some assumptions there—I'd expect a typical VDOM implementation's memory is rarely released, since re-building that data structure would be high cost if you need it again and largely defeat the purpose).

VDOM's also pure JS in the typical implementation, which is going to tend to be slower and (much) less memory efficient than getting the fuck out of JS and into the browser's C++ or Rust or whatever, ASAP (React's, for instance, is a big ol' tree of JS objects, AFAIK).

If you're often modifying or inserting 10,000 elements per update and can't be bothered to somehow batch those yourself, virtual DOM is probably a performance win. If the count is typically more like 1-10, it's probably overhead. In between, shit, I dunno, benchmark it.


There's some nuance. DOM mutations are still expensive if you interpolate reading and writing operations. The declarative paradigm allows frameworks to batch same-type operations to prevent double repaints. This is the upsell of virtual DOM vs jQuery, but it's not a benefit that is exclusive to virtual DOM.

Virtual DOM comes with a different set of trade-offs in terms of needles and haystacks. If you have lots of mutations relative to the size of the DOM, then virtual DOM overhead per mutation is relatively low. But if you're only updating a single element in a very large tree, then you are incurring a lot of overhead per mutation.

Another modern confounding factor to be aware of is that some browsers (notably Chrome) have made it so that mutations through the DOM API no longer cause a repaint to block the main thread (which is how every UI system ever should work, really). What this means is that any performance benchmark that uses JS APIs to measure UI responsiveness is going to be problematic (either by not measuring repaints correctly, or by adding a ton of confounding factors by shoving the macrotime queue of setTimeout/friends into the measurement)

Also, qualitatively, there's different levels of overhead. A repaint takes in the order of hundreds of milliseconds (i.e. it can be noticeably expensive). DOM API calls are also "expensive", but only in the order of a millisecond or so; you do want to touching the DOM unnecessarily if possible and virtual dom helps avoid silly mistakes like re-querying the DOM on every event like in the `$('.foo').on('mousemove', () => $('.bar'))` anti-pattern. Virtual DOM is "overhead" in the sense that allocating memory for a virtual DOM node is "expensive" (compared to not allocating any memory). But we're in microsecond-per-instance territory at this point. You need large haystacks with very small needles at high frequencies in a slow device to experience human-noticeable performance degradation from virtual DOM object allocation overhead.


>I seem to remember that when React was first introduced, DOM mutations _were_ very expensive.

Not really. Rendering was always a heavily optimized area. The DOM, by the way, is also an in-memory data-structure, and can also be clever on how it batches draw commands to the hardware (GPU or otherwise). I was always skeptical of the performance benefits of frameworks like React for that reason.

The big benefit of UI frameworks (React or Angular) is that it organizes your code into a defined, maintainable pattern. Traditionally JavaScript has been a mess of a programming language so with raw JS/HTML development it was easy to shoot yourself in the face and do the wrong thing.

>I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?

That's not true. There is an enormous amount of investment being poured into the entire HTML/JS/CSS stack.


See https://developer.chrome.com/blog/renderingng/ for some idea of the scale of investment being made.


> As a general claim, that is a bullshit claim.

How so? It improved on JQuery's performance ten-fold which was the "easy" way to webdev at the time.


> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day.

React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output.

Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least).

That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it.

I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist.

I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.


That is true, Svelte did not have a big benefit over React, so no need to change. And i use Svelte.

When you start or build a new product/team and can freely choose which Framework you want to use, you can have a look at Svelte.

For our company Svelte is easier to use, it has (in our opinion) less bloated code (e.g. state handling) in our app as React or Vue (which we used before). BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React.

That React has better active contributers is one big point for React. But it depends on Facebook.


> BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React.

Do you have an example?


>Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here.

That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.


>> That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

This is complete and utter nonsense. Were you programming seriously before React? There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems. As an incumbent it has staying power because there is benefit in sticking with the herd, it remains a pretty nice developer experience, and because it has essential features other frameworks don't really provide yet (React Native being the biggest one although I do realize other frameworks are working on this now too).

Svelt isn't popular because to disrupt a solid incumbent you need something that is dramatically better at solving problems devs actually care about (not corner case performance benchmarks when React is "good enough" 99% of the time). Svelt has failed to do that, plain and simple.

Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community, maybe is a clue as to why Svelt has failed to be sufficiently introspective in either accepting it is a niche framework (which maybe it is great for) or that it needs to change if it wants to be more mainstream.


>This is complete and utter nonsense. Were you programming seriously before React?

Indeed I was.

>There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems.

I'm not saying React isn't a good framework, it is perfectly nice, though I think you're overstating it. AngularJS was a perfectly fine framework as well, and that was out long before React.

>Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community

I'm not part of Svelt's community. I haven't actually used Svelt at all. I barely know about it. But I've been around for a while. Why certain frameworks go viral and others do not, is not always based on merit. I'll buy the argument that Svelt doesn't have enough of a benefit over React ... it also came out a few years later and doesn't have Facebook's marketing weight behind it either. Does that mean React is the best thing ever? Eh, it's alright. Having done everything from Flash/Flex/Starling, to Silverlight, to Backbone, to AngularJS, to React, I actually get more excited about State management patterns than widget overlays with some declarative patterns and data-biding. By the way, when it comes to ergonomics of building complex SPAs, I think we're just hitting the place that Flash/Flex was 15 years ago in Web Development.


I'm not sure I'd agree that when React took over, Angular was a perfectly fine framework. I mean, what happened with React was actually very unusual and remains very unusual. It took over. There is this popular and snarky notion that js devs are constantly chasing every shiny thing but that is exactly the opposite of what has happened over the last several years with React. Instead I'd argue that js devs were nomads prior to React because none of the existing solutions were solving the big problems they had. Not because they are ADD fad chasers. Also I don't remember seeing React "marketing" any more than any other framework. Of course when Google or FB or any other major player gets behind a framework, we take notice, but that doesn't have anything to do with why React took off. It won because frp in a FE framework with the Flux pattern was a total game changer and made FE development awesome for the first time ever (well since Flex, I'll take your word for it since that is even before my time (I cut my FE teeth on jquery and Dojo!))


When React first come out, the whole notion of mixing HTML and Javascript code was, if anything, widely rejected. Rather than going viral as a kind of fashionable thing, I feel that it really had to earn its position.


>When React first come out, the whole notion of mixing HTML and Javascript code was, if anything, widely rejected.

And it still is. Mixing JS and HTML/DOM does result in fragile code and you shouldn't do it. React VDOM and JSX is not the same thing .. at all. Again, JSX isn't new. XML-based declarative UI frameworks with data-biding were an old thing by the time React arrived on the scene. That's how Flash Flex (MXML) and Silverlight (XAML) worked, for example.


Angular was a hot mess and I found it a nightmare to program with.

It basically embodied the bad side of JS frameworks pre-React.

It managed to take alllll the wrong lessons from Flex.


Whichever framework has a prominent PR lead is "safe" to choose. If it's bad or breaks or whatever, it's not your fault, it's... I dunno, the hive-mind's, I guess. It's the "no-one ever got fired for buying IBM" factor. Whether it's actually any good or the best fit for the case it's been selected for, is very much secondary.


"at scale" here means # of contributors, not # of lines or scope of code base.

Svelte vs React on a single side project I work on in my free time by myself is different conversation than Svelte vs React on a team that's moving fast and has more than a single dev.


>"at scale" here means # of contributors, not # of lines or scope of code base.

I understood what you meant, I just disagree that this is a real consideration. Both are just UI frameworks following modern conventions in architecting your SPA code-base. From that point, both are just fine. Other considerations, like the fact that React is more popular and therefore more likely to be supported in the future, and therefore has more devs familiar with it, are way more important.


> performance of front end frameworks is near the bottom of my evaluation checklist

Sorry to pick on this point but depending on your application this should be more (or much more) important. Too many teams have this same opinion and it's glaringly obvious how little they care about performance. I'd agree that raw performance isn't really important, but the ways you can and the tools you have to optimize the performance of the app are if you find that you have bottlenecks is and this does partially depend on the framework.

That said, I would agree, all frameworks would probably be fast enough for most use cases, and even with the optimization aspect arguably the most important aspects are about application structure and how the framework forces you to structure your application. As you mention, I think this is why React wins, the way it forces you to think about things unidirectionally, think about state and components separately, etc. are all big wins for understanding your application.

Also worth noting is that Svelte doesn't really have a big company backing it like React does and so the ecosystem is smaller, which could contribute to its relatively small size.


Maybe I worded that incorrectly - yes performance is important. But the negligible gains between framework x and framework y are not high on my evaluation checklist, as long as the minimum performance requirement is met (which is often dictated by the product requirements).

I've been working in React for ~4 years now, at all types of scale. While I've definitely seen performance issues, it's never been a case of a flaw in the approach the React takes.

I guess a better way to phrase my point - until I encounter a scenario where the performance is bad enough in React to warrant looking at other frameworks, choosing a framework based on pure performance is an over-optimization.

Of course, this would be a different conversation if React was known for being the one and only bottleneck in web app performance - but afaik that is a rare case.


The scale argument is really just a chicken-and-egg thing. A few years ago, people were saying the same thing about how Vue wasn't "proven" at scale. But these days there are sizable teams using Vue just fine. The entire point of the components-first paradigm is that you can scale a UI fractally.

Large teams were using jQuery back in the day, with none of that HMR prettier-on-save Redux devtools fanciness. There's nothing inherently "unscalable" about the technology, especially now that most frameworks more or less use the same framework design paradigms.

> nothing about has convinced me to lead a project/team towards picking that over React,

This is just a cost of switching consideration. For better or for worse, first movers advantage is a thing. You're also not likely to switch from date-fns to dayjs or postgresql to mysql because you are invested into your choice of technologies, even though each pair might in theory be perfectly interchangeable.


> Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

One of the lead developers of Svelte uses it at the New York Times on some of their high traffic interactive data visualization pages, including their COVID charts.


I'd say that the NY Times is pretty good for "at scale".


Doesn’t the NYT do a lot of React too? From what I read in other comments Svelte was an experiment.

I think what people mean when they say “at scale” is they want to see a large codebase, with a large team working on it, where Svelte is the primary front-end choice.


The creator of Svelte (Rich Harris) works for the NYT. If you ask him, I'd venture to guess he wouldn't say it's an "experiment" as they regularly use it. I doubt his frontend work there is alone too, so I'd guess it's fairly in-use. But again, that's just my guess.


> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman”

The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.


That’s the weird part. I agree with you, but then at the end, they say the important part:

> It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development.

I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understands that virtual DOM is a means to an end. But then at the same time it is classified as a meme that only wins in performance against things nobody would ever do.

In a way, writing it like this makes it harder to critique.


Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed.

At the end of the day, I've never spoken to a developer who was using React because it was fast, but because it was easy to use and understand.


React’s changes over time have always been broadly compatible, and the same under the hood, just presented and manipulated a different way at the surface. Migrating to anything like Svelte would be a radical and extremely incompatible change on multiple fronts. It’s never, ever going to happen; the closest you’ll get will be another layer on top of React that embeds something like Svelte—such as https://github.com/Rich-Harris/react-svelte.

Svelte’s approach requires detailed knowledge of the structure of state, and requires compilation: components’ <script> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics, and some places where JavaScript is too flexible to be tractable get replaced with special template syntax (like {#each} instead of for-loops or Array.prototype.map). Svelte cannot be implemented as a JavaScript library (I disqualify eval()). Svelte is also deliberately severely limited in what it can express in various places, whereas React gives you the full power of JavaScript (for better and for worse).

You could perhaps implement an optimising compiler for a small subset of React components that avoid problematic patterns and are written in TypeScript with proper specifications of the types of state and props; but if you considered it unacceptable for this compiler to change the component’s semantics, I think you’d be surprised at how little serious React code in the wild could actually be supported. Even simple loops might be out of reach. The Svelte approach can’t be a progressive enhancement, it’s an all-or-nothing (at the component level).


> <script> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics

One could argue that React's hooks are the same: they look like JS but change JS semantics.

However, your point is still valid.


Nah, React hooks are still JavaScript—they’re library functionality, executed directly as JavaScript.


I was quite involved in the project around 2017-2018, and this is just what I feel, but I think the API is pretty much hardened at this point. Context was a disaster. Hooks are useful but more difficult to reason about compared to classes. They have said straight out that JIT optimizations don't work well when the main pattern was to heavily manipulate a singular state object, and that was a culture that I think they failed to change with Hooks.

If Facebook comes up with something else, I think it will be something new. Maybe that is Reason, or something that abuses WASM/Rust in the core architecture. Who knows. The project has a lot of tech debt, and the ecosystem has changed quite a bit as well.


Context and hooks both feel very much like "I'm being paid to work on this but it's basically done... so... guess I'll find something to do" additions. The latter especially.


Hooks are a big shift towards a more fine grained reactive programming in terms of API. However even vdom vs reactivity systems is not an obvious choice, since they have their tradeoffs. The same conflict is much more visible in vue. Thankfully, there are a lot of alternatives that explore this problem space


    It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.

    But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.


> No one actually really cares about it, and its not the reason why people use React.

This is probably true today, especially for newcomers, but the article is from 2018 and the context of the time period is significant here, I think.

Having used React since around 2015, there definitely was an aire of "React is fast because of the Virtual DOM!" and it was one of its big selling points early on. I can remember reading this article and nodding along, but reading it now evokes more of a sense of "I remember when VDOM mattered". I think around that time was maybe the tail end of VDOM being a big selling point, and this article might've even precipitated that, to a degree.

As React's usage has grown, I think the significance of VDOM as a feature has fallen by the wayside in favor of things like "everyone uses React so we use React too." The competition between frameworks at the moment seems less about performance and more about their approaches and tradeoffs.


> The part that I think the article misses

The article is about VDOM and nothing else. It does not "miss" the part about why react is popular, it simply does not discuss it.


Firstly, as the article emphasises, _diffing_ is far from the only issue with virtual DOM. And this isn't about microbenchmarks; plenty of people have run up against React's performance limits in real world applications and have had to spend time engaging in menial optimisation work as a result.

Secondly, you're dismissive of the idea that 'the virtual DOM is fast' is a meme (in the original Dawkinian sense; I'm not talking about gifs with Impact-typefaced captions), which suggests you haven't spent a lot of time around developers on places like Twitter and Stack Overflow. This misperception _absolutely_ exists, and this article was written to correct it, not to 'sell' Svelte.

Svelte isn't intent on 'taking over'. We're quite happy providing developers with an alternative to React that enables them to write less code and not have to worry about performance. That said, I'd argue the 'irrelevant' label is somewhat unfair (https://twitter.com/swyx/status/1409529125539254277, https://2020.stateofjs.com/en-US/technologies/front-end-fram...).


Svelte hasn't taken over because React is way too popular already. If you want a job you have to learn React (the same way Java is still one of the top lang to get a job but it's for legacy rather than technical reasons).

Svelte performance is a nice bonus but it is the last reason I prefer Svelte over React. I prefer Svelte because it is truly reactive (unlike React) which makes everything easier, cleaner & more readable.

Svelte is the only framework you can grasp in 10min by just looking at a few examples. To get started, you don't even have to read a tutorial or documentation, the code is self-explanatory.

React is a complex beast and, in my opinion, all this is an overkill / overengineered environment for expressing UIs.

I find Svelte to be the only framework that "make sense". Ultimately UI is not that complex, it's a store -> derived variables -> UI where each step is a reactive function of the previous one. A framework should let you express this very concisely and take care of everything else for you.

If x = y + z then I want to write x = y + z, end of the story. Like in a Excel sheet, just write the formulas and that's it. No useStates, hooks, componentShouldUpdate(), and other wierd stuff.

Svelte is to React what Pluto is to Jupyter Notebooks, less popular because of legacy, but, in my opinion, obviously more elegant & cleaner


I’m in agreement with you that the performance is only a part of why Svelte is so nice.

The state management in Svelte is fantastic.


>But, this is not how you sell something.

I feel that way about a lot of articles like this. I want to know what you do well, I don't want to hear someone complain about something else.

Sell me on what you do well and what that means for me.

I work in React a lot and I don't feel like I run into this “pure overhead” type concept in the way they describe it and thus this article makes me:

1. Wonder what they're doing in React that they feel this way.

2. The article quickly becomes much less relevant to whatever it is I'm thinking about.


> However, this article is overly focused on just one element of how React works.

Because that is the topic of the article.

It never even says "The virtual DOM overhead is a problem". It actually says exactly the opposite, it's often fast enough and not a problem. It didn't call Virtual DOM a meme, it called "the virtual DOM is fast" a meme.

Performance wise, as the article says, it is pure overhead. Virtual DOM is the solution to a problem the javascript frameworks create themselves.

I've had argue against managers that no, using a virtual DOM will not magically make our pure JS app run any faster. Especially once I put in the work to make the DOM as seldom accessed as I could.

There is a fantastic reason these JS frameworks work that way. Instead of building creating and update logic, you just need creation logic and always rebuild the widget. But that's super slow, so you use a virtual DOM to make it faster. Just not as fast as it would have been if you hadn't used the framework.

The tradeoff being that your code is often significantly simpler and easier to maintain. Though that also breaks down in some parts.


> If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning.

I think you're interpreting their messaging as "Svelte's compiled DOM is faster than virtual DOMs ergo Svelte is appropriate for every application" whereas the implication is certainly "Svlete's compiled DOM is faster than virtual DOMs ergo Svelte may be a good choice for applications that are constrained by virtual DOM". I don't think it's a reasoning failure, but rather a misunderstanding (an inadvertent straw man on your part).

> Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here

I think this makes a fair amount of sense. Often an incumbent needs to be quite a lot better in order to justify the learning curve, and I'm not sure that Svelte is. That said, I've been part of a lot of Python projects because Python's problems don't often manifest for new projects, but rather at scale (real workloads suffer from Python's poor performance, development velocity decreases at scale due to type annotations, package managers crawl as the dependency tree grows beyond the "toy" category, etc). I wonder if perhaps there's a similar effect in which React is "good enough" for new projects but not enough for

> The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.

I don't understand this claim. In order for it to be "strictly overhead" we have to assume that Svelte's compilation step has no benefit i.e., the output code doesn't reduce the JIT's workload but even more than that, the output code has no advantages (i.e., performance advantages) over React?

> I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion.

The way you sell a framework to programmers is largely by the backing of huge tech companies who use it in large, noteworthy projects. That's presumably not an option available to Svelte developers?


Svelte does two things very well: it's easy to integrate with other vanilla and not js technologies and opens up the space of your solutions. You don't have to have full buy in in it. You are not forced to do things how the framework want you to think about them. That's alone is a big win against React in my book, where you are not doing web dev, you are doing React dev, and sometimes that is way too constrained. That's is also a reason why Svelte is not irrelevant. It doesn't need to become React to be useful.


> The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.

Modern software commonly goes through multiple transformation (compilation stages) and it's increasingly common for some of them to be AOT, and some to be JIT, and neither AOT or JIT is overhead, even in combination. They have different pros/cons and in fact together you get the best of both worlds.

This doesn't negate your main point, but I wish you didn't end with an example of "irony" that actually is incorrect.


Performance is not a problem for the most developers, as long as the app runs smooth.

React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React.

React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code... thats what developers like, tinker all the day complex bloated code. Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more.

I rememnber the day when everybody was shouting, Redux is the best thing every ;) And now "hooks" Really?


> Performance is not a problem for the most developers, as long as the app runs smooth.

On their machines.

That's often a critical distinction. Developers often get the nicest computers, and they often get to have good, fast Internet connections that are close (in terms of Internet topology) to the server where the site is running. So they can't necessarily perceive the effects of the browser being starved for resources, or jank from the app being chatty over a high latency connection, or resources failing to load due to a spotty connection, or anything like that.

What some of these technical decisions add up to is situations like a family member who's using a cheap Chromebook and has flaky Comcast cable internet, bewilderedly asking me why this site they're trying to use keeps showing them a blank page or somesuch. They know that, if the page doesn't load at all, the browser usually gives them a, "We couldn't load that page. Try refreshing," error. What they don't get is that, if it's a React app and some JS resource fails to load, it'll stop the rendering of the site cold, and they'll just see a blank page, or a half-loaded page, or some other confusing state. And I've yet to figure out a way to explain things to them that gets them to see this as, "The Internet is being flaky." They see it as, "Your site is flaky."

They're not entirely wrong about that. The people who develop Internet and Web standards have put a lot of time trying to engineer the Web to tend toward failing gracefully. React (and frameworks like it) seems to have, in one stroke, undone all that and instead engineered things to tend toward failing catastrophically.

I don't know if you could get a JS-first framework that doesn't behave that way, so maybe it's a necessary evil? But, I get that React solves a real problem that some people have, so it'd sure be nice if it weren't.


Most devs using React work in development mode which is several times slower than production. I used to test with a chromebook and production builds were often faster than dev builds on my macbook.


> Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more.

You can keep telling yourself that React only took over because it makes things more complex and it came from Facebook, if that's what makes you happy.


No you can tinkle complex code, i did not say that anybody does it. It remembers me on WordPress, where many "pro" devs mixed nice complex unreadable code, that is only necessery, because they use WordPress. If they would use something else, they would not have complex code.


> Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second

And this, ladies and gentlemen, is how we ended up with web pages that lead modern mid- and even high-end personal computers grind to a halt.


I liked Svelte reactivity but the component props are unergonomic to use and TypeScript support is lacklustre


Care to expand on this? Component props seem quite straightforward where I stand and Typescript support has improved drastically over the preceding months


>However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning.

a more catastrophic failure of reasoning, that is far more prevalent, is not understanding that virtual DOM is overhead on top of the regular DOM, not some magic fairy dust invented by facebook geniuses that just makes the web better (tm) because you are a dev whose first exposure to web development was via a React tutorial where you built some <popular app> clone as it held your hand every step of the way, and now you are loosed into the jungle of problems in the wild ready to crush the spirits of those old tired jquery devs. bwahahahaha.


When we designed to UI library for FOAM in 2011 at Google, we did extensive benchmarking, and discovered that DOM calls were very slow and that we could greatly improve performance by batching them. Yes, in the end, you still need to make DOM calls to update the DOM, but you were better off forming all of your DOM's html on the JS side and then just make one call to element.innerHTML = myHTML and then hookup listeners if necessary. The JS to C++ bridge was very slow, and so you were better off to make one large call and then have C++ parse your HTML and build all of the DOM itself than you were to make many small DOM calls adding each element and attribute value individually. However, I was recently writing a document on the performance advantages of FOAM's virtual DOM, but rather than just assert the fact without proof, I wrote some benchmarks to demonstrate... that it is in fact no longer faster. As a result, we're replacing FOAM's UI library, called U2, with a new non-virtual DOM library called U3.


innerHTML has been slower than the DOM API for a few years. React had a big refactor at one point to rip out innerHTML logic precisely due to this. To make matters more interesting, the order of DOM API calls also mattered. In IE, building a DOM tree bottom up was significantly slower than building it top down (meaning, no large document fragments for you!). There are also a ton of other quirks: `.textContent = ''` being faster than removeChild, appendChild vs insertBefore vs replaceChild, childNodes random access, properties being faster than attributes (which is a rabbit hole of its own because SVG), cloneNode being faster but nigh unusable in a framework setting, orders of magnitude difference in performance due to data structure polymorphism...

Squeezing performance out of DOM manipulation is really tricky because the performance profile of pretty much everything changes frequently without rhyme or reason.


Not to travel too far off the main topic, but I use this exact fact to demonstrate to new developers why I prefer a developer that looks things up instead of relying on what "everyone knows". When Jeremy Keith's DOM Scripting book was written many years ago, it claimed that DOM methods were much slower than innerHtml. And that was true. If we all just took that as gospel, we'd be WAY off base.

So I'll take the dev that looks things up, as there's much more possibility they're operating on more up to date information.

Consequently, this is why I also tell people to stop repeating "this is a best practice" a year or so after something is discovered. It's a "common practice". You don't have enough info to know if it's truly "best".


In my personal experiments, I ended up using document fragments. I wasn't doing FRP, just classic MVC, but a view (which was a JavaScript object) had a reference to the DOM elements it was responsible for. If it needed to replace them, it created a document fragment, did anything that needed to be done in there (including having children redraw) and then swapped out that fragment. This gave very nice performance.


The most important part of Svelte, to me, is that it allows me to write web applications in the most elegant possible way. The compiler first approach means we get to choose whatever syntax we want to make the whole process as enjoyable as possible.

The most brilliant part of Svelte was the decision to stay as close to JavaScript as possible, so anyone who knows JS, HTML, and CSS knows svelte. Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue.

The unbeatable performance is just a plus for me. The DX is so good that building things is incredibly fun, intuitive, and headache free. I can’t emphasize enough how empowering it is.

It’s so exciting seeing the community grow exponentially lately!!


> The DX is so good that building things is incredibly fun, intuitive, and headache free. I can’t emphasize enough how empowering it is.

Yes! I've been a full-time React developer for about 5 years, and recently had the chance to try Svelte on a small pet project. I'd written most of the project in React and had a free weekend so I figured what the heck – let's see how it'd look in Svelte. :)

Within a day most of the functionality was in place, and the code just felt _beautiful_. I loved that it removed so much boilerplate (wrote some examples here[0]), and some of the React headaches (like using "Undo" in a controlled <textarea>) were just gone. The ergonomics (especially the built-in stores, error handling, and <svelte:head>) were lovely surprises!

I'm really bullish on it and so happy it's starting to grow.

[0]: https://mtm.dev/react-vs-svelte


Really helpful article. Thinking about diving into Svelte. I'm a huge fan of react-query[0] so I was wondering, is there a good alternative for it in Svelte? Would you recommend svelte-query[1]. Thanks.

[0]: https://react-query.tanstack.com/ [1]: https://github.com/SvelteStack/svelte-query


> Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue.

This makes me feel conflicted.

With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech.

With JS libraries it's the wild west once again and before you know it, your components will need 3 different mechanisms of being initialized, their internals will use different approaches, before long you'll have multiple versions of jQuery in there as well and it'll make you consider the downsides of that approach.

But maybe I only have that outlook because I've witnessed many such situations of poorly integrated JS libraries and have therefore gotten used to walled gardens.


> With React/Angular/Vue you're given a stable base upon which to build new components and logic

Oh you sweet summer child. Wait until you see the multilayered horror of devs insisting on styled components because they never spent the time to learn the specificity rules of CSS; their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves; suggesting that core concepts of the web are outdated because they came up in the Age of React.

React/Vue/Angular will not protect you from bloated, poorly written apps. I would argue they encourage bad practices.


> their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves

Yeah let's stop (re-)using open source software and write everything ourselves.

Who needs React when we can have cuddlecake's spontaenously written mini-framework (I lovingly call it anguvuesveact, because I got inspired) that definitely does not provide the required feature set or developer experience to support a productive professional development process, but it's mine.

Now that we have WebAssembly, couldn't we write applications in actual Assembly? It just takes confidence that we can build something lean with it, no other considerations necessary.

Well, uh, I just realized we don't need to rely on Firefox, if we just, uh, develop our own browser, uh, from first principles. A lean one, to be sure, only providing the features we need for our Web App. If we need new features we'll build them along the way.

Ah shit, my DIY lodash (I lovingly call it cuddledash, because I got inspired) has a bug but I'm focusing on the custom browser, so no time to fix that. :/

> React/Vue/Angular will not protect you from bloated, poorly written apps.

Only our self-written lodash lib will protect us, hear hear.


This is an extremely cringey, gatekeepy reply. It's just missing a "it's nothing personal, kiddo".

Good on you if you prefer writing everything from scratch. Some of us have shit to do and goals to meet and we'd rather spend our time on building actual functionality than reinvent the wheel for the nth time.


Your reply is the real cringe here. "I got shit to do" is no excuse to toss aside quality and craftsmanship. And you misread their argument they didn't say write everything from scratch, they said write a simple leaner version, but the argument is most people lack even basic problem solving skills. If you spend all your day glueing things together, you forget how to design and build them yourself. Sure you can stack the blocks in order, and make a really tall tower, but how soon until it falls over, or how will it withstand the first gust of air. That's the larger point. And this isn't "gatekeepy" this is reality. As software continues to eat the world, and most of us are forced increasingly to rely on these shitty apps and interfaces, it could do a little good to the world if Software engineering as a discipline took on a little more professionalism. So less of the "I got shit to do" and "move fast and break things" mentality, and more of the "lets do this right" mentality. Good engineers can write a little utility that solves a problem wonderfully for their context or scope, and still get their shit done and meet their goals.


It's kind of gatekeepy insisting on styled components being of lower quality than using pure CSS. Styled Components serves a specialized purpose of styling things on the web.

Maybe less elegant or performant in some respect than pure CSS, but with trade offs that some development teams will happily take.

I also hate the sentiment, that software development needs to adhere to some notion of purity or divine elegance. And yes, I'm using the word divine because people like the grandparent comment keep acting like CSS is the church. It may well be, for some, but there's a reason why CSS is getting new features continuously... Because it's not perfect for every purpose across every development department.

Talking about this makes me sick.


Use styled components if they suit your use case, by all means.

But if that use case is We don't have to learn CSS because we can just not think about it with this nifty innovation then the use case is horrific.


Eh, I'd say it's a valid use case as any.

Maybe someone just didn't have the time confidence or interest to learn CSS. Maybe it's as simple as doing what you want, doing what you can afford to do, etc.

What I don't like is the negative framing of this choice. Bad things will be built, regardless of the underlying tools. Grandparent claimed that using Frameworks results in bad practices. I claim that shaming people and questioning their choices (whether they made them consciously or unconsciously) is a bad practice.


I dunno. Maybe. How about the practice of removing a test that fails? Literally, test fails, remove it, problem solved. Ship it. Sure there are build warnings, but CI isn't complaining, so..? Is that a valid use case? If your team member did that, you'd be cool-and-the-gang, easy-like-sunday-morning, shaming-is-the-real-shame?


You're trying to reframe my argument in a bad way.

I'm talking about people deciding to use a certain technology with tradeoffs.

You're talking about people going against quality standards of a development team. And that's where I end the conversation, you bore me.


Not trying to reframe anything. Just trying to understand the bounds of your ease with team members making these decisions.

I haven't been hostile to you or anyone who disagrees with me, by the way. Just trying to understand if and where I'm incorrect.

Furthermore, I said what I said in reaction to someone disliking the idea of Svelte being able to use any javascript library at all because of the chaos and bad practice that represents.

> You're talking about people going against quality standards of a development team.

That's what I've been taking about this whole time


I hear you. It's a balance. You grab a library or open-source project, boom! Done. Move on dot org.

Except later, maybe your project needs some custom functionality. Now you have to dig into docs to see if it's possible, then deeper into the source code to see if you can monkey patch using something undocumented. Maybe now it takes more time to cobble together what you need than wiring something lean from first principles. Understood the full import of the dependency from get.


The purpose of styled components (or CSS modules or what have you) isn't to deal with specificity. It's to deal with collisions between what are essentially global variables.


I don't think you and I disagree. Use the tool appropriate for the job. If the team doesn't have the discipline or will to use the cascade as intended, definitely, better to have a bloated CSS-in-JS that at least is usable, rather than a bloated cascade that people are afraid to use.


I agree 100%.

The number of times someone told me they prefer using Bootstrap classnames while using CSS when they bootstrap does not provide a classname for it... My front-end heart sinks!


Gah, at least it's not Salesforce. That year I spent in a Salesforce shop I earned gobs of money and nearly slit my wrists. I took the following year off. Learned to play ukulele. What a shitty platform. God bless the devs who thrive in it.


Looking at the future (sadly?). Most web apps are just shitty compilers that should be largely Metadata driven.


This is certainly not my experience. I’ve never had to touch a library with jQuery, and the vast majority of libraries with framework wrappers also have vanilla implementations. The difference being the wrappers need to be updated to keep up with the frameworks, and often have more ways to fail considering they’re often just vanilla libraries + wrapper code.

If a library is maintained, the existence of a framework wrapper doesn’t make it any more reliable in my experience.


The web stack, from tunneling thru HTTP to the JavaScript language itself, is a very interesting case study.

I think that many decisions, like creating a virtual DOM, make a lot of sense in isolation. But, if you look at the complete ecosystem, no sane human being would have ever designed anything like that.

Maybe, the Virtual DOM is pure overhead if you look at the complete system, but:

1. It was reasonable at the time 2. Some other patch to the Web Ecosystem will fix this

The more systems are interconnected, the more difficult is to change anything radically and only incremental changes are possible.


What's interesting to me, as someone who is currently learning Web development mid-career, is that I can see that vanilla JS is actually a really good option nowadays, but not necessarily available to anyone who's more established. Because it doesn't seem to have gotten good until fairly recently, and, for the most part, everyone had already made the important technical decisions before that happened.

So, even if it's not necessary now, there's not necessarily any escape. The problem with complex tech stacks is that, for a variety of technical and social reasons, it's much easier to add to them than it is to take away. You can't necessarily incrementally roll back any of the bits of an existing React-based site; such an effort is liable to spiral into a complete rewrite. It's relatively easy, though, to incrementally add new things in order to paper over whatever's bugging you at the moment.

The social story is similar. Coming from a position of knowing very little, the effort for me to learn the vanilla JS way of doing things is roughly similar to the effort to learn the React way of doing things. But, if I were already invested in the React ecosystem, that wouldn't be the case. I wouldn't just have to learn new tooling, I'd also have to re-learn my entire way of thinking about how to architect a webpage. Realistically, you can't, all else being equal, justify a radical re-tooling in order to achieve an incremental benefit like that.


Pedantry time: there is no such thing as a vanilla JS way of building web applications, in the same way there is no vanilla C way of writing compilers. JavaScript as a language does not concern itself with web browsers - that's the responsibility of the DOM API. But even ignoring that, there is no standardized or widely adopted way to build interactive web applications without frameworks.


I'm new here, so maybe I'm misunderstanding some Web developer jargon? I had assumed that, when someone says "vanilla JS" in a web development context, it was understood to mean, "the core language plus the standard browser APIs."

"Vanilla C" maybe isn't a perfect analogy because the language and standard library are both covered by the same spec. But I suppose I would argue that it means, "Just C and its standard library, not including, for example, glibc extras." I don't know what a C equivalent to React would be. Maybe a better analogy would be "Vanilla Java", with the intent being to imply that you aren't using Spring?


You are correct. "Vanilla JS" is typically compared to React/Vue as a joke. As in "React.js is 2kb but Vanilla.js is 0kb and super lightweight".

"Vanilla C" doesn't have the same context as far as I'm aware. In the same spirit I could imagine a comparison for C would be along the lines of "you could use SDL (Simple DirectMedia Library) for your indie game dev, but why bother when you could use vanilla C (code Vulkan 3D graphics API directly)".


True, except for the fact Javascript would have no reason to exist without a web browser. Do you remember when Netscape 2.0 was released? That's when Javascript was born. Its primary use cases were form validation and image preloading.


Vanilla JS gets messy as your app scales. You will end up building a framework.


You've betrayed your bias in your choice of words, though: "app." And, for that matter, choosing the word "as" instead of "if."

I'm not personally building apps, and I'm certainly not building things that need to be single-page apps. I'm building websites. They may be dynamic, they may include interactive elements on the page, but they're still mostly just plain old websites with limited state to manage. Which is fine by me. I suspect, that, were it not for those social constraints I described up above, that would be fine for most websites.

One of the other problems with complexity is that it's addictive. You get a taste of it in a situation where you actually need it, and next thing you know you're afraid to go anywhere without it, because you're worried (or is it hopeful?) that you might need it again.


There is a gaping chasm between a website that needs some Vanilla JS and light interactivity, to the point where a framework like React is a necessity though. Like if all you're using React for is to pop open a side menu or render some lists, you've taken on a boatload of tooling overhead for pretty minimal gain. Performance isn't going to be the problem there, the issue is having to maintain a relatively cumbersome tooling ecosystem for the site. That's not a contrived example either, I've seen plenty of that going on.


At my job, we have a desktop app that uses HTTP and WebSockets. We compile it into WASM for the browser. My side project is a single page app. My personal website static HTML and CSS, with almost no JavaScript at all.

I think that the independence of various parts of the web stack is actually a strength, not a weakness. Because you don't need the complete ecosystem — you can pick and choose which parts to use, mostly without compromise.


While this may have been true previously, React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames, to achieve perceptual improvements over synchronous DOM updates. Svelte’s AOT compilation approach, I believe, is limited in these kinds of time-spanning deferrals, though I’d love to be proven wrong! https://reactjs.org/docs/concurrent-mode-intro.html


> React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames

That's just cheating though, isn't it? And not in a good way. If you smear your DOM update over consecutive frames, you can maybe cram in 2-4x more operations in there before the user starts noticing. Past this point, a smeared update starts having design implications - things that should happen simultaneously now happen sequentially. Not to mention, application starts to feel heavy.


The only reason you need that in the first place is because of how expensive updates in react are. It’s lack of true reactivity and user-controlled memoization lead to a ton of trashing.

Svelte on the other hand is as optimized as possible - update the data, modify the corresponding DOM pieces directly. There is no realistic use case where you’d need to spread an update over multiple frames.


React's concurrent mode doesn't split DOM updates across animation frames because that would cause visual tearing. It splits all the component "overhead" and the virtual DOM cost over multiple tasks though.


Man I've been waiting for this for so long.


I've commented on Svelte before [0]. Adding the same comment here -

>> I've worked on multiple modern JS frameworks and Svelte is the closest I can get to mapping my mental model of how a web page works (HTML, CSS, JS) with the framework.

Actually, I should correct myself - yes, the breakdown in terms of technology is HTML, CSS, JS but the underlying abstraction is actually - structure, presentation and functionality.

This is where, imho, Svelte really shines. It helps you to map your mental model of structure, presentation and functionality to it's corresponding implementation of HTML, CSS, JS with a sprinkle of syntactic sugar. This goes way far in keeping the code easy to understand and maintainable in my opinion.

[0]: https://news.ycombinator.com/item?id=26723214


Time and again it has been proven that the number one metric for success of a language or framework is developer experience.

Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being.

React has become that for frontend development. React is easier to use than Svelte. I got excited when I first learned of it, but its awkward to use at times and far more quirky than React.

As others have pointed out, that bleeding edge performance is only as great as what you are building. If you don't need to update the DOM multiple times a second, then it barely matters.


Where do you find React easier to use than Svelte? I did mostly backend and simple pure-JS frontends before and never picked up react because of how long the tutorial was and how messy the tooling felt. Svelte was a breeze in both of this and I didn't experience larger issues yet, so I'm curious what I'm missing out on?


I'd argue that Svelte is easier for beginners or simple stuffs, the tutorial is miles better than react's.

But of course, for complex stuffs, react's bigger community becomes to the rescue with many edge-cases solutions


> Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being.

JavaScript is the wrong example. It didn't succeed on merit, but because it was the sole language available for the web platform for the entire history of the web until recently and even now it enjoys significant "unfair" advantages (browsers only expose DOM APIs to JavaScript, the JS standard library is baked into the browser while other languages must ship their own over the network, etc).


While never widely adopted, VBScript was able to be ran in script tags in Internet Explorer.


I fully believe that JS is better than VBScript, but it's also possible that many other factors contributed to JS's triumph over VBScript. In whichever case, this is pretty weak evidence for the claim "JS won its popularity relative to other languages by merit" (presumably you weren't intending it to be strong evidence).


I was only commenting on the claim that JavaScript was the "sole language available for the web platform".


Fair enough, thanks for clarifying. :)


> but it was easy to use

I disagree. I've found Javascript to be quite complicated.

However, I agree with your takes that:

1. It's highly accessible - yes, you can learn a single language and get away with only knowing that language for a good chunk of your career nowadays.

2. It does involve fairly immediate feedback (somewhat akin to Python in that regard), because it's interpreted. Given that it's also visual, and a strong majority of people equate the internet to solely what you see in a browser, it's a pretty gratifying experience (even if, later in your career, you avoid it like the plague).


I think it's ubiquitousness, not developer experience, but perhaps that's what you meant. Both PHP and Javascript are examples of that. PHP wasn't nicer to use than other languages, it was just available to everyone. They're also both unencumbered by the aspirations of software engineering. The language doesn't care that you're writing untyped, procedural spaghetti code, they're very forgiving and so are the community and ecosystem.


That’s surprising, because the overwhelming consensus among anyone I’ve spoken to with significant experience in both seems to emphasize the vastly improved DX of Svelte over its predecessors. State management is trivial, and the amount of code needed to accomplish anything is significantly less in Svelte.

I’m curious- how much experience do you have with Svelte and what in particular do you find it makes more difficult or convoluted than React?


This blog says what I've always thought - that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code - not just DOM calls. If your pure JS code already is designed to eliminate redundant calls, then you already get the minimal DOM calls from JavaScript too. That's the best case, and VDOM can only be slower as it adds diffing overhead on top.

There might be other good reasons to use a VDOM (including cases like using the DOM in a web worker). But I don't think performance is one of them.


that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code

That will still only result in a performant, smooth 60fps application if you can do all the calls and ops that aren't redundant in less than 11ms (16.6ms per frame, but the browser needs about 5ms to update the screen). If you're trying to do more than you can calculate in 11ms then you have to start spreading things over multiple frames hopefully doing what's most important first. This is pretty much what React's concurrent rendering claims if can do for you. If it works well it really will make applications feel significantly better. As far as I know Svelte doesn't have a solution for that. It just hopes you can get everything done in that 11ms.

To be fair, 11ms is quite a lot of time on a modern computer, so unless you're doing some heavy calculation work that you can't move off the main thread to a worker you should be fine.


> you need to eliminate all redundant calls and operations

this is a no-brainer, right? The tricky part is how you identify redundant calls and eliminate them, knowing that some have more cost than others.


I've never really bought into this.

The diffing is mostly an implementation deatil that is abstracted away. React could check to see if props.items changed instead of the nonsense it does. If it still does that in 2021.

The thing is vue uses getters and setters that would trigger direct changes without needing to diff the entire tree. It could theoretically be really fast, but it still used a virtual dom, and it was around react speeds, give or take.

I am convinced that if react really wanted to, they could make optimizations to make it really close to svelte. I remember seeing a tweet by Evan You about vue3 being pretty much as fast svelte if not slightly faster.

The point is that speed, when it comes to front-end frameworks, is a weird thing. There are other factors that are much more important like tooling, stability, code style, dealing with animations, etc.

Things like svelte's compiler approach are much more interesting and unique selling points.


> I am convinced that if react really wanted to, they could make optimizations to make it really close to svelte

Facebook has been working for a while on Ahead-Of-Time compilation for React. Interestingly, it looks like they thought the problem was too complicated and they gave up:

> To address this challenge we initially experimented with one approach to ahead-of-time (AOT) optimization — Prepack — but ultimately that direction did not pan out. Specifically, we realized that many AOT optimizations don’t work because they either don’t have enough global knowledge or they have too little. For example, a component might be static in practice because it always receive a constant string from its parent, but the compiler can’t see that far and thinks the component is dynamic. Even when we could make optimizations work, we found that they were unpredictable to the developer. Without predictability it was hard for developers to rely on them.

Instead they're now experimenting with moving the virtual DOM resolution to the server and avoiding sending all the "templating" code to the client, which achieves a similar result. See https://reactjs.org/blog/2020/12/21/data-fetching-with-react....


The blog ends with

> But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.

Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?


There's a better explanation of the differences here: https://svelte.dev/blog/svelte-3-rethinking-reactivity

  Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like that eat into your frame budget and tax the garbage collector.

  Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.


Isn't this very similar to Angular's Ivy compiler?


They briefly touched on what makes Svelte different but for some reason didn’t highlight it as the main takeaway.

When Svelte builds your app, it’s fully aware of what components will need to update when data changes, and so it can wire up those precise dependencies statically. Then when data changes at runtime, instead of needing to diff the new state against the old state, components are updated in the way that was prescribed at build time, which is maximally efficient (as long as Svelte’s compiler is reasonably smart).


Svelte is:

- smaller (because Svelte doesn't include Svelte in the binaries it outputs, but rather a dynamically generated static mapping between data and elements)

- better organised (single function components, with the JS, HTML and CSS in a single file) - like Vue!

- simpler (name = 'Joe' instead of const [getName, setName] = useState(null); setName('joe')). The last one isn't quite true as you can't use this in all circumstances - fruits.push('pear') won't update fruits, you have to run 'fruits = fruits' afterward to trigger the update (there are other ways too).


It compiles the code into vanilla JS that directly updates the DOM on state changes.


Yes, I too was hooked but disappointed there was no link to a follow-up article!


For 95% of apps, Svelte's custom syntax is pure cognitive overhead making little difference to the performance of the app.


For me, trying to make sense of how React's reconciler matches hook invocations to component instances is pure cognitive overhead. Other people don't seem to have this problem. But trying to accomplish anything in React is arduous for me, particularly with function components and hooks. Class components seem a little more obvious.


And for me, both are unnecessary overcomplicated abstractions over mithril+js based classical MVC (not web-renamed one):

  class App {
    constructor() {
      this.message = 'Hello'
      this.foo = new Foo
      this.show_foo = true
    }
    bye() {
      this.message = 'Bye'
      this.show_foo = false
    }
  }

  class AppView {
    view({attrs:{app}}) {
      const attrs = {
        onclick: (e) => app.bye(),
      }
      return m('div.container', [
        m('h1', attrs, 'Hello!'),
        (app.show_foo
          ? m(FooView, {foo:app.foo}),
          : null),
        this.render_footer(app),
      ])
    }
    render_footer(app) {
      return m(…)
    }
  }

  window.app = new App

  m.mount(document.all.root, {
    view: () => m(AppView, {app}))
  })


Is it possible to just not think about it? Or is that easier said than done?


Usually it just works. But, even following the "Rules of Hooks" (https://reactjs.org/docs/hooks-rules.html), I managed to write some code where the state that belonged to one component ended up in its adjacent sibling. When that happened, I really wasn't sure what to do other than go on a deep react dive. It's not clear how to debug stuff like that.

I came to realize that I had confused the reconciler. The fix is basically to just use the key= attribute everywhere, not just in arrays.


How did this happen? I've never seen this in practice if you weren't doing something "obviously" wrong.


Here's a minimal-ish repro of the issue I ran in to. It's totally possible that I'm doing something "obviously" wrong. However, I've spent more than a couple of hours reading through docs trying to figure out what it is. I'm not seeing it.

https://codepen.io/recursive/pen/XWMLWBZ

If you could point to anything in the docs that I'm missing, I'd genuinely appreciate it.


I assume the issue here is that you are rendering a single nameInput instance in two places.

This is definitely not idiomatic react and I can't ever think of seeing this in the wild. Just render two instances. If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop.


> If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop.

This is the kind of stuff that's difficult for me to wrap my mind around. If I have to remember to "do it this way, but not that way", that's mental overhead. Especially when it's difficult to articulate exactly under what circumstances this problem occurs.

Obviously, there are plenty of people that have no problem with it. However, my first inclinations seem to be more likely to be those that React has problems with. I'm having a difficult time "thinking in React".


I'm not sure this is anything specific to react? Its just a question of internal vs external state. Internal state gets managed by the component itself, external state gets managed by some ancestor in the tree. One component's internal state is another's external state. No different to objects or any other data modelling exercise imo.

As for rendering a single instance in two places, you'd see weird behaviour trying to do the same with raw DOM element instance (well not so weird as not being able to render in two places).


Everything you say is true for pretty much every technology?


No. Some technologies use paradigms that are much more natural to me. Of course, this will vary from person to person. I'm not saying that anyone should stop using react. I'm just saying that I find it to be difficult. Specifically more difficult than other technologies.


Been working with React since 2014. That is the damndest thing ever, especially that it doesn't even throw a warning.

It seems like an identity confusion issue where the VDOM diff is ambiguous, and React resolves it in the "wrong" way. Adding keys to each `LabeledInput` resolves the issue, but I'm surprised that the runtime doesn't complain when you create the inputs without keys.

I wonder if this is why the checkbox that's checked moves, but stays in the same relative position (the second checkbox in the list): https://medium.com/@ryardley/react-hooks-not-magic-just-arra... or if it's just the ambiguous VDOM diff causing that.


If you render the inputs via a list, like

    const inputs = isBob ? [name, confirmation, request] : [name, request]
then it complains that there's no key prop and the issue persists. This shows it's because of confused identity. In the example, it doesn't complain because it doesn't understand that {name}{confirmation}{request} is essentially an unrolled loop.


    {name}{confirmation}{request}
is basically a hidden render loop. If you had something like

    const inputs = [name, confirmation, request]
and rendered that via inputs.map() (or just {inputs}), it would have complained about the missing key prop. React can't seem identify which state belongs to which item in the "iteration".

Using a conditional render like

   {nameInput}
   {isBob ? confirmationInput : null}
   {requestInput}
seems to avoid the issue as well, without using a key prop. So yeah, beware of hidden loops.


Yea, I was startled by the issue at first, but once I checked it in more detail it took me like 5min to figure out what was going on.

I'll grant the particular example or edge case is not available in the public docs, but it's extremely easy to intuit what is happening and relate it to the requirement of list components needing keys.

Like I replied to OP, you would be in all likelihood using arrays anyway, instead of this contrived pattern.


I’ve been coding in React for a few years and I’ve never seen anything like this. Bookmarking this so I can take a look tomorrow and also in case someone provides an answer.


I seem to have a talent for coming up with things that shouldn't be, can't be, or are difficult to express in react. Note that I'm not particularly interested in other ways of writing this that would work. I now know several. I'm more interested in simple general rules that one could follow to stay out of trouble.


> I'm more interested in simple general rules that one could follow to stay out of trouble.

I don't know what to tell you, just don't do this?

I've been working professionally for years in React and have never encountered this particular issue. Once I've gotten to to it this morning with fresh eyes it's taken me like 5min to understand - React sees this as a list of the same element, which requires keys - this on the other hand is extremely common and well documented, so even a junior could intuit it.

This is a contrived example and as a moderately experienced developer you would almost certainly reach for the idiom, which would be rendering the input as a list with a map, in which case you would see clearly what's going on, get a warning, and a clear mapping to the official docs [1]

As far as footguns go, I think this is a weak and contrived example. I get why one would not want to work with React - maybe they don't like JSX, or the lack of baked-in state management, that there are a million ways to do the same thing, the general philosophy of the framework, etc.

But I've worked with many other technologies on the front and the back end and not only have I seen infinitely worse than this, I can't think of a technology where if you try really hard to break it, you won't find ways to do so.

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


Thanks for your thoughts.

I eventually did figure out what's going on. I did figure out that using key= solves it. I also found I could use class components and make the three labeled instances in the constructor. That gives them a long enough lifetime to stay consistent also.

I'm not trying to tell anyone else they shouldn't use react. It's great that so many find it to be so productive.

You might say I dislike the general philosophy of react. I would rather choose whether I'm using 1-way or 2-way binding than being told. I actually have come around on JSX. I think it's pretty good now.

As for being weak and contrived, I don't know what to tell you. This honestly seems like a natural way to write this. I'm a react beginner. When I ran into this, it took me some time to figure it out, but I did eventually. I suppose another part of the philosophy I don't like is entire premise of virtual DOM and reconciliation. It creates another layer of concerns the developer needs to think about. This kind of stuff should be an implementation detail. Instead, you have to remember to use an array rather than unrolling. Or just use keys everywhere. More precisely, maybe you don't need to. But I would need to.


Yes, it's completely possible and most people don't think about it, at all. It's not complicated.


I think it's perfectly possible if you just don't place hooks in a loop or if, which you shouldn't do and are warned against.


Svelte is quite small, you can be effective with it in a weekend.


This, that's why React was a bit revolutionary at its time. No customized template dsl. Just speak JS.


Writing HTML programmatically or using JSX are both unfortunate React-isms.

Not saying that Angular's banana box is ideologically superior, just that all JS frameworks have idiosyncrasies.


Honest question, why? The problem one always runs into in client side apps is you need various features like conditionals and looping when rendering your HTML. This has lead to a proliforation of templating languages that half-assedly implement these features. Moving to using a full programming language for generating your HTML removes the need for janky inconsistant templating languages.


Browsers support HTML and JS (and a few other things not relevant to this point).

Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions.

If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything that currently exists and does what you're describing.


Natively no, but writing some JS code that will take an array of objects and turn it into a DocumentFragment is a trivial exercise. And once you're representing your HTML as data, looping and data binding are trivial.


You're right. But how often do you want to rewrite that code? It may be worth accepting a few -isms (and the associated performance hit) in order to be able to write something like this instead of having to bang out the imperative version:

<BulletedList [(DataSource)]="MyCollectionProperty" />


What are you talking about? That's the exactly the purpose of jsx - manipulate html with straightforward javascript. and jsx is just a wrapper for React.createElement().


JSX isn't HTML. Is it truly less cognitive burden to have a language that looks like HTML but isn't? With properties changed because they're reserved words? And with control statements from other languages supported inline?

If someone gave me a language that looks like Lisp but with car and cdr renamed to something else, is that really making my life easier?


What cognitive problem do you have? It's just syntax sugar to let you easily manipulate the dom tree. Generating dom nodes and intertwined logic becomes trivial when you have jsx. If u want a list u can do dataList.map(data -> SomeComponent); or do ifTrue ? Component1 : Component2; or even use a function to return conditionally with a switch.

JSX is not HTML because it need to blend logic and HTML seamlessly. React is not static site builder, it's an app builder. If your project doesn't need this sure go ahead. Otherwise are there much better choices?


I find JSX is only straightforward for the simple cases. Often you wind up with unreadable, convoluted garbage because someone was trying to be clever with too many ternary operators, etc.


If you can refactor JSX with simpler js code then you should do that. It's just js expression. If u find reading js expression is harder than all those custom operators in other template languages, you can always switch.


JSX is exactly a customized template DSL. It's not a particularly difficult one, but that's exactly what it is.


> JSX is exactly a customized template DSL.

Yes, but its a template DSL for JavaScript (and TSX is one for TypeScript), not a template DSL for HTML.

Building JSX outputs JS, not HTML.


Yes, that's true. I don't see why it's significant though. There doesn't seem to be any inherent reason why an HTML-hosted DSL is more difficult to learn or use.


What custom syntax? You don’t even need to use it, but 100% of the time I do, the custom syntax implementation is vastly simpler than any alternative. I would love an example that contradicts my experience.


I'm curious to better understand what you mean by this (maybe an example or two?).


Svelte is so 2020, the new hotness is SolidJS. https://dev.to/ryansolid/solidjs-official-release-the-long-r...


Honestly, SolidJS is one of the most exciting options on the horizon. The creator wrote the vanillajs implementation for the frontend framework benchmarks so he really knows a lot about the performance implications of implementation details. The great thing about Solid is that it's a lot closer to react with hooks and jsx (I feel like Svelte is learning too much non-js stuff). The problem is that it also has its gotchas. It's much "smarter" than react about re-rendering, which means that it memoizes nodes all over the place and doesn't rerender the entire tree and diff all the time. Instead, it's only rerendering the node that changed (and not even the children of that node unless you set up the children correctly—gotcha). But look at the benchmarks... it's solid!

I asked Rich Harris (author of Svelte) this: https://twitter.com/jamescuenod/status/1326747369480871941?s...

Ryan Carniato (author of Solid) makes some comparisons to Svelte here: https://dev.to/ryansolid/5-ways-solidjs-differs-from-other-j... and also here: https://github.com/solidjs/solid/blob/809fd5b8683e6f8c338961...


This prompt to check on current Svelte and Solid-js alternatives, resulted in new posts on Marko[1], and OT, on Mini Apps.[2] Thanks! :)

EDIT: Hmm, a few minutes later, the Marko post is blank, or not, depending on whether I'm logged it. That's... unexpected. Maybe a rate limit? The working url is https://dev.to/ryansolid/what-has-the-marko-team-been-doing-... . Too late to delete the post to leave the url clear for someone else to post. :/

[1] https://news.ycombinator.com/item?id=27676785 What Has the Marko Team Been Doing All These Years? Jun14 By Ryan Carniato of Solid, now on ebay's Marko. The interesting discussion at the end (including why Marko didn't catch on) turned up: [2] https://news.ycombinator.com/item?id=27676743 Mini apps: A web developer's exploration into mini apps — apps that are built with web technologies but that do not run in browsers.


SvelteKit is 2021 though :)


Any good comparison between Svelte and Solid.Js?


Maybe this is a dumb question from a JS muggle, but the thing that kills me about this whole movement to virtual/shadow DOM is that it's made the "ctrl+f" search useless on more and more websites. Is there a nice way to hook the search function to actually look inside elements that haven't been swapped in yet? If so, more people should be using it.


Virtual DOM is completely different from Shadow DOM. Shadow DOM is an isolated DOM of a web component, separate from the global DOM.


Never had this problem really (doesn't mean that it doesn not exist). Is shadow DOM a thing outside of SVGs? For sure it's not used by React, Vue etc. MDN is telling me that the upcoming Web component spec uses it though, so maybe libraries like LitElement use it too?

Sites using React or Vue all seem to be searchable using standard CTRL-F for me.


I suspect this is a reference to the specific feature infinite/virtual scroll. The DOM nodes are only materialized when you scroll near them. CTRL-F is not able to find text that isn't currently in the DOM. If you scroll it into view, it suddenly starts working.


That's a very far stretch from purely the topic "Virtual DOM" though, no matter how few JS knowledge. I hate Infinite Scroll with a passion. FWIW Infinite Scroll can be and is often implemented as a jQuery plugin.


I’ve experienced this (Reddit comes to mind) but I’m pretty sure it’s because it aggressively mounts/dismounts things on/from the real DOM.

In other words it virtualizes views (like when you have a 1000 row table and you only render rows 40-50), but this is not the same as DOM virtualization.


I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the direction things are going?


You might want to take a look at the HAT stack:

https://htmx.org - server interactions in HTML

https://alpinejs.dev - small front end tweaks in your HTML

https://tailwindcss.com - styling in your HTML

This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free.

full disclosure: I am the author of htmx

[1] - https://htmx.org/essays/locality-of-behaviour/


My impression of reading [1] is that its just moving the "spooky action at a distance" to a different place.

If I see this:

<button hx-get="/clicked">Click Me</button>

My immediate question is

* What actually executes when I click the button?

* How can I debug the code that sends the GET request?

* How can I customize the GET request and add stuff like custom headers?

In the jQuery example all of that is obvious on first glance.

I feel like complexity can't be destroyed, only moved around.


Do you feel that way when you see an href on a link? Do you feel the need to debug that? If so, how do you do it?

There is an hx-headers attribute to modify headers, or you can plug into the events system if need be.

htmx is extending HTML as a hypermedia and, therefore, is a very different model than most javascript-based apps today.

I am not sure if complexity can be destroyed (I'd need to have a solid definition of complexity to discuss that) but it can certainly be managed in different ways, some of which are more effective than others for certain problems. We don't do web programming in assembly for a reason.


> This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free.

Not to be "that" guy but what you're describing is a .vue file. And with a Vue single file component you have 1 dependency: Vue. With HAT you have 3. Or am I missing something?


HTMX has been on my radar for a little while.

Do you have a starter template with all of these hooked together? Or an example repo?


There are example projects in a bunch of different back ends available here:

https://htmx.org/server-examples/


Yes and no.

Browser differences are mostly disappearing, they have gained some very good APIs are CSS has gained significant layout capabilities with grids and flex. So the need for libraries like jQuery for dealing with DOM differences is disappearing. New standard libraries like Intl and now Temporal make libraries like Moment obsolete.

The web is also gaining a component model with Web Components that will help you get some level of sanity when building some mildly complex reusable stuff. This is probably very good for content heavy sites, which make the majority of the web.

The other part of the web is applications running on top of the Web platform. Those still heavily benefit from frameworks. Having some amount of sanity when managing state is very much welcome. And functional programming models have proven that a declarative way of approaching UIs is much better than dealing with browser APIs imperatively.

So for some years frameworks will still be useful for certain use cases. For the others, we should be embracing Web technologies. Maybe with some light libraries like Stencil and Catalyst.


I used React for 3 years and I'm using Angular for 2 years now; Angular is super heavy handed and gets in your way


I have professional experience in Angular and it is simply a framework for building applications. It hits that out of the park.

I genuinely tried React and had to ditch it. Way too much drama just to manage state. It is clearly for building components, not applications.

I don't think comparing the two is relevant. Angular gets in your way if you are just building components but it unleashes a deluge of productivity instantly if you need to build an application--especially for a team.


To me scaling this Angular codebase has been more challenging than it was to scale React codebases for collaboration across multiple projects and teams. Going through NgModule instead of using plain node packages is my main gripe here; coincidentally this is also what gets in your way if you're trying to build reusable dumb components in Angular

I almost like ngrx because it reduces boilerplate, but I don't understand why their createAction helper doesn't follow Flux Standard Action; I can't be convinced this isn't a design flaw


I spent part of last Saturday going through the Svelte tutorial, and I really liked the framework.

I then was looking at recommendations for building fully functional web apps, and the official recommendation was to use "Svelte Kit". I began the tutorial for that, and was surprised at how the philosophy of that framework seemed to completely contradict the core Svelte framework. It was extremely odd and unappealing, and killed my newly gained enthusiasm for Svelte.

Has anyone built full web apps without Svelte Kit (previously Sapper)?


You absolutely 100% do not have to use Svelte Kit.

Svelte Kit is just the equivalent of (an opinionated) Next.js, Gatsyby, or Nuxt.js framework. Those frameworks are also incredibly opinionated on purpose.


One of the things I came to enjoy regarding React was that the router was separate and kept the core React API small. I had hoped that something similar was the norm for Svelte, but it was quite clear that the official recommendation was to use SvelteKit.

Have you built production apps with just Svelte? Is the tooling and feature set good enough to use Svelte alone in an actual app?


I agree. SvelteKit should not be advertised as the standard way to use svelte imho. Fortunately it’s not necessary to use svelte. I’ve some quite complex apps built using svelte, all without SvelteKit/sapper (I am of the “explicit is better than implicit” school of thought).


So, what do you use for something like a router?


I’ve used page.js and some other generic ones. It’s up to you, svelte is not bound to anything in particular.


I built https://www.listenaddict.com/ with Sapper. It was a good experience. That said, all of my other apps are using Kit, and I'm finding that experience even nicer.

What did you find unappealing about Kit?


This post [0] sums up my general feeling toward SvelteKit. It seemed very opinionated and very restrictive, two qualities which seemed opposite the philosophy of core Svelte.

[0]: https://www.reddit.com/r/sveltejs/comments/ni9g5d/svelte_vs_...

Do you have concerns with using SvelteKit in production? It's still in Beta last I checked.


Yes, it's very much in beta! And if that's a concern for you, then I'd stick with Sapper or Elder.js or another.

That said, I think the replies covered the concern pretty well. For me, I don't really have any concerns with it. I don't find it very opinionated nor restrictive, but I come from a Rails background where I'm used to convention over configuration, so maybe I'm biased towards reasonable defaults.


We've been building Budibase without SK and it's great: https://github.com/Budibase/budibase


Very cool, thanks for the link.


macspoofing said elsewhere ITT:

> DOM mutations are not the expensive thing, it's the final render.

This is the crux of the issue: Updating the DOM will immediately rerender the page, even if there are additional changes that need to be made at the same time. So library/framework authors twist themselves into pretzels trying to work around the browser automatically doing all this unnecessary extra work that developers don't even want. Clearly it's a DOM api deficiency; there is no api to 'make these 15 changes scattered across the DOM all at once', instead each individual change causes a cascade of wasted effort repeated until the last change is applied OR developers take the nuclear option and just replace the whole damn page with a completely new DOM on every frame. Insanity. The solution seems obvious to me:

Browsers should introduce a transactional DOM api that is only rendered after the transaction is 'committed'. It could be full-on transactions like a real DB or something simpler like a double-buffered frame swap. This would be relatively easy to retrofit into JS apps and frameworks and would enable them to effortlessly avoid a huge amount of wasted effort on the part of the browser.


When I learned frontend web work and React years ago, I fell for the same "VDOM is fast!" hype, and assumed there was non-JS magic under the hood.

I eventually built a VDOM-based frontend WASM framework in Rust (Seed).

I now built frontends in HTML and CS, with no frameworks, and minimal, targeted JS code to manipulate the DOM directly; it's liberating, and much faster than both React and WASM/Rust.


It's crazy how quickly frontend UI frameworks became the standard approach. They're not necessary in so many instances where they are used.

I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget?

Anyway, it's not that frontend UI frameworks are bad, it's more that pragmatism gets thrown out the window so quickly.


> I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget?

A lot of new kids (we call them frontend engineers) haven't done the old school way. They just know SPAs, because that's what they've been taught in the last decade or so.


Yes, there's a lacking sense of measure in frontend and I work in a shop full of people that talk about what framework to use for a few buttons, a search form, and a result list. CSS is good enough that you can implement a lot of your UI state machine with classes as switches and scoped CSS variables available with `calc()` for threading particular derived values


It feels like we were coasting on a mentality of "Computation is cheap; We're in post-performance-scarcity era; Performance doesn't matter since computers are fast". -- Ignoring the reality that responsiveness is critical to user experience.


> Seed

Sigh. https://wiki.gnome.org/Projects/Seed

(JavaScript-related, so not just any random name collision.)


I work on the Lit team at Google. A colleague there who went on to work on Flutter's VDOM-like system once said that React traded off CPU cycles for developer ergonomics and conceptual simplicity.

A VDOM tree represents far more DOM states than a template will ever be put in, so materializing VDOM and diffing are absolutely pure overhead compared to the system knowing ahead of time what might change. With VDOM you repeatedly compare many nodes that will never show a diff, and that's just waste.

VDOM brought three important things to the table, initially paid for by that overhead: * Template as values. JSX expressions produce JS values, and this is allows a functional programming approach to UI. * Expressions and control flow in JS. This shrunk the domain of the template DSL to just the component nodes, and reused knowledge and machinery of JS. Theoretically that leads to faster and smaller templating. * One-way data flow. This is a result of the first two items, but important on its own. Two way binding is nice sugar for some situations, but it makes it hard to reason about the state a template is in.

Those are really great aspects of the VDOM approach (for a class of programmers, markup based templates are great for others).

So the challenge to me had been to preserve those features, actually deliver on the smaller and faster part, and reduce the CPU overhead. That can be done with compiler-first systems like Svelte, but I think we get just as faster or faster, and as small or smaller with a pure runtime approach based on template literals, like we have with lit-html.

Template literals let us describe the static and dynamic parts of a template separately, so there's no VDOM overhead. We don't compare the output of template expressions, we compare the inputs to the dynamic bindings. It's often an order-of-magnitude less diffing work, and approaches the point where the required DOM operations are the limiting factor. So we get low-CPU overhead, templates as expressions, logic in JS, and one-way-bindings, with no compiler. I really think this is the best of both conceptual simplicity and overhead - preserving much of the VDOM model, but doing it faster.


> I really think this is the best of both

I think this approach definitely has a lot of merit, but in terms of absolutes, it's still not quite there. Specifically, you're still going to be diffing as many bindings as a component has, be it one or one hundred, even if only one changed.

Another more micro-level issue is that dynamically resolving which DOM properties to update is polymorphic, so you don't get nearly as much JIT optimization compared to a compiled approach that outputs monomorphic static property assignments.

I quite like Solid.js' approach, which addresses both of these problems via a reactive data flow and aggressive compilation, while still providing a React-like experience.


If you don't need Virtual DOM then Web Components are a great idea for building reusable components that work with all frameworks, including React. You can even use JSX to build Web Components: https://github.com/wisercoder/uibuilder


The most important line:

> It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development.

Declarative, state-driven UI development is a valuable abstraction.

I really hope readers take this to heart, rather than the article title becoming a new meme.


They note right after that:

> it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in

The abstraction is valuable, but its cost need not be so high. I do wish they'd elaborate on what Svelte does differently though, or link to another post which elaborates.


The front page of their website proclaims Svelte to be "Cybernetically enhanced web apps", whatever that means.

The "Rethinking" post gives a little more detail:

> Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.

https://svelte.dev/blog/svelte-3-rethinking-reactivity

Seems like a great idea, if it can gain the critical mass required and build a community of people developing code for it.


Declarative, state-driven UI development is a valuable abstraction.

Which browsers do not support natively for decades and entire markets of ecosystems grow to work around that stupidest fact. Browsers could detect, batch and “reconcile” (whatever that means) the changes to the js runtime with much less runtime and devtime overhead than it is done in js by manual state tracking and updates.


Declarative state-driven UI is great, but personally, I really prefer the way e.g. knockout does it over react. It uses observables and publish/subscribe to issue updates to DOM elements directly where they're needed. You may not like knockout, but it shows how virtual DOM isn't a requirement for declarative state-driven UI.


Okay, but - why does Rust frontend libraries (like Yew and Seed) use vdom instead of doing whatever Svelte does?

Actually, is anyone else doing it the Svelte way?


There are some VDom-less libraries popping up now. https://github.com/sycamore-rs/sycamore


This is very cool, thanks!


I created Seed. I didn't know any better at the time! I'm no longer a fan of the extra computations VDOM does. Svelte's approach sounds like a clever way to mix declarative code without running extraneous computation.


I understand. Btw, what do you think about MoonZoon? (https://github.com/MoonZoon/MoonZoon) In special, the decision to not use Elm architecture. I see it's created by the current Seed maintainer.

It appears MoonZoon uses https://github.com/Pauan/rust-dominator which, like Sycamore, is also a DOM library that doesn't use vdom.


Looks like a cool concept. Martin started working on it some time after I moved on, so I don't have any insight on it. I'd considered incorporating Dominator instead of an original VDOM, but at the time, it wasn't obvious how you'd interface with it. Ie not much in the way of docs or examples.


Because VDOM is useful for writing declarative code. It's DX over UX - and most of the time it won't impact UX anyway.


I'm somewhat surprised that React won out versus Angular or something similar. Because React isn't opinionated about the supporting things around it, there seems to be wide variations in a React stack and approach from team to team.

More so than I would typically see in any other ecosystem. But nobody seems to care. Is is that it makes for a sort of meritocracy where people that keep up with the fast changing landscape get the best opportunities? Basically, I can't figure out why JS developers aren't overwhelmed and frustrated with all the choices.


I think it was:

- The Angular dependency injection stuff seemed rather complicated compared with React pragmatism. Using React became heavier by the time Redux and other boilerplatish practices became widespread, but React had already gained adoption by then, and you could still get into it on tiny projects without fancy state management.

- The VDOM had articles saying how much faster it was than everything else, so it gained a reputation for speed compared with the other client-side templating alternatives at the time. Angular 1 had a reputation for being slow due to scanning all state variables on every refresh. Really React wasn't fast at everything, but fast at enough things to get that reputation. People who really understood DOM differential updates already knew how to do it faster than VDOM, either by hand or with smarter differential template compilers, but implementations weren't common. Marko and Svelte came along later.

- After years of being trained that separating HTML templates and code was the right thing to do for better engineering, preferably in separate files, it turns out that was annoying and lots of people really liked inlining the dynamic parts of HTML directly into code.


One reason React won over Angular is it relies on JavaScript instead of custom templating syntax. E.g. You loop with a forEach, not some ng-...


forEach in react/jsx, are you sure?


For those who have worked on traditional desktop apps (rather than web), what underlying paradigm is used for UI updates there? I assume all these problems of fast partial updates must have been addressed there long ago. So apart from the specifics miasma of language and markup formats, how was it done?

I ask in complete earnest, and if I should just be reading some particular Wikipedia article I'm grateful for any links.


It's been a while, but when I developed Windows applications, I generally had a well-defined, observable central data structure. You made updates to it in systematic ways, and then each important section of your UI would handle updates and redraw intelligently.

Sometimes, I'd make use of a component that did this itself, but yeah. At least back then, it was a lot of manual wiring. Maybe similar to backbonejs in some ways.

The toy video games that I wrote were more React-like, in that you would simply update your models, and then a separate process would re-render 30-60 times per second. So, as a developer, you could really just think in terms of data transformations.

Anyway, it's been 15 years since I've done either. I'm not sure how modern, native toolkits work. I assume there are decent React-like top-down-dataflow approaches these days.


From my limited experience with c#/xaml and swift apps, it's MVC/MVVM mostly, although apple is moving towards react-like swiftui.


I read this long ago and I love Rich Harris and I think he is a super smart guy. But the problem as I see it is that he focuses on VDOM as just a performance hedge. As browsers improve (or rather as the market consolidates on WebKit variants as is happening now), then certain DOM operations that took substantially longer on average on IE or Edge vs. Chrome will no longer be as much of a problem, which is my view of what the VDOM was trying to solve. There are some operations that depending on the browser and how the internal mechanics of the layout engine work will take substantially longer on one browser vs another for instance. You are at the mercy of each layout engine's architecture. In this case, if you use a VDOM to calculate the simplest operation to be performed and just push the end results with the simplest operations manageable, you can elide away the differences between certain DOM operations taking longer than others across browsers. Setting innerHTML for example on IE (Trident), Edge (EdgeHTML), Safari (non-Blink WebKit), Firefox (Gecko) and Chrome/Chromium (Blink) is likely the best way to ensure consistent performance since it is one of the base operations you will need to do to manipulate HTML.

I personally love the idea of the VDOM, because it liberates the content from being stuck to one document type: HyperText. While true when VDOM showed up on the scene, Facebook and others said the VDOM would help cure performance issues and that was the main selling point.. as we see now with things like ReactPixi, and Netflix using React for some of their apps - the VDOM is infinitely valuable for transcending the limits of HyperText and instead abstracting it away so that content may be projected by any sort of renderer using the same scaffolding as web pages. If you code to just the DOM - that is is where you will stay. Forever.


“ If you code to just the DOM - that is is where you will stay. Forever.”

Svelte native exists…

The VDOM which mirrors the document DOM is an implementation detail of React, as something sitting between the actual DOM, and the VDOM fragment returned by a React view. It’s true that if the document DOM gets fast enough, the mirroring VDOM could go away, but some diffing algorithm would still have to reconcile the document DOM with whatever fragment is returned from a view.

I think one of the realisations of Svelte is that rather than returning arbitrary runtime generated DOM fragments from views, it is better to have the view implemented by a template that a compiler can understand and manipulate at compile-time. Here we trade off some expressivity (run-time generated DOM) for the ability to do much much more at compile time - I think this is the real point that should be being made in the article.


For me, it's absolutely hilarious to see the frontend development discussion. They somehow figure the way to go full circle every 6 months.


I thought most of the JS world know that virtual DOM is slow and ahead-of-time direct binding is the way forward at this point - why do something expensive inside your users browser when it should be done on the developer's machine? Svelte will either take over, or React will get patched to start doing this in a major new release. It could go either way at this point.


I doubt Svelte will take over. Although I really like Svelte, and worked with it before React, the tooling with React is simply superior. Besides, React already mentioned in one of their introduction tutorials that they are considering taking Svelte's approach at one point. Developers choose the tools that makes them productive and that are enjoyable, not the ones that are most efficient (otherwise we'd all be writing assembly code)


> Developers choose the tools that makes them productive and that are enjoyable

That true, but that points more towards Svelte taking over.



the "strawman" of updating innerHTML on every change isn't that far from the truth of how a lot of backbone apps worked, you had a template that you'd render and set to innerHTML on input change, maybe the app would be broken down into different parts with their own template and the app would spend a bunch of logic tracking which changes updated which parts or trying to batch changes up, but that's not far off for a lot of backbone apps.

One of the big selling points of react was you could basically write your app that way and it would fine.


People often say things like "because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code"

But what would be a minimal as possible example for this?

I know a bit reactjs and it can get complicated as well with multiform s and various elements states depending on each other quickly too.

A bad architecture can be "achieved" by either, I am curious about some examples showing me what people mean exactly by that.


Compare the design of Featherstitch [1], in contrast to BSD's soft updates.

(I wonder what happened to Featherstitch.)

[1]: https://lwn.net/Articles/354861/

It's a common pattern that you have a list of items of work to be done which in principle you could know ahead of time, but in practice it's better to track at runtime (even though it means the computer ends up repeating the same calculation again and again).


I do agree. When I first see it I knew that. Comparing two sequences (actual dom and dom) to find diff is like O(n^2) and the assumption that dom ops is expensive is a lie (premature optimization). Dom ops on ids and classes and fragments is very fast. In most cases a slow dom is always a developer fault failing to use fragments.


Applications are open for YC Winter 2022

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

Search: