Web-dev nirvana, and why I needed to let go of React to reach it (bryanbraun.com)

These "anti-React" and "web is too complex" articles are common.

It takes 1 command to generate a React project, all the configuration is done for you. This includes code-splitting where it generates a small runtime. The other chunks in the bundle are pretty small. Most of the dependencies are just for development.

React components themselves are easy to write and they don't lock you in to just the web.

I've been in situations where, for reasons I won't get into, I wasn't able to use large tool chains or have tons of dependencies. I had to distill things to the basic problem(s) that I needed to solve and come up with maintainable ways to solve them.

  (ns demos.core
    (:require [reagent.core :as reagent]))

  (defn DarkMode []
    (let [dark? (reagent/atom false)]
      (fn []
        (.setAttribute js/document.body "data-theme" (if @dark? "dark" "light"))
        [:label
          [:span "Dark Mode"]
          [:input {:type "checkbox"
                  :onChange #(reset! dark? (not @dark?))
                  :checked (when @dark? "checked")}]])))

Only you can. React on a CDN works and create-react-app is but a one line CLI invocation to... create a React app.

> we’d need to get rid of Webpack, since it’s difficult to comprehend and customize

Is it? You don't really need to customise create-react-app and even if you did, Webpack has good docs.

> We’d drop Babel too, since transpiling creates a workflow burden (especially for debugging).

Bit slow to start up the dev server, I grant you, but we're talking seconds here and how often do you do it? Hot reloading is instant. Source maps work. This feels fairly false. Importantly, the tool chain will check my code for issues, making my work flow much better. Especially if we throw in typescript. It also lets me use things like lambdas, again making me more productive, not less.

> we can end up with a codebase that’s shockingly React-like, without the workflow and maintenance overhead

Except for maintaining your own custom router, event handling, wrapper around some popular CSS framework so that you don't have to style everything explicitly, and all the rest of it, of course.

> It’s hard to overstate how much easier it is to develop once all the extra tooling and abstractions are gone.

It's hard, because it isn't really easier, is it? What specifically is easier? Having to make and debug all your own custom everything, including your own leaky abstraction? Having to figure out how to optimise the site's performance because you've thrown away the virtual DOM and all the benefits that brings? Having to write your tests against a real browser's DOM engine?

> You save a file, you refresh the page, and you see your changes.

That works just fine with create-react-app, etc.

> You can read your stack traces.

I already can, thank you.

> You can pause execution and not be lost.

Have you heard of breakpoints, or run to cursor? I'm not sure what this even means - does the author mean hitting the pause button in the debugger randomly while rendering the page?

> You can spend all of your time working on your app, instead of chasing down obscure build issues.

I already do, thank you. I suspect chasing down obscure build issues is comfortably less than 1% of the problem. I suspect it will be more than that if I follow the author's advice by "creating a production-only build", which will make my prod and dev environments wildly diverge. No thank you. I already have a production-ready build backed by battle-tested tools maintained by someone else.

This looks strongly like a toy solution in search of a problem.

No one would advocate building your own custom C++ compiler just because you don't use all the features of the language. This is basically the same.

Also, wouldn’t using innerhtml cause scroll positions etc to be lost?