Hacker News Reader

Comment by Philip-J-Fry | Hacker News Reader

The thing I enjoy about frameworks like React is the declarative nature of the UIs.

I'd love to not be able to use them and to create complex UIs in pure JavaScript but it always ends up being painful where you spend more time optimising the rendering than doing any work.

In simple apps I will write UI in a functional matter in pure JavaScript, regardless of the performance implications. But bigger DOM means worse performance with this method.

When will we get to the point where we can tell the browser what we want the DOM to look like and then the browser does the diffing like a framework would?

View on HN

There’s absolutely no way you’ll have worse performance with this vs React. The app is modifying the target elements directly, not recreating the whole page with innerHTML. React will do the same amount of work at a minimum, and that’s after rebuilding the whole tree and diffing it.

The main bottleneck here are the synchronous localStorage calls happening in the render path, they could be moved to a separate timer.

It seems like you didnt actually look at the code because thats exactly what its doing: https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js... it clears innerHTML there and then rerenders the children

Right but proper manual dom is generally faster than optimized react code. That does not means that in general manual dom code is proper.

I did this style to mimick modern framework code — taking the state (todos) and render the state of the world every time. If the browser had a DOM diffing api this would be more efficient and we would be there. So for a larger project I might using something like Lit’s html stand-alone package or fastdom to get the DOM digging functionality without much dependency code.

You’re right, I did a quick reading and thought it was updating elements one by one.

I still suspect this might be faster than React anyway. Would be interesting to try.

> There’s absolutely no way you’ll have worse performance with this vs React.

It's normal to get much worse performance than React if you layout thrash and it's very easy to layout thrash without batched updates. There's overhead in the vdom but getting all the updates batched tends to be a performance win in any decent sized app. This was an active area of library exploration/development in the 2008-2012 timeframe but the only framework actively promoting it was Sencha IIRC.

I never suggested you'd have worse performance. But it's not declarative, it's tedious.

Read my comment again.

One way React can be faster than hand-written code is by batching all dom manipulation into animation frames.

The rendering code here is already batched since everything happens within a single render() call. And unless you’re using react fiber, its rendering is also synchronous.

Handwritten JS could also batch DOM manipulation (without the need for virtual dom comparison).

https://github.com/wilsonpage/fastdom

Ooo fastdom looks great! Thanks for the link.

https://www.youtube.com/watch?v=VKMw2it8dQY

Echoes of Alan Kay's recent comment on how software devs are way too concerned with the how the computer works to the detriment of what the software is supposed to do.

Yup. The reality is that programmer time is far far more expensive than compute time. And as long as that's the case, increasing levels of abstraction are our only hope at building complex software.

Programmer time is more important than their computer time, sure. Not sure that programmer time is always more expensive than the compute time of all the users of the software added up.

Yep because software devs is in the business of making money, while Alan Kay is in the business of smugly commenting from the side lines. He has very little understanding on what matters in the commercial world of software.

The battle is fought over performance and size, I think that's exactly what the user wants.

I don’t think the typical user cares about size.

I agree. In over 20 years I've never had a single user ask or complain about the size of the app. They have let me know when there was something not working right though.

People definitely notice speed and performance. They won’t complain about it generally, sure… but there’s plenty of data and case studies on the fact that users care https://nitropack.io/blog/post/web-performance-matters-case-...

>People definitely notice speed and performance.

There's sort of a "Maslow's Hierarchy of User Needs" that exists in software though. So long as the user can do something, and their immediate needs are met, performance concerns are just a small annoyance. And generally they will continue to ask for more features rather than performance improvements as long as the app remains usable.

Well then you've never seen poor people uninstalling apps from their cheap smartphones because they need to install and use a different one ;-) that you don't see it doesn't mean it's not there

it sounds sort of wild to expect there to be diffing! why do you have to generate a whole copy of the stuff instead of just telling the browser what changes to make? bonus: the existing apis instead of one that don't exist yet.

Because it can be automated? Every app that doesn't do this is just implementing the diff by hand, e.g. on this event delete this element, update this element, add CSS class to this element, etc. When the UI gets complicated you have to maintain this all yourself and it's a pain. Multiple event listeners between components to say something has happened.

It makes sense to be able to describe what you want to achieve and to let the browser determine how to get there in the most efficient way.

If the browser could do this it would make a tonne of JS code so much simpler. There's a lot that goes into making sure that there's no unnecessary DOM updates because it's just slow.

I don't write assembly and move things between registers by hand, I write a function and the compiler decides the most efficient way of doing it. UI should be the same way, I say what I want to happen and the browser decides how to get there.

Yes, but there are ways to accomplish this automation without diffing. Svelte does this by statically wiring up the data dependencies in your app when it builds, and then at runtime making exactly the changes to the DOM that it needs to based on the information it had at build time. No need to diff.

The point is that A) that's a framework and B) that requires you to compile Svelte files.

If you want to write declarative UI in pure JS then you need the browser to do these DOM optimisations for you, and diffing the changes is the way to do that.

> When the UI gets complicated you have to maintain this all yourself and it's a pain

This is also something that can be automated by a framework. Check out https://svelte.dev/blog/virtual-dom-is-pure-overhead

Yes... but that's the exact argument I'm making here. Unless you want to go through that pain, you need a framework.

Whether that's Svelte without a VDOM or React with a VDOM. The entire point of these frameworks is that you can write complex UI in a declarative way. They both exist because writing it declaratively in pure JS leads to performance issues. But there's nothing stopping the browser implementing something that does this optimisation for you.

I find the "pain" to be drastically overstated. See this HN post.

I mean, it’s clear that with a single view, it’s possible to manage this without too much trouble. But next to no apps are single views. And any project that has multiple people working on it is going to have multiple views and features which all interact in interesting ways. It’s definitely not overstated. Try writing a moderately involved app yourself in plain JS! It does get to be a pain, I’ve done it! By the time you finish, you’ll have likely created some level of abstractions, and invented yourself a nice new JS framework for yourself ;)

Diffing seems necessary when your UI gets complicated to the level that a small change requires a full page re-render. However, I don't think this is necessary for at least 95% of the websites on the internet.

Diffing is exactly what you need to do (barring newer methods like svelte) to figure out what to tell the browser to change. The vdom tree is much faster to manipulate than DOM nodes.

But you can't see those changes until the actual DOM changes as well. It's only because of react's insistence that mutation is evil that this became a problem. You could just directly update the thing you wanted to and just skip the whole diff thing.

No, the reason React has a VDOM is because the DOM is slow to update, compared to manipulating javascript objects. It's worthwhile to calculate the list of minimum updates ahead of time rather than using the DOM as the source of truth.

Not sure where you think mutation comes into play here, that's an orthogonal concern—you can have an API that mutates some internal representation of a VDOM, and it's still faster than manipulating the DOM directly.

In order to achieve immutability, large chunks of state have to be cloned whenever a single value changes. This sometimes causes a whole new DOM node to be created during reconciliation. React encourages you not to think about it too much. But some nodes can't be replaced. Like canvas or anything contentEditable. It's not orthogonal. It's a direct consequence of the design philosophy.

Cases where "UI should be a function of state" seem like a small sliver of all use cases. Probably not worth the complexity for implementing directly in the browser. And there are plenty of conditions that just prohibit the pattern entirely as far as I can tell. Things where referential stability matters, like you have a contentEditable or allow arbitrary edits on a canvas.

> Cases where "UI should be a function of state" seem like a small sliver of all use cases.

Maybe not “should”, but it’s an incredibly helpful mental model, and I can think of very few cases it can’t model correctly. It’s so helpful a model that it’s gained traction in Rust, Swift, Kotlin, Dart, Go. It’s the ~only model in Clojure and and literally the foundation of Elm.

None of these cases, AFAIK, apply the model literally when they interface with inherently imperative APIs. They provide APIs expressing the model, and manage the imperative behavior on your behalf. This is ultimately how all functions in meaningful programming work. At the end of the day, allocating memory or displaying output is a side effect.

This is also how you can have custom renderers like those used in ink, three-solid, even React Native. The code is modeled as a declarative function of state, implemented as a set of imperative behaviors corresponding to state and dependency changes.

I’ve worked on contentEditable solutions in the past, probably more than most people who didn’t ultimately produce a library from the work (I went mad, literally angry at the complexity of making it a good UX, and gave up). I hope I never have that task again, but if I do… you can bet your ass I’d use a function of state model. It’s the only way I could reason about the problem without going mad.

Personally I would argue that UI should always be a function of state. When it isn’t, you open yourself up to all sorts of inconsistencies and difficult edge cases. Of course, it’s not always that easy; having two sources for said UI (the HTML document itself and the JavaScript within it) certainly complicates matters.

For what it’s worth, even using “vanilla” JS it’s generally much easier than it’s made out to be. It requires design discipline and knowing ahead of time what discipline to apply. But it’s pretty simple once you know it:

- the UI isn’t a source of truth, it’s a computed interface to it

- changes/interactions in the UI should update the source of truth, not other parts of the UI

- the source of truth is fully responsible for managing and notifying dependencies of relevant changes

Or much shorter: state and presentation are separate concerns. Once you have that, you can focus on the actual problems you’re trying to solve rather than the ones created by crossing underlying technology boundaries.

i agree it's up to the browsers chromium , Safari , and Firefox to do the diff. But we might need a new meta tag or change to the Fetch API to tell them this html page should only update the elements that are different.

Remember <meta http-equiv="refresh" content="5"> .

It was discouraged because the back button broke. If you're developing a single page react app, I don't think you care about the back button.

> If you're developing a single page react app, I don't think you care about the back button.

You should though. One easy way is to use react-router. e.g. going to /profile renders the Profile component. Then navigating to /dashboard renders the Dashboard component. Pressing the back button will take you to /profile.

Another pet peeve of mine is people using internal react state when they should just use path or query params to make it transparent and easily sharable.

> If you're developing a single page react app, I don't think you care about the back button.

Your users likely do, so you should too.

The primitives of fine grained reactive programming seem to me more amenable to be implemented by the browser than react-style whole world diffing

Reply on news.ycombinator.com