[HN Gopher] Virtual DOM is pure overhead (2018)
___________________________________________________________________
Virtual DOM is pure overhead (2018)
Author : rob
Score : 301 points
Date : 2021-06-29 13:19 UTC (9 hours ago)
(HTM) web link (svelte.dev)
(TXT) w3m dump (svelte.dev)
| EMRZ wrote:
| For me, it's absolutely hilarious to see the frontend development
| discussion. They somehow figure the way to go full circle every 6
| months.
| btown wrote:
| 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
| jiofih wrote:
| 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.
| agumonkey wrote:
| Man I've been waiting for this for so long.
| TeMPOraL wrote:
| > _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_.
| spankalee wrote:
| I work on the Lit team at Google. A colleague there who went on
| to work on Flutter's VDOM-like system once said that React traded
| off CPU cycles for developer ergonomics and conceptual
| simplicity.
|
| A VDOM tree represents far more DOM states than a template will
| ever be put in, so materializing VDOM and diffing are absolutely
| pure overhead compared to the system knowing ahead of time what
| might change. With VDOM you repeatedly compare many nodes that
| will never show a diff, and that's just waste.
|
| VDOM brought three important things to the table, initially paid
| for by that overhead: * Template as values. JSX expressions
| produce JS values, and this is allows a functional programming
| approach to UI. * Expressions and control flow in JS. This shrunk
| the domain of the template DSL to just the component nodes, and
| reused knowledge and machinery of JS. Theoretically that leads to
| faster and smaller templating. * One-way data flow. This is a
| result of the first two items, but important on its own. Two way
| binding is nice sugar for some situations, but it makes it hard
| to reason about the state a template is in.
|
| Those are really great aspects of the VDOM approach (for a class
| of programmers, markup based templates are great for others).
|
| So the challenge to me had been to preserve those features,
| actually deliver on the smaller and faster part, and reduce the
| CPU overhead. That can be done with compiler-first systems like
| Svelte, but I think we get just as faster or faster, and as small
| or smaller with a pure runtime approach based on template
| literals, like we have with lit-html.
|
| Template literals let us describe the static and dynamic parts of
| a template separately, so there's no VDOM overhead. We don't
| compare the output of template expressions, we compare the inputs
| to the dynamic bindings. It's often an order-of-magnitude less
| diffing work, and approaches the point where the required DOM
| operations are the limiting factor. So we get low-CPU overhead,
| templates as expressions, logic in JS, and one-way-bindings, with
| no compiler. I really think this is the best of both conceptual
| simplicity and overhead - preserving much of the VDOM model, but
| doing it faster.
| lhorie wrote:
| > I really think this is the best of both
|
| I think this approach definitely has a lot of merit, but in
| terms of absolutes, it's still not quite there. Specifically,
| you're still going to be diffing as many bindings as a
| component has, be it one or one hundred, even if only one
| changed.
|
| Another more micro-level issue is that dynamically resolving
| which DOM properties to update is polymorphic, so you don't get
| nearly as much JIT optimization compared to a compiled approach
| that outputs monomorphic static property assignments.
|
| I quite like Solid.js' approach, which addresses both of these
| problems via a reactive data flow and aggressive compilation,
| while still providing a React-like experience.
| mjw1007 wrote:
| Compare the design of Featherstitch [1], in contrast to BSD's
| soft updates.
|
| (I wonder what happened to Featherstitch.)
|
| [1]: https://lwn.net/Articles/354861/
|
| It's a common pattern that you have a list of items of work to be
| done which in principle you could know ahead of time, but in
| practice it's better to track at runtime (even though it means
| the computer ends up repeating the same calculation again and
| again).
| incrudible wrote:
| Ironically, the thing that supposedly no one does (setting
| innerHTML) in many cases is still much faster than using the
| finer grained DOM APIs the way React or Svelte would.
| Yaina wrote:
| I think it's hard to argue that these frameworks are out-of-the
| box faster than using the DOM APIs directly. What they do is
| provide abstractions that lets you scale HTML-interactivity up
| much faster.
|
| Plain-JS DOM manipulation code can become quite complex very
| fast, and I think that's what opens the door for inefficiency
| and also a lot of errors, because it's hard to keep track of
| possible DOM permutations.
| KaoruAoiShiho wrote:
| Svelte is so 2020, the new hotness is SolidJS.
| https://dev.to/ryansolid/solidjs-official-release-the-long-r...
| mncharity wrote:
| 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.
| croes wrote:
| Any good comparison between Svelte and Solid.Js?
| jcuenod wrote:
| Honestly, SolidJS is one of the most exciting options on the
| horizon. The creator wrote the vanillajs implementation for the
| frontend framework benchmarks so he really knows a lot about
| the performance implications of implementation details. The
| great thing about Solid is that it's a lot closer to react with
| hooks and jsx (I feel like Svelte is learning too much non-js
| stuff). The problem is that it also has its gotchas. It's
| _much_ "smarter" than react about re-rendering, which means
| that it memoizes nodes all over the place and doesn't rerender
| the entire tree and diff all the time. Instead, it's only
| rerendering the node that changed (and not even the children of
| that node unless you set up the children correctly--gotcha).
| But look at the benchmarks... it's solid!
|
| I asked Rich Harris (author of Svelte) this:
| https://twitter.com/jamescuenod/status/1326747369480871941?s...
|
| Ryan Carniato (author of Solid) makes some comparisons to
| Svelte here: https://dev.to/ryansolid/5-ways-solidjs-differs-
| from-other-j... and also here:
| https://github.com/solidjs/solid/blob/809fd5b8683e6f8c338961...
| dgellow wrote:
| SvelteKit is 2021 though :)
| lkrubner wrote:
| 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:
|
| 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."
| tarkin2 wrote:
| Browsers have improved to the point where VirtualDOM is basically
| unneeded.
| 8note wrote:
| I'd imagine that over time, depending on browser makers focus,
| either virtual doms or non virtual doms will be faster than the
| other.
|
| It'd be handy to have it as a flippable switch
| Panther34543 wrote:
| I spent part of last Saturday going through the Svelte tutorial,
| and I really liked the framework.
|
| I then was looking at recommendations for building fully
| functional web apps, and the official recommendation was to use
| "Svelte Kit". I began the tutorial for that, and was surprised at
| how the philosophy of that framework seemed to completely
| contradict the core Svelte framework. It was extremely odd and
| unappealing, and killed my newly gained enthusiasm for Svelte.
|
| Has anyone built full web apps _without_ Svelte Kit (previously
| Sapper)?
| arxpoetica wrote:
| You absolutely 100% do not have to use Svelte Kit.
|
| Svelte Kit is just the equivalent of (an opinionated) Next.js,
| Gatsyby, or Nuxt.js framework. Those frameworks are also
| incredibly opinionated on purpose.
| davidwparker wrote:
| I built https://www.listenaddict.com/ with Sapper. It was a
| good experience. That said, all of my other apps are using Kit,
| and I'm finding that experience even nicer.
|
| What did you find unappealing about Kit?
| infogulch wrote:
| macspoofing said elsewhere ITT:
|
| > DOM mutations are not the expensive thing, it's the final
| render.
|
| This is the crux of the issue: Updating the DOM will immediately
| rerender the page, even if there are additional changes that need
| to be made at the same time. So library/framework authors twist
| themselves into pretzels trying to work around the browser
| automatically doing all this unnecessary extra work that
| developers don't even want. Clearly it's a DOM api deficiency;
| there is no api to 'make these 15 changes scattered across the
| DOM all at once', instead each individual change causes a cascade
| of wasted effort repeated until the last change is applied OR
| developers take the nuclear option and just replace the whole
| damn page with a completely new DOM on every frame. Insanity. The
| solution seems obvious to me:
|
| _Browsers should introduce a transactional DOM api_ that is only
| rendered after the transaction is 'committed'. It could be full-
| on transactions like a real DB or something simpler like a
| double-buffered frame swap. This would be relatively easy to
| retrofit into JS apps and frameworks and would enable them to
| effortlessly avoid a huge amount of wasted effort on the part of
| the browser.
| recursivedoubts wrote:
| i don't know the Virtual DOM well enough to say for sure, but
| this appears to be yet further proof that, collectively,
| developers _love_ complexity
|
| they say they dislike complexity
|
| but look at what they do
|
| not at what they say
|
| is it for fear of appearing insufficiently intelligent?
| yuchi wrote:
| @dang please add the (2018) suffix to this article.
| rob wrote:
| Apologies, given that I registered here in 2007 I should have
| known. Been away for a while!
| mhoad wrote:
| This is one of the reasons I am so into Lit (lit.dev). The web
| platform has changed so much the past few years, vDOM made a ton
| a sense back when React first launched and even for many years
| after that. It makes a lot less sense in 2021.
|
| I would even make the same argument for JSX itself. Once again JS
| now have template literals built into it.
|
| For anyone coming from a React background check out this code lab
| to see the difference:
| https://codelabs.developers.google.com/codelabs/lit-2-for-re...
| selimnairb wrote:
| I'm not a JS frameworks expert, too much churn to keep up. I
| learned Angular 2+ a few years ago and found it to be a bit heavy
| weight. Thinking of learning Vue 3 now. Svelte looks interesting
| though. What I am hoping for long term is that the JS/CSS/HTML5
| stack will be mature enough and have enough batteries included
| that I can just write apps using the "standard library" with
| minimal external libraries. Is that the direction things are
| going?
| arenaninja wrote:
| I used React for 3 years and I'm using Angular for 2 years now;
| Angular is super heavy handed and gets in your way
| datavirtue wrote:
| I have professional experience in Angular and it is simply a
| framework for building applications. It hits that out of the
| park.
|
| I genuinely tried React and had to ditch it. Way too much
| drama just to manage state. It is clearly for building
| components, not applications.
|
| I don't think comparing the two is relevant. Angular gets in
| your way if you are just building components but it unleashes
| a deluge of productivity instantly if you need to build an
| application--especially for a team.
| arenaninja wrote:
| To me scaling this Angular codebase has been more
| challenging than it was to scale React codebases for
| collaboration across multiple projects and teams. Going
| through NgModule instead of using plain node packages is my
| main gripe here; coincidentally this is also what gets in
| your way if you're trying to build reusable dumb components
| in Angular
|
| I almost like ngrx because it reduces boilerplate, but I
| don't understand why their createAction helper doesn't
| follow Flux Standard Action; I can't be convinced this
| isn't a design flaw
| recursivedoubts wrote:
| You might want to take a look at the HAT stack:
|
| https://htmx.org - server interactions in HTML
|
| https://alpinejs.dev - small front end tweaks in your HTML
|
| https://tailwindcss.com - styling in your HTML
|
| This is pretty a simple stack that keeps everything in one file
| (for something I am calling Locality of Behavior[1]) and all of
| them are dependency free.
|
| full disclosure: I am the author of htmx
|
| [1] - https://htmx.org/essays/locality-of-behaviour/
| arduinomancer wrote:
| My impression of reading [1] is that its just moving the
| "spooky action at a distance" to a different place.
|
| If I see this:
|
| <button hx-get="/clicked">Click Me</button>
|
| My immediate question is
|
| * What actually executes when I click the button?
|
| * How can I debug the code that sends the GET request?
|
| * How can I customize the GET request and add stuff like
| custom headers?
|
| In the jQuery example all of that is obvious on first glance.
|
| I feel like complexity can't be destroyed, only moved around.
| recursivedoubts wrote:
| Do you feel that way when you see an href on a link? Do you
| feel the need to debug that? If so, how do you do it?
|
| There is an hx-headers attribute to modify headers, or you
| can plug into the events system if need be.
|
| htmx is extending HTML as a hypermedia and, therefore, is a
| very different model than most javascript-based apps today.
|
| I am not sure if complexity can be destroyed (I'd need to
| have a solid definition of complexity to discuss that) but
| it can certainly be managed in different ways, some of
| which are more effective than others for certain problems.
| We don't do web programming in assembly for a reason.
| dstick wrote:
| > This is pretty a simple stack that keeps everything in one
| file (for something I am calling Locality of Behavior[1]) and
| all of them are dependency free.
|
| Not to be "that" guy but what you're describing is a .vue
| file. And with a Vue single file component you have 1
| dependency: Vue. With HAT you have 3. Or am I missing
| something?
| fokinsean wrote:
| HTMX has been on my radar for a little while.
|
| Do you have a starter template with all of these hooked
| together? Or an example repo?
| recursivedoubts wrote:
| There are example projects in a bunch of different back
| ends available here:
|
| https://htmx.org/server-examples/
| bmuon wrote:
| Yes and no.
|
| Browser differences are mostly disappearing, they have gained
| some very good APIs are CSS has gained significant layout
| capabilities with grids and flex. So the need for libraries
| like jQuery for dealing with DOM differences is disappearing.
| New standard libraries like Intl and now Temporal make
| libraries like Moment obsolete.
|
| The web is also gaining a component model with Web Components
| that will help you get some level of sanity when building some
| mildly complex reusable stuff. This is probably very good for
| content heavy sites, which make the majority of the web.
|
| The other part of the web is applications running on top of the
| Web platform. Those still heavily benefit from frameworks.
| Having some amount of sanity when managing state is very much
| welcome. And functional programming models have proven that a
| declarative way of approaching UIs is much better than dealing
| with browser APIs imperatively.
|
| So for some years frameworks will still be useful for certain
| use cases. For the others, we should be embracing Web
| technologies. Maybe with some light libraries like Stencil and
| Catalyst.
| px43 wrote:
| Maybe this is a dumb question from a JS muggle, but the thing
| that kills me about this whole movement to virtual/shadow DOM is
| that it's made the "ctrl+f" search useless on more and more
| websites. Is there a nice way to hook the search function to
| actually look inside elements that haven't been swapped in yet?
| If so, more people should be using it.
| arcturus17 wrote:
| I've experienced this (Reddit comes to mind) but I'm pretty
| sure it's because it aggressively mounts/dismounts things
| on/from the real DOM.
|
| In other words it virtualizes views (like when you have a 1000
| row table and you only render rows 40-50), but this is not the
| same as DOM virtualization.
| moritzwarhier wrote:
| Never had this problem really (doesn't mean that it doesn not
| exist). Is shadow DOM a thing outside of SVGs? For sure it's
| not used by React, Vue etc. MDN is telling me that the upcoming
| Web component spec uses it though, so maybe libraries like
| LitElement use it too?
|
| Sites using React or Vue all seem to be searchable using
| standard CTRL-F for me.
| recursive wrote:
| I suspect this is a reference to the specific feature
| infinite/virtual scroll. The DOM nodes are only materialized
| when you scroll near them. CTRL-F is not able to find text
| that isn't currently in the DOM. If you scroll it into view,
| it suddenly starts working.
| werm82 wrote:
| Virtual DOM is completely different from Shadow DOM. Shadow DOM
| is an isolated DOM of a web component, separate from the global
| DOM.
| [deleted]
| tonymet wrote:
| Is there a good benchmark showing the number of dom nodes vs ui
| latency? React works well for few dom elements but suffers in
| messaging apps where dom count and dependency graph are large and
| complex
| Yaina wrote:
| As users of these web-frameworks it's not really noticeable if
| there is a V-DOM or not I think. The only thing that's really
| noticeable is the smaller bundle size (and maybe performance).
|
| But what I really, really like about Svelte is how refined the
| experience is. I think that's just a natural progression though.
| React got invented, then it got clear that some things have to be
| done again and again (boilerplate code) and some parts of it are
| too complex. Things you can only notice in hindsight. Then Vue
| came along and fixed a lot of these issues (making it beginner
| friendlier and simpler). And now we have svelte which takes the
| learnings and hindsight of Vue and what React did in the meantime
| and improves upon them.
|
| When projects grow, there is always this point where you have to
| start fighting the framework. The magic functions and implicit
| behaviour that makes them so easy to start with suddenly don't
| work for a use-case anymore and you have to almost hack a
| solution within the confines of the framework. Svelte on the
| other hand seems to be a lot more hands-off, a lot more vanilla
| javascript, where so far I didn't have the feeling I needed to
| fight it, even for ideas that were a lot more out of the box.
|
| I started using Vue when it was there where Svelte is now, so I'm
| fairly confident the tooling and larger community support will be
| a lot better in 1 to 2 years ^^
| tyingq wrote:
| I'm somewhat surprised that React won out versus Angular or
| something similar. Because React isn't opinionated about the
| supporting things around it, there seems to be wide variations in
| a React stack and approach from team to team.
|
| More so than I would typically see in any other ecosystem. But
| nobody seems to care. Is is that it makes for a sort of
| meritocracy where people that keep up with the fast changing
| landscape get the best opportunities? Basically, I can't figure
| out why JS developers aren't overwhelmed and frustrated with all
| the choices.
| daok wrote:
| One reason React won over Angular is it relies on JavaScript
| instead of custom templating syntax. E.g. You loop with a
| forEach, not some ng-...
| dsego wrote:
| forEach in react/jsx, are you sure?
| jlokier wrote:
| I think it was:
|
| - The Angular dependency injection stuff seemed rather
| complicated compared with React pragmatism. Using React became
| heavier by the time Redux and other boilerplatish practices
| became widespread, but React had already gained adoption by
| then, and you could still get into it on tiny projects without
| fancy state management.
|
| - The VDOM had articles saying how much faster it was than
| everything else, so it gained a reputation for speed compared
| with the other client-side templating alternatives at the time.
| Angular 1 had a reputation for being slow due to scanning all
| state variables on every refresh. Really React wasn't fast at
| everything, but fast at enough things to get that reputation.
| People who really understood DOM differential updates already
| knew how to do it faster than VDOM, either by hand or with
| smarter differential template compilers, but implementations
| weren't common. Marko and Svelte came along later.
|
| - After years of being trained that separating HTML templates
| and code was the right thing to do for better engineering,
| preferably in separate files, it turns out that was annoying
| and lots of people really liked inlining the dynamic parts of
| HTML directly into code.
| ferdowsi wrote:
| 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.
| holtalanm wrote:
| > 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.
| dstick wrote:
| 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
| holtalanm wrote:
| 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.
| midrus wrote:
| Tell that to my cpu when using the new reddit
| croes wrote:
| It's not only performance, but cpu time and data volume.
| dgellow wrote:
| And battery life.
| datavirtue wrote:
| 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.
| shadofx wrote:
| So it's no surprise why devs choose React over anything less
| plush. They test on desktop, test on their plugged in
| cellphones, and call it good.
| gregoriol wrote:
| 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.
| lamflam wrote:
| 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.
| joppy wrote:
| 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.
| sopooneo wrote:
| For those who have worked on traditional desktop apps (rather
| than web), what underlying paradigm is used for UI updates there?
| I assume all these problems of fast partial updates must have
| been addressed there long ago. So apart from the specifics miasma
| of language and markup formats, how was it done?
|
| I ask in complete earnest, and if I should just be reading some
| particular Wikipedia article I'm grateful for any links.
| christophilus wrote:
| It's been a while, but when I developed Windows applications, I
| generally had a well-defined, observable central data
| structure. You made updates to it in systematic ways, and then
| each important section of your UI would handle updates and
| redraw intelligently.
|
| Sometimes, I'd make use of a component that did this itself,
| but yeah. At least back then, it was a lot of manual wiring.
| Maybe similar to backbonejs in some ways.
|
| The toy video games that I wrote were more React-like, in that
| you would simply update your models, and then a separate
| process would re-render 30-60 times per second. So, as a
| developer, you could really just think in terms of data
| transformations.
|
| Anyway, it's been 15 years since I've done either. I'm not sure
| how modern, native toolkits work. I assume there are decent
| React-like top-down-dataflow approaches these days.
| iaml wrote:
| From my limited experience with c#/xaml and swift apps, it's
| MVC/MVVM mostly, although apple is moving towards react-like
| swiftui.
| preommr wrote:
| I've never really bought into this.
|
| The diffing is mostly an implementation deatil that is abstracted
| away. React could check to see if props.items changed instead of
| the nonsense it does. If it still does that in 2021.
|
| The thing is vue uses getters and setters that would trigger
| direct changes without needing to diff the entire tree. It could
| theoretically be really fast, but it still used a virtual dom,
| and it was around react speeds, give or take.
|
| I am convinced that if react really wanted to, they could make
| optimizations to make it really close to svelte. I remember
| seeing a tweet by Evan You about vue3 being pretty much as fast
| svelte if not slightly faster.
|
| The point is that speed, when it comes to front-end frameworks,
| is a weird thing. There are other factors that are much more
| important like tooling, stability, code style, dealing with
| animations, etc.
|
| Things like svelte's compiler approach are much more interesting
| and unique selling points.
| bmuon wrote:
| > I am convinced that if react really wanted to, they could
| make optimizations to make it really close to svelte
|
| Facebook has been working for a while on Ahead-Of-Time
| compilation for React. Interestingly, it looks like they
| thought the problem was too complicated and they gave up:
|
| > To address this challenge we initially experimented with one
| approach to ahead-of-time (AOT) optimization -- Prepack -- but
| ultimately that direction did not pan out. Specifically, we
| realized that many AOT optimizations don't work because they
| either don't have enough global knowledge or they have too
| little. For example, a component might be static in practice
| because it always receive a constant string from its parent,
| but the compiler can't see that far and thinks the component is
| dynamic. Even when we could make optimizations work, we found
| that they were unpredictable to the developer. Without
| predictability it was hard for developers to rely on them.
|
| Instead they're now experimenting with moving the virtual DOM
| resolution to the server and avoiding sending all the
| "templating" code to the client, which achieves a similar
| result. See https://reactjs.org/blog/2020/12/21/data-fetching-
| with-react....
| flowerlad wrote:
| 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
| vlovich123 wrote:
| The blog ends with
|
| > But it turns out that we can achieve a similar programming
| model without using virtual DOM -- and that's where Svelte comes
| in.
|
| Ok. I'm convinced in principle but is there a follow-on blog that
| describes specifically what Svelte does differently?
| dsego wrote:
| It compiles the code into vanilla JS that directly updates the
| DOM on state changes.
| porpoisemonkey wrote:
| There's a better explanation of the differences here:
| https://svelte.dev/blog/svelte-3-rethinking-reactivity
| Svelte is a component framework -- like React or Vue -- but
| with an important difference. Traditional frameworks allow you
| to write declarative state-driven code, but there's a penalty:
| the browser must do extra work to convert those declarative
| structures into DOM operations, using techniques like that eat
| into your frame budget and tax the garbage collector.
| Instead, Svelte runs at build time, converting your components
| into highly efficient imperative code that surgically updates
| the DOM. As a result, you're able to write ambitious
| applications with excellent performance characteristics.
| TedDoesntTalk wrote:
| Yes, I too was hooked but disappointed there was no link to a
| follow-up article!
| nailer wrote:
| Svelte is:
|
| - smaller (because Svelte doesn't include Svelte in the
| binaries it outputs, but rather a dynamically generated static
| mapping between data and elements)
|
| - better organised (single function components, with the JS,
| HTML and CSS in a single file) - like Vue!
|
| - simpler (name = 'Joe' instead of const [getName, setName] =
| useState(null); setName('joe')). The last one isn't quite true
| as you can't use this in all circumstances -
| fruits.push('pear') won't update fruits, you have to run
| 'fruits = fruits' afterward to trigger the update (there are
| other ways too).
| [deleted]
| bobbylarrybobby wrote:
| 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).
| jchw wrote:
| 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.
| madeofpalk wrote:
| > 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.
| cwillu wrote:
| 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.
| jchw wrote:
| 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.
| vinnymac wrote:
| 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.
| chrismorgan wrote:
| 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).
| alserio wrote:
| 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
| engineeringwoke wrote:
| 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.
| handrous wrote:
| 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.
| fosefx wrote:
| > The part that I think the article misses
|
| The article is about VDOM and nothing else. It does not
| "miss" the part about why react is popular, it simply does
| not discuss it.
| dceddia wrote:
| > 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.
| rich_harris wrote:
| Firstly, as the article emphasises, _diffing_ is far from the
| only issue with virtual DOM. And this isn't about
| microbenchmarks; plenty of people have run up against React's
| performance limits in real world applications and have had to
| spend time engaging in menial optimisation work as a result.
|
| Secondly, you're dismissive of the idea that 'the virtual DOM
| is fast' is a meme (in the original Dawkinian sense; I'm not
| talking about gifs with Impact-typefaced captions), which
| suggests you haven't spent a lot of time around developers on
| places like Twitter and Stack Overflow. This misperception
| _absolutely_ exists, and this article was written to correct
| it, not to 'sell' Svelte.
|
| Svelte isn't intent on 'taking over'. We're quite happy
| providing developers with an alternative to React that enables
| them to write less code and not have to worry about
| performance. That said, I'd argue the 'irrelevant' label is
| somewhat unfair
| (https://twitter.com/swyx/status/1409529125539254277,
| https://2020.stateofjs.com/en-US/technologies/front-end-
| fram...).
| alserio wrote:
| 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.
| apatheticonion wrote:
| I liked Svelte reactivity but the component props are
| unergonomic to use and TypeScript support is lacklustre
| [deleted]
| progx wrote:
| 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?
| mumblemumble wrote:
| > 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.
| hajile wrote:
| 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.
| arcturus17 wrote:
| > 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.
| progx wrote:
| 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.
| macspoofing wrote:
| >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.
| ubercore wrote:
| 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?
| macspoofing wrote:
| >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.
| chrishtr wrote:
| See https://developer.chrome.com/blog/renderingng/ for
| some idea of the scale of investment being made.
| handrous wrote:
| Tons of DOM mutations in a hot loop are slow.
|
| One DOM mutation is faster than one VDOM-to-DOM flow,
| though, of course, since the latter's doing the same thing
| _plus more_. The latter also uses a lot more memory, and
| keeps it around indefinitely unless you want to risk
| performance-killing deallocs and allocs later (I 'm making
| some assumptions there--I'd expect a typical VDOM
| implementation's memory is rarely released, since re-
| building that data structure would be high cost if you need
| it again and largely defeat the purpose).
|
| VDOM's also pure JS in the typical implementation, which is
| going to _tend to be_ slower and (much) less memory
| efficient than getting the fuck out of JS and into the
| browser 's C++ or Rust or whatever, ASAP (React's, for
| instance, is a big ol' tree of JS objects, AFAIK).
|
| If you're often modifying or inserting 10,000 elements per
| update and can't be bothered to somehow batch those
| yourself, virtual DOM is probably a performance win. If the
| count is typically more like 1-10, it's probably overhead.
| In between, shit, I dunno, benchmark it.
| lhorie wrote:
| 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.
| cush wrote:
| > As a general claim, that is a bullshit claim.
|
| How so? It improved on JQuery's performance ten-fold which
| was the "easy" way to webdev at the time.
| mumblemumble wrote:
| > 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.
| darepublic wrote:
| 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.
| imbnwa wrote:
| > 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.
| notJim wrote:
| 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.
| mumblemumble wrote:
| 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(tm), 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.
| nobleach wrote:
| 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.
| mumblemumble wrote:
| Definitely not trying to assume malice. I meant it when I
| said, "unwitting".
| lhorie wrote:
| > reaches for a complicated library way to do it
|
| This is neither here nor there. Some people write awful
| React code too.
|
| > having the level of understanding TO write surgical DOM
| manip code should be a basic floor of ability for any web
| developer
|
| I mean, knowing how to do it is good and all, but knowing
| how to do it _well_ is a rare skill. There 's a ton of
| random performance gotchas to be aware of (like, reading
| a property in the middle of a bunch of writes causing
| double repaints) and frameworks do consistently apply
| optimizations that you as a regular dev would probably
| not ever think of (sorting optimizations being some of
| the least trivial ones).
| catlifeonmars wrote:
| > 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.
| megous wrote:
| 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.
| aidenn0 wrote:
| 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.
| macspoofing wrote:
| >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.
| aidenn0 wrote:
| > 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.
| Quinner wrote:
| 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.
| zozbot234 wrote:
| > 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.
| throwaway894345 wrote:
| > 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?
| kujino wrote:
| 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
| protonimitate wrote:
| > 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.
| progx wrote:
| 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.
| RivieraKid wrote:
| > BUT, Svelte has other problems, especially when you
| heavily use dynamic components, which are easier to handle
| in Vue or React.
|
| Do you have an example?
| mbgerring wrote:
| > 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.
| davidwparker wrote:
| I'd say that the NY Times is pretty good for "at scale".
| arcturus17 wrote:
| 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.
| lhorie wrote:
| 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.
| yladiz wrote:
| > 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.
| protonimitate wrote:
| 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.
| macspoofing wrote:
| >Svelte has been around for a few years now - and I've yet to
| see/hear about an application built with Svelte at scale.
|
| What do you mean 'at scale'. It's a UI framework that runs JS
| and mutates the DOM - there's no issues with 'scale' here.
|
| That Svelte isn't popular is because some frameworks get
| popular and go viral and others don't. That's it.
| protonimitate wrote:
| "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.
| macspoofing wrote:
| >"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.
| handrous wrote:
| 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.
| eagsalazar2 wrote:
| >> 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.
| macspoofing wrote:
| >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.
| eagsalazar2 wrote:
| 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!))
| Marazan wrote:
| Angular was a hot mess and I found it a nightmare to
| program with.
|
| It basically embodied the bad side of JS frameworks pre-
| React.
|
| It managed to take alllll the wrong lessons from Flex.
| darepublic wrote:
| >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.
| duxup wrote:
| >But, this is not how you sell something.
|
| I feel that way about a lot of articles like this. I want to
| know what you do well, I don't want to hear someone complain
| about something else.
|
| Sell me on what you do well and what that means for me.
|
| I work in React a lot and I don't feel like I run into this
| "pure overhead" type concept in the way they describe it and
| thus this article makes me:
|
| 1. Wonder what they're doing in React that they feel this way.
|
| 2. The article quickly becomes much less relevant to whatever
| it is I'm thinking about.
| edave64 wrote:
| > 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.
| slver wrote:
| > 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.
| nailer wrote:
| 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.
| dragosmocrii wrote:
| 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)
| leeoniya wrote:
| also read https://ryansolid.medium.com/components-are-pure-
| overhead-12...
| mvanaltvorst wrote:
| 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.
| shp0ngle wrote:
| 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 have heard that claim myself before.
| Ashanmaril wrote:
| > 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."
| mvanaltvorst wrote:
| You're right! Seems like I skimmed over that part. My point
| still stands, though.
| nailer wrote:
| 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.
| akx wrote:
| This article is from 2018. Plenty of water under the JS bridge
| since then.
| FractalHQ wrote:
| The most important part of Svelte, to me, is that it allows me to
| write web applications in the most elegant possible way. The
| compiler first approach means we get to choose whatever syntax we
| want to make the whole process as enjoyable as possible.
|
| The most brilliant part of Svelte was the decision to stay as
| close to JavaScript as possible, so anyone who knows JS, HTML,
| and CSS knows svelte. Importing any vanilla JS library is plug-
| and-play, meaning the community and ecosystem span the entire JS
| ecosystem. No more x-for-react or y-for-vue.
|
| The unbeatable performance is just a plus for me. The DX is so
| good that building things is incredibly fun, intuitive, and
| headache free. I can't emphasize enough how empowering it is.
|
| It's so exciting seeing the community grow exponentially lately!!
| mtm7 wrote:
| > The DX is so good that building things is incredibly fun,
| intuitive, and headache free. I can't emphasize enough how
| empowering it is.
|
| Yes! I've been a full-time React developer for about 5 years,
| and recently had the chance to try Svelte on a small pet
| project. I'd written most of the project in React and had a
| free weekend so I figured what the heck - let's see how it'd
| look in Svelte. :)
|
| Within a day most of the functionality was in place, and the
| code just felt _beautiful_. I loved that it removed so much
| boilerplate (wrote some examples here[0]), and some of the
| React headaches (like using "Undo" in a controlled <textarea>)
| were just gone. The ergonomics (especially the built-in stores,
| error handling, and <svelte:head>) were lovely surprises!
|
| I'm really bullish on it and so happy it's starting to grow.
|
| [0]: https://mtm.dev/react-vs-svelte
| KronisLV wrote:
| > Importing any vanilla JS library is plug-and-play, meaning
| the community and ecosystem span the entire JS ecosystem. No
| more x-for-react or y-for-vue.
|
| This makes me feel conflicted.
|
| With React/Angular/Vue you're given a stable base upon which to
| build new components and logic, so most of the libraries end up
| being vaguely consistent with the underlying tech.
|
| With JS libraries it's the wild west once again and before you
| know it, your components will need 3 different mechanisms of
| being initialized, their internals will use different
| approaches, before long you'll have multiple versions of jQuery
| in there as well and it'll make you consider the downsides of
| that approach.
|
| But maybe I only have that outlook because I've witnessed many
| such situations of poorly integrated JS libraries and have
| therefore gotten used to walled gardens.
| FractalHQ wrote:
| This is certainly not my experience. I've never had to touch
| a library with jQuery, and the vast majority of libraries
| with framework wrappers also have vanilla implementations.
| The difference being the wrappers need to be updated to keep
| up with the frameworks, and often have more ways to fail
| considering they're often just vanilla libraries + wrapper
| code.
|
| If a library is maintained, the existence of a framework
| wrapper doesn't make it any more reliable in my experience.
| rendall wrote:
| > _With React /Angular/Vue you're given a stable base upon
| which to build new components and logic_
|
| Oh you sweet summer child. Wait until you see the
| multilayered horror of devs insisting on _styled components_
| because they never spent the time to learn the specificity
| rules of CSS; their grabbing at _lowdash debounce_ or _react-
| virtual_ because they don 't have the confidence to build a
| leaner version themselves; suggesting that core concepts of
| the web are outdated because they came up in the Age of
| React.
|
| React/Vue/Angular will not protect you from bloated, poorly
| written apps. I would argue they encourage bad practices.
| cuddlecake wrote:
| > their grabbing at lowdash debounce or react-virtual
| because they don't have the confidence to build a leaner
| version themselves
|
| Yeah let's stop (re-)using open source software and write
| everything ourselves.
|
| Who needs React when we can have cuddlecake's spontaenously
| written mini-framework (I lovingly call it anguvuesveact,
| because I got inspired) that definitely does not provide
| the required feature set or developer experience to support
| a productive professional development process, but it's
| mine.
|
| Now that we have WebAssembly, couldn't we write
| applications in actual Assembly? It just takes confidence
| that we can build something lean with it, no other
| considerations necessary.
|
| Well, uh, I just realized we don't need to rely on Firefox,
| if we just, uh, develop our own browser, uh, from first
| principles. A lean one, to be sure, only providing the
| features we need for our Web App. If we need new features
| we'll build them along the way.
|
| Ah shit, my DIY lodash (I lovingly call it cuddledash,
| because I got inspired) has a bug but I'm focusing on the
| custom browser, so no time to fix that. :/
|
| > React/Vue/Angular will not protect you from bloated,
| poorly written apps.
|
| Only our self-written lodash lib will protect us, hear
| hear.
| yohannparis wrote:
| I agree 100%.
|
| The number of times someone told me they prefer using
| Bootstrap classnames while using CSS when they bootstrap
| does not provide a classname for it... My front-end heart
| sinks!
| jakelazaroff wrote:
| The purpose of styled components (or CSS modules or what
| have you) isn't to deal with specificity. It's to deal with
| collisions between what are essentially global variables.
| rendall wrote:
| I don't think you and I disagree. Use the tool
| appropriate for the job. If the team doesn't have the
| discipline or will to use the cascade as intended,
| definitely, better to have a bloated CSS-in-JS that at
| least is usable, rather than a bloated cascade that
| people are afraid to use.
| rendall wrote:
| Gah, at least it's not Salesforce. That year I spent in a
| Salesforce shop I earned gobs of money and nearly slit my
| wrists. I took the following year off. Learned to play
| ukulele. What a shitty platform. God bless the devs who
| thrive in it.
| IceDane wrote:
| This is an extremely cringey, gatekeepy reply. It's just
| missing a "it's nothing personal, kiddo".
|
| Good on you if you prefer writing everything from scratch.
| Some of us have shit to do and goals to meet and we'd
| rather spend our time on building actual functionality than
| reinvent the wheel for the nth time.
| dimitrios1 wrote:
| Your reply is the real cringe here. "I got shit to do" is
| no excuse to toss aside quality and craftsmanship. And
| you misread their argument they didn't say write
| everything from scratch, they said write a simple leaner
| version, but the argument is most people lack even basic
| problem solving skills. If you spend all your day glueing
| things together, you forget how to design and build them
| yourself. Sure you can stack the blocks in order, and
| make a really tall tower, but how soon until it falls
| over, or how will it withstand the first gust of air.
| That's the larger point. And this isn't "gatekeepy" this
| is reality. As software continues to eat the world, and
| most of us are forced increasingly to rely on these
| shitty apps and interfaces, it could do a little good to
| the world if Software engineering as a discipline took on
| a little more professionalism. So less of the "I got shit
| to do" and "move fast and break things" mentality, and
| more of the "lets do this right" mentality. Good
| engineers can write a little utility that solves a
| problem wonderfully for their context or scope, and still
| get their shit done and meet their goals.
| cuddlecake wrote:
| It's kind of gatekeepy insisting on styled components
| being of lower quality than using pure CSS. Styled
| Components serves a specialized purpose of styling things
| on the web.
|
| Maybe less elegant or performant in some respect than
| pure CSS, but with trade offs that some development teams
| will happily take.
|
| I also hate the sentiment, that software development
| needs to adhere to some notion of purity or divine
| elegance. And yes, I'm using the word divine because
| people like the grandparent comment keep acting like CSS
| is the church. It may well be, for some, but there's a
| reason why CSS is getting new features continuously...
| Because it's not perfect for every purpose across every
| development department.
|
| Talking about this makes me sick.
| rendall wrote:
| Use styled components if they suit your use case, by all
| means.
|
| But if that use case is _We don 't have to learn CSS
| because we can just not think about it with this nifty
| innovation_ then the use case is horrific.
| cuddlecake wrote:
| Eh, I'd say it's a valid use case as any.
|
| Maybe someone just didn't have the time confidence or
| interest to learn CSS. Maybe it's as simple as doing what
| you want, doing what you can afford to do, etc.
|
| What I don't like is the negative framing of this choice.
| Bad things will be built, regardless of the underlying
| tools. Grandparent claimed that using Frameworks results
| in bad practices. I claim that shaming people and
| questioning their choices (whether they made them
| consciously or unconsciously) is a bad practice.
| rendall wrote:
| I dunno. Maybe. How about the practice of removing a test
| that fails? Literally, test fails, remove it, problem
| solved. Ship it. Sure there are build warnings, but CI
| isn't complaining, so..? Is that a valid use case? If
| your team member did that, you'd be cool-and-the-gang,
| easy-like-sunday-morning, shaming-is-the-real-shame?
| cuddlecake wrote:
| You're trying to reframe my argument in a bad way.
|
| I'm talking about people deciding to use a certain
| technology with tradeoffs.
|
| You're talking about people going against quality
| standards of a development team. And that's where I end
| the conversation, you bore me.
| rendall wrote:
| I hear you. It's a balance. You grab a library or open-
| source project, boom! Done. Move on dot org.
|
| Except later, maybe your project needs some custom
| functionality. Now you have to dig into docs to see if
| it's possible, then deeper into the source code to see if
| you can monkey patch using something undocumented. Maybe
| now it takes more time to cobble together what you need
| than wiring something lean from first principles.
| Understood the full import of the dependency from get.
| thunderbong wrote:
| I've commented on Svelte before [0]. Adding the same comment here
| -
|
| >> I've worked on multiple modern JS frameworks and Svelte is the
| closest I can get to mapping my mental model of how a web page
| works (HTML, CSS, JS) with the framework.
|
| Actually, I should correct myself - yes, the breakdown in terms
| of technology is HTML, CSS, JS but the underlying abstraction is
| actually - structure, presentation and functionality.
|
| This is where, imho, Svelte really shines. It helps you to map
| your mental model of structure, presentation and functionality to
| it's corresponding implementation of HTML, CSS, JS with a
| sprinkle of syntactic sugar. This goes way far in keeping the
| code easy to understand and maintainable in my opinion.
|
| [0]: https://news.ycombinator.com/item?id=26723214
| ankurpatel wrote:
| 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.
| antihero wrote:
| Have a look at Astro. It's compiled to static by default and
| then parts that need to be dynamic are hydrated at runtime.
| slumdev wrote:
| Most of the web can and should be static HTML and CSS.
| kfk wrote:
| 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.
| nesarkvechnep wrote:
| Not quick enough, actually
| hallway_monitor wrote:
| 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.
| datavirtue wrote:
| 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).
| dbrueck wrote:
| 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.
| imvetri wrote:
| For anyone who wants to know how svelte handles DOM CRUD look at
| this question I had asked in stackoverlow
| https://stackoverflow.com/questions/56215374/what-is-the-con...
| nextaccountic wrote:
| Okay, but - why does Rust frontend libraries (like Yew and Seed)
| use vdom instead of doing whatever Svelte does?
|
| Actually, is anyone else doing it the Svelte way?
| pcstl wrote:
| Because VDOM is useful for writing declarative code. It's DX
| over UX - and most of the time it won't impact UX anyway.
| posnet wrote:
| There are some VDom-less libraries popping up now.
| https://github.com/sycamore-rs/sycamore
| nextaccountic wrote:
| This is very cool, thanks!
| the__alchemist wrote:
| 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.
| the__alchemist wrote:
| When I learned frontend web work and React years ago, I fell for
| the same "VDOM is fast!" hype, and assumed there was non-JS magic
| under the hood.
|
| I eventually built a VDOM-based frontend WASM framework in Rust
| (Seed).
|
| I now built frontends in HTML and CS, with no frameworks, and
| minimal, targeted JS code to manipulate the DOM directly; it's
| liberating, and much faster than both React and WASM/Rust.
| ehnto wrote:
| It's crazy how quickly frontend UI frameworks became the
| standard approach. They're not necessary in so many instances
| where they are used.
|
| I also found it pretty comical when server side rendering
| became a hot topic, like duh guys, that's what we were doing
| first! Did you forget?
|
| Anyway, it's not that frontend UI frameworks are bad, it's more
| that pragmatism gets thrown out the window so quickly.
| imbnwa wrote:
| Yes, there's a lacking sense of measure in frontend and I
| work in a shop full of people that talk about what framework
| to use for a few buttons, a search form, and a result list.
| CSS is good enough that you can implement a lot of your UI
| state machine with classes as switches and scoped CSS
| variables available with `calc()` for threading particular
| derived values
| the__alchemist wrote:
| It feels like we were coasting on a mentality of "Computation
| is cheap; We're in post-performance-scarcity era; Performance
| doesn't matter since computers are fast". -- Ignoring the
| reality that responsiveness is critical to user experience.
| dsego wrote:
| > I also found it pretty comical when server side rendering
| became a hot topic, like duh guys, that's what we were doing
| first! Did you forget?
|
| A lot of new kids (we call them frontend engineers) haven't
| done the old school way. They just know SPAs, because that's
| what they've been taught in the last decade or so.
| pwdisswordfish8 wrote:
| > Seed
|
| Sigh. https://wiki.gnome.org/Projects/Seed
|
| (JavaScript-related, so not just any random name collision.)
| kgr wrote:
| When we designed to UI library for FOAM in 2011 at Google, we did
| extensive benchmarking, and discovered that DOM calls were very
| slow and that we could greatly improve performance by batching
| them. Yes, in the end, you still need to make DOM calls to update
| the DOM, but you were better off forming all of your DOM's html
| on the JS side and then just make one call to element.innerHTML =
| myHTML and then hookup listeners if necessary. The JS to C++
| bridge was very slow, and so you were better off to make one
| large call and then have C++ parse your HTML and build all of the
| DOM itself than you were to make many small DOM calls adding each
| element and attribute value individually. However, I was recently
| writing a document on the performance advantages of FOAM's
| virtual DOM, but rather than just assert the fact without proof,
| I wrote some benchmarks to demonstrate... that it is in fact no
| longer faster. As a result, we're replacing FOAM's UI library,
| called U2, with a new non-virtual DOM library called U3.
| lhorie wrote:
| innerHTML has been slower than the DOM API for a few years.
| React had a big refactor at one point to rip out innerHTML
| logic precisely due to this. To make matters more interesting,
| the order of DOM API calls also mattered. In IE, building a DOM
| tree bottom up was significantly slower than building it top
| down (meaning, no large document fragments for you!). There are
| also a ton of other quirks: `.textContent = ''` being faster
| than removeChild, appendChild vs insertBefore vs replaceChild,
| childNodes random access, properties being faster than
| attributes (which is a rabbit hole of its own because SVG),
| cloneNode being faster but nigh unusable in a framework
| setting, orders of magnitude difference in performance due to
| data structure polymorphism...
|
| Squeezing performance out of DOM manipulation is really tricky
| because the performance profile of pretty much everything
| changes frequently without rhyme or reason.
| nobleach wrote:
| Not to travel too far off the main topic, but I use this
| exact fact to demonstrate to new developers why I prefer a
| developer that looks things up instead of relying on what
| "everyone knows". When Jeremy Keith's DOM Scripting book was
| written many years ago, it claimed that DOM methods were much
| slower than innerHtml. And that was true. If we all just took
| that as gospel, we'd be WAY off base.
|
| So I'll take the dev that looks things up, as there's much
| more possibility they're operating on more up to date
| information.
|
| Consequently, this is why I also tell people to stop
| repeating "this is a best practice" a year or so after
| something is discovered. It's a "common practice". You don't
| have enough info to know if it's truly "best".
| madhadron wrote:
| In my personal experiments, I ended up using document
| fragments. I wasn't doing FRP, just classic MVC, but a view
| (which was a JavaScript object) had a reference to the DOM
| elements it was responsible for. If it needed to replace them,
| it created a document fragment, did anything that needed to be
| done in there (including having children redraw) and then
| swapped out that fragment. This gave very nice performance.
| cwmma wrote:
| 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.
| jeswin wrote:
| For 95% of apps, Svelte's custom syntax is pure cognitive
| overhead making little difference to the performance of the app.
| FractalHQ wrote:
| 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.
| dgellow wrote:
| Svelte is quite small, you can be effective with it in a
| weekend.
| nobody0 wrote:
| This, that's why React was a bit revolutionary at its time. No
| customized template dsl. Just speak JS.
| slumdev wrote:
| Writing HTML programmatically or using JSX are both
| unfortunate React-isms.
|
| Not saying that Angular's banana box is ideologically
| superior, just that all JS frameworks have idiosyncrasies.
| blacktriangle wrote:
| 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.
| slumdev wrote:
| 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.
| blacktriangle wrote:
| 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.
| slumdev wrote:
| You're right. But how often do you want to rewrite that
| code? It may be worth accepting a few -isms (and the
| associated performance hit) in order to be able to write
| something like this instead of having to bang out the
| imperative version:
|
| <BulletedList [(DataSource)]="MyCollectionProperty" />
| flyingchipmann wrote:
| 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().
| icedchai wrote:
| 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.
| flyingchipmann wrote:
| 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.
| slumdev wrote:
| 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?
| flyingchipmann wrote:
| 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?
| recursive wrote:
| JSX is exactly a customized template DSL. It's not a
| particularly difficult one, but that's exactly what it is.
| dragonwriter wrote:
| > JSX is exactly a customized template DSL.
|
| Yes, but its a template DSL _for JavaScript_ (and TSX is
| one _for TypeScript_ ), not a template DSL _for HTML_.
|
| Building JSX outputs JS, not HTML.
| recursive wrote:
| 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.
| dbrueck wrote:
| I'm curious to better understand what you mean by this (maybe
| an example or two?).
| recursive wrote:
| 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.
| madeofpalk wrote:
| Is it possible to just not think about it? Or is that easier
| said than done?
| recursive wrote:
| 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.
| madeofpalk wrote:
| How did this happen? I've never seen this in practice if
| you weren't doing something "obviously" wrong.
| recursive wrote:
| Here's a minimal-ish repro of the issue I ran in to. It's
| totally possible that I'm doing something "obviously"
| wrong. However, I've spent more than a couple of hours
| reading through docs trying to figure out what it is. I'm
| not seeing it.
|
| https://codepen.io/recursive/pen/XWMLWBZ
|
| If you could point to anything in the docs that I'm
| missing, I'd genuinely appreciate it.
| WickyNilliams wrote:
| 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.
| recursive wrote:
| > 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".
| arcturus17 wrote:
| Everything you say is true for pretty much every
| technology?
| arcturus17 wrote:
| 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.
| scotty79 wrote:
| I think it's perfectly possible if you just don't place
| hooks in a loop or if, which you shouldn't do and are
| warned against.
| millerm wrote:
| Yes, it's completely possible and most people don't think
| about it, at all. It's not complicated.
| wruza wrote:
| And for me, both are unnecessary overcomplicated abstractions
| over mithril+js based _classical_ MVC ( _not_ web-renamed
| one): class App { constructor() {
| this.message = 'Hello' this.foo = new Foo
| this.show_foo = true } bye() {
| this.message = 'Bye' this.show_foo = false
| } } class AppView {
| view({attrs:{app}}) { const attrs = {
| onclick: (e) => app.bye(), } return
| m('div.container', [ m('h1', attrs, 'Hello!'),
| (app.show_foo ? m(FooView, {foo:app.foo}),
| : null), this.render_footer(app), ])
| } render_footer(app) { return m(...)
| } } window.app = new App
| m.mount(document.all.root, { view: () => m(AppView,
| {app})) })
| slumdev wrote:
| The most important line:
|
| > It's important to understand that virtual DOM isn't a feature.
| It's a means to an end, the end being declarative, state-driven
| UI development.
|
| Declarative, state-driven UI development is a valuable
| abstraction.
|
| I really hope readers take this to heart, rather than the article
| title becoming a new meme.
| recursive wrote:
| 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.
| WillDaSilva wrote:
| They note right after that:
|
| > it turns out that we can achieve a similar programming model
| without using virtual DOM -- and that's where Svelte comes in
|
| The abstraction is valuable, but its cost need not be so high.
| I do wish they'd elaborate on what Svelte does differently
| though, or link to another post which elaborates.
| slumdev wrote:
| The front page of their website proclaims Svelte to be
| "Cybernetically enhanced web apps", whatever that means.
|
| The "Rethinking" post gives a little more detail:
|
| > Instead, Svelte runs at build time, converting your
| components into highly efficient imperative code that
| surgically updates the DOM. As a result, you're able to write
| ambitious applications with excellent performance
| characteristics.
|
| https://svelte.dev/blog/svelte-3-rethinking-reactivity
|
| Seems like a great idea, if it can gain the critical mass
| required and build a community of people developing code for
| it.
| wruza wrote:
| _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.
| strangescript wrote:
| Time and again it has been proven that the number one metric for
| success of a language or framework is developer experience.
|
| Javascript was a meme language, but it was easy to use and highly
| accessible. Now its everywhere, in everything, including places
| it has no business being.
|
| React has become that for frontend development. React is easier
| to use than Svelte. I got excited when I first learned of it, but
| its awkward to use at times and far more quirky than React.
|
| As others have pointed out, that bleeding edge performance is
| only as great as what you are building. If you don't need to
| update the DOM multiple times a second, then it barely matters.
| ehnto wrote:
| I think it's ubiquitousness, not developer experience, but
| perhaps that's what you meant. Both PHP and Javascript are
| examples of that. PHP wasn't nicer to use than other languages,
| it was just available to everyone. They're also both
| unencumbered by the aspirations of software engineering. The
| language doesn't care that you're writing untyped, procedural
| spaghetti code, they're very forgiving and so are the community
| and ecosystem.
| mvolfik wrote:
| Where do you find React easier to use than Svelte? I did mostly
| backend and simple pure-JS frontends before and never picked up
| react because of how long the tutorial was and how messy the
| tooling felt. Svelte was a breeze in both of this and I didn't
| experience larger issues yet, so I'm curious what I'm missing
| out on?
| madacol wrote:
| I'd argue that Svelte is easier for beginners or simple
| stuffs, the tutorial is miles better than react's.
|
| But of course, for complex stuffs, react's bigger community
| becomes to the rescue with many edge-cases solutions
| FractalHQ wrote:
| That's surprising, because the overwhelming consensus among
| anyone I've spoken to with significant experience in both seems
| to emphasize the vastly improved DX of Svelte over its
| predecessors. State management is trivial, and the amount of
| code needed to accomplish anything is significantly less in
| Svelte.
|
| I'm curious- how much experience do you have with Svelte and
| what in particular do you find it makes more difficult or
| convoluted than React?
| ar_lan wrote:
| > but it was easy to use
|
| I disagree. I've found Javascript to be quite complicated.
|
| However, I agree with your takes that:
|
| 1. It's highly accessible - yes, you can learn a single
| language and get away with only knowing that language for a
| good chunk of your career nowadays.
|
| 2. It does involve fairly immediate feedback (somewhat akin to
| Python in that regard), because it's interpreted. Given that
| it's also _visual_ , and a strong majority of people equate the
| internet to solely what you see in a browser, it's a pretty
| gratifying experience (even if, later in your career, you avoid
| it like the plague).
| throwaway894345 wrote:
| > Javascript was a meme language, but it was easy to use and
| highly accessible. Now its everywhere, in everything, including
| places it has no business being.
|
| JavaScript is the wrong example. It didn't succeed on merit,
| but because it was the sole language available for the web
| platform for the entire history of the web until recently and
| even now it enjoys significant "unfair" advantages (browsers
| only expose DOM APIs to JavaScript, the JS standard library is
| baked into the browser while other languages must ship their
| own over the network, etc).
| SquareWheel wrote:
| While never widely adopted, VBScript was able to be ran in
| script tags in Internet Explorer.
| throwaway894345 wrote:
| I fully believe that JS is better than VBScript, but it's
| also possible that many other factors contributed to JS's
| triumph over VBScript. In whichever case, this is pretty
| weak evidence for the claim "JS won its popularity
| _relative to other languages_ by merit " (presumably you
| weren't intending it to be strong evidence).
| SquareWheel wrote:
| I was only commenting on the claim that JavaScript was
| the "sole language available for the web platform".
| throwaway894345 wrote:
| Fair enough, thanks for clarifying. :)
| obphuscate wrote:
| 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.
| joppy wrote:
| " 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.
| dvdcxn wrote:
| I think this 3 year old topic needs to be revisted considering
| the improvements that Concurrent mode will provide.
| AshleysBrain wrote:
| 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.
| onion2k wrote:
| _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.
| madeofpalk wrote:
| > you need to eliminate all redundant calls and operations
|
| this is a no-brainer, right? The tricky part is _how_ you
| identify redundant calls and eliminate them, knowing that some
| have more cost than others.
| ElViajero wrote:
| 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.
| jakelazaroff wrote:
| 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.
| mumblemumble wrote:
| 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.
| paavohtl wrote:
| 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.
| mumblemumble wrote:
| 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?
| icedchai wrote:
| 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.
| jacob019 wrote:
| Vanilla JS gets messy as your app scales. You will end up
| building a framework.
| mumblemumble wrote:
| 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.
| ehnto wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-29 23:02 UTC)