
Show HN: Thi.ng/hdom – S-expression based, pure ES6 UI/VDOM components - toxmeister
<a href="https:&#x2F;&#x2F;github.com&#x2F;thi-ng&#x2F;umbrella&#x2F;blob&#x2F;master&#x2F;packages&#x2F;hdom&#x2F;README.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;thi-ng&#x2F;umbrella&#x2F;blob&#x2F;master&#x2F;packages&#x2F;hdom...</a><p>Lightweight UI component tree definition syntax, DOM creation and differential updates using only vanilla JS data structures (arrays, iterators, closures, attribute objects or objects with life cycle functions, closures). By default targets the browser&#x27;s native DOM, but supports other arbitrary target implementations in a branch-local manner, e.g. to define scene graphs for a canvas element as part of the normal UI tree.<p>Benefits:<p>- Use the full expressiveness of ES6 &#x2F; TypeScript to define user interfaces<p>- No enforced opinion about state handling, very flexible<p>- Clean, functional component composition &amp; reuse<p>- No source pre-processing, transpiling or string interpolation<p>- Less verbose than HTML &#x2F; JSX, resulting in smaller file sizes<p>- Supports arbitrary elements (incl. SVG), attributes and events in uniform, S-expression based syntax<p>- Supports branch-local custom update behaviors &amp; arbitrary (e.g. non-DOM) target data structures to which tree diffs are applied to<p>- Suitable for server-side rendering and then &quot;hydrating&quot; listeners and components with life cycle methods on the client side<p>- Can use JSON for static components (or component templates)<p>- Optional user context injection (an arbitrary object&#x2F;value passed to all component functions embedded in the tree)<p>- Default implementation supports CSS conversion from JS objects for style attribs<p>- Auto-expansion of embedded values &#x2F; types which implement the IToHiccup or IDeref interfaces (e.g. atoms, cursors, derived views, streams etc.)<p>- Only ~5.5KB gzipped
======
aaron-santos
There is an interesting synergy at play amongst UI as s-exprs, functional
programming, and components/vdom where the whole is more valuable than the sum
of its parts. I was surprised to find no mention of Reagent[1] nor Om[2] both
ClojureScript interfaces to React. They share a remarkable similarity with
Umbrella especially the s-expr syntax. However, Reagent[1] and Om[2]'s
language choice pushes the functional composition further.

I'm interested to see this how this combination of ideas spreads outside the
browser and into other applications of UI. As for myself, I've been
experimenting with a writing a terminal emulator/component lib[3] using
Clojure that is inspired by Reagent/Om and React Native. It's been satisfying
seeing the way these ideas compose.

[1] - [https://reagent-project.github.io/](https://reagent-project.github.io/)

[2] - [https://github.com/omcljs/om](https://github.com/omcljs/om)

[3] - [https://github.com/aaron-
santos/zaffre/blob/master/src/examp...](https://github.com/aaron-
santos/zaffre/blob/master/src/examples/components.clj)

~~~
toxmeister
I actually did mention Reagent in the readme in this section (below the
diagram): [https://github.com/thi-
ng/umbrella/tree/master/packages/hdom...](https://github.com/thi-
ng/umbrella/tree/master/packages/hdom#the-hdom-data-flow)

Quote: "The syntax is inspired by Clojure's Hiccup and Reagent projects, which
themselves were influenced by prior art by Phil Wadler at Edinburgh
University, who pioneered this approach in Lisp back in 1999. hdom offers
several additional features to these established approaches."

However, Reagent also still relies on React under the hood whereas hdom is
completely standalone. Also, hdom has a lot more features in terms of what
kind of values are supported within an hiccup tree and additionally, in this
latest version (5.0), hdom already has been extended to support non-DOM
targets to update. Currently, the only user of this feature is the hdom-canvas
package ([https://github.com/thi-
ng/umbrella/blob/master/packages/hdom...](https://github.com/thi-
ng/umbrella/blob/master/packages/hdom-canvas/README.md#about)), which allows
you to define canvas scene graphs in the same way as the rest of the UI, but
those virtual shape elements are translated into canvas draw calls. A WebGL
version of this is in early progress. In general, by implementing a certain
interface you can support _any_ other target context/data structure.

Ps. I've never used Om so didn't list it as an active influence.

~~~
aaron-santos
Thank you for pointing that out. My mistake in missing it!

------
nothrabannosir
_> \- Less verbose than HTML / JSX, resulting in smaller file sizes_

I always wondered: if you use reasonable compression (what is reasonably
expected to be provided by CDNs these days? brotli? I'm so out of the loop..),
if you use this, how much does file size actually matter? Isn't it about
entropy, rather than size? Say, if every HTML tag required 136 <'s to open,
and 136 > characters to close. How would it actually affect different
compression algorithms?

My intuition says that we're all on this wild goose chase for smaller file
size while it may (should) not matter _at all_.

For example, I took Wikipedia's page on entropy and replaced each < by 136*<,
same for >. I bring you the file sizes for different algorithms:

    
    
                normal	crazy	% larger
      raw       423953	3470903	718 %
      Gzip -9   78897	134319	70 %
      Bzip2 -9  64286	64441	0.24 % (!)
    

I don't know what compression algo is de rigeur these days, and 136 <s is
obviously not the same as substituting double tags for sexprs. Still, I hope
we can put this file size boondoggle in the perspective of entropy one day,
instead of just mindlessly chasing the character count dragon.

EDIT: turns out you can convert HTML to pseudo sexprs with some regex. here
are more realistic numbers:

    
    
      	    sgml	sexpr	% diff
      raw       423953	403777	-4.8 %
      Gzip -9   78897	76936	-2.5 %
      Bzip2 -9  64286	63590	-1.1 %
    

Less radical, but still following the trend.

~~~
superkuh
It may be less verbose but it fails completely to render anything if
javascript is not enabled (in the browser) on the domain the scripts are to be
loaded from. Bad accessibility, bad degredation, bad practice for the web.

I'm sure it's fine for commercial JS web apps, but those are bad for the web
too.

HTML is the web. All this pure es6/dom stuff is a cancer.

~~~
zeroname
> It may be less verbose but it fails completely to render anything if
> javascript is not enabled (in the browser) on the domain the scripts are to
> be loaded from. Bad accessibility, bad degredation, bad practice for the
> web.

I call BS on that. The accessibility tools that people actually use only work
with "proper" browsers (counting in IE here) that all support Javascript.
Modern browsers don't even officially support disabling Javascript. For most
web apps, the only feasible way to degrade from "no Javascript" is to display
"this page requires Javascript". Spending any more effort here because it's
"good practice" is a complete waste of time. Put some effort into testing
screen readers instead.

> HTML is the web.

Nonsense.

> All this pure es6/dom stuff is a cancer.

Hey, _who are you_ to tell people what to use the web for? If somebody wants
to serve as static HTML page, nobody is stopping them. Nobody is forcing
people to use some Javascript framework for that.

~~~
superkuh
> Modern browsers don't even officially support disabling Javascript.

That's right. The big browsers have all been co-opted (even firefox) and now
target Grandma browsing Facebook and other SPA as their demographic. This is
bad for the web but very good for corporations making money. These two things
aren't very compatible no matter how much most web devs are invested in not
realizing there's a difference.

I'm telling you how I see it and how I design my sites. None of them require
javascript to function (even for my comment system). I can do this because I'm
not being paid I'm just doing it for fun. I understand people being paid
_have_ to make bad websites. But that doesn't make it okay.

------
tofflos
Nice visualizations. I particularly liked [https://github.com/thi-
ng/umbrella/tree/feature/estuary/pack...](https://github.com/thi-
ng/umbrella/tree/feature/estuary/packages/estuary). Where can I find more
stuff like this? :)

~~~
rgovostes
Karsten is an accomplished computational artist:
[http://postspectacular.com](http://postspectacular.com)
[http://toxi.co.uk](http://toxi.co.uk)

~~~
toxmeister
hehe... just not an accomplished documenter of his works. those "websites" are
all ancient. don't bother visiting!

~~~
rgovostes
I was a middle school student probably when I saw your hair demo in
Processing. Still looks great!

------
spankalee
I'd still rather write markup in a format that looks like markup. I think this
is why JSX is so popular.

This is why I prefer something like lit-html with actual markup.

Example from hdom readme:

    
    
        // component w/ local state
        const counter = (i = 0) => {
            return () => ["button", { onclick: () => (i++) }, `clicks: ${i}`];
        };
    

In lit-html:

    
    
        const counter = (i = 0) => {
          return () => html`<button @click=${() => i++}>clicks: ${i}</button>`;
        }
    

Yeah, there some extra weight to the close tag, but it looks like HTML.

Disclaimer: lit-html author. [https://github.com/Polymer/lit-
html](https://github.com/Polymer/lit-html)

~~~
gwn7
Let's start some controversy.

I think JSX is popular because of historical reasons. Not the history of JSX,
but the Web in general, specifically about HTML being the primary API to build
web interfaces since the early days. Everyone feels at home with HTML because
of this. We all started with it and it is unquestionable for many.

DOM is the second way to build a web interface. But nobody in their right mind
would prefer DOM over HTML as long as HTML is sufficient for the task at hand.

The advent of stuff like Hyperscript and virtual DOMs of today introduced a
new alternative to HTML and DOM: Now we can build our interfaces using simple
data structures (POJOs). This was already possible from the beginning, but the
interactivity requirements of the modern application forced us to invent the
"UI as a function of the state" paradigm and this approach became mainstream
after that (AFAIK).

But wait... Isn't HTML a data structure as well? Not sure. It clearly started
as some kind of DSL for building web interfaces. Then XML is invented and HTML
was declared as being an extension of XML; thus some kind of data structure
(roughly). Then it got complicated. Today I have no idea about what HTML is.

This is the first part of the story.

The second part is about RPC. This one is short. XML used to be everywhere
until the advent of JSON. Suddenly everybody started to embrace JSON and hate
XML; for several reasons most of which are reasonable.

The question is....

Why isn't the same thing happening with user interfaces? HTML is a subset of
XML (or something like that), and the syntax proposed in this article is
clearly JSON. Why is everybody embracing JSX like crazy. Do they not find it
extremely ugly, as XML is, compared to a POJO?

Is HTML really a better way to represent user interfaces than a solution such
as the one presented in this article?

It may be hard to answer as we are all biased in favor of HTML.

I'm not experienced enough to make big claims, I'm just thinking out loud, I
find this topic interesting. Corrections and feedbacks are welcome. Not trying
to start a flame war.

~~~
zeroname
My two cents: It's a generation of programmers raised on the Web who think web
technology is good because _that 's what they know_. They _believe_ in "open
standards" and "design by committee" and nonsense like "semantic HTML" being
"best practice".

To everyone outside of that bubble, the following is _obvious_ : Web
technology sucks. HTML sucks. CSS sucks. Javascript sucks. They're inadequate
solutions, which is why people keep reinventing the way to do web frontend
every two years.

> It may be hard to answer as we are all biased in favor of HTML.

Not me.

~~~
gwn7
Yeah I kinda agree with this. I'm not old enough to remember the pre-Web era
but I did my share of research and know that hackers of the previous
generation does not hold much love for the Web, and I'm convinced that it's
for good reasons. Nowadays I feel the same way.

But this problem is not specific to our generation as far as I understand.
Maybe the thing that sucks the most that became big in our generation is the
Web, but weren't there similar scenarios before us as well?

Doesn't Linux suck? Systemd? Java?

Doesn't every freaking mainstream technology suck? I regularly come across
rants from significant developers regarding this issue. There probably is no
way to prevent this from happening. Because worse is unfortunately better.

I regularly and seriously consider to leave software development because of
this (as I'm really suffering) but then I remember how much power it gives me
despite the horrible faults it has.

I think it's very important to understand that the tools we work with mostly
suck. In my opinion this is something that is missing from software education
curriculums. People need to know and understand how and why everything is
messed up and how can we work around this issue while preserving our mental
health and the intellectual satisfaction we are supposed to get from the
craft.

~~~
zeroname
> Doesn't every freaking mainstream technology suck? I regularly come across
> rants from significant developers regarding this issue. There probably is no
> way to prevent this from happening. Because worse is unfortunately better.

Web technology is fundamentally different in that you have a big standards
body regulating everything from layout down to color blending, then leave it
up to multiple vendors to implement all that stuff at great expense and with
long delay. Worse, it's all shoehorned on top of some "document model" than
was never designed with applications in mind. It's a waste.

To see what a better platform could look like, consider this:

[https://mickens.seas.harvard.edu/publications/atlantis-
robus...](https://mickens.seas.harvard.edu/publications/atlantis-robust-
extensible-execution-environments-forweb-applications)

[https://www.youtube.com/watch?v=1uflg7LDmzI](https://www.youtube.com/watch?v=1uflg7LDmzI)

The key here is reducing surface area. It's entirely possible that WASM will
bring us closer to that, but the web developers of today probably won't like
that.

> I regularly and seriously consider to leave software development because of
> this (as I'm really suffering) but then I remember how much power it gives
> me despite the horrible faults it has.

I don't know what you do, but I find web development to be significantly more
frustrating than other areas. That doesn't mean there isn't frustration
elsewhere though and it's definitely part of the job.

------
localvoid
I hope you are aware about this attack vector[1] that was fixed in React long
time ago.

1\. [http://danlec.com/blog/xss-via-a-spoofed-react-
element](http://danlec.com/blog/xss-via-a-spoofed-react-element)

~~~
toxmeister
Thanks & I wasn't (aware of it). hdom doesn't use `.innerHTML` anywhere,
though. So I'd dare to say less dangerous... though not saying it's out of
danger!

------
Fifer82
Thanks for sharing and Kudos for TypeScript! This question is not aimed at you
and certainly not at your work.

I used to be a game developer from an OOP background. I find this really hard
to read.

[https://github.com/thi-
ng/umbrella/blob/master/examples/hdom...](https://github.com/thi-
ng/umbrella/blob/master/examples/hdom-canvas-draw/src/index.ts)

Would anyone be able to give 2 cents about where the industry is headed in
this regard? Will I be looked down on that my codebase is OOP in the future?
Also for those who were cut from my cloth, did you find the transition
difficult?

~~~
groovy2shoes
I have no idea where the industry is headed, but I feel rather confident that
there will always be some group of people that will find some reason to look
down on your codebase. If you rewrote the whole thing in state-of-the-art FP
tonight, then by morning there will be some contingent of zealous logic
programmers with their noses turnt up.

Don't worry about being looked down on. Worry about improving yourself as our
field figures out how we can improve our craft. There's a lot of noise, which
makes it hard to tell which things offer the most improvement, but knowledge
is _never_ a setback. You will never learn something new and be worse off than
you were before. And learning something new doesn't require you to rewrite
your codebase to use it, either—of course, you can if you so chose, but that's
not a decision you can make until you've grokked the newness ;)

As for the difficulty of the transition: I didn't find it difficult, but I
also had the luxury of time. I think it could potentially be difficult for
someone thrown into the deep end (e.g., "go into the `hdom-canvas-draw`
example and implement new features X, Y, and Z by Thursday!"). People often
talk about FP being a different way of thinking about programming. That's true
to some extent, but it's not _entirely_ different from what you're used to. I
think the thing that seems strangest for newcomers to FP isn't the way of
thinking, it's the terminology. Names like `filter`, `map`, `mapcat`,
`partition`, &c. seem odd and incomprehensible at first. But they're just
operators, like `add`, `multiply`, `insert`, `append`. They're the kind of
operator that make functional programming functional: they operate (at least
in part) on functions.

If FP is something you want to learn, my advice is to start slow and simple.
Some people can probably dive into that example code, tear it apart, figure
out how it works, and learn that way. Perhaps I could if I were motivated
enough, I don't know. What I _do_ know is that I can't be arsed to do
something like that. It's frustrating. Annoying. I have better things to do
with my time.

The common advice is Abelson & Sussman's «Structure and Interpretation of
Computer Programs», which is pretty good, though it has some problems.
Felleisen & al. wrote «How to Design Programs» to address some problems with
SICP, and wound up introducing even more problems. The choice between those
two boils down to whether you want a book that addresses you like a 13-year-
old with a good grasp of the infinitesimal calculus (SICP) or one that
addresses you like an 11-year-old that barely understands elementary algebra
(HtDP). Personally, I rather like Paulson's «ML for the Working Programmer»,
which assumes you're an adult who probably doesn't hold a degree in
mathematics. Unfortunately, it's not freely available like the other two.

If you decide to go with SICP, I recommend using either MIT Scheme or Racket
with sicp mode (you can install the mode through the menus in the DrRacket
IDE). For MLftWP, I'd recommend using PolyML (any Standard ML implementation
compatible with the revised definition will work fine, but PolyML is actively
maintained and easy to set up).

From there, you should be pretty versed in the foundations of FP, and it's
just a matter of practice to get comfortable. Of course, there will always be
more to learn—the student may never rest :)

ETA - My best advice would be this: if you have the money and the time, read
both the Paulson book and SICP; if you have the money but not the time, read
the Paulson book; if you don't have the money, read SICP, which you can find
in many formats on the Web (it's CC BY-SA licensed). I would not recommend
HtDP to a professional programmer, and only maybe to a neophyte.

~~~
toxmeister
very well said indeed! +1

------
tln
OP, a README in that directory would be useful

I found some docs:

[http://docs.thi.ng/umbrella/hdom/](http://docs.thi.ng/umbrella/hdom/)

~~~
toxmeister
I dunno, there's a 1000+ LOC readme there. Also updated the above link to
point to it directly. It's a shame that GH is automatically displaying the
readme on desktops, but not in mobile version...

~~~
tln
Doh! I did miss it

------
chris_wot
I've never quite understood S-expressions. Can someone give me a good primer
on them?

~~~
CamTin
S-expressions are just the lowest common denominator of programming language
syntax and more generally trees (aka lists of atoms and lists).

The idea is that all program listings are essentially just lists of things,
including other lists: A Javascript source file can be thought of as a list of
lines, or more semantically a list of statements and expressions. Function
calls are just the name of a function and a list of arguments. Each different
kind of statement or expression has its own kind of syntax: a `function(baz) {
yadda(baz); }' expression uses different syntax than a `if (something) {
yadda(foo); } else { blah(bar); }' statement. S-expression languages just use
one kind of syntax for everything, so you can do `(lambda (baz) (yadda baz))'
and `(if something (yadda foo) (blah bar))' instead.

This uniformity of syntax allows most of the interesting features of lisps,
like that everything is an expression (returns a value), and macros, which are
kind of a souped-up version of C preprocessor `#define's.

~~~
galfarragem
A great explanation. It's a pity that is buried in the thread.

------
uxcolumbo
Wow - this is an impressive body of work.

Particularly like the Estuary and chart samples.

You mentioned you still use ClojureScript - but I'm guessing you're not using
CLJS for front-end stuff anymore and just stick to your ES6 libs?

~~~
toxmeister
Merci beaucoup & please see my other comment about this...

~~~
uxcolumbo
Yes, saw you posted it after my comment.

You were one of the reasons why I got interested in Clojure / CLJS. Even
visited a workshop of yours a couple of years ago ;) I'm still in dabbling
mode unfortunately.

So my understanding after reading your tweets - is that for your use cases
ES6/TS is better suited for front-end stuff. But Clojure is still worth
digging into - if only for learning the philosophy, principles, ideas and
simplicity of FP.

For what use cases would you use ClJ / CLJS nowadays?

Anyway, thanks again for your work - I like the hiccup style of building UIs -
so will be checking out hdom.

Edit: typo

~~~
toxmeister
Oh hello & wow... now if only I knew who you are... :)

Those tweets really weren't meant to discourage people from using CLJ(S) at
all!! I was merely trying to explain why, personally, I think TS is better
suited for _my own_ use cases (and those of my job)... I'm not building
"standard" websites and for the tools I'm dealing with, CPU performance is
more important than for most other web apps. I sometimes just felt constrained
by some of the features & indirections people usually come to Clojure/Script
for in the first place. For example, when generating or processing large
amounts of geometry I really don't want or even need immutable data structures
by default and so I wanted to have the freedom of being able to break out from
this more easily. In some cases I too wanted to have more of a 1:1
correspondence between the code I write and what it ends up as in JS,
something the combo of CLJS + GCC made hard(er). ES6 syntax offers many
niceties (e.g. array and object destructuring, iterators, async fns) and
without those I'd probably be still using CLJS more.

~~~
uxcolumbo
Ok thanks for clarifying - I didn't read your tweets as a discouragement and
it makes sense the type of apps you're working on you probably need to squeeze
out as much performance as you can and need something which gives you more
control.

I was in your last Clojure for beginners course. I remember your dog was very
friendly and liked to play with the half chewed tennis ball ;)

------
geokon
A bit off-topic, but have you moved away from Clojure entirely? I guess it
sorta makes sense b/c creative coding in Clojure never quite took off (though
there are some very nice individual libraries)

I really loved your geom library btw, thank you!

~~~
toxmeister
I commented on this recently on twitter & reddit:

[https://twitter.com/toxi/status/1041143431786115072](https://twitter.com/toxi/status/1041143431786115072)

[https://twitter.com/toxi/status/1041144813092044800](https://twitter.com/toxi/status/1041144813092044800)

[https://www.reddit.com/r/Clojure/comments/9deyxe/thinggeom_a...](https://www.reddit.com/r/Clojure/comments/9deyxe/thinggeom_appears_to_be_back_in_active_development/e6984at/)

Hth!

~~~
geokon
Thanks for the context :) Yeah, I understand it's a bit hard to work on a
massive project of that scale with little feedback! It can be a bit draining.

I funny enough came at CLJ in part for the math functionality - but I might
hit the awkwardness you mentioned. Mostly I'm quite interested in Neanderthal
which runs native (MKL) and OpenCL. But living outside of the browser and
JS/CLJS presents other limitations (like mixing geom with JavaFX for GUIs has
some clunkyness - and the JavaFX wrapper libraries like fnfx are great but not
polished)

It's great to see the no-org branch! I love org-mode and use it a lot (for
templates and examples) but it always ends up a bit tricky for me to massage
the code layout to fit the right narrative structure - so I get why you're
moving away to encourage contribution :)

Thanks again for this awesome piece of tech. The API is just so fun to use
once you learn how it works (it's so different and ergonomic from anything
else I've used in C++/Cinder/etc.), and the end result looks very sexy. I'll
keep using it and maybe add some PRs with examples once no-org merges in

------
ricardobeat
What makes this different from Mercury
([https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)) and a
ton of other pre-React frameworks?

~~~
toxmeister
I don't want to sound snarky (and please don't see it as such), but did you
read the readme? I'm not familiar with Mercury, but looking at the code
examples, some obvious differences are:

\- hdom does NOT care about state, where it comes from or how you manage it

\- hdom uses vanilla arrays(*) instead of `h()` function wrappers, which not
just create more legible (IMHO) style, but also open components up for more
options in terms of construction/composition and also transformation.

I think that last aspect is seldom talked about in all those discussions and
comparisons w/ React & co. Entire 3rd party frameworks are invented &
maintained just to provide augmentation, configuration & injection features
for React style components, issues which can be much easier solved if your
components are in a less abstract & more native data format already. ES6
provides a ton of nice features to construct and transform arrays without any
additional support structures. hdom also supports & fully embraces ES6
iterators and the more modern ways of transforming data they support.

There's a blog post about this forthcoming, so apols for not going into more
detail here now...

~~~
ricardobeat
Neither do most of the other libraries care about how you manage state. There
are also other libraries that can take arrays/data as input, we ended up with
inline functions mostly due to performance. There is no intrinsic advantage to
plain arrays other than being serializable without an intermediate step,
everything else is the same (jsx pragma and an array-based tree are fully
interchangeable since you can easily generate one from the other).

Looking forward to that post as I’m always happy to be proven wrong!

------
jefozabuss
FYI the "Mouse gesture analysis" example has performance issues after 300~
samples (e.g. keep drawing big circles continuously)

Win10/Chrome/i7 4790k/GTX 970

~~~
toxmeister
That's because that demo is using SVG for graphics and hence updating 300+ DOM
elements every frame will of course start stuttering... Once I've updated that
example to use the hdom-canvas support lib ([https://github.com/thi-
ng/umbrella/blob/master/packages/hdom...](https://github.com/thi-
ng/umbrella/blob/master/packages/hdom-canvas/README.md)) this will be a non-
issue. E.g. here's another demo which draws 10k rectangles @ 60fps. Only once
I go >25K, I'm starting to loose framerate (MBP 2016):

[https://demo.thi.ng/umbrella/hdom-canvas-
shapes/#points-10k](https://demo.thi.ng/umbrella/hdom-canvas-
shapes/#points-10k) [https://demo.thi.ng/umbrella/hdom-canvas-
shapes/#points-50k](https://demo.thi.ng/umbrella/hdom-canvas-
shapes/#points-50k)

~~~
jefozabuss
I found a similar issue with the git commit log example (when filtering from
initial state and clearing filter) - I guess it can be reproduced via a
"heavier" example e.g. a couple hundred nodes with more frequent state
changing.

~~~
toxmeister
The commit table has a 100ms throttle on key press, but I think might have a
bug, need to inquire more... :)

There's also a stress test here which updates several hundred nodes each
frame:

[https://github.com/thi-
ng/umbrella/tree/master/packages/hdom...](https://github.com/thi-
ng/umbrella/tree/master/packages/hdom#benchmark)

E.g. each cell shown requires 3 DOM updates per frame, so in the 256 cells
config it updates 768 DOM nodes. On my MBP2016 this config runs at ~35 fps,
192 cells (576 real DOM updates) at 59-60fps

------
TheRealPomax
Is the DOM an afterthought here, like in React, or is everything strongly tied
to the DOM?

~~~
toxmeister
"Afterthought" is too a strong a term, but the largest aspect of that latest
version of the library was to generalize the approach to aim at other non-DOM
targets. I left another comment about this somewhere else in this thread.
Basically, you can choose branch-local implementations of the main hdom
interface. If none is provided, it uses the default one which targets the
DOM...

