
RE:DOM – Tiny turboboosted JavaScript library for creating user interfaces - edward
https://redom.js.org/
======
anonytrary
Not having a VDOM is only a pro if your library maintains feature parity with
libraries that have a VOM. Otherwise, you just lack whatever it is that VDOMs
enable. This library seems to forget why view libraries use a VDOM. In this
library, you have to write imperative update logic, which the VDOM
specifically allows you to avoid. The VDOM is a slight performance hit most
people accept in order to be able to write declarative code.

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.

~~~
giornogiovanna
In my opinion the benefits of declarative GUI are vastly overstated for the
average web app. Given that your application is appropriately componentized,
it rarely makes things much clearer.

~~~
pkstn
Agreed!

------
jillesvangurp
We're actually using this. Re-dom is a very thin layer on top of the DOM.
Basically all it does is hide some of the weirdness of that.

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.

------
jtms
Try my new lib... here it is right here!

    
    
        document.createElement("div");

~~~
oh_sigh
What's your library licensed as?

~~~
bigiain
Surely you'd have to pick SSPL, to avoid the risk of Amazon getting rich off
this innovative technology without contributing back to the community???

------
Eli_P
Huh, one day I forked a part of RE:DOM called nodom[1], to use it in my
library for rendering D3 charts in the background worker. I'd been extending
nodom, and finally got working D3 in worker[2], sorry the pun. As I recall,
nodom was pretty straightforwardly coded w/o magic and easy to extend, a nice
library if you need to play with lightweight vdom.

[1] [https://github.com/ptytb/nodom](https://github.com/ptytb/nodom) [2]
[https://github.com/ptytb/d3-worker](https://github.com/ptytb/d3-worker)

------
kowdermeister
This idea of creating DOM with some API is not new and never really understood
it. Just look at the login class, it's way more complex than plain HTML, hard
to read and messes with .this.

If you want DOM in your code, JSX is the way to go.

~~~
pkstn
With more complex project there’s benefits of having purely updatable
components, the support of just native JS without quirks and knowing exactly
what’s happening and when without black magic.

But if course it always depends on the project which way is better.

~~~
anonytrary
With more complex projects, anything that isn't a declarative becomes painful
to manage. In complex web-apps, the benefits of using a VDOM over imperative
libraries like this far outweigh the extra O(N) memory consumption.

~~~
localvoid
> this far outweigh the extra O(N) memory consumption.

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.

------
xtagon
If manipulating the DOM directly is so much faster than using a virtual DOM,
then why do libraries like React or Ember use a virtual DOM in the first
place? I honestly though it was for speed.

~~~
gpmcadam
It depends what you mean by "faster". In some cases you'll be better off with
something lighter and accessing the DOM directly.

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.

~~~
xtagon
That makes sense. Thanks for explaining :-)

------
buremba
Seems similar to Backbone.js which was popular a looong time ago. Well, in
fact, it's probably 4 to 6 years but it's a really long time for the front-end
world. :)

~~~
pkstn
Not much, really..

------
kreetx
For those in the know on the internals of the topic library: is this like
hyperHTML or lit-html in the way that it remembers the "holes" in the html so
every update is just the update of live DOM at the right place?

~~~
pkstn
Check out my talk if you're interested in internals:
[https://www.youtube.com/watch?v=0nh2EK1xveg&t=410s](https://www.youtube.com/watch?v=0nh2EK1xveg&t=410s)
;)

~~~
kreetx
Hi and thanks for the link!

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 :)

------
guscost
This sounds kinda like my little DOM component library:
[https://github.com/guscost/protozoa](https://github.com/guscost/protozoa)

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.

~~~
JustSomeNobody
That just sounds so... backwards to me.

------
lopatin
It looks like the Element.update function is more or less the equivalent of
setState in React. So the UI does seem to be declarative (you may want to
emphasize this, at first it looked like a jQuery-like library). How does the
declarative aspect of this work without a virtual dom?

~~~
lopatin
Answering my own question here: It's not the equivalent of setState as it
doesn't set in memory state, but edits the dom directly when called.

------
Zelphyr
Can anyone explain why you’d use this over just writing the HTML? This reminds
me of the days when there were similar libraries in PHP and I could never find
a use for them. It was easier and faster to just write the HTML.

------
cfv
Loving it, built something similar a long time ago. Can you use it the other
way around tho? Like, take an HTML string and return its RE:DOM
representation.

------
baybal2
> Because RE:DOM is so close to the metal and doesn't use virtual dom, it's
> actually faster and uses less memory than almost all virtual dom based
> libraries, including React (benchmark).

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.

~~~
burlesona
IIRC the performance gain is when doing things like updating the state of a
deep component tree, where react and others diff on the vdom to see what
elements need to be re-rendered and then only so actual dom manipulation on
those, rather than clear and re-render the entire tree.

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.

~~~
anonytrary
I think he's comparing VDOM to the equivalent imperative instructions, which
!== re-rendering the entire tree.

For example we want to turn the prev tree into the next tree:

Prev:

    
    
      <ul>
        <li>1</li>
      </ul>
    

Next:

    
    
      <ul>
        <li>1</li>
        <li>2</li>
      </ul>
    

A VDOM would have a representation of prev and next in objects, diff them, and
then decide to do something like

    
    
      parent.appendChild(makeLiWithText("2"))
    

OP is saying that this is less efficient than just manually executing the
above line. Obviously, it's less efficient because the latter solution skips
the entire diffing process.

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.

~~~
baybal2
> I think he's comparing VDOM to the equivalent imperative instructions, which
> !== re-rendering the entire tree.

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.

------
royjacobs
I can't comment on the quality of the library, but I did get a quick chuckle
from the term "close to the metal" being used to describe a Javascript browser
library.

~~~
codeflo
I think very soon, "low-level programming" will mean writing JavaScript
directly without a transpiler.

~~~
jayflux
Soon? I’ve already seen that described as low level JS

~~~
EGreg
Obligatory XKCD (albeit about editors)

[https://www.xkcd.com/378](https://www.xkcd.com/378)

------
aaaaaaaaaab
>closer to the metal

Lol. Sure! Just like how I get closer to the Earth’s core if I’m sitting on
the floor instead of my chair.

~~~
pkstn
It’s a bit of a joke.. ;)

------
ziont
i dont want to convert HTML into any other format...its like coffeescript.
somebody is gonna pick up your code and they see all these el('h1','OMFG HN
SUX'); instead of normal sane HTML.

don't reinvent the wheel man.

~~~
cpfohl
This..._isn't_ converting HTML into any other format. It's providing an
ergonomic way to generate elements in javascript. The alternative is directly
using `myEl = document.createElement(...)` and `myEl.appendChild(...)`. and
`myEl.src = 'whatever'`. You're comparing apples and dumptrucks here.

~~~
ziont
thats pretty much converting javascript into html and vice versa

