badge.textContent = count > 99? '99+' : count
  badge.classList.toggle('show', count > 0)
  paper.classList.toggle('show', count > 0)
  fire.classList.toggle('show', count > 99)

Anyway nice demo. Bi-directional is already quite powerful!

The reskill problem is of similiar difficulty with learning a new framework I think. Especially because the language is rather simple compared to typescript (which is also its strength).

I do understand it is an uphill battle. The whole nobody get's fired for choosing IBM thing. The language is still unproven in the general perception. I do think that when it comes to libraries and frameworks I see a lot of developers choose new unproven stuff, more then they do languages.

You don't have to rewrite your whole codebase to start using it. It grows horizontally (you add typed files along the way) compared to typescript which grows vertically (you enable it with Any types).

The point is that we don't have to move back to plain js. We have learned a lot since typescript was created and I think the time has come to slowly move to a better language (and ReScript feels the most like Javascript in that regard).

In general I prefer a better language over an involved javascript framework that does not look like js anymore.

cleaning up listeners or cleaning up DOM nodes is rarely needed. Just remove the component element and the browser cleans up automatically.

    
        a
        b
    
    ...
    ...
    

    const [showing, setShowing] = useState(null)
    const handleChange = ev => setShowing(ev.target.value)
    let other
    if(showing == "a") other = ...
    if(showing == "b") other = ...
    return <>
        
            a
            b
        
        {other}
    

- The complexities of both of these tiny pieces of code is similiar (I would say)

- React needs to load a big bundle

- React spits out a large stacktrace with react internals if something goes wrong

- React is slower

- React code cannot be easily stepped through with the debugger

- React needs a build step

- React performance is very unpredictable (this is more of a problem with many elements and dynamic code)

Your next question might be what you do once your form grows huge. See my other answer to @iliaznk how I handle that.

    const tag = (tagName, props, ...children) => {
        const el = document.createElement(tagName)
        for(let k in props) el.setAttribute(k, props[k])
        for(let child of children)
            el.appendChild(typeof child == 'string'? document.createTextNode(child) : child)
        return el
    }

The main advantage I think React brought is breaking the concept of "separation of concerns" (keeping css, html and js in different files even when they change together). Keeping stuff that belongs together in the same file and mostly pure is what gives the most benefit. You don't need complicated frameworks for that.

    const createSpecialButton = text => tag("button", {style: "background: purple"}, text)

I wrote a figma clone (see other comment) with couple of these utility functions. It looks a lot like a regular react project really. Mostly functions (which you might call a component if they return HTML), mostly pure or local state.

On the first page "Quickstart" all code blocks contain code that contain JSX and call you. They do not even show the part where you need to call render. Copying this code into your codebase will not do anything.

On that same page they also introduce state management with hooks.

On the installation page npm installing react is not mentioned. They suggest using create react app.

Sure you can theoratically use react as a library but I've never seen it and from the website it seems like usage as a library is not the inteded way to use react.

The first sentence "The library for web and native user interfaces" is the only thing pointing to react being able to be used as a library. The rest of it looks like a framework to me.

When I write vanilla js I don't have a seperate file called framework.js. There is very little code needed to manage state. Almost all functions in my codebase are doing concrete things.

As you can see most functionality can be implemented in around 100 lines of code. The advantage is that you can build up functions just for your needs. These functions are super easy to understand because they don't have any dependencies and the whole implementation fits on one or two screens. There is very little indirection.

Another advantage is that most code is actually doing something concrete. With frameworks you often have a lot of code that is just pointing to other code, or is boiler plate code to set something up. Not having any boilerplate code also makes stepping through the debugger a lot easier.

The project has no build step in development which also makes debugging easier. It does have a build step in production.

Most people use frameworks to give the code structure. When writing vanillajs you need to bring the structure of the code yourself. This does take some getting used to but I think it is an essential skill for good programmers to have. On top of that many frameworks push you into structure that does not make much sense in my mind (for example seperating the view and the controller if those are always gonna change together).

So to conclude: My advice for building without frameworks is, just start building. Problems will come up and you can tackle those as you go. Do you think you need to use events in your application? A simple implementation is 10 lines of code and can be written in 10 minutes. If it takes me 1 hour to not use a library I will spend that 1 hour. Most frameworks will not bring that much value. Easy things become short and hard things will become impossible. I think most value is actually brought by the language and the basic api's (DOM, CSS, etc)

I guess this means that one should solve the appropriate problems for a given skill level

It is sometimes still a problem when you define a function without reference to it (because the types are unnkown ofcourse). You will have to add types to it or call the function before implementing it.

There was also a great blogpost about it: https://www.javierchavarri.com/data-first-and-data-last-a-co...