Slides, may be?

act1.md

How to avoid React, may be

1. React is not a "simple" library. A lot of pull for React or any similar frameworks/libraries is the ecosystem. Once you embrace the ecosystem, there really is little you can do to go back or simplify anything.

   The problems with client-side-first libraries are probably well-documented:

   1. Not simple
   2. Bleeds into static HTML heavy pages and ends up being a heavy JS blob rather than a browser-optimized HTML, unless you go all the way like what Gatsby does.
   3. SSR with dynamic data is not straight forward. Yes, there are libraries to do this, but still.

   etc. Not going into this argument

2. The point of the talk is not to talk about the pros/cons of React or even client-side rendering. It's more about: how much and how far can you delay the decision to start using a full-fledged client-side rendering framework.

   Say your team is comfortable in PHP or Rails or something. What's the furthest that team can go without actually doing a full rewrite (and possibly re-teaming [that's not even a word!]) in JS.

   If you've sat in meetings where they lead to the decision of "just" using a frontend library, or contemplated this on your own, may be try to push that decision further away.

[ SCENE 1 ]

Product Manager: Hey, we have all these images and links on our product page. We need tracking to see how long users are viewing that content.

You: Hmm. This might mean I'll have to write a scroll listener that picks up all the ids of the "components" and somehow call a backend API to signal the times.

"components". Ah. React.

Me: No.

[ SCENE 2 ]

Engineer 1: Hey, I need to implement dynamic client-side validations for our main form. I added some event listeners on the fields, but the code is getting hard to manage. If only I could refactor each of the fields into self-contained "components".

"components". Ah. I know. I'll write the form in React.

Me: No

[ SCENE 3 ]

Engineer 2: Our product page loading performance is pretty bad. We're loading all these images at a higher resolution to ensure customers on retina-like displays don't see graded/blocky images, but it's not helping people who aren't on them.

Engineer 1: Ah, we can detect the pixel ratio of the screen, and make sure we render the exact image component that we need.

"components". Ah.

Me: No

[ SCENE 4 ]

Engineer 1: We have a JSON blob coming from some source, and we need to render HTML out of it. The appendChild-ridden code we wrote works, but is hard to maintain. Should we just use Preact?

Me: Maybe. Don't.