Rethinking Reactivity by Rich Harris (2019)
Virtual DOM is pure overhead (2018)
261–270 of 337 posts
Re: Virtual DOM is pure overhead (2018)
#262Earlier quoted context omitted.
Is this still the case with the newer transactional methods like Element.append(), Element.before(), and DocumentFragment? When I manipulate the DOM I try to create the entire structure in a fragment and the use .append(...) only once.
I'd be interesting in learning the answer here as well. I've read that documentFragment are faster, but some microbenchmarking on chrome/mac makes me think either the improvements are negligible. Rerunning benchmarks on stackoverflow ( https://stackoverflow.com/questions/14203196/does-using-a-do... ) (both individually and swapping the order of fragment vs non-fragment tests) nets me ~60ms when rendering 100000 ul in…
Fragments are still real dom nodes, and those are heavy.
Unless you getting computed styles in between add/deletions, etc, I don’t think there would be much of a difference.
Re: Virtual DOM is pure overhead (2018)
#263Earlier quoted context omitted.
Inferno was one of the first frameworks to embrace compiling JSX as an opportunity for advanced performance. the `$HasTextChildren` is a special attribute their JSX compiler (its a babel plugin) uses to optimize the tree at that point in time the that flag is found. It can do advanced optimization knowing that the children of that component are purely text VNodes. There are other flags available too that optimize dif…
I think React won partly because one of the most important tools for Facebook's revenue, the "Power Editor", was built on react (before react even existed, I suppose) As one of the first Facebook PMDs (later FMPs) part of my job back then (around 2010-2012) was to keep up to date with changes in the ads API, but our main contacts were two guys in Ireland and themselves not always kept up to date with every developmen…
I’d love to hear more about the earth days like this. It’s amazing to me just how special a time this was in web development
Re: Virtual DOM is pure overhead (2018)
#264Earlier quoted context omitted.
>React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this. Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous ren…
My issue with React is that it's truly hard. It markets itself as easy but it's not. I have 20 years of programming experience, I dealt with UI a lot, I used WinAPI, Java Swing, I know JS and HTML pretty well. I'm fine with reactive programming or async stuff. Yet I often struggle with React. I'm not a full-time web developer, I admit, I'm more like full-stack developer but when I need to write novel React code, I st…
I'm sorry but I don't share your experience. I find React very easy, and short of a period of creating the baseline components and skeleton, everything else flows very fast in terms of development time. By the way, I think react in strict mode does run components twice in dev, so not running in strict mode will prevent that, and you can use a regular Promise in your useEffect.
Re: Virtual DOM is pure overhead (2018)
#265Earlier quoted context omitted.
> 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 n…
> 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.
It's entirely unclear to me how compiled templates result in drastically less code. If we're comparing Svelte and React as frameworks, then sure, but your original comment specifically talked about JSX syntax being inferior to the alternatives. Templates require a custom DSL for control flow, iteration, etc, whereas with JSX you can use standard JavaScript. That also means that you can take third-party libraries that work on regular JS data structures, like objects and arrays, and apply them to JSX elements with zero fuss. With a DSL, you have to find a domain-specific version of the code you've already written in your head, and in some cases, it may not even be possible to create the same abstractions. This has its advantages, of course, but I strongly disagree with the notion that it's simply better.
For the record, I really like Svelte as a framework, but I can't honestly say that their decision to use templates has anything to do with that.
Re: Virtual DOM is pure overhead (2018)
#266Earlier quoted context omitted.
> 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…
> But unless it is a drastic simplification
95% of what you write in Svelte is just HTML. You then databind whatever you need using an obscenely lightweight syntax.
Svelte also has an optional SRS framework called SvelteKit that auto creates REST endpoints for you, and auto binds stuff to them, but all that is optional and not needed.
My issue with backend HTML templates is that essentially you always have to know HTML + CSS anyway because browsers suck and they still have differences, so I always end up spending a ton of time fixing CSS and HTML issues. Having to fix HTML issues by way of the backend that then generates HTML feels like an unneeded abstraction.
Instead I can just... write HTML and CSS.
Re: Virtual DOM is pure overhead (2018)
#267https://twitter.com/dan_abramov/status/1135424423668920326 Above thread summarizes the issue pretty well I think. Optimizing for DOM updates is nice, but you also want to optimize for bundle size and page load time, and at a certain app size the compiler output is always going to be bigger than just using a virtual DOM.
It is true that Svelte and React bundles will grow at different speeds as the app grows. Redundancy gets compressed in React library, but it just stays there in Svelte. That said, since it is redundancy , I wonder if Svelte bundles are more gzippable (or at least, could be made so).
As far as I understand, in React, there is no redundancy to compress. You have one algorithm for diffing the virtual DOM and you're done. On a spectrum of biggest bundle size to smallest possible bundle size, the React model (more specifically Preact) would be as far to the right as you can go. Whereas any solution which does more specific compilation on individual operations to minimize DOM update work is going to have special code for each case.
Re: Virtual DOM is pure overhead (2018)
#268Earlier quoted context omitted.
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…
I’d say DSLs in general are really annoying. They’re almost never as well designed as a mainstream language, their tooling is usually worse, and good luck if you ever need to do something that isn’t well supported by them.
These problems are surmountable, but man, I’ve used and created some crappy DSLs in my time. If you’re wondering, “Should I create a a DSL for this?” Default to “No” unless the evidence is overwhelmingly in favor of it.
Re: Virtual DOM is pure overhead (2018)
#269Earlier quoted context omitted.
Is there some VM that allows limiting the CPU to a performance similar to a P4? (A PIII is way too bad for my tastes.) I imagine Linux would have a bad time running in it.
Pretty sure PIII's beat P4s at a lot of benchmarks. :-D Thus why AMD is around today.
Well, I was using AMD at the time.
AFAIK, the P4 faced badly on jump-happy code, but this was not common enough to be a problem on the real world when compared to a PIII. It was also a power hog, that could barely outrun a snail if you didn't have proper thermal management, but that also doesn't means the processor is slow.
Re: Virtual DOM is pure overhead (2018)
#270Imagine being someone in the semiconductor industry reading this. You're at the absolute pinnacle of high-tech and are approaching the limits of material reality to realize a 20% faster CPU. It's a true super human accomplishment. Software developers: well yes, 99% of the cycles I use are completely needless, but it's still plenty fast enough! Which we justify with the idea that a framework like React is abstract, he…
[deleted]