VanillaJSX.com

From my experience creating complex web UIs, the performance angle of using a vdom is pure fantasy if your application is complex enough.

In fact I now strongly believe it's counter productive, because most people come to it thinking "I can just trigger however many re-renders of this large piece of UI as I like, the vdom makes it ok" and it doesn't, the performance sucks, but now you have architected the app in a way that requires a rewrite to make the app perform well.

I have seen this exact sequence of events four times, by four different teams. The second, third and fourth, as a principal architect consulting for the team I tried to intervene and advocate for a vanilla architecture that is mindful about performance, citing the issues they would likely experience with react, but to no avail. There was a lot of "oh but there many ways to avoid those issues" followed by a list of things I was presumably ignorant about.

I guess most of us need to learn things the hard way.

You want to return a description of the DOM, rather than the real DOM, because you want to be able to reevaluate your templates repeatedly with new state, and efficiently update the DOM where that template is rendered to.

Depends who "you" are. I prefer to have my DOM nodes updated in place without all the reconciliation machinery. (no implication about what you want)

is probably the main benefit of a VDOM

I get the "no more imperative updates" dream. I've used these frameworks for probably a decade. I've mastered them.

Me personally, I prefer imperatively updating my DOM. I get completely fine-grained control over what's happening. I can architect it to be an extremely efficient machine. I can make it extremely easy to add/change/remove/fix features in my apps without forcing myself to think according to anyone else's opinionated methodology.

This really just isn't true. If your state updates are at the component subtree level (like react) a vdom is a good choice. But, if you make your state changes more granular, you can get away with skipping VDOM entirely and work with just* regular dom nodes. Look at Solid or Svelte. No VDOM there, just pure granular updates.

*List reconciliation still has to happen, but you don't need to pull out an entire vdom. You just have to have some mapping between list items and their resulting DOM nodes.

Whether you like this project or not, your comment so completely misses the point. You are confusing the JSX syntax, which is what the author wanted by extracting it away from React, for all the React candy. This is a missing the forest for the trees kind of thing.

This mind numbing reliance upon layers of abstraction nonsense around state management is why I really don't like React. State management is ridiculously simple. State management, when done correctly, is the most primitive example of MVC with no abstractions needed.

Returning actual DOM nodes entirely blunts the big advantage of JSX (and non-JSX libraries like Lit) - which is their immediate mode style API, and UI=f(state) model.

I feel like this is one of the leakiest abstractions in all of computing. There's a reason there's an entire cottage industry around react; how to stop things rendering multiple times, refreshing needlessly, etc.

I agree with the sibling comment that this really depends on the user. To take a different approach: JSX is just a different DSL to the createElement function call pattern (see Preact.h for example) and all of the benefits you’re describing come from the framework and runtime.

More concisely: JSX is just an alternate function call syntax with some useful applications.

For example at my last company we used JSX to make test data factories that had an XML-like look but were using a builder-pattern in the element creation that was able to make contextual decisions about what was in the final data. Nothing to do with React, DOM, or inability to express the same thing declaratively without JSX.

I'm having fun using lit-html with vanillajs, after I saw a tweet from Marc Grabanski suggesting he didn't use the full Lit library. Admittedly I am then not taking advantage of all the reactivity goodness, but I also really dislike the decorators syntax and 95% of the time I just don't need the reactivity after the first render.

It works great! I was amazed at how you can do so much in templates, it's pretty much everything I could do in Vue templates, though a little more verbose.

I built my own `VanillaComponent` class, which has a mount() method which calls the render() function which I define on the child class.

My VanillaComponent class looks like this:

    import { html, render } from "lit-html";
    
    abstract class VanillaComponent {
      abstract render(): ReturnType<typeof html>;
    
      private _mountPoint?: HTMLElement;
    
      mount(this: VanillaComponent, target: HTMLElement) {
        target.textContent = '';
        this._mountPoint = target;
        this._update();
      }
    
      _update() {
        let templateResult = this.render();
        let rootPart = render(templateResult, this._mountPoint!);
      }
    }

    class MyComponent extends VanillaComponent {
      constructor(props: { label: string }) {
        this._props = props;
      }
      
      render() {
        return html`<button>${this._props.foo}</button>`;
      }
    }

    let myComponent = new MyComponent({ label: "I am a button" });
    let target = document.querySelector("#demo");
    myComponent.mount(target);

    myComponent.update()

However something I have not been able to solve with lit-html only, is when I compose parent and child components I have to do something like :

    class MyDialog extends VanillaComponent {
      render() {
        let childComponent ...  // another VanillaComponent previously instanced
        return html`
          <div>
            ${childComponent.render()}
          </div>

But this means I can not do `childComponent.update()` because I don't know the root element of child component, since I did not mount it explicitly myself.

I mean technically because of the lit-html optimizations, I can do `.update()` on myDialog (the parent component) after any child component's props changes, and it will only re-render what is necessary... but let's say my child component has like 1000 cards... it seems very wasteful and it would be ideal if I could re-render only the child.

I wonder if there is a trick to get around that with just lit-html?

JSX in SolidJS directly returns DOM elements much like in the top part of this post, yet it does not have these disadvantages. It's true that strictly put it's not immediate mode like React and Lit are, but the framework is designed such that there's few practical downsides to that.

Nice, I love lit-html(1)!

I wanted to add my two pennies to the discussion. You are of correct that with that approach you lose the declarativeness but sometimes you don't need that, if the thing is mostly static.

I went this road many years ago for a project. The nice thing of this approach is getting rid of all the ugly DOM API but enjoying it's performance over innerHTML.

(1) I absolutely love lit-html but don't like the rest of the lit components framework. Luckily you can use it independently!

Svelte and SolidJs work pretty well without VDOM

UI is not a pure function of state[0], "UI state" is relatively stable and does not have to be recreated constantly when data input changes.

[0] https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

you want to be able to reevaluate your templates repeatedly with new state

No you don't. It is inefficient and increases complexity. You then have to extract and keep track of state yourself where the platform/UI components could have done much of this themselves.

    Calling the same method over and over again is wasteful.

    So we don't do that.

    First, we did not start with the obviously incorrect premise that the UI is a simple "pure" function of the model. Except for games, UIs are actually very stable, more stable than the model. You have chrome, viewers, tools etc. What is a (somewhat) pure mapping from the model is the data that is displayed in the UI, but not the entire UI.

    So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability.

Just curious, have you seen Astro? I feel like it's the perfect SSG, but maybe you have some reservations that VanillaJSX solves.

What I’m seeing here is not new. It’s this vanilla pattern but with enough back support to leave off the framing and get the syntax highlighting:

Var button = html(’<button>im a button</button>’);

The html() function is trivial, but it just doesn’t feel like real programming to do this, even though there’s nothing else to it in the end.

A JSX for Django server side would be cool.

Large WASM payload on your site could be optimized.

not the hero we deserve but the villain we need

Love the idea. FYI, on your demo page, the todo app is 404. And you might want to spell out static site generator instead of saying "SSG" on your docs. I didn't know what SSG was, even though I've used static site generators. I had to ask the AI.

Have you looked into lit-html?

Coming from Vue I was really surprised it does a lot of what Vue templating does, including attaching events, with just vanilla JS templates. And when you use VSCode lit extension, you get syntax highlighting and full type checking inside the templates.

I learned about lit-html after a tweet from Marc Grabanski, where he said he used lit-html with vanillajs, not Lit.

After some experimenting I found it works great and it seems like you are trying to solve something very similar.

When you use the lit-html template package you can do basically evetything that is described in the Templates chapter

https://lit.dev/docs/templates/overview/

... without all the other abstraction of components that are part of lit-element.

https://lit.dev/docs/libraries/standalone-templates/#renderi...

DOM interactions (read, writes) are synchronous, they're very slow, and it must happen on the main thread. This can cause the browser tab to freezing if access and updates aren't carefully "curated" (ie you don't want to read-check-then-write in a tight loop; or even write too often, even if it's the same value).

It can also simplify some stuff surrounding event handling (but that's not it's main goal I think)

So people wrote various ways to defer/batch/denounce updates.

Virtual DOM is a general solution/implementation. It's not the only one, but I think you always need at least a tiny runtime to avoid too much DOM access (ie Svelte, Solid JS are fairly minimal)

The virtual dom makes implementing a declarative templating system easer, and declarative templates are easer for a developer to reason about, and less error prone, than having to mutate the dom directly.

People often mistakingly describe the vdom as faster than the dom, this is incorrect. It would be faster than throwing away the whole components dom and rebuilding, so the same templating code building a new dom, rather than a vdom that's then diffed. Hand crafter mutations will be faster than a vdom diff, simply because the computer is doing les work, however much more error prone.

Slows down your app too, sometimes. Depends how well you can work with and mutate a DOM, but if all things equal no VDOM is always faster cause no diffing.

It enabled a style of view library where you write immediate-mode type code that always recreates a whole component from scratch, versus having to write finicky code that both creates and then updates pieces of the page as state changes (dirty tracking, etc). Behind the scenes, you're creating the vDOM from scratch, which is diffed against the actual retained-mode DOM, and then only the pieces that are different are updated.

If you couldn’t efficiently batch updates, a vDOM could avoid repetitive updates in close succession, especially on IE6 (the browser React was designed for).

If you can control your app’s structure, it primarily adds significant increases in the RAM and CPU required for your app and slows load time because you are using a huge amount of JavaScript to emulate the carefully tuned C++ code built in to the browser. If you notice, most of the benchmarks from when React launched claiming performance wins were compared to heavyweight frameworks or complex jQuery plug-in combinations where a single user interaction might trigger cascading updates forcing the browser to rerender things which didn’t change along or to reflow multiple times in cascading update-measure-update chains. Pure DOM implementations were always faster, often by multiple orders of magnitude and once you could drop IE6, and then IE11, the DOM APIs and CSS were rich enough that much of the library code is now a net negative as well (e.g. people used to use complex code trying to build layouts which CSS grids solved).

With vDOM I could say `x = JSX` then cache that in state, inserting it in multiple places. Switching to Solid you have to make sure to use `x = () => JSX` & there's some mental model adjustments since logic outside JSX isn't reactive

E4X had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively. That's why JSX eclipsed it, and there hasn't been a serious proposal for HTML templating in JS since then.

But maybe we can revive the general idea with a modern take: https://github.com/WICG/webcomponents/issues/1069

Fun fact, E4X is the reason JavaScript has ‘for(of)’ instead of ‘for each’ (the reason we didn’t get ‘for (:)’ is even dumber - it would conflict with ‘:type’ annotations a few TC39 members were convinced would magically be in the language)

I would assume that lot of people just find the JSX equivalent a lot more readable and familiar (a matter of opinion, of course.)

  <div>
    <p>this is easy</p>
    {list.map((l) => <li>{l}</li>)}
  </div>

To be fair to JSX, you use regular loops, interpolation, etc without any different syntax (`{}` accepts a vanilla JS expression), you just obviously need the compiler step to de-sugar the element tags to `createElement` calls.

Here's my perspective. I never understand how some people could look at the code you pasted and think that's just as good. But different people's brains process information differently. Your example has a lot of punctuation that's very difficult for me to parse quickly. I don't see the DOM structure that's being created unless I manually pick the syntax apart in my mind, but understanding the DOM structure at a glance is far more important to me than whether I need a compiler. For the record, I'm neurodivergent. I hope that helps.

I've wondered the same thing. I think one benefit is that it looks like HTML, which means it looks similar to what you see in the browser's DevTools, which makes it easier to compare and debug.

Elm works a lot like this and it's quite nice.

Keep going down that logical rabbit hole. You end up with Common Lisp!

You might be confusing JSX for something else. In JSX you also don’t need new syntax for loops. JSX Is JavaScript, as people like to say.

But to your point, JSX doesn’t really do much. Your h function is basically what React.creatElement does. Google “React without JSX” and you’ll see how it looks.

JSX is just syntactic sugar over React.creatElement. And that is what makes it so nice… there _are_ no special constructs for loops, or variables, or components. They are actual JavaScript loops, JavaScript variables, and JavaScript function.

It makes JSX easier to reason about than most templating languages.

Because that code is very hard to read, especially with a complex HTML structure.

And then Svelte showed that you could avoid all that with a compilation step and live update the dom efficiently.

https://svelte.dev/blog/virtual-dom-is-pure-overhead

React is also at the point where re-rendering the whole app is a fiction the library maintains for you while being smarter and doing less, why not go the whole way?

(honest question, not trying to be snarky) Do you have one (many would be great) use cases where the practical gain of the virtual DOM solutions have a genuine impact?

I'm asking because, many of React (or friends) introductory material naturally focus on building things like TODO lists or Tic Tac Toe; while those offer insights into how to work with React (& cie), they're not showcasing cases where the performance gains are perceptible, and IMO not even cases where the "organizational" benefits of such libraries are salient.

There are plenty of cases where optimizing for performance isn't necessary. This is where React is not worth the extra headache and complexity.

For me is because is hard to remember that problem while dealing the the ones react brings.

I don’t recall being able to construct XML inline like this unless maybe that was a Flex server thing?

https://en.wikipedia.org/wiki/ECMAScript_for_XML - Firefox had it too, but people at large just didn't want it, so it got removed. It got disabled for web pages with the release of Firefox 17, 6 months prior to the first release of React.

Maybe I'm missing something, but how would this prevent you from using setTimeout/setInterval? But I agree that these projects often work great in small use cases, but quickly crumble under "real world" scenarios.

The technique I used here and in all my browser-side code is the exact same technique used by VS Code internally, and it scales very well. The only difference in my code is it's more concise than writing 10 lines to construct and setup a DOM element the typical way.

Honestly, the real interesting part about my framework is literally everything else. Returning strings from JSX on the ssg-side; being able to import raw source directories and manipulate string|Buffer at ssg-time; the extremely efficient and lightning fast module system I wrote on top of chokidar and swc; probably more I'm forgetting, but basically the JSX-as-DOM is only the most visually interesting part. But really just a party trick.

[edit] Case in point: the source code to vanillajsx.com is extremely concise and clear and short, I literally wrote the whole thing today with zero deps (besides imlib), and the JSX-as-DOM demos are the least innovative part of it: https://github.com/sdegutis/vanillajsx.com/tree/main/site

I'm by no means an advocate of this library, and never plan to use it, but to support component props that trigger rerenders, a'la React/Vue, I would use JS Proxies here. Wouldn't be that hard to implement.

Yup, in order to scale this approach to any real size (and still have confidence that everything is working together like you expect), a proper reactivity solution is needed.

For those that appreciate this approach of JSX returning concrete DOM elements, Solid works exactly like this, with the addition of a proper reactivity layer.

With the first example you have syntax highlighting and compile-time check.

With the second of you have stringa.

The benefit is that it makes people puke from looking at it so you have more job security I guess. Putting xml onto the same line with a scripting language is like mixing toothpaste and orange juice.

I don't understand why people take such offense to calling document.createElement() or document.getElementById() or kind of document. or window. function. It's consistent and native.

You're not alone. Someone suggested that the W3C should convene a Community Group to discuss JSX, but the grown guys involved in writing standards immediately scrapped the idea.

If there can be JS inside HTML, why not HTML inside JS?

There's a trick to it. Kind of like one of those 'magic eye' stereograms that were popular in the nineties. You sort of unfocus and boom, there it is.

It also reminds me of that Douglas Adams line about flying: it's the trick of falling and completely missing the ground, so in order to do it, you can't think about it too hard.

#real-todolist has an autofocus element and I'm using Firefox

Isn't SolidJS useless in the bundle size comparison?

React came out in 2013. At that time object manipulation would likely have been, at best, only marginally faster than writing to the DOM.

First, you have to understand that at that time Firefox was about 500x faster at accessing the DOM than Chrome and about 250,000x faster accessing the DOM via the API methods than via querySelectors. Firefox and Chrome performed about equally in use of querySelectors with Chrome being a tiny bit faster. So, the DOM was already fast, but occupied a different memory space than JS.

At any rate the original motivation had nothing to do with performance. The goal was to introduce a template system that fit with React’s state/component system. JS modules weren’t a thing yet, so code organization was very different at that time and centered around concepts like AMD and Common.js, though it was mostly some form of AMD typically require.js.

The design of the template system in Vue was created to solve for the exact same conditions according to the internal organization of Vue.

There is a library for Python called htpy that does this.

Trouble is if you're used to HTML it can take a while to get used to it. It's like a learned helplessness or something.

There are a lot of DOM util libraries that look like

  h("ul", h("li", "task 1"), h("li", "task 2"))

There's also variants like h.ul(h.li("task 1"), h.li("task 2")) using Proxies now too.

I see what you’re getting at, but technically the virtual DOM is what makes JSX declarative.

JSX doesn’t actually write anything, it’s just a templating language over React.createElement.

It’s the virtual DOM that actually syncs those structures created by createElement to the real DOM. So it’s the virtual DOM that allows you to write your code declaratively.

That’s evidenced by OP’s project, which is JSX without the declarative piece. You just get an Element and then you have to update it imperatively if you want to change anything.

Many programmers seem to be scared of anything that doesn’t have semicolons and braces.

Object.groupBy doesn’t seem to be available to all browsers before march 2024: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...