RE:DOM – Tiny turboboosted JavaScript library for creating user interfaces
redom.js.org
redom.js.org
In this case, I find it a bit misleading to pass off not having a VDOM as a pro. It's a bit like building a social media site with no users and claiming everyone should join because it doesn't have spam.
The best way of using it is simply emulating what you would do in react (without jsx) in terms of design patterns. So you have component classes, with state, and a render method. Half of the success is just using good patterns like that. All redom does is allow you to create trees of elements and manage those.
It has a few simple primitives for that. The main thing is a an el method that takes 3 parametes (maximum). The first is the element name, classes and id as a string. ".foo.bar" means a div with class foo and bar. "span.foo" means a span with class foo, and so on. The second (optional) one is an object with attributes. So if you have an a tag, you might want to pass in an object with an href, title, target, etc. The last parameter is either a string for text nodes, another element, or a list of elements. There are setAttr, setChildren, etc. methods you can call on elements. There are mount/unmount methods and there is some syntactic sugar for managing lists. That's about it.
You can shoot yourself in the foot (just like with other frameworks) but otherwise this works as advertised. Mostly there is not a lot of magic happening in terms of expensive stuff.
document.createElement("div"); element(‘h1’, {class: “foo”}, “Chapter 1”)
And that’s how new Javascript frameworks are born.
Fun stuff, https://github.com/mini-eggs/ogle-tr-122b
[1] https://github.com/ptytb/nodom [2] https://github.com/ptytb/d3-worker
If you want DOM in your code, JSX is the way to go.
But if course it always depends on the project which way is better.
Calculating memory overhead for vdom is actually pretty hard. With imperative code there will be several different code paths for initial rendering, updates and removal, and depending on the ratio of component instances per component type in the application, vdom can consume less memory because there will be less code and less code means that there will be less internal data for JIT.
Also, if it is a highly dynamic application with high ratio of dynamic bindings per DOM element, and imperative library will wire all dependencies with direct DOM bindings in a huge dependency graph, it is much more likely that this graph will consume more memory, especially in use cases like filtering large lists.
It’s different than React though, that’s by design, since we needed more precise DOM handling.
Too bad I am forced to use ES5 (IE9).
If you need to do something at scale, then you may choose React. The benefit here isn't from just something as simple as changing the items in a list or the text in a header, but when you need to have large amounts of state in an app that is represented by a complex DOM tree.
The benefits of React here are that the virtual DOM can prevent unnecessary updates to the rest of the tree when your state change should only affect a nested element, for example.
Being fast is not just about micro updates, I think that most vdom authors don't care too much about micro updates performance because it isn't a bottleneck.
For example, Virtual DOM with a powerful composition model can significantly reduce code size because composition gives you code reusability, and virtual dom is one of the most compact output formats to render/update DOM.
I will definitely watch it, but may I ask if you know how the lit-html or hyper work? Reason I was asking was that all the vdom libraries maintain a virtual dom (behind the live dom) that they always recreate when the data changes (but this is cheap, since it's only a data structure), then they compare reconstructed virtual dom to the live dom and swap out only the new parts. And this way the browser only needs to re-render the new parts -- since the old ones didn't change.
But the two other libraries I mentioned remember the "holes" in the html templates directly. So when the component gets new data, then the updated content is simply set as the value of these direct references into the live dom. This way (1) only the new parts are updated and thus re-rendered, but also (2) no virtual dom needs to be reconstructed. And this is why they are faster than the vdom libraries.
So my question basically was, do you reconstruct the entire component tree too or not. But I guess I need to watch the video and read some code :)
It’s a cool approach, and this one looks more fleshed out. But I’d still think in 2018 it’s almost always a premature/inappropriate optimization to forgo a virtual DOM, unless you’re doing something pretty far out there.
Very well said. Author of "one very popular library" is plainly lying claiming that "Virtual DOM" was somehow faster than real DOM.
That was never the case, even back in IE6 era, aside from very few and well known edge cases.
Switch to Virtual DOM led to one of the biggest slowdowns in website performance.
I’ll be honest, though, it feels to me like a solution to a hard problem you inflict on yourself by first committing to have the giant component tree rather than questioning if that was a great idea.
For example we want to turn the prev tree into the next tree:
Prev:
<ul>
<li>1</li>
</ul>
<ul>
<li>1</li>
<li>2</li>
</ul>
parent.appendChild(makeLiWithText("2"))
I do think OP is missing the point of VDOMs. "Figuring out" the resulting imperative instructions for a given prev -> next is not easy (the above example, however, it trivial), and is very error prone, which is why the VDOM diffing solution is motivated in the first place.
You don't have to have tons of handcoded input handling or tree merging code. As I said in another post, the approach with some structured getters and setters was known since time immemorial. S.js, I think, is the best modern iteration of the approach. There are a lot of different ways of handling that, just google.
> "Figuring out" the resulting imperative instructions for a given prev -> next is not easy (the above example, however, it trivial), and is very error prone, which is why the VDOM diffing solution is motivated in the first place.
Yes, you very much get that. For that reason, when someone is faced with handling frequent and complex page structure manipulation, he is better to apply some actual computer science knowledge, and algorithmics to the task, than to use half-baked solutions. This is exactly because the gain from doing things properly in such case is great.
From utility standpoint, VDOM has its use, but its advertisement as a somehow superior and more performant approach is a disingenuous.
Even back in "medieval" era when YUI was the king, the practice of making getter-setter pairs with direct control over DOM elements was recognised as a preferred practice over any kind of state machine controlled page re-rendering system.
There of course was Angular.js - the prime target for React authors, against which all their claims held true.
I usually create a requestAnimationFrame debounce to have just a single render per animation frame.
Debugging is also way easier without long stack traces.
There’s pros and cons in everything.
Even in the often brought forward case "when a lot of changes to DOM don't translate to changes in markup," like demonically complex template merges, never seen in real life, that VDOM proponents like to throw into benchmarks, VDOM often lost because they were trying to do browser's job when they really shouldn't.
Browsers already used a lot of very similar logic on the inside when DOM 3.0 was being popularised, and it's only natural that VDOM was losing out by trying redoing what browsers were already doing.
You miss the point of VDOMs. VDOMs aren't so much about performance as they are about ease of development and automatically maintaining tree consistency. No one disputes the fact that creating templates and diffing them against the DOM adds overhead compared to writing out the equivalent instructions manually. The point is that nobody wants to write out imperative spaghetti for complex applications.
You really don't have to, you just have to walk out of that "wood of popular notions." There are libs to handle functionality of any part of a modern MVC app: reactivity, input handling, declarative components, templating... that don't even making you think of manually manipulating the DOM tree.
Keep in mind, too, React handles MANY edge cases for scenarios like keeping scroll position on update, or animations.
But usually the bottleneck with React apps are state managing libraries, like Redux etc plus all the other bells and whistles.
https://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageF...
This and "blazing fast" make me cringe every time.
As well as ”turboboosted”. Don’t take them too seriously :D
There is wasmjit [1] a kernel module that enables execution of webassembly via the linux kernel.
Furthermore there is AssemblyScript [2] that allows to transpile typed javascript to WebAssembly
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Lol. Sure! Just like how I get closer to the Earth’s core if I’m sitting on the floor instead of my chair.
don't reinvent the wheel man.