
Web-dev nirvana, and why I needed to let go of React to reach it - tobr
https://www.bryanbraun.com/2019/09/11/web-dev-nirvana-and-why-I-needed-to-let-go-of-reactjs-to-reach-it/
======
s_y_n_t_a_x
Recreating the wheel with many less features. React is an abstraction of the
view layer that's able render to multiple platforms (DOM, iOS, Android,
Windows).

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.

~~~
dclusin
The phrase using a shotgun to swat flies comes to mind. These modern
frameworks and tool chains solve very well understood problems. They enable
large teams of software engineers to collaborate and release complicated
interrelated software on predictable schedules. Not every project has this
requirement. For smaller projects the overhead and the included complexity
that comes as a result of using these frameworks and tool chains vastly
overshadows the benefits.

~~~
s_y_n_t_a_x
You should develop every project like it's an enterprise level app. Why would
you rewrite it in a different tech when it's ready to grow? It's easier to
use, why shoot yourself in the foot.

It's a myth you need a large team to create a React app.

~~~
dclusin
[https://arxiv.org/pdf/1702.01715.pdf](https://arxiv.org/pdf/1702.01715.pdf)

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.

~~~
s_y_n_t_a_x
The skeleton I use to create weekend projects is the same as what I use to
create enterprise projects. I don't see the need to juggle "simpler"
frameworks for no reason, especially when those "simpler" frameworks are
harder to use (because you have to remake everything yourself)

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?

~~~
dclusin
Following this logic Spring never would have been invented in the Java world
because Java EE does everything you need it to even though you don't need all
of those features. Frameworks and tool chains become bloated and convoluted
over time. I'm not super well versed in react/js/etc web development, but
given the regularity that you see and hear about these sorts of posts, a not
insignificant minority feels like the toolchain is overly complex for lots of
use cases. If it wasn't then the post wouldn't have made it to the front page.
It wouldn't have been upvoted just like our comments in this discussion :)
Just because _you_ find the toolchain an easy to understand time saver that's
pretty DRY doesn't mean everyone else does. Who knows? Maybe complexity in
React will continue to increase and someone somewhere will invent the Spring
equivalent for React. Why would they? Because they didn't need all of those
features. (Also thought of Vue.js spinoff from AngularJS)

------
mello151
Honestly, I love articles like these. I feel like so much of the time we think
in terms of frameworks as opposed to the problems they're there to solve.

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.

~~~
sunstone
"Things should be as simple as possible, but not simpler." AE

------
capableweb
Just for fun, here is what I would currently call nirvana when it comes to
writing React components (12 lines compared to 35~38 from the article)

    
    
      (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 + Reagent

------
Merg
That is way I really think Svelte3 can shake webdev a bit. It generates small,
plenty fast builds by default with easy syntax. Currently it is missing a bit
in terms of tooling, but the results just bring you back to almost pure HTML
and JS with much less to be worried about.

------
Epskampie
I like the gist of this article, but how would these components be nested? (Or
how could you add this?) That’s something I really need. I checked the source
repo, there is no nesting.

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

~~~
bryanbraun
Original author here.

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](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...](https://github.com/bryanbraun/music-box-
fun/blob/dc899c14adcd4b228b243cee1e88a394e204f805/js/components/note-
lines.js#L22-L25)

Edit: typos

------
HereBeBeasties
> You can’t just create a React app.

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.

