Hacker News Reader

> Observables+DOM elements is a leaky abstraction

The DOM itself is also a leaky abstraction. Render cycles are so prohibitively slow that we've started maintaining a parallel DOM and implementing diffing algorithms in JavaScript. As brilliant as that may be, it's also crazy that it's come to that.

This is a problem that should be solved in the browser. HTML5 should add a simple API to transactionally update the DOM and only render after all changes are committed. This would prevent every single framework from having to implement this logic.

Seeing as how ES6/7, HTML5 and CSS3 specs haven't been afraid to incorporate ideas that started in external libraries, I do hope we see this baked directly into the browser at some point.

For what it's worth, transactional DOM update is a fantastic idea that I hadn't heard before your comment. Are you familiar with anyone actively exploring such a thing?

The DOM _is_ only rendered after your JavaScript is finished running - as long as you don't ask for properties that can only be known By rendering it out.

It's not "crazy", it's basically just double buffering, a technique that has been around for a very long time.

I remember React devs saying they always remember about that, so the whole library is designed to be easily detachable from the DOM, or whatever renderer you might be using. They're also kind of proving that now with ReactNative, and knowing what's coming in the next React versions it's gonna be even better.

Nice thing about React is that even after you remove the Virtual DOM it still encourages a really good model of programming and makes it effortless to build your app.

The little time I've spent learning Mithril [1] makes me think it's a nice middle ground between speed and pleasurable coding experience.

Their benchmarks have it at 8x faster at rendering (uncompiled) and 28x faster to load (although Benchmarks Lie (TM)).

It feels like writing vanilla javascript for the most part, which is delightful and exciting. The Views part however, which is most comparable with React since React only deals with views, is extremely reminiscent of React, and you can even write MSX, which is just basically JSX with some subtle differences.

[1] http://mithril.js.org/

EDIT: Link

Mithril is awesome (been using it for 7 months now). I really like that they finally have implemented components and described how they should be made.

Whats the situation about components now? Last time I checked this a while ago React would encourage having lots of components with internal state and calling setState on a subcomponent would only update the DOM on that subtree. On the other hand, most other virtualdom frameworks they would encourage you to keep a single global model object to describe the whole page.

"It feels like writing vanilla javascript for the most part, which is delightful and exciting." - this sentence makes me shiver.

That being said, this looks interesting, thanks for bringing it to attention!

ahaha I understand why it would. I meant that the framework is extremely unobtrusive. All you do is create the beautiful expressive javascript objects which act as your models and controls, and then you just mount it with a mithril command, and that's it!

The leaky abstraction thing is at the core of everything that is wrong the the AngularJS model. I still like a number of things about AngularJS, but the data-binding model was really poorly thought out and implemented.

As far as I can tell this has been recognized even by the core team and is a major reason for the sizeable changes in 2.0. It surprises me how many people in the community continue to defend it as "OK" when even the AngularJS team has arguably admitted it's mistakes.

There's an interesting video by Netflix where they discuss using React in their stack. To increase performance on many of Netflix's TV or Console based UI's they have their own rendering engine they're using instead of the manufacturer's browser engine. This means any of React's "speed" improvements are a moot point so instead they use it because of its simplicity for UI layouts.

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

Along that line of thinking, Flipboard created React Canvas, which renders directly into a <canvas> tag, bypassing a lot of the DOM:

https://github.com/Flipboard/react-canvas

I just have to add that this is how pages were generated server-side before XmlHttpRequest emerged. This was deliberate. Addressable and re-loadable states were part of the original design by Tim Berners-Lee. The fact that we have had this whole circus with mutable state on the client side is just a joke to me. I hope that someone invents a sane client-side lib with sane page generation quite soon. Should certainly be possible.

Oh and not even performance-critical stuff like video games deal with the big mess that is mutable state. If game devs redraw their stuff at 100+ FPS and haven't needed mutable state, how come that web devs fall right into that trap? Crazy.

I'm no AAA game dev but I'm pretty sure games are all about mutable state. I'd love to see some examples of what you're talking about.

Sorry I should have said view state.

The DOM is not a view. In fact it stands for Document Object Model :P I know it's confusing since it's where you create the view for your app, but the DOM is actually a model of your view (i.e. the V on your app's MVC is built manipulating the M on the browser's MVC).

Why can't the web draw at 100 FPS from immutable data? Because the web renders through constraints based on the DOM, and constraints cascade, which is a problem more akin to physics in games (which are mutable for a reason) than their graphics. The bottleneck is updating such model.

Also, game physics constraints are usually faster to calculate because action at a distance is unusual and there are optimizations like quad-trees. In web pages, inserting a single DOM node can trigger a huge change, making it more like simulating hydrodynamics that the common solids found in videogames.

You bring up some interesting points. I guess you could compare the DOM to the OpenGL/DirectX scene, with some differences. I'm not entirely convinced that the graphics rendering is less complex though, considering occlusion lightning etc. My main point was really yhat re-building the entire scene is entirely possible and a lot easier to code than manipulating a stateful scene.

I guess physics is stateful since the programmer only sets initial conditions and the engine moves it forward, so the final state is unknown to the programmer.

Dom is a fine tool but I would like a better separation between the model and the view, which re-rendering gives you in a straightforward way. The other way is data binding, but it's considerably more involved and probably not worth it for 99% of the cases IMO.

> If game devs redraw their stuff at 100+ FPS and haven't needed mutable state

Well I wouldn't quite say that... although there was a time when "dirty rectangles" was an important feature of a graphics engine. Generally speaking, games are based on mutation of entities: to move an existing entity, we mutate their position, not recreate them in the new position.

Sorry I should have said view state. Dirty rectangles are indeed such an optimization, you are right.

Generally speaking, games are based on mutation of entities: to move an existing entity, we mutate their position, not recreate them in the new position.

Actually, games are generally an area where immutability is relatively easy to use. All of the mutation code can be isolated in one place that handles the transition to the next "tick", leaving nothing but immutables in the game logic itself. This is analogous to how ReactJS manages things through diffing.

Conceptually it's very easy:

World(t+1) = Sim(World(t))

but performance in practice is going to suffer a lot compared to in-place mutation, for any simulation that has a great degree of temporal coherence. I don't know of real world examples of game developed with immutable / reactive patterns, outside of thought experiments like Carmack's (Or Tim Sweeney's), or a few simple games in Haskell, Elm, etc. But I'd love to hear of more examples.

(Edit: some parts of games and game engines use this sort of "double buffer" approach for other purposes: smoothing and interpolation mostly, of visual frames in between logic ticks, or for network prediction. But in the cases I have seen or coded, most of the world state is not interpolated and not duplicated)

I am not yet a professional game developer, but I did write a multiplayer server in Clojure. It had most of the features of the current version, which was ported to golang:

https://secure.emergencevector.com:8000/

(Be sure to mouse click on the map, otherwise your arrow key keystrokes may never get read due to focus.)

I got pretty similar performance out of Clojure's persistent collections as I got out of mutable state in a traditional game loop in golang. (Though to be honest, in neither case was that enough performance. 150 to 250 concurrent users, potentially all in the same location, interacting.)

Well... I'm not expecting to do both, and get 100fps on the client while also doing all the processing serverside.

> I hope that someone invents a sane client-side lib with sane page generation quite soon. Should certainly be possible.

No good libraries that I know of yet but people are already doing it, at least I am: https://groups.google.com/d/msg/clojurescript/T6no_srtBzc/8o...

> I hope that someone invents a sane client-side lib with sane page generation quite soon.

Can you explain more fully what you mean by "sane page generation" please? I am not getting your drift, apart from wondering if you want a return to 1990's static HTML pages...

The author however has focused specifically on the often read speed advantages. They use it themselves and he apparently likes it.

I guess the point I'm getting at is that the virtual DOM's speed is really just the answer to the question "But isn't re-rendering the whole world over and over really slow?" Which is the first thing anyone deeply familiar with web UIs would ask.

It's the solution to a problem that arises when you move to this programming model. It's the programming model that's the real advantage. The virtual DOM's speed is worth mentioning because it remedies what would otherwise make React completely impractical in the real world.

Virtual DOM makes rendering fast, but it has extra costs in eventing and in javascript timers. Virtual DOM is not free IMHO.

Some quantitative results - http://blog.nparashuram.com/2015/03/performance-comparison-o...

Ugh, React people... Please stop saying "Reason about". Did you ever use that phrase even once in your life before you started using React? Just say that the code is more understandable or whatever.

I agree completely - I've been recently using React to build a static website, and it's a joy to use over standard HTML, or something rendered server side. Being able to split apart the different parts of your page into small components makes it easy to reason about without needing to take an entire page in.

The fact that you can then transfer that to a dynamic website with reasonably good performance is huge IMO.

> DOM diffing isn't there to make React faster than everything else ever imagined.

This is not how React has been sold.

I've been following the rise of React fairly closely and the speed thing has never felt oversold to me. It was more: "Faster than angular on complex pages unless you jump through lots of hoops" and that still seems fairly reasonable.

I've seen several React talks given by Facebook people and the pitch they make is that React makes things simpler to reason about with acceptable out of the box performance (and levers to make it faster as needed). There may be some people pitching the speed angle, but I don't think it's the Facebook people.

I disagree. The main message I got was never "React faster than everything" it was rather "React makes complete DOM re-renders fast".

This is the ONLY way I hear about it being sold.

I completely agree. Trying out react and learning how to structure things with it. It all just felt natural.

> pleasant to work with

if you're a startup or small shop.

if you have to deal with any native code that expects to know something about the dom, now you just forced that code to do expensive and constant polling algos because you completely pulled the dom from under its feet.

> small shop

Like Facebook? Netflix? The BBC?

netflix = have their own renderer. that is lot of hours of good engineers dedicated to that.

facebook = probably hack away all the low level stuff they need to tweak.

bbc = they probably have the same problem we have here. that does not stop them or we to boast that we use react all over the place. doesn't mean we like it.

He forgot to add Airbnb to that list.

i'm not a web dev, so i could be missing something obvious, but i can't think of any use cases for inspecting the dom from native code. example?

The comment makes some sense if you replace "native" with "plain" or "vanilla" JavaScript.

yep. like 99.9% of the code ad networks expect. they want to check DOM state to make sure you are not a sleazy publisher hiding the ads under the content or if you are not being shown in an iframe on some porn site.

with react, they will get inconclusive results because their code might run while they are virtualized or god forbid during the render. and you will only get garbage ads because now they consider you a garbage publisher.

Write your wrapper for ads as a component that renders a div... bind your ad-logic as part of the componentDidMount() event handler. The results should be consistent.

oh! yeah, that does make more sense; i was thinking of something like a qt webview.

React isn't polling, it is callbacks and recursive functions.