I agree about the nuisance of creating DOM elements. innerHTML is OK if you’re doing static content, but for anything that needs to be dynamic (untrusted input, event handlers, etc.) I have a little tiny helper library that I carry around in my head and write into projects that need it:

    const $T = text => document.createTextNode(text)
    
    function $E(tag, props, kids) {
        const elem = document.createElement(tag)
        for (const k in props) {
            elem[k] = props[k]
        }
        for (const kid of kids) {
            elem.appendChild(kid)
        }
        return elem
    }
(Add flourishes as necessary for things like optional arguments and allowing falsey kids.)

This isn’t as nice as JSX, but it makes a reasonably ergonomic API for quick little projects. Here’s what the example in the article would look like (admittedly it’s a bit easier to follow with syntax highlighting):

    const button = $E('button', {}, [
        $E('i', {className: 'icon-lightbulb'}, []),
        $T('I learned something!'),
        $E('object', {data: '/confetti.svg', width: 30, height: 30}, []),
    ]);

Not nearly as minimal as your example, but I like the "no build tools route" of using preact. You don't need to build your code, and you can get JSX-esque syntax and some of the niceness of React without messing with npm or webpack or any of that.

https://preactjs.com/guide/v10/getting-started#no-build-tool...

I am failing to understand why someone would choose this over React. The page you linked to, I kid you not, has a section about how you build a Preact application from the command line...

I linked to the "no build tools route":

> Preact is packaged to be used directly in the browser, and doesn't require any build or tools

Oh I gotcha! That quote applies to react as well though (I've done it many times!).

I suppose I could rephrase my question to something like "What is the point of this library?". Every other page on that site that includes examples uses JSX... which means there needs to be a build step.

I guess if someone really just wants to include a 3rd party library to programatically create elements, but get none of the benefits of using them this would be great! Then again there is like 3 examples in this thread of tiny functions (< 10 LoC) that appear to do the same thing.

I guess 3.5kb is about 10x smaller than React + React DOM, but 35kb isn't exactly breaking the bank either. I can't tell specifically by glancing over their examples, but I also suspect feature parity is not quite there. Specifically, I develop with Typescript so being able to type hint `React.ChangeEvent` etc. is sometimes necessary. It's not clear if Preact exposes a sufficient API. Maybe you know?

> I suppose I could rephrase my question to something like "What is the point of this library?"

It's just a lightweight, no-build-steps-required library that's similar to React. If you already like using React there's nothing much compelling to make you switch.

I like using it with HTM for a nice alternative to JSX which doesn't need any build steps.

I can't speak on its interaction with TypeScript, I've only used this for simple pages where I want to add some interactivity without involving the rest of the nightmarish JS ecosystem.

https://github.com/developit/htm