Just came across Imba via this announcement Introduction to Imba and thought I should share http://imba.io/
1 Like
Thanks – isn’t this how Blaze works, only change the fields that are dynamic and keep the rest of the DOM static? If we can invest in optimizing blaze (e.g. have a timed render queue, better diff-ing of changes, improvements to ReactiveVar to be able to watch 1st level fields) it can be just as fast – if not faster
3 Likes
Apparently virual dom is growing out of fashion, actually it’s not as fast as it was hyped. Most libraries are now heading toward compiling pure JS code during build time (Rawact, Svelte etc…) and Netflix has removed React from it’s landing page and reverted back to pure JS. The issue here is with bundle size and time to interactive specially on mobile. React/Vue are becoming the new Angular/Ember heavy weight frameworks and many niche libraries attempting to optimize around them.
Regarding Imba, I tend to stay away from anything that attempts abstract JS language and compile to it, historically most attempts like that ended up futile with JS itself evolving, and for the speed many other JS frameworks easily outperform React/Vue, you can find some benchmarks here. Redom is the fastest being very close to bare metal JS…
There is so much hype/cult/churn/herding/FUD and even lies in the JS ecosystem, that it really takes a lot of effort to get the facts, perspective and correct reasoning in place.
9 Likes
I think what Netflix is saying on the Twitter thread linked above, is that they are dropping React from their landing page only, but using it on the rest of their site:
Yes, as I said it’s the landing page only to speed up the first interaction time which inspired the creation of the rawact library.
But the reality is react is heavy, if you inspect what caused slow interaction time in chrome, you will see it’s mostly JS execution and frameworks like react with their virtual dom surely don’t help.
Question: without a virtual dom, is it possible to avoid a full-page refresh when dom elements change?
Yes of course, that’s what DOM manipulation is all about, you use JS to modifying the content of the DOM. That’s how Blaze, handlebars and pretty much every JS library/framework worked before React.
In fact, all frameworks try to modify and adjust the dom, instead of re-mounting every dom node on every change. The goal is to do as little manipulation as possible, because dom-elements are heavy. In particular, you want to avoid unnecessary dom-manipulation (e.g. when no property of that element has changed).
Blaze on one side, tries to have “intelligent” data-structures, where the dom can map to certain entities in your data. The most common data-structure in blaze is a mini-mongo-collection, so the dom-tree is coupled to your mongo-cursor. If an element changes its properties or even changes its position on the cursor because of new elements or different sortings, blaze knows to which dom elements it belongs to and tries to avoid re-rendering the whole collection.
You will start to notice this, if you use a data-structure that is not aware of this, like an array. If you bind your dom-list to a normal array (e.g. because you need to calculate this array) and update the array, every element in the list will update and you get poor performance compared to a collection. (In this case you will need a client-only collection to store your calculated data, which is somewhat similar to the concept of a virtual dom)
React or other libraries with virtual dom on the other hand try to avoid unnecessary dom-manipulations by the following approach:
- instead of doing every manipulation directly on the real dom, build up a light-weight version of it, that is optimized for manipulation and comparing.
- If anything changes in your app, you calculate a new virtual dom-tree and compare it with the last one.
- Then do only these real dom-manipulation for the differences you found on the virtual dom.
This allows you (as dev) to have more “dumb” data-structures and worry less on bad performance due to dumb data-handling. E.g. changing an array like insertion, sorting, etc. is less of a problem, because react avoids unnecessary work already in the virtual dom (It also gives you some api to identify elements in an array (key) and help optimizing further.)
Personally, React does a good job in here, because it’s api is very simple without much changes. Even if they change the architecture behind (virtual dom or not), the api could still be the same. Focussing more on functional programming with its simple and clear data structures is also the right way in my opinion for many webapps.
1 Like
That is a big benefit to using React/Vue/etc. Full-page refreshes look out of date to me. The weight of React may be justified by the benefit.
Would be great to have a working example of Meteor and Imba!
This Imba is amazing concept technology, its even better than Elm, I really believe that it will grow one day and become substitute for Meteor & React, but right now its in a children stage, so no practical use is possible
1 Like