Earlier quoted context omitted.
S/handles/handled
You can edit your posts after you have posted them
The edit window had already expired.
Virtual DOM is pure overhead (2018)
281–290 of 344 posts
Re: Virtual DOM is pure overhead (2018)
#282Earlier quoted context omitted.
My god, it finally all makes sense! And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I h…
> perfect automatic horizontal scaling Nothing is perfect, but aws aurora serverless auto scales compute and storage for MySQL https://aws.amazon.com/rds/aurora/serverless/
Isn't there downtime involved in Aurora's auto scaling?
Does that than really fit the "auto" bit of the term?
Re: Virtual DOM is pure overhead (2018)
#283Earlier quoted context omitted.
> There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that... How is this different than the "non-trivial" transformations that V8 makes to actually compile and run your code? Does svelte do unpredictable / unexpected things? Don't you make runtime calls to…
I don't actually have a strong aversion to compilers. I use tools like Babel and Webpack regularly. However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Source maps can only do so much. It's much harder to debug code that doesn't resemble what you wrote in the first place.
On the other hand, VDOM is a type of transformation that makes it extremely difficult to debug events sometimes.
Re: Virtual DOM is pure overhead (2018)
#284Direct manipulations of DOM are expensive. It is vastly more cheaper to create or update JS object than create or manipulate DOM node. So the claim that VirtualDom is always an overhead is not true. The diff algorithm can give a set of DOM operations that are less expensive than typical sequence of manual mutations. So virtual DOM can be faster if savings from less DOM operations are bigger than extra JS work. Surely…
Seems like the author - and a lot of people here - have failed to realize this. This is the real benefit in DOM manipulations with VDOM.
the author and others did not avocate manual DOM manipulations. He wrote a framework that can generate optimal DOM manipulation code without the need of a virtual DOM.
Re: Virtual DOM is pure overhead (2018)
#285Earlier quoted context omitted.
> where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines The DOM is fast enough for desktop apps @60 or even 90 frames per second, especially of you follow best practices (no framework required)
If it is fast enough, why is everyone optimizing?
For an individual developer it is not obvious how you should structure your usage of the DOM API to avoid the performance potholes and other problems. Even a team of experts in the DOM will sometimes take shortcuts or one expert's technique doesn't play nicely with another's.
Some parts of the DOM are extremely slow if the API is used naturally, and obvious usage of the API has other side-effect penalties (e.g. stored state, difficult component destruction, or reference loops causing memory blowouts).
So the vast majority of developers use the native DOM in such a way that the page is slow and buggy.
React et al provide a clean API that avoids the worst performance problems, while providing a framework that steers a team towards good practices, so the average developer can be productive.
The framework has a bunch of extra overhead, but the overhead is far less than the average overhead of not using the framework.
Re: Virtual DOM is pure overhead (2018)
#286Earlier quoted context omitted.
Before anybody runs away and thinks there's a fundamental insight here, I have to say that all that's really changing is who owns the retained model: application or UI library. I mean retained by contrast with immediate, as in the early DirectX jargon. By retained model, I mean the source of truth as to the current state of the UI. Games normally use an immediate mode API, but they still render the UI from a model; i…
How are these other state concerns you mention (e.g., focus) handles in immediate mode GUIs? Do the components retain those states or do you keep a separate model for those states that needs to interact with the application model? If so, how is that interaction wired up?
I would argue that the state of the global model includes some information about the state of a widget (e.g. selected="true") and some state is unique to the widget itself (hover).
The trick here is how do you reconcile those two states when both have a copy of the data. For instance, the holds its own state and you hold the value in the global state. When a user types a character into the input, the input hold a copy of the letter in its "value", and the state is updated with the same value, which then triggers the input to compare its state with that of the global state for equality before attempting to render the value in the global state. Tricky stuff.
Re: Virtual DOM is pure overhead (2018)
#287Earlier quoted context omitted.
Pricing aside (as it's almost unreasonably expansive if your app requires frequent db writes), firestore is indeed "A magical database that has perfect automatic horizontal scaling". But as you have your happy setup on aws it probably makes little sense to switch.
Yeah there are a few in that category also Google Cloud Spanner and the stuff by CitusData. All of them work, but are prohibitively expensive to get started. I've harangued them a number of times about how people aren't going to want to use something they can't scale up from $1/month to $10000/month without migrating any data (that's the whole point of an auto-scaling horizontal service imo), but so far no changes fr…
$90/month is really not that much, it's like an m5.large on AWS which is pretty much the minimum for a medium/high traffic website. Well, I guess the scene might have changed since they introduced t2 unlimited, but that would only take it down to $40/month. Support costs are still there for a $5/month user.
Re: Virtual DOM is pure overhead (2018)
#288I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'. But frankly, what I see in virtual DOM is not about speed. It's a declarative interface, an abstraction. It's more like a blueprint that's easier to interpret across different environments like React Native, WebGL. Even if you don't need any of these cross-platform benefits it's still good for tes…
I work on one with React that is too slow in the browser with a team that only has senior devs, and users even filed bugs about the performance - we do heavy computations, and React's model of blocking rendering on having everything updated can freeze our UI for up to 10s while data comes in from various API requests. I believe our app would be performing much better for the end user if we were using Angular 2+ inter…
I don't understand what this has to do with React. You are sending 2MB of data to the frontend. Can you paginate it? Request a subset?
If you are fetching data from multiple endpoints and waiting to render anything until ALL of them come back, that has nothing to do with React. You can start rendering the components that already have their data as soon as it comes back, not wait for all of the other components to have fetched.
Re: Virtual DOM is pure overhead (2018)
#289Earlier quoted context omitted.
My god, it finally all makes sense! And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I h…
Pricing aside (as it's almost unreasonably expansive if your app requires frequent db writes), firestore is indeed "A magical database that has perfect automatic horizontal scaling". But as you have your happy setup on aws it probably makes little sense to switch.
> But as you have your happy setup on aws it probably makes little sense to switch.
TBH I lean more towards google cloud services in general, so as long as they had very good ping times between each other, I'd consider it.
Re: Virtual DOM is pure overhead (2018)
#290Earlier quoted context omitted.
Yeah there are a few in that category also Google Cloud Spanner and the stuff by CitusData. All of them work, but are prohibitively expensive to get started. I've harangued them a number of times about how people aren't going to want to use something they can't scale up from $1/month to $10000/month without migrating any data (that's the whole point of an auto-scaling horizontal service imo), but so far no changes fr…
Hmm I wonder if spanner has more minimum hardware costs or something. Like if they have to provision you at least one standalone atomic clock to get started.
But like that's sort of my point. They could have data default to going into a tiny VPS slice that would be free-tier territory, and then automatically move it to whatever infrastructure spanner requires when the time comes. That could all be seamless. Why keep the seams in?