4 ms·
Angular also works in a somewhat similar way, there is also no virtual DOM. Instead, the modern compiler is used at build time to generate what looks like a ch
by vfc1 7y ago
Angular also works in a somewhat similar way, there is also no virtual DOM.
Instead, the modern compiler is used at build time to generate what looks like a change detection function and a DOM update function per component.
These functions will detect changes and update the DOM in an optimal way without any DOM diffing.
However, because Javascript objects by default are mutable, after each browser event Angular in its default change detection mode has to check all the template expressions in all the components for changes, because the browser event might have potentially triggered changes in any part of the component tree.
If we want to introduce some restrictions and make the data immutable, then we can check only the components that received new data by using OnPush change detection, and even bypass whole branches of the component tree.
This is the current state of things, for the near future Angular is having it's internals rebuilt in a project called Ivy.
One of the main goals of Icy is to implement a principle called component locality.
Ivy aims at getting to a point where if we change only one component, we only have to recompile that component and not the whole application.
I think the article puts the focus on the wrong thing. The current change detection and DOM update mechanisms made available by modern frameworks virtual DOM or not are more than fast enough for users to notice, including on mobile and once the application is started.
What we need is ways to ship less code to the browser, because that extra payload makes a huge difference in application startup time.
- 2T1Qka0rEiPr 7y agoThanks for the write up - it's a very succinct explanation of how Angular works in comparison. I found the original article to be a really good read, and the Svelte approach in general seems rather neat. I do however find that in this current front-end framework sphere, there seems to be a huge amount of religiosity and one-upping going on. I hear routinely (on-line and off) developers vocalising some anti-[jQuery,angular,etc.] mantra, which to be honest saddens me. Yes the jQuery approach was flawed in so many ways in comparison to the modern frameworks. Yes Angular 1.x was flawed in many ways compared to what we have on offer today. But those tools were still great improvements on what we had before (for anyone who knew the DOM-API standardisation nightmares pre-jQuery, or state management / testability woes pre angular/react). Svelte may take us down the next path, and if it allows us to produce better, smaller, more testable code then it has my full backing. But I think as a community we need to strive to be less polarising - from my perspective its likely to be mostly reductive, and lead to even more JavaScript fatigue.
- ralphstodomingo 7y agoI would guess this is partly because the modern front-end framework leaderboard is a zero-sum game: you can't possibly be sane to use two or more different frameworks for most of your day-to-day work. Maybe you have one for work and one for hobby development, but that's about it. I'd be torn to remember quirks of both React and Vue, for example. And thus you see it in discussions that people feel the need to pull one down to put their preferred one on the top. We know what happens to a library without a critical mass of adopters: they lose contributors, which in turn reduces the rate of growth, and in turn, the quality of the library over time. Which is kinda sad. A lot of work goes into these frameworks that I really respect. There's no logical rule that says these new ideas completely succeed their precedents. I wonder what needs to be done to get us over that JS fatigue.
- fauigerzigerk 7y ago>The current change detection and DOM update mechanisms made available by modern frameworks virtual DOM or not are more than fast enough for users to notice, including on mobile and once the application is started. What we need is ways to ship less code to the browser [...] I wonder how it affects battery usage though. Downloading the code doesn't happen as often as running the code, if it's really an app and not content needlessly packaged as an app.