Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

251–260 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#251

Post by tobr »

peterhunt wrote: post #232
tobr wrote: post #223

Earlier quoted context omitted.

I think your conclusion in point 2 is misguided, but I can see where you’re coming from. It’s true that virtual DOM has a lot of expressive power, and Svelte’s templating features are more limited in how you can approach certain problems. I find Svelte’s slots especially challenging for more advanced use cases, and wish they were more composable. But in my experience, React’s openness to expressive experimentation is…

I think there are two things that are interesting about your point of view. First, I think a mistake the react team made was not exerting more control over the ecosystem. I think a lot of questionable content marketing pieces ended up as “best practices” which we are still unwinding as a community. Second, I totally buy the idea that there are multiple personas and that different tools speak to different personas. Th…

But are you against constrained templating DSLs on principle, or just the specifics of how Svelte does it? I think the reason bad ideas take hold is because people are looking for guidance; constraints, if you will. In React that is offered through libraries, frameworks and best practices, but not all of those are good. Svelte has a lot more control of its ecosystem because the constraints are built in to a compiler. And as I said, I think it falls short in certain areas, but all in all I think those restrictions are a net win.

Re: Virtual DOM is pure overhead (2018)

#252

Post by KronisLV »

shortcake27 wrote: post #185
pweissbrod wrote: post #126

Earlier quoted context omitted.

By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including…

> By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. No you don’t. > In most cases you must choose a framework for routing. Also a framework for state management. I don’t understand this argument. React gives the developer this freedom by design. If you want a framework that has all of these decisions made for you, they exist. > You also dedicate to duplic…

I won't touch upon most of the points (because those are highly situational), but I'll offer my opinion on the following:

>> By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application.

> No you don’t.

It is true that you typically don't have to do that: you can just package the built assets of your SPA into whatever serves the rest of it, provided that you don't mind a monolithic deployment. I've seen many applications like that, both in Java (Spring Boot), PHP (Laravel), Ruby (on Rails) and so on, it generally works okay.

However, I'll also say that it's pretty great to have two separate folders in your project: "back-end" and "front-end" (or separate repos altogether) and to be able to open those in different IDEs, as well as to be able to deploy them separately, especially if you want to create a new front end (say, migrating over from OLD_TECH to NEW_TECH while maintaining the old one in parallel) or something like that. Otherwise you have to mess around with excluded folders for your IDEs, or if you open everything in a single one everything kind of mushes together which can be annoying, and your build also cannot be parallelized as nicely, unless you separate the back end and front end compile steps from the package step, where you shove everything together.

Personally, having a container (or a different type of package) with Nginx/Apache/Caddy/... with all of the static assets and a separate one with the back end API feels like a really nice approach to me. In addition, your back end framework doesn't need a whole bunch of configuration to successfully serve the static assets and your back end access logs won't be as full of boring stuff. If you want to throw your SPA assets into an S3 bucket, or use one of the CDNs you can find online, that's fine, too. Whatever feels comfortable and manageable.

Now, whether SPA is a good fit for what you're trying to build in the first place, that's another story. Personally, I like the simplicity of server side rendering, but also like the self-contained nature and tooling/architectures behind SPAs (though personally I'm more of a Vue + Pinia person, than a React/Angular user, though they're passable too).

Re: Virtual DOM is pure overhead (2018)

#253

Post by MrOwnPut »

revskill wrote: post #237
MrOwnPut wrote: post #215

Earlier quoted context omitted.

Why did I have to scroll this far down for the real answer? This is the true power of the VDOM, to abstract the view from platforms. Why be a web developer when you can be a cross-platform app developer? That's why I don't use Svelte and other web SPA frameworks...

The point is, if you want to make your web app the most performant as possible, cross-platform solution has limitation.

That's a pre-optimization. React Native Web has been very performant for all my real world use cases.

I'd rather a small perf hit than have another code base for web. You get web for basically free when making a RN app.

That is for APPS you want your WEBPAGE to perform better, don't use a SPA, use Astro or something similar.

Might as well do everything in Assembly or C because it's faster right? Same argument. Development speed matters too.

Re: Virtual DOM is pure overhead (2018)

#254

Post by 88913527 »

hbrn wrote: post #244
88913527 wrote: post #20

Poorly written react code isn't performant and removing the Virtual DOM will not fix your problem. It's a hill I'm willing to die on. Many engineers seem to struggle with unnecessary re-renders, to the point where I see long tasks in the performance tab. Clicking a button shouldn't lock the UI thread for 2 seconds.

> removing the Virtual DOM will not fix your problem Having seat belts will not fix car crash deaths. But it does make them less likely to occur, doesn't it?

I think if you take someone who isn't too skilled in React, and then give them a different framework, that you'll end up with too much different of a result. I don't write much Vue, so I don't know what performance issues there look like, but I do know it isn't discussed much since it has a much smaller market share. If going VDOM-less really is a silver bullet, I'd be curious to hear more.

Re: Virtual DOM is pure overhead (2018)

#255

Post by ttfkam »

horsawlarway wrote: post #218
ttfkam wrote: post #107

Earlier quoted context omitted.

Tell us you've never tried Svelte without actually saying you've never tried Svelte. You would have likely not said this if you had ever looked at Svelte-compiled JS. The amount of mutation is surprisingly small and easy to follow. Especially when coming from a world with JSX.

So what part of this statement do you disagree with? > "it's building a vdom engine specific to your template" Because that's... exactly what it's doing. It's doing it at compile time, and so yes - the amount of mutation in the output is small, which is not surprising at all because most templates are fairly static. We can quibble over exactly what a VDOM is, but I don't really know that tracking only a subset of the…

I'm not sure we can quibble over the definition of a vDOM. There is the DOM as found in browsers and then there's a layer on top of that, proxying access to the DOM, which we call a vDOM.

Svelte does not have this construct. All actions are performed on the DOM without an intermediary proxy object.

Tracking 100% matters, because you must iterate through the vDOM to determine the diffs that must be applied to the underlying DOM. On every change to the vDOM. This is not free. It is why the following abstraction leaks exist in React:

    • shouldComponentUpdate
    • React.PureComponent
    • useMemo
    • useCallback
This is making the developer worry about things the computer should've be able to suss out for itself. You expressed concern that Svelte's compiler approach is new and therefore subject to bugs. Aside from Svelte being over 6 years old now and having gone through 3 major versions already, my assertion is that any potential bugs present in Svelte's compiler at this point pale in comparison to the number of potential (and actual) bugs or performance gaffes present in the equivalent React app due to excess lines of code, complexity, and abstraction leaks such as those listed above. The cognitive overhead is real and has a measurable effect on developer output. Bugs are proportional to number of lines of code regardless of the language being used.

I assert that we developers, people, human beings, are far more fallible in this regard as to render concerns about the Svelte compiler's accuracy relatively moot. This is analogous to the switchover from Assembly to C. Early C compilers certainly had their issues, but even in the earliest days, the increase in productivity and reliability as a whole far outweighed the benefit of manually generating all instructions at that lower level. Even though today there are still optimizations to be made from analyzing hotspots and replacing generated code with assembly in those few spots, the compiler-first approach stills wins out because 90%+ of the time, it does as well or better than the hand-crafted Assembly... err... React code can in a tenth the developer time simply because compilers are now and have always been better than human beings at managing rote development tasks. Rote as in flagging variables for reactivity, (un)subscription to stores, accessing data properties, handling data binding, marking sections as immutable, etc.

Re: Virtual DOM is pure overhead (2018)

#256

Post by pweissbrod »

com2kid wrote: post #245
pweissbrod wrote: post #224

Earlier quoted context omitted.

Recently we went through an exercise where we built a to-do simple app using react and rewrote it using HTMX. The functionality was identical between the two apps. The amount of tooling code and duplicative logic was massively higher because of SPA and all the fundamental things it demands. Now if you really need an SPA for your requirements because you have an intrinsically complex front end and you've mastered the…

> Recently we went through an exercise where we built a to-do simple app using react and rewrote it using HTMX. React is boilerplate madness. Do the same in Svelte. I did a form heavy app in Svelte, literally took 1/5th the time it would have taken in React. SPA fundamentally means that instead of refreshing the page, just the data needed to update what is on screen is sent down to the user. Ideally, "send data about…

When you have a team with predominantly back-end knowledge expertise using a templating language they are familiar with plays to their strengths. MVC applications were written for over a decade. Perhaps it is a subjective thing because I don't see any logical difficulty in a web page that exchanges partials instead of JSON. I was programming that way for over 10 years.

Svelte really sounds compelling from what you're telling me. I'll check it out. But unless it is a drastic simplification it brings with it the fundamentals of effectively writing a thick client in JavaScript or TypeScript and all the things that come with it. React and angular have left a very bad taste in my mouth. The time and code cost for building basic user interfaces should go down not up. We should be spending less time talking about how to do something and more time talking about what to do

Re: Virtual DOM is pure overhead (2018)

#257

Post by harel »

jcelerier wrote: post #80
harel wrote: post #11

Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…

> Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast. we don't live in the same universe. even with powerful computers, browsing any friggin modern website is an exercice in pain and frustration, everything, literally every interaction is slow when you compare to the average desktop app

If a developer coded a slow app in react they will code a slow app in svelte. We need to stop blaming the language.

Re: Virtual DOM is pure overhead (2018)

#258

Post by peterhunt »

brundolf wrote: post #241
The5thElephant wrote: post #208

Earlier quoted context omitted.

Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from do…

> HTML and CSS not being first class-citizens as they are in other frameworks In what ways are HTML and CSS less than first-class citizens in React? In my React codebases we've always written CSS (or SCSS) stylesheets, and components bottom-out in JSX (which is almost exactly just an HTML template with inserts) In my experience the biggest barrier to (and most legitimate complaint about) React vs other frameworks is…

The main divide I've observed is whether you are encouraged to use JavaScript's built-in control flow and code reuse mechanisms or a less expressive DSL.

Hooks are pretty sweet but I think they should have launched with higher order hooks that used the same lifecycle as original React. That way you wouldn't need to think too hard about things like object identity (which I think is the state management issue you're getting at -- it wasn't a huge issue in the pre hook days)

Re: Virtual DOM is pure overhead (2018)

#259

Post by ttfkam »

RussianCow wrote: post #209
ttfkam wrote: post #195

Earlier quoted context omitted.

I swear, folks and their JSX have me convinced they have Stockholm Syndrome. HTML+CSS in JS was always a pragmatic choice back in 2015, never the most elegant or most maintainable one. It's like the folks who refused to use anything but the DOM APIs when JQuery was sitting right there. Or who keep on using onclick handlers on their div tags instead of using perfectly good HTML tags like: JSX was never the best of any…

> We have better ones now. Would you mind elaborating on what the better options are? The way I see it, there are a few possible alternatives: 1) Keep the same runtime DOM representation but use normal JS (something like `div({className: 'beer'})`). I know some people disagree, but I strongly believe that this is strictly worse than JSX because it's more verbose and far less readable. 2) Use string templates parsed a…

I would argue #3 is obviously better, especially if it's done as Svelte has done it. It's hard to look at a Svelte component and see much more than a tag, a tag and some lightly annotated HTML for data binding, event capture, and control flow etc. Compared to JSX, it's a breath of fresh air.

Are you dependent on IDE integration for syntax highlighting? Yes, of course. Same with HTML, CSS, and JS. And if Svelte were not already six years old, I'd be more concerned. But the simple truth is that every major IDE I'm aware of for front end development supports Svelte already.

    • VSCode
    • Jetbrains Webstorm
    • Neovim
    • Sublime Text
I would be shocked to the core if Emacs didn't already have something mature as well. Compilers are better than humans at managing rote boilerplate, of which React has no end of. I can only see how output improves by removing that recurring cognitive load. It's Assembly vs C all over again where folks have a hard time accepting that the easier path also leads to demonstrably better results. If I can do in 10 lines what previously required 50, that code I contribute is far less likely to have as many bugs or suffer from performance problems.

Re: Virtual DOM is pure overhead (2018)

#260

Post by peterhunt »

tobr wrote: post #251
peterhunt wrote: post #232

Earlier quoted context omitted.

I think there are two things that are interesting about your point of view. First, I think a mistake the react team made was not exerting more control over the ecosystem. I think a lot of questionable content marketing pieces ended up as “best practices” which we are still unwinding as a community. Second, I totally buy the idea that there are multiple personas and that different tools speak to different personas. Th…

But are you against constrained templating DSLs on principle, or just the specifics of how Svelte does it? I think the reason bad ideas take hold is because people are looking for guidance; constraints, if you will. In React that is offered through libraries, frameworks and best practices, but not all of those are good. Svelte has a lot more control of its ecosystem because the constraints are built in to a compiler.…

I am against constrained DSLs in general unless it buys you something. In the general case, with a DSL you sacrifice expressivity in order to gain security guarantees or improved performance. In this case you are sacrificing expressivity to gain performance but I don't think the performance gains are meaningful enough to be worth sacrificing all of that expressivity. So to answer your question, I am generally opposed to constrained templating DSLs for web frontend applications overall.
Post reply on HN