- 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).
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.
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).
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)
You could also say Python is pure overhead. You can write any Python programme in C, but more efficiently! C is faster, and therefore better.
This article avoids the fact that declarative programming has proven to be more pleasant for most people. And React simply is fast enough for most use cases, even though it has a performance penalty compared to Svelte. The virtual DOM is an elegant optimisation that usually works well in the real world, and methods like `shouldComponentUpdate()` can be used in the 1% of cases where the default is not fast enough.
> This article avoids the fact that declarative programming has proven to be more pleasant for most people.
No it doesn't. Second-to-last paragraph:
"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."
Ease of use is definitely important - but 9/10 programmers not familiar with either Svelte or React, learning either for the first time, would prefer Svelte.
There's many good reasons to use React - mainly the React ecosystem - but simplicity is not one of them.
This article is specifically attacking a claim that I have heard before - that React is fast, because it works on virtual DOM, therefore it is faster than real DOM operations.
I will probably get downvoted as I am in minority who still believe Server Side Rendering is the best approach for most of the web with exceptions to some websites that require Single Page App functionality.
I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimulus JS is good enough. Personally I do not see why everyone wants to build a Single Page App when 80% of your pages are static and can be server rendered and with SSR frameworks you can build something a lot faster than building a Frontend and Backend separately and fragmenting or hiring extra developers when it is not needed.
DHH said your code reflect your org structure and I agree companies that use SPA and Backends micro service arch usually tend to require more developers rather than companies that use SSR monoliths which appeal to smaller 1-3 developer companies that are building out a POC before committing huge amount of venture capital or their own money behind an idea that may not succeed.
about the monolith, the way data is growing in companies it will be impossible for one team to manage apps running for all data business domains. Businesses are not monoliths, they are organized in departments. The Supply chain department is the best suited for building supply chain services. The monolith might make technological sense but it’s making less and less business sense, just look at how quickly monolith systems like SAP or Salesforce are becoming obsolete.
The SPA movement has always seemed like a cargo cult to me. Yes, AJAX is handy and it was exciting when it came out. We used it to update search results when you changed a filter.
For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.
But then we wouldn't have the ability to build cross platform apps in HTML/CSS/JS. I'm working on an app that is built on Ionic (packages app for various platforms) and Electron (primary deployment model for desktop utilized by Ionic) that would not be practical if we were stuck on a server side rendering paradigm.
I can use HTML/CSS/JS skills (and Angular) to build a serious business application that runs anywhere and looks the same on each platform (or morphs to the platform UI if I care about that).
A (the?) primary argument for SPAs is state preservation/management. If you're actually building a web "application" (as opposed to web pages), then the default state model that a web browser provides is pretty bizarre when you think about it.
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.
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.
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.
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.
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.
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".
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.
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).
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.
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.
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.
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.
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".
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.
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:
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().
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 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?
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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)".
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.
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).
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.
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 feel like nobody is asking: what is the point of all this performance chasing with frontend frameworks? You might get a millisecond here or there. So what?
In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering might be a problem is at Facebook SPA scale, and the vast majority of apps are not Facebook.
You are considering this from the side of one web app, but users generally will have dozens of tabs open. When you need a Core i7 with 16GB of RAM to handle your browser, because each developer didn't care about their individual performance, the web experience becomes a nightmare.
For the applications I have worked on, rendering is basically the only reason for unresponsiveness. Loading from the network happens asynchronously and doesn't block the JS thread so any other interactivity or loading state/animation should work just fine. If loading over the network makes the application seem unresponsive, that's generally just bad UX implementation.
I am currently working with low-latency audio and the latency requirements mean I have minimal buffering. While the VDOM render cycle is generally fast enough to be unnoticeable to the user, it stalls the audio buffering just enough to cause some stalling. There's a few heavier parts of the application where the rendering is expensive enough to briefly stall animations as well.
While both of these issues are something we need to fix, it is specifically the rendering/vdom process that we need to work around to address these performance concerns, and we are definitely not at all Facebook.
Lots of vdom frameworks are more than fast enough to run business-style SPA applications, but start being very laggy for data visualisation kind of work, or anything where complicated animation combined with user interaction is involved. This means the developer only gets a nice declarative framework sometimes, and has to go back to a more messy way of thinking otherwise.
Svelte (and some other contenders, like concurrent mode React) improve performance enough that interactive animated datavis stuff can also be done declaratively.
> In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application.
Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.
Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.
Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.
My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.
Would you mind elaborating a bit on _how_ you implemented this? In my experience with Vuex and large datasets with dozens of stores, the devil is in the detail and how you change stuff matters a lot.
For example, you can't just create and keep a copy of a dataset / variable. It will remain reactive. You need to clone it. Failing to do so will indeed quickly clog up... everything :D
you don't have to clone it. cloning the object and putting it in Vuex will still result in it being reactive.
`Object.freeze` is what I used. This causes Vuex to not traverse the object for changes. in my case, the objects I was pushing into the Vuex state were essentially immutable once I pushed them in, so this did the ticket.
well, that, and only pushing partials of the entire state, so the object model didn't get too unwieldy. To get the total state, i just replayed the changes on top of the base state. base state was reset once the number of changes got to a certain size.
Batteries. Inefficient JS aggregates to result in significant energy use.
If I'm building a desktop app that will run in the browser then it isn't much of an issue, but if that same app is expected to run on a mobile device then my wild JavaScript kludges start to really matter.
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.
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
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.
> 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.
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.
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.
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.
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).
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
> 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.
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?
> 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.
> 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.
> 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.
> 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.
"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.
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.
>> 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.
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.
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.
> 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.
Care to expand on this? Component props seem quite straightforward where I stand and Typescript support has improved drastically over the preceding months
>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.
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?
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.
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.
> 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.
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
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.
> 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.
> 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.
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.
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.
> 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?
> 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.
>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.
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
> 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.
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 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.
> 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.
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.
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.
I need to sit down and write a long blog post on this subject, but the tl;dr would be "The modern Web environment, from programming to browsing, is a massive case of path dependence; if we were starting from scratch today, knowing all that we now know, we would not design anything like this."
I have in my head a few dozen examples of what I mean, some small and some large. I won't even get into TCP/UDP which has already been argued over a thousand times. But I would point to RINA and other paradigms of remote execution:
But that's the large scale stuff. We can also focus on very minor stuff where a different design decision might have lead to less trouble. Take, for instance, a mouseclick. Which element on a Web page should receive that mouseclick? Well, there is a well-established hierarchy that the browsers respect, walking up the DOM, checking each element to see if it has a handler registered. It can be a royal pain if your application needs you to break out of that hierarchy, and you can end up with something buggy because this is still an area where the different browsers have slight differences. But why should any hierarchy exist by default? We could have it such that there is no hierarchy by default, the only hierarchy is that which is defined by me, the programmer. I believe this original decision (of a default hierarchy) was made because there was an assumption, in the 1990s, that each page would be hand-coded, but nowadays we have frameworks that write much of our Javascript for us, so the possibility of assigning mouseclick handlers on the basis of classes, rather than the DOM, seems like a smart choice now, but probably didn't in the 1990s.
I tried to write about some of this in essays like "The problem with HTML":
I'm not sure I really communicated myself very well previously, but perhaps if I focus on it, I can build the case that we've been following a path into a dark wood, and we've been so busy focusing on the path one step before us that we have perhaps not noticed that we've wandered into the lands where, in innocent days of yore, developers would have warned, "There be dragons, do not go."
292 comments
[ 4.6 ms ] story [ 218 ms ] thread> 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?
- 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).
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).
That true, but that points more towards Svelte taking over.
This article avoids the fact that declarative programming has proven to be more pleasant for most people. And React simply is fast enough for most use cases, even though it has a performance penalty compared to Svelte. The virtual DOM is an elegant optimisation that usually works well in the real world, and methods like `shouldComponentUpdate()` can be used in the 1% of cases where the default is not fast enough.
No it doesn't. Second-to-last paragraph:
"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."
There's many good reasons to use React - mainly the React ecosystem - but simplicity is not one of them.
I have heard that claim myself before.
I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimulus JS is good enough. Personally I do not see why everyone wants to build a Single Page App when 80% of your pages are static and can be server rendered and with SSR frameworks you can build something a lot faster than building a Frontend and Backend separately and fragmenting or hiring extra developers when it is not needed.
DHH said your code reflect your org structure and I agree companies that use SPA and Backends micro service arch usually tend to require more developers rather than companies that use SSR monoliths which appeal to smaller 1-3 developer companies that are building out a POC before committing huge amount of venture capital or their own money behind an idea that may not succeed.
For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.
I can use HTML/CSS/JS skills (and Angular) to build a serious business application that runs anywhere and looks the same on each platform (or morphs to the platform UI if I care about that).
Actually, is anyone else doing it the Svelte way?
It appears MoonZoon uses https://github.com/Pauan/rust-dominator which, like Sycamore, is also a DOM library that doesn't use vdom.
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.
https://codepen.io/recursive/pen/XWMLWBZ
If you could point to anything in the docs that I'm missing, I'd genuinely appreciate it.
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.
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".
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).
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
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.
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.
Using a conditional render like
seems to avoid the issue as well, without using a key prop. So yeah, beware of hidden loops.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.
Not saying that Angular's banana box is ideologically superior, just that all JS frameworks have idiosyncrasies.
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.
<BulletedList [(DataSource)]="MyCollectionProperty" />
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?
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?
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.
> 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.
> 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 "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.
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.
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.
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.
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.
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.
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.
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.
"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?
"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)".
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.
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.
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.
(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).
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.
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...
In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering might be a problem is at Facebook SPA scale, and the vast majority of apps are not Facebook.
I am currently working with low-latency audio and the latency requirements mean I have minimal buffering. While the VDOM render cycle is generally fast enough to be unnoticeable to the user, it stalls the audio buffering just enough to cause some stalling. There's a few heavier parts of the application where the rendering is expensive enough to briefly stall animations as well.
While both of these issues are something we need to fix, it is specifically the rendering/vdom process that we need to work around to address these performance concerns, and we are definitely not at all Facebook.
Svelte (and some other contenders, like concurrent mode React) improve performance enough that interactive animated datavis stuff can also be done declaratively.
Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.
Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.
Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.
My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.
For example, you can't just create and keep a copy of a dataset / variable. It will remain reactive. You need to clone it. Failing to do so will indeed quickly clog up... everything :D
`Object.freeze` is what I used. This causes Vuex to not traverse the object for changes. in my case, the objects I was pushing into the Vuex state were essentially immutable once I pushed them in, so this did the ticket.
well, that, and only pushing partials of the entire state, so the object model didn't get too unwieldy. To get the total state, i just replayed the changes on top of the base state. base state was reset once the number of changes got to a certain size.
If I'm building a desktop app that will run in the browser then it isn't much of an issue, but if that same app is expected to run on a mobile device then my wild JavaScript kludges start to really matter.
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.
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....
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 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.
> 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.
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.
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.
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).
One could argue that React's hooks are the same: they look like JS but change JS semantics.
However, your point is still valid.
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.
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.
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?
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.
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.
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.
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.
Do you have an example?
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.
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.
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.
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.
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.
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.
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.
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.
It basically embodied the bad side of JS frameworks pre-React.
It managed to take alllll the wrong lessons from Flex.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.
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.
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.
> 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.
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 saying developers don't have an attitude problem. We often do. I just think you might be assuming malice where there might be none.
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).
"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.
How so? It improved on JQuery's performance ten-fold which was the "easy" way to webdev at the time.
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.
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?
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.
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.
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
The state management in Svelte is fantastic.
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.
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...).
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.
One of the big selling points of react was you could basically write your app that way and it would fine.
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.
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.
I have in my head a few dozen examples of what I mean, some small and some large. I won't even get into TCP/UDP which has already been argued over a thousand times. But I would point to RINA and other paradigms of remote execution:
https://en.wikipedia.org/wiki/Recursive_Internetwork_Archite...
But that's the large scale stuff. We can also focus on very minor stuff where a different design decision might have lead to less trouble. Take, for instance, a mouseclick. Which element on a Web page should receive that mouseclick? Well, there is a well-established hierarchy that the browsers respect, walking up the DOM, checking each element to see if it has a handler registered. It can be a royal pain if your application needs you to break out of that hierarchy, and you can end up with something buggy because this is still an area where the different browsers have slight differences. But why should any hierarchy exist by default? We could have it such that there is no hierarchy by default, the only hierarchy is that which is defined by me, the programmer. I believe this original decision (of a default hierarchy) was made because there was an assumption, in the 1990s, that each page would be hand-coded, but nowadays we have frameworks that write much of our Javascript for us, so the possibility of assigning mouseclick handlers on the basis of classes, rather than the DOM, seems like a smart choice now, but probably didn't in the 1990s.
I tried to write about some of this in essays like "The problem with HTML":
http://www.smashcompany.com/technology/the-problem-with-html
and also, "HTML is the failed GUI for TCP/IP":
http://www.smashcompany.com/technology/html-is-the-failed-gu...
I'm not sure I really communicated myself very well previously, but perhaps if I focus on it, I can build the case that we've been following a path into a dark wood, and we've been so busy focusing on the path one step before us that we have perhaps not noticed that we've wandered into the lands where, in innocent days of yore, developers would have warned, "There be dragons, do not go."