Cover image for Stop Using React

Stop Using React

ender_minyard profile image ender minyard Updated on ・3 min read

I thought I simply didn't understand React. I taught myself React and I still wish I could go back in time and make it like React never existed. Here's why.

1. It's slow

mobile source: tim kadlec

53% of mobile users abandon websites that take longer than 3 seconds to load. For every additional second a page takes to load, 10 percent of users leave. Performance is user experience.

Also read this.

2. It's expensive

Put your React app into this testing tool: https://whatdoesmysitecost.com/.

Do you care about people who can't afford to pay for expensive websites on their data plan?

A lot of people have discussed how expensive JavaScript frameworks are, but it seems developers don't care about reaching all their potential users. I'm not the first person to make this point, but it seems like the message isn't getting through. Do you think some users are more important than others? Do you care about reaching all users or only the wealthy ones?

3. It's inaccessible

Hundreds of millions of users access the Internet from feature phones with a 2G connection. When you load all your JavaScript onto a feature phone, all the user sees is a spinning wheel.

There's so many articles, tools, and frameworks that help you develop for these users - but developers scorn them. Within the JavaScript subreddit, web workers are hated, even though they are one of the best tools we have for effectively developing apps on feature phones - scratch that, for all users!

If your app is fast on a feature phone, it will be blazing fast on an iPhone. When you develop with all users in mind, it improves the user experience for all users.

4. React goes against what the web was made for

Here's the general idea of React: you download all the JavaScript a website needs for like, seven seconds in a row without showing anything, but once you do that, you never have to download resources again, because you've made a single page application.

Is this how websites are supposed to be?

"The web is a streaming thing by default. You go to a page and it serves HTML. You'll start seeing it as it's downloaded. Same with images, video...You can do something with just a little bit of the response." - Jake Archibald

The Internet is a stream. React is not. I see it like this: React fights against the natural flow of the Internet.

Ditch React and become friends with the web. It's a web, interconnected, with resources coming from everywhere. Web apps are not like native apps that take 30 seconds to download before the user accesses the content. Stop treating webpages like native apps.

5. It's made by...those people

Just read this Wikipedia article. No, it's more than you expect.

Posted on by:

ender_minyard profile

ender minyard


Web performance, web workers, and multi page applications.


markdown guide

I think this is not the problem with React (well, apart from point 5), but with modern webdev in general. React is a good tool for single-page applications (so is Vue or Angular) but in many cases you simply don't need and should not have a SPA in the first place.


I was going to title this "Stop Using Modern JavaScript" but decided to call it "Stop Using React". I can't agree with you more, the problem is SPAs in general. I would like someone to explain to me why SPAs need to exist actually. (Preact is an okay framework for speed, but I would still prefer writing HTML...)

I think SPAs are mostly useful for companies who need to organize their code...right? I don't get it.

HTML already has modularity and templating built in, if copy and pasting is what grinds people's gears.


SPAs are actually useful. It is justified when you trade a longer loading time for faster interactions in the future. Think a webmail client, like GMail. Sure, you can load a lo-fi version and keep reloading on every click, but the experience of having email load super-fast and be able to answer them fast is just nice. You usually spend a couple of minutes browsing them and then the time consumed on initial load is saved.

Other areas where SPAs are good are live applications, such as betting ones. You always want to see the current stakes, so you need the data pusher from the server to update what you see in the frontend. No one would probably bet on a static site (unless those are bet for something static too, for example "which year a human will land on Mars").

And of course, SPAs are a must in web applications imitating interaction from regular desktop applications, such as Google Docs.

Pity they are also used in blogs (!), contact forms (!!) or just informative website about the small business.

Thanks for the explanation!

My opinion is that React should be a last-resort option considering all the negatives, and even then, should be used with adaptive loading and every web performance optimization possible. Right now it seems like React is the default for every app and no one considers the negatives.

I also know that Facebook, who developed React, is aware of these negatives and serves a different version of Facebook to users on feature phones (a version of Facebook with less JavaScript to download) than the version they serve to users on iPhones. The developers of React know that React is flawed.

Complex apps that actually require JavaScript intensive SPAs usually have adaptive loading in place (Gmail has the basic HTML version for slow connections) but the average developer doesn't think about any of this.


SPAs fit into the Progressive Web App movement which is about bringing native experience to web. So websites feel like mobile apps that have instant load time.
It can also involve service workers to fetch data in the background and also cache it esp like a feed of posts or photos.

What I like about a SPA is it can be served as a static site on GH Pages or Netlify (if you use a CI build step). So no speed and hosting and security issues that go with having a Node Express app. Just fast static assets served.

I recently moved a project from templating with Mustache to templating with Vue and the move meant I didn't have to think about low level DOM operations to find values on form elements and push the results to an output section. I get to focus on the variables as they are bound to HTML elements.

I do agree with your sentiment. Don't make a web app into a desktop app and don't break if JS can't run.
JS was designed for a philosophy of progressive enhancements. I have a JS book I read which emphasises this at the start. Yet many sites are blank with a warning to enable JS. And sometimes just a blank page! The obsession with JS means sites are unusable if you have an older browser or the developer used only the newest syntax and didn't use babel to get output that works pre-ES2016/ES6

I like using Jekyll for templating in general to avoid JS on the page. Or to just add JS to add sort or filter on say a table.

The main reason I guess I like JS whether SPA or not SPA is that there is no page load when you submit a form or like a photo etc. There is white screen flicker.

Progressive Web Apps are great!

For interest, I added Vue to my jquery mustache site using frontend code only. So adding a script tag loading vue.js and then using a script tag on my HTML page.

This was light as there was no build step and the site was not a SPA yet, just HTML pages with JS added on top. And I could have using jekyll to add consistency so I have Vue load in the head of each page.

And I could have broken my JS into standalone JS files so I can run tests and linting against them.

The thing about the SPA style is that it means you manage your JS deps using a package file and you then import that in each of your scripts. You treat them like modules like in a server side app like an API or CLI. The problem with the browser approach is there aren't imports, just script tags loaded in a certain order.

Having said that there is a newer syntax where a script tag is imported as a module and you can use import x as * from 'jquery' in a JS file and then use it on the frontend! I am have just not tried it yet. But it means better server side feel of development with the frontend usage without making it a SPA.

SPAs fit into the Progressive Web App movement which is about bringing native experience to web.

That is a misconception that dates back to the App Shell Model.

The core technology for PWAs is ServiceWorker using the Cache to retain the essential parts of an (possibly MPA) web site for offline usage.

Developing Progressive Web Apps (PWAs) Course.

"bringing native experience to the web" is a fools errand.

Web vs. native: let’s concede defeat (2015)

Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.

Why Progressive Web Applications Are Not Single Page Applications

I like using Jekyll for templating in general to avoid JS on the page.

FYI: Eleventy was inspired by Jekyll but uses JS instead of Ruby.

So adding a script tag loading vue.js and then using a script tag on my HTML page.

That approach isn't recommended:
Why You Should Avoid Vue.js DOM Templates

The problem with the browser approach is there aren't imports,

Besides type="module" bundlers were introduced to enable "modular JavaScript" - not to support SPA's. If you are using React/Vue your choice (webpack) is essentially made for you - but for anything else I find rollup.js a lot saner especially as it is built around ES2015 modules (esbuild is faster).

So adding a script tag loading vue.js and then using a script tag on my HTML page.

That approach isn't recommended:
Why You Should Avoid Vue.js DOM Templates

I don't really understand. The website just tells good solutions, but not really against it.

Thanks for the links.

The part about not using Vue template on the frontend might make sense in certain cases like if you are making tables or you have SSR. But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it. Same goes for React and Preact especially. A SPA structure comes with safety but it also has a cost which is the point of the post.

What I meant by the module syntax is that I can use that to get the experience of writing JS tests and imports like in a SPA but without actually structuring as a SPA.

I have heard of Eleventy and Gatsby and others but haven't really tried them

But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it.

When using DOM HTML as a template you have to ship and execute runtime + compiler (93kB) rather than just the runtime (65kB) on the client.

When you use a build step to compile the template into a bundle you only need to ship the vue runtime to the client - this isn't the same as building an SPA. At the core of the original article is the notion that it should be a goal to ship and execute less JavaScript on the client.

The "Developer Experience" Bait-and-Switch

Any opportunity to complete work at build time that reduces the amount of code needed at runtime should always be taken.

Time and time again Rich Hickey's observation proves to be accurate: Programmers know the benefit of everything and the tradeoffs of nothing.

Many tools are adopted to enhance the "developer experience" while the potential negative consequences downstream are either ignored or downplayed.

I see the solution as quite easy.

Use *.vue file, with Parcel. It will internally use vue-template-compiler.

Do not put <template> tag inside Jekyll.

I actually followed an approach without a template element so could have skipped the compiler.

I just added v-model etc. to plain html and setup new Vue(...) at the bottom.

Here was the work in progress before moving to SPA


I did use vue-markdown tag though which I guess needs the compilation.

Thanks for sharing. I liked the video a lot.

I it was pointed out earlier in this thread but there is a major misconception that SPAs are PWAs. A SPA can technically be a PWA, but honestly there is no justification for SPAs in the context of a well written PWA.
The service worker can eliminate the network latency, which means you can ditch the fat, out of shape, slow JavaScript that are popular fast food frameworks.


Why not use sth like NextJs? That’ll create a server side rendered page using React. No SPA here.


SSR introduces component rehydration overhead on the client (compared to plain server rendering) which increases Time to Interactive (TTI).


Even static websites generated with Gatsby rehydrate (by default).

Doesn't matter. With Next or Nuxt you get a fast first render with SSR, and then if you use their Link component, that requests all links from the page in the background and caches them in the client side router so that when you click something else, navigation is instant. And anyway, you can't get away from the client-server model and network lag, so why is everyone here expecting INSTANT f'ing load times? That's just ludicrous!

so why is everyone here expecting INSTANT f'ing load times? That's just ludicrous!

Because the gold standard is set by the speed of static pages.

Starting with The Cost of JavaScript 2018 Addy Osmani identified "hydration" as a potential cause for

An experience that can’t deliver on this will frustrate your users.

in reference to

For a page to be interactive, it must be capable of responding quickly to user input. A small JavaScript payload can ensure this happens fast.

2013: Progressive Enhancement: Zed’s Dead, Baby

Despite progressive enhancement repeatedly being declared dead, in 2016 Jake Archibald stated

So you should think of the network as a piece of progressive enhancement

This illustrates that PWAs got their name from progressive enhancement:

  1. Content is the foundation
  2. Markup is an enhancement
  3. Visual Design is an enhancement
  4. Interaction is an enhancement
  5. PLUS: The Network is an enhancement

Jeremy Keith outlines that hydration is no substitute for progressive enhancement.

The goal is keep the amount of JavaScript that is critical for interactivity to an absolute minimum (and load anything else separately, preferably on demand or to be cached for later use).

Matching the performance of static pages with dynamic pages is unrealistic but web site/app owners have a wide range of approaches available to them for improving performance on the server side. But they have no control over:

  • the quality of connection to the client device
  • the compute power on the client device

In light of these limitations the prudent defensive strategy is to deliver payloads that are small (the minimum for the necessary capabilities) and require relatively little compute.

Modern web development within the current JavaScript ecosystem doesn't follow these kind of practices.

The approach to move as much work away from client run time to site build time (e.g. Sapper/Svelte) is a step in the right direction.


Well, you still have to use React, which is Facebook porting the PHP bad practices into JavaScript.

I don't like to say "X is better than Y" because it's usually very subjective but let's put it that way. The only people I've ever seen like React are comparing it to jQuery in their heads while the people I see using Vue/Nuxt often had a severe JS fatigue and take pleasure again in doing front-end.


Because that means JavaScript on the backend.


I found this to be a great guide from @_developit , jasonformat.com/application-holotypes, when deciding on how to architect your application.


Alright, I gotta admit, this is a pretty interesting take on react. Everywhere I go (meaning conferences, bootcamps, workshops etc.), all the web devs are always raving about React. When I tell them that I have never learned react and I am just a good old PHP guy, they look at me like I am from the stone age.

What, in your opinion then, is worthy of learning when it comes to web dev frameworks in say 2021?


Try Svelte. It's a lot more fun and fast to get results. And the pages run faster. You feel like you are just doing html pages with minimal templating/framework bullshit. You can add self contained components into plain JS sites very easily so long as you are prepared to use webpack or rollup. I'm an Elm fan for real engineering otherwise but if you want something quickly such as your own project then Svelte wins.


You can do so much with plain Javascript considering the advances it made in the last several years. There is also Vue.js which could be imported using a good old script tag.

Personally, I prefer the React's approach to UI (one-way data flow, views as composable functions, hooks), and it is where other ecosystems are converging to (android's Jetpack compose, iOS's SwiftUI).


I've worked with vue for quite some time and used react little bit, but I'm most comfortable with php and now work with php mostly. Thankfully now there is tools like livewire when I need some frontend framework like interactivity


Take a look at the modern MPA approach with Rails 6, StimulusReflex, CableReady, and ViewComponent. All the goodness of a full featured SPA framework, reactive interactions, components, organized js, and all state remains on the server. docs.stimulusreflex.com/


With the amount of churn on the front end I'd recommend just picking something up as and when you need it. The problem with the front end is that you can master something, and it be totally looked down upon in 2 years time


Everywhere I look it's React, Angular or Vue. Everywhere I looked 2 years ago, it was React, Angular or (albeit less so) Vue. Sure, new contenders are coming up, but these "Big Three" are not going anywhere anytime soon.


Assuming you're in PHP you must be a back end dev, so makes no sense to learn complex workarounds for front end while you'll never use them at back end. You could get more profit from learning laravel, lumen, symfony and so than putting your hands on a front-end library/framework.

Even those I'm full stack myself but I'm more on the front end and also learned about laravel for example so if you got the time take a look to those trendy SPAs using react, angular, svelte to see what is the reason to be for each and where they can fit best if you want to know more


I understand your point but just to clarify, even though I am a backend dev, I do a whole lot of front end development work as well. I have made a lot of websites in my freelance career and I am proficient in JS, jQuery, etc. Trouble is that now when I attend web dev interviews, the interviewers seem to have somewhat of an obsession with JS frameworks. I have only attended workshops for Node, React, Angular etc and have never done an industry level implementation of them. But just because I am not into JS frameworks doesn't mean that I should be treated like a dinosaur 😛

Hahahaha of course not, at the end if you know javascript and how to deal with APIs that's all you need to put your hands on into any JS framework and being productive in few days

Agreed. It just surprises me how the definition of a web developer evolved into 'JS Frameworks Expert". There is so much more to web dev than that!

well, even having those caveats (no static typing, single thread, performance...) still have some benefits such as being multi-platform (almost run everywhere), easy to learn and there are tools that "patches" JS "issues" such as TypeScript (javascript superset), and so, and browsers increased the performance of JS engines a lot too. It's used widely and consistently because there's no good supported option over the table to replace it yet.


Phoenix LiveView. You code it like an MPA, it feels like a SPA, it doesn't suffer the large JS bundle problems and uses web sockets to send diffs back to the client. And if they disable JavaScript? Things still mostly work as an MPA.


Based on what's out there, I would say Preact is accessible to way more users than React. And truly, you don't need to use a framework. HTML is okay, don't let anyone tell you otherwise.


Alright TBH, I have never even heard about Preact before so will definitely have to look it up 😛. I would love to stick to my roots (i.e., php), but the level of condescension I face during interviews for it is frankly unbearable. Even though more than 50% of the internet is wordpress (i.e. php), somehow I am considered ancient.

There's no evidence that JavaScript frameworks consistently improve the user experience but you're considered out of touch for not using them because they're in style right now. Trends are exhausting, but don't worry. They come and go.


I love React, but I feel there are two kinds of developers: the ones who understand it and others who don't. The "standard" way of learning and doing React is wrong: bootstrapping an app with CRA and just building it to create a SPA is bad as OP pointed out.

I have been working with React for like 5 years and I can tell you I have created some fast and performant JAMstacks, just look how successful Gatsby.js and Next.js have become...


I think you have forgotten another of the main points why react should not be the first option. I'm talking about one of the ugliest and most aberrant things that have been done related to the web lately. Of course I'm talking about JSX


To each their own, I really like JSX. Prefer it way more than HTML templating for sure.


Comparing the ugly spaghetti code that forces you to produce JSX with the clean, comfortable and easy template engine of frameworks like Angular, Vue or Svelte??. Analyzing one of the most basic examples:

// React ul loop syntax
const names = [‘John’, ‘Sarah’, ‘Kevin’, ‘Alice’];
const displayNewHires = (
    {names.map(name => <li>{name}</li> )}
// Same Vue Syntax
  <li v-for=’name in listOfNames’>

I'm really trying to understand your position my friend, but I just can't ...

As I've said, to each their own. I might have been burned by AngularJS that I don't really like HTML template strings or whatever. JSX feels really good to me and tooling for it is phenomenal since it's "mostly JavaScript". Although I do admit it can get a bit complicated at times if you have lot of conditional rendering or stuff like that.

One small flaw with this example is that you show React component rendering, but for Vue you just show the syntax for that component so these examples cannot really be compared. If this example didn't have ReactDOM.render call, it would then be apples to apples comparison in this case.

You can't decouple view from the logic in react, no matter how hard you try, so it's a perfect example

Completely contrived example. You are comparing apples to oranges by including extraneous stuff in the React section. Once you strip that away, you are left with just a few lines of what is essentially HTML + JS.

One can certainly argue that the mixing of HTML and JS in JSX is strange/unconventional. But I'd rather think in terms of JS logic that can spit out HTML than deal with some random template syntax. To each their own.

I have never said that it is not useful or powerful. I just think it's pretty ugly at the code level. In any case, HTML came before Javascript and although a tag language may not be very attractive for modern programmers, for a reason of hierarchy and how the web works, I see more sense to put JS in HTML than the opposite


Regarding the code sample above: there is no such thing as "React ul loop syntax". It's just plain old mapping any JS dev already knows, with JSX output. With Angular etc. you need to learn a framework-specific syntax, which is fairly easy with loops but gets messy as you go deeper.

I don't buy the "logic coupled with syntax" argument, either. It's perfectly fine to couple UI-related logic (animations, accordion states, focus trapping in modal windows, you name it) with the UI itself.

Now, if by "logic" you mean sending network requests or managing application-wide state, then just don't do this in UI components, what's so difficult about that?


Although I don't really like JSX in the past, I have changed my mind.

JSX is the best way for your template engine to be smart with IDE, being a mere JavaScript function, that is.

Spaghetti or not is something you have to learn to manage your code.


Garbage In, Garbage Out. Don't blame the tool.


Interesting perspective. I think rather than being solely a React issue I think it’s a SPA issue. Single Page Apps are the reason the web doesn’t behave like the web anymore.

Another issue is using frameworks for the sake of using frameworks. The first thing that should be considered before starting any project is who are the users, where are they and what are we giving them. answering these questions help identify the correct stack.

You can write performant react. So again I think the issue is people not considering performance as a first class citizen and instead it’s become a “nice to have” and here is where users with poor connections or less powerful devices suffer most.


Point 5 is the main reason I've not tried react. I learnt angular, until i realised it was a Google project. I do use vue.js despite its Google roots, because it's not a Google product.

I'm not condemning anyone who does use react or angular, but it doesn't sit well with me.


That's too bad, React is bloated but it inspired Preact, which is awesome.

Some of the patterns Facebook introduced to the scene that Preact/React implements are solid, so are the state patterns that Flux/Redux introduced.

Don't you think that we miss out somewhat if we base our choices on branding rather than content/actual-code?


I realise there is no ethical consumption under capitalism, but what Facebook and Google do and have the power to do puts them in another league.

It has nothing to do with brands, and I don't condemn anyone who choses differently to me.

Using their libraries is implicit support for the companies. I can work adequately without them.

I’m not sure i can see how that support works, how it could be negative, or how it ties into capitalism for that matter.

The whole open source ecosystem seems very apart from the idea of using currency for trade, or trade even being a thing for that matter. :)

What do you think?

I think that using software created by a company is showing support for that company. If there's no other choice, then fine, but there is so much choice in OSS that choosing to align myself with a company I find abhorrent is illogical.


Very well said! We built and shipped a very very large React website. It takes 7 sec to print the front page in Google Lighthouse.
Well our team just didn't stop at just showing some html and css via js but we even parsed 10k-50k lines of markdown documentation on the browser itself, which wasn't so bad initial when the lines were just 500 but as the project grew so the documentation. One major issue I find is incapability of React developers to looks for other potential contenders or to say, including myself is the misconception of thinking that programming in JavaScript is the correct programing paradigm even when we have to drive our css and html from our javascript. I am not going to use React for everything, even for static websites I have decided not to use Gatsby when I can just drive most of my static content via proper file structuring and small javascript scripts.

I think React is good for dashboard(interactive) and for better code maintenance (component architecture) but that's just what developer cares for not the end user. Please correct me if I'm wrong, thanks for reading.


I'd like to understand why people enjoy using it.

If it's good enough for FB it must be good for us.
It's a perceived productivity cult.
It's an attempt to minimize cost of implementation at the expense of everything else.
There is the expectation that components are more "reusable" (how does this work out in practice?).
The component mindset is grounded in familiar OO while the view = fn(state) approach is easier to reason about at design time - imposing the runtime cost of loading and running the VDOM.

"Components are objects"

Interestingly the Elm community came to the conclusion that "components don't work" (in Elm). Packaging pieces of the Model, Update, and View into a "component" abstraction doesn't create a unit that composes particularly well. The constituent parts of the Model, Update, and View compose in very different ways. It's the types that flow through them that connect everything.

Elm Europe 2017 - Richard Feldman - Scaling Elm Apps

Some of the emerging React Patterns remind me of the old meme that many OO patterns exist to get around the shortcomings of OO (a bit of a slanderous claim - but there are some "I need a pattern for that?" moments).

Some older posts (i.e. this is not news, people have been warned):
React + Performance = ? (2015)
The DOM Is NOT Slow, Your Abstraction Is (2015)

At this point the horse has left the barn. There are lots of codebases that are heavily invested in the React ecosystem and developers to help them grow are in ready supply. So what's left? Pointing out that there are better performing alternatives (like Preact/Unistore) for many projects?

The other issue is that "current UI frameworks on the web are the centre of your universe".

"If it's good enough for FB it must be good for us."

Do people actually think this way? That scares me a bit.

Pointing out that there are better performing alternatives (like Preact/Unistore) for many projects?

I've been a fan of Preact. Thanks for showing me Unistore.


Do people actually think this way?

The fact that it's backed and used by a mega-corp gives people a sense of stability and sustainability.

What doesn't enter into their thinking is that FB has the resources to deliver native applications to any platform they wish - FB has no problem with "walled gardens" so their web solution doesn't have to have the full reach of the "entire web" - just enough for first contact and to get somebody to download a native app for a "better experience" (and more access to their data).

Another thing I didn't mention is the lure of "reuse" via React native. Historically speaking cross-platform solutions don't serve any particular platform that well - it's always a compromise. In this case it's the VDOM that makes it possible to reuse React components on another rendering platform. There's already a varied collection of web platforms so trying to additionally accomodate other platforms which are even more different can only be severely limiting.

I've been a fan of Preact.

You may also enjoy this article: radEventListener: a Tale of Client-side Framework Performance

Thanks for showing me Unistore.

Jason Miller also created a JSX alternative HTM.


These are all fair points. Web development is vastly different than five years ago when React was becoming wildly popular. Some people may take this personally because of how invested they are in the React ecosystem, but that doesn't mean the most popular JavaScript library doesn't deserve this kind of criticism.

I would like to extrapolate on #4 because this seems to be encoded in the DNA of Facebook. "Move fast and break things" is their famous motto. Facebook has almost singlehandedly destroyed any notion of egalitarianism on the internet. The internet was originally created in order to share things and I'm sure that didn't necessarily mean everything about our lives. The internet I grew up with in the 90s was a vastly different space. Anyone could learn html. The barrier to entry has become too great. jQuery simplified things while React made them way more complicated. The level of tooling needing to bootstrap a React application is way too much. The methods used to code React applications have changed dramatically over time. It's fitting the library distributed by Facebook is as disruptive to the web development community as the company is to everyone on Earth.

Is the disruption React caused really a good thing? Perhaps. What web engineers should be excited about in my opinion are other libraries that are a response, web standards that have evolved over time that essentially replace or outperform React.

I think it's fantastic how you framed #2. Web engineers should have more empathy for the end user.

React is just a tool, like any other. If you prefer React then go for it. Every JavaScript framework or library has advantages, teams using any tool find ways to create technical debt.

It's fitting the library distributed by Facebook is as disruptive to the web development community as the company is to everyone on Earth.




React is gross. But it's kinda cool that they made it - so that people could learn from it and borg it's best parts into things like Ember bright side?. But we don't use it - and don't plan on using it. Anyone who (doesn't teach React for a living) and uses it for a few years comes to the same conclusions. It's a learning process. React is just wrong.

It really sucks that all of new developers are already addicted to Netlify and Gatsby. They can't do anything without it. I tutor people all the time just out of a "React bootcamp" who can't write the HTML and CSS for a simple portfolio site. They learned JSX and non of the things that really matter about markup, styles, functionality, or MVC concepts etc. And now even WordPress's stupid Gutenberg blocks are written with React (and yeah - inaccessible ) even causing some notable people to quit their jobs at WP because it's so bad.

SPA's (apps) have their purposes. Google Docs isn't just a "webpage" - and so, you gotta know when to use what stuff... for what reason... but - not sure when React would ever be that choice.


What's your opinion on Netlify?


It's fine. It does what it does well. But - it's a little bit of a black box. The whole JAMstack - is a marketing idea. It's nothing new. But - the problems we're seeing is that people go to boot camps / or learn in tutorials --- and then come to us thinking they are a 'pro' dev... and they can't write basic HTML. The idea of having pre-rendered pages and they hydrating parts of those pages with dynamic data is great! Great idea! So, why do we need to create a system all tangled up in command-line tools and React? People think that every website can be like Dev.to - and that it can just all be created with markup - and that I'll only be used by developers - and that's not true. I think that Netlify is doing some cool stuff. They've chosen the right spokespeople... but the way people are using it - seems to be stunting them - instead of helping them.


The definition of engineering isn't "solving problems with the tool you like". 🤷‍♂️


How about we just let people use the tools they like?

That's "technology driven development" rather than "user driven development", which inherently reduces the effectiveness of any project that is intended for use by anyone other than the author.

The author raises a point that those of us with fancy smartphones easily forget: A lot of people are still using devices that can only practically handle "Web 2.0". By deciding which tool to use based soley on what we like, we might be inadvertantly worsening inequality of access to information. By not simply letting people use what they like without being bothered, the author stands up for the disadvantaged. Bothering a select few who don't want to be bothered, but for the greater good, is a heroic thing to do.


OK, I have some anecdotal experiences as well.

  1. SPA may be slow for minority of users with slow bandwidths, but a complex WordPress site can be slow for MAJORITY of users with decently fast connections -- mainly because of lack of preloading.
  2. Although I don't know much SSR technologies, I would say that developer's experience matters. Breaking into fully contained components help with development.
    • I know there are templating engine, but I don't know how well it integrates with JavaScript (bundler)...
  3. I personally think that websites are usually either content-focused or functionality-focused.
    • Faster-than-whole-page-loading functionality-focused must be a valid use case for SPA's.
    • About content-focused, Static-site generators (like Jekyll, Hugo) might be faster than SSR (and security?), but I am not so sure. But what about when you need some minor interactivity? That's when JavaScript, and perhaps esbuild is needed.

I agree. Take a website such as github for an example, it is fetching html as you use it and it is very fluent and complex (much like an SPA) without all the overload a big JS bundle brings.

This is why I'm interested on initiatives such as LiveWire, that try to bring the benefits of not having to reload a page without all the extra stuff that makes development with tech such as react a big pain.


Can you explain more about what Github is doing? Are they using a particular tech stack? I’m curious if what alternatives there are for developing web applications.

I’ve used both Vue and React and sometimes I prefer templating and other times I prefer JSX depending on the complexity of the component.

I’m always curious about solutions that follow the “ Ship HTML, not too much, mostly plain.” mentality.


At its core, GitHub is a Ruby on Rails monolith. I can't speak to what they use for frontend interactivity, but the main application is a traditional rendered-on-server Rails app.


I've really gotten to that point. I've stopped using react for most of my projects, tried doing things the good old way, and damn - it's good. Although, I know there might be some issues as things get bigger, but I'll cross that bridge when I get there. I won't let the fear of some unknown scalability issue push me to make the wrong choice.

Things can be a lot simpler than they are now, if you want an SPA, do it the old way and use Turbolinks. I've never felt more saner since I stopped using react.


So, you would just replace one JS library (React) with another (Turbolinks)? On top of that, Turbolinks wasn't updated in ~2 years unfortunately.

I know React isn't supposed to be used anywhere and everywhere because that doesn't make sense, but people offering alternatives don't always have the best arguments really.


Turbolinks is just to give it a SPA feel, I'm not building the whole site with turbolinks. I don't write turbolinks, there's a difference.


I see that as an Analysis issue from the beginning.

I've stopped using react for most of my projects, tried doing things the good old way, and damn - it's good.

This means you didn't analyzed properly what you are about to build so you chosen react for everything and now you are pleased and how well the things that shouldn't be done with react work without react.

For giving an example you can use PHP for coding a simple form handler for a landing page or you can use java.
If you chose java for code 100 landing pages and then you switch to PHP you will be pleased (and your cloud server's bills too) because java was not the right technology for that job from the beginning.


That has no bearing on what I'm talking about


Very easy, why people like to use it:

  • It is designed by people with absolutely no knowledge for frontend
  • It is used by people who has zero-to-non knowledge for frontend
  • It is designed by people with absolutely no affinity for frontend, design, colours or in general nice things
  • It is used by people who has zero-to-non affinity for frontend, design, colours...
  • Designed by people who think factory pattern is the best way to automatize everything
  • Used by people who has zero chance to build something nice because of time budget or lack of management decision
  • Designed and used by people who absolutely don't have to work with SEO nor optimizing the code/site/snippet/component.
  • Once you learn it, quite fast to setup/use/build small things in it.
  • Don't have to think about how and what (DOM structure, elements, functions...)

This is my personal opinion. I do have couple of years of experience in frontend/UI/UX. And have more than a dozen years of experience in development.


Yep. It's about memorizing how a JS object looks - and not really about design or thinking.


I only learn and using some tiny parts of React, such as how to make web component, looping and props, for creating a basic templating based on the given prototype UI design, just to pleasing my frontend dev team.

I personally not a fan of React language design. It's ugly to me.


Do you mean JSX?

modern react can be done almost purely functional, and libraries like htm (github.com/developit/htm) bridge the gap of sanity so we do not have to use tools like JSX anymore. :)


Yeah, JSX is one of the main reasons. And also looping is not look pretty to me. Thanks for the module that you recommended. I try not to add additional modules to the build. I still can live with the stock feature from React. I just give myself a chance to complaining about my experience in React. Developer Experience is also important to me. I also understand React is made by the big company and it is famous on the internet. But, I am more a practical person. If a tool is good for me, then it's good. Very controversial, yeah?