Web-dev nirvana, and why I needed to let go of React to reach it
bryanbraun.com
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.
It's a myth you need a large team to create a React app.
From the bottom of page 11: Most software at Google gets rewritten every few years... (continues with another paragraph).
In most of the companies Ive worked at for more than a few years some major piece of the architecture changes in ways unforeseen by the original designers. This usually incurs massive changes on the frontend, since it's often the glue that wires everything together. Migrating to react from a simpler framework is a minuscule amount of the effort. Large structural changes for growing software products are the norm, not the exception. If your project never gets past the initial stages its pointless to plan for the future when there might be none. Which is what this guy's project was, an initial project on a weekend retreat.
There are many small things I don't want to recreate that are always needed in every web app. Translations, authorization, accessibility, bug tracking, and more.
Another person said it best. You aren't going to use your own C++ compiler just because it's simpler and you don't need all the features, why do the same to the toolchains for 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")}]])))
Done with ClojureScript + ReagentAlso, wouldn’t using innerhtml cause scroll positions etc to be lost?
I don't think nesting is possible in the examples in that post. I'm sure there's some way to get it working that I just haven't figured out yet. Maybe you could replace the default template strings with something using tagged template literals (like https://github.com/developit/htm).
You can work around nesting by spinning up new components after the innerHTML assignment, and assigning them with IDs. Here's an example where I've done that:
https://github.com/bryanbraun/music-box-fun/blob/dc899c14adc...
Edit: typos
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.