
Progressive React - brandonhall
https://houssein.me/progressive-react
======
mhd
"Performance advocate" is a thing now? Things like that or "growth hacker"
make me long for the peaceful days of "ruby rockstars" and "javascript
ninjas"...

Never mind the fact that we're plowing the depths of functional programming,
complex data structures and asynchronous wizardry just to make sure that
displaying a few bytes of text and flat-shaded borders isn't too slow.

I don't remember GUI programming being that hard in the years before this. At
least for these rather simple results. Getting a full DTP platform out on a 20
mhz machine with 4 MB of RAM required some advanced pattern wizardry, but most
web UI patterns aren't that complicated. They just aren't helped by the
client-server nature and Javascript being Javascript, as much as you wrap it
up in the Emperor's new C# clothes.

> Sites have become bigger, more interactive and more complex and this number
> is still gradually increasing in an upward trend year after year.

Yeah, but is it useful complexity? The whole frontend scene often reeks of
"bullshit job" syndrome. To get results customers could live without in a
framework not re ally suited for it, we're developing complex tools, even more
complex tools to package and deploy them and then have more coaches, trainers,
video walkthrough creators and premature optimization providers than ever
before.

------
ahartmetz
It's funny because scrolling in this article is a stuttery mess (Firefox on
Linux).

~~~
LeftHandPath
Yeah, this made my whole browser lag (buttons-shading-five-seconds-after-
hover-level lag).

FireFox Quantum on Windows 10 with a pretty badass CPU. Also slow in Opera.
Also slow in Vivaldi.

And it crashed Chrome Canary.

For a web-tech post, this is pretty fucking bad.

~~~
airstrike
Works fine in Firefox in iOS...

~~~
Proziam
Works fine in Firefox on Deepin as well.

------
adatavizguy
As someone who has web apps in production written in backbone.js, Angular, and
React, I can say selectors with Reselect to transform all the data being
passed into props, Sagas to manage all async workflows, and Ramda with Redux
reducers is pure fire. There is no business logic in components or containers
unless it is tied directly to the view and layout, not for the data. It is
such an easy way to reason about huge amounts of data coming into the system
from lots of different places. For performance, everything gets memoized based
on object references. Using the immutable data structures in the store,
Reselect keeps the transformed data cached with memoization until the object
reference is changed in the store.

~~~
sickcodebruh
I’m mostly with you there but I’ve found saga to be a double-edged sword. The
library offers some KILLER features and when you’ve got the right use case,
it’s perfect, but it’s so easy to abuse. Because it does so much, I found
myself putting more and more responsibilities on it and wound up with some
very magical feeling, hard to troubleshoot code.

What changed everything for me was adding GraphQL and getting the majority of
my API communication and data storage out of redux. Now, sagas and redux are
further down the list of tools I reach for, complexity is way down across the
board, and the sagas and reducers that’s remain are more narrowly scoped and
easier to reason about and maintain.

~~~
acemarke
I'm a Redux maintainer. Sagas are a great power tool, but most apps don't need
them [0]. We recommend that most apps stick to thunks as the default [1], and
our new official Redux Toolkit package [2] adds thunks automatically to your
store setup.

I've used sagas in a couple apps that truly did have very complex async
workflows, and they were great for that use case. But yeah, using sagas _just_
for something like data fetching is definitely overkill.

[0] [https://redux.js.org/faq/actions#what-async-middleware-
shoul...](https://redux.js.org/faq/actions#what-async-middleware-should-i-use-
how-do-you-decide-between-thunks-sagas-observables-or-something-else)

[1] [https://redux.js.org/style-guide/style-guide/#use-thunks-
for...](https://redux.js.org/style-guide/style-guide/#use-thunks-for-async-
logic)

[2] [https://redux-toolkit.js.org](https://redux-toolkit.js.org)

~~~
the_gipsy
As someone that had inherited a redux-thunks project, for me thunks are like
calling fetch() directly inside your components callbacks, with extra steps.
Really bad for testing and isolating code.

I haven't tried saga, just rxjs with redux which was definitely good. I've
also worked with Elm, which supposedly inspired redux. Elm does it perfectly,
I don't know why Redux missed async.

------
timw4mail
The more I deal with it, the more I hate React, and the very idea that
websites must require Javascript to just show HTML.

~~~
sombremesa
Fear is the path to the dark side. Fear leads to anger. Anger leads to hate.
Hate leads to suffering.

Jokes aside, everything has its place. You're still allowed to hate it though.
For example, I hate Redux because everyone uses it for every React app and
it's got boilerplate up the wazoo.

Just know that if you "hate" things, though, you won't learn as much in life,
like I won't learn how to use time travel debugging. Almost anything that gets
this popular has at least a few core ideas we should probably learn, or learn
from.

~~~
randomsearch
I’m not sure this is true. For example, what can I learn from JS that isn’t in
better languages? In tech we have this weird situation where many things
become popular without good reason. It’s ironic, because a group of people
(nerds) who think they are the epitome of rationality are actually the
opposite: we make very emotional decisions when we could be entirely rational,
as we have access to data other fields do not.

~~~
simongray
Frontend doesn't always mean using JS. You can use a well-designed, modern
language like ClojureScript instead that isn't anything like using JS, yet
nevertheless has the same access to the browser.

~~~
austincheney
Well... there are only two standard APIs for the front end: DOM and the web
API (browser stuff and HTML5 things). Once comfort with those is achieved you
suddenly need so much less code to do radically more ambitious things.

The time saved in both authoring and maintenance pays for itself in learning
the standards.

------
singlow
Start by making your blog not crash android chrome.

~~~
maverick2007
Crashes mobile Firefox too. Very ironic given the small portion of the article
I read before it crashed.

------
5Qn8mNbc2FNCiVV
Visiting that page on the Pixel 3aXL and it literally crashed while scrolling.
I've never had that happen once in the last few years. Damn.

------
duxup
Is that site crashing anyone else's browser?

I'm using chrome on Android and it kills my browser every time.

~~~
skept
It's crashing Samsung Internet on my Pixel 3.

------
jingw222
So progressive that the minute I open the page, it crashes. Have no idea why
that is.

------
ggregoire
Great write up, going deep into the topic.

This comments section tho.

------
qbaqbaqba
Crashes mobile Chrome.

------
seph-reed
I know this is a low quality comment, but given I was once the guy at my last
company who's job it was to make React do things it didn't want to, I really
dislike React. It's a dead end for interactive UIs, and the closer you can
stay to native html elements with encapsulation, the better off you'll be
later down the road.

~~~
hesarenu
React is best suited for interactive ui. For static sites just html/css should
be fine.

~~~
friedman23
I actually like to use react for static sites too but mostly because my main
work is in react and I like to maintain one mental model for everything.

