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

First of all, let us be honest here. You used React to get more clicks. This "article" could have been titled "Why you should stop using Angular/Vue/Svelte/Aurelia/Ember" or any other JS framework.

1 It's slow

You list the source for that image, but don't actually link to the source. How can I know where is this image actually coming from? Wasn't "web made for this"? Linking to other pages and there you don't do that basic thing?

EDIT: Forgot to add that React isn't really slow, but apps created with it could be. That could be said for any framework/library, if you build a slow app it will be slow no matter what you use.

2 It's expensive

What about other assets? Images, videos, CSS? Those aren't expensive, right? Average website will have you download way more KB/MB in other assets compared to JavaScript. It's just that JavaScript will also use some more CPU time because it has to be parsed, but this point isn't about performance it's about bandwidth cost and in that case 1MB of JS === 1MB image

3 It's inaccessible

I kinda agree with this point, but for those same users an image heavy site is also kinda inaccessible, so it's not just JavaScript, it's whole page "weight" combined, but JS does have that extra parsing step compared to images for example.

4 React goes against what the web was made for

Web isn't what is used to be. Web isn't just static HTML pages that are connected with links anymore. You do realize that web has evolved far beyond its initial idea?

5 It's made by...those people

What search engine do you use? Google? Bing? Yeah, that is made by "those people".
What browser do you use? Chrome? Yeah, that is made by "those people".
What car do you drive? XYZ? Yeah, that is made by "those people"
This whole point is pretty stupid in the end.

Tell my why you like React in the comments! I'd like to understand why people enjoy using it.

Because it redefined how we write and think about web apps. Because it has a nice API and it's fast. It encourages consistency with components. Developer experience is also top notch and when developers enjoy working with tools, we tend to write better apps because we just enjoy the process more. React just brought a lot to the table since it was first released and shifted the mindset on how we approach frontend development.

To be honest, this whole article feels seriously low effort because you didn't include a single "solution" to all these "problems". You just list some random stuff and that's it, there is really no real value in anything you say here.

I agree that modern web apps can be bloated, but apps are doing more and more in the browser today than ever before and it's not like apps made previously with jQuery or Backbone or AngularJS weren't big, it's just that they maybe didn't do this much work as we do now in the browser.

Even if you go with using vanilla JS only, you will eventually make some kind of "framework" yourself because it won't be easy to handle a decently big app with vanilla JS. I mean, if you don't write some type of internal framework and you just start all over again on each project, what are you even doing?



(other claims already addressed in article + comments)


Huh, kinda disappointed with your answer. I expected more...

Images and CSS are not as expensive for the end user as JavaScript. External links in the article explain this if you did not know already.
You need to go back to basics. Is that the attention you wanted from me 😛

You are talking about cost from a bandwidth (download) perspective and in that case 1KB of images is the same as 1KB of JavaScript. I know JavaScript has additional cost because of parsing, but that is performance cost, not bandwidth.

Are you serious? You don't know a single site that ships few images that amount to few hundred KB? Just open any news site, open an average blog etc.

And regarding that 139KB (React 0.14.5 + React DOM) you mention from that URL, make it more like 97.5K (React 16.2.0 + React DOM) because who the hell ships React 0.14.5 these days? And those are not even gzipped sizes, but minified js only without gzip. That list you sent shows gzipped size of 31.8K which is more realistic. I mean, you turn on gzip right?

You have got to be trolling at this point and I'm just dumb for falling for it.

EDIT: Nice job editing your comment above this one so this comment kinda doesn't really fit as an answer...

It's okay. You can stop using React whenever you feel like it.

ender minyard is definitely trolling. This very page with a tiny handful of images is shipping nearly 100 kb of image data, which is 3x more data than gzipped React + React DOM.

I'm very glad that you made an account to comment on my post. Welcome to dev.to 🤠

Thank you. It has been fun reading through your article and everyone's comments. I like when people have differing opinion. Keeps things interesting. :)


Whoa, solid dialog you got there!

I also like react, it is very easy to get started with even for junior devs. But one reason that I don’t like react is that nowadays people don’t use it the way it was meant to be used. It’s small and loaded with features, but people are not satisfied with that. I see more and more people try to turn react into something it’s not. People hear about fancy buzz words and immediately jump on the bandwagon of things like dependency injection, service architecture, etc. when all they end up with is messy code and nothing else. I think it is a futile effort to turn React into something close to angular (being a backend dev this is closest analogy I can make), and I don’t remember how many times my suggestion “if you like the features so much why not use angular, you won’t come close to the quality with which things like these need to be implemented and still meet the deadlines” has been put down with the reason that angular is very big and slightly less popular than react (yes, that is an actual reason I had to hear)

I haven’t got anything against anything, but I cringe a lot when people use things not the intended way, apologies for the poor analogy but you can’t hammer a nail using a sword, this doesn’t mean that a sword is useless.


What do you mean by "low effort"? Also I invite everybody to use my nojs static site generator who goes with the original ideas of the web: mkws.sh.


Person writing this "article" didn't even invest any effort to properly elaborate each point and potentially offer a solution for any of them.

It looks like a low effort clickbait article that just used some "cons" listed from somewhere else and doesn't really offer any value and it's just a waste of time to read it to be honest.

I guess you aren't really even interested in me answering this, but primarily wanted to promote this site you have. One suggestion is to work on the design of the site and limit the width of content because on fullHD monitor it's hard to read and is hard to use overall.

It was both! Why is 'investing effort" a good thing? Isn't honesty effortless?

I don't have access to a fullHD monitor, but thanks for the suggestions.

Hmm I don't really want to get philosophical here, but if you want to attack something like this online you should at least invest some effort into writing a proper article, not something like this we are discussing here.


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.

It depends on many factors but you generalize a problem for everyone. We've different analytic tools so we know our customers devices, resolutions and so. Why I must take care about 2G connection guys when the slowest connection we get is with 3G or 20Mb ADSL and on a <5%?
You need to know your market before choosing technology, isn't it?

If my customers are using high speed internet connections I MUST NOT care about those who are with 2G, because you put extra-efforts and engineering for it to run as nice as possible, even building a different version (check the cost of that in time and money) instead on giving the best experience to YOUR customers.

I see all that post and most comments some kinda romantic programming where things are idealized like "welcome all 2G users, welcome 56Kb modem users, let's push accessibility" but on the real world companies do what their customers need and no more for obvious reasons. And if you are a programmer you either will work on a company or being the boss of one so you need to take this in mind (the third option is being so bad you've no job).

If you already thank on that, you probably are on a country with very bad internet speeds then ok, change the title and say "Stop using react if your business market is on [country_name]" and will be zero misunderstanding.

This sounds like you really believed that most of decisions about using technology X are preceded by careful market evaluation, not just jumping on a hip technology bandwagon. I feel that software development is plagued by this kind of thinking:

  • Most of my users are on a fast internet, so I don't care about the bundle size
  • Most of my users are not blind, so I don't care about accessibility
  • Most of my users have names longer than three characters so it's okay if I put the validation like that in my registration form

The thing is, if you think about it from day one, you probably won't spend huge resources on adjusting the project for people who are not a majority of your market. But if you did not think about it, sure, you have to spend time on coming up in post-factum justifications like that ;)

Of course, there are some cases when using SPA is fully justified (see my previous comments) - but let's be honest, in most cases it's not.

I must be biased about business side thinking but that's what you're taught at college, doing before thinking makes you redo several times so it's inefficient 🤷

When you open up a new project to a market there must be a previous analisis, not doing that and complain about the results is something dumb, don't you think?

SPAs fit well on tones of applications while does not fit on tones of others, that's right, the same for microservices architecture vs services or vs monolithic.

That's just the point, there's a big nonsense on recommend to stop using something "as is", your needs will depend on what do you need to achieve (requirements), knowledge about your market, seek the pros and cons for each option and decide which one fits better for your product, that's all

Well put. Some people keep saying "stop using Laravel" but if you don't have crazy concurrent requests, Laravel can solve almost all of the problems you would typically need & can get a lot done using this framework in a limited amount of time. So the context is important. 2G,3G,4G these are relative to the business of the website is catering. Remember we had to support that shitty IE ? Now we don't because the market cap is insignificant for the older versions of IE. There's always a tradeoff according to your customer base.


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.


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


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.


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?


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.


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/


React is not a framework. It's merely a library to abstract away the messy parts of building UIs. There's very little to actually learn as it's just JS and JSX (which is nothing to learn if you already know HTML and have worked with templates).

React is not a framework. It's merely a library to abstract away the messy parts of building UIs.


stop Trolling ♥️

The React core team would disagree with that. It really depends on definition.

That being said, perhaps my wording was too strong. The point I was trying to make was that React provides relatively little outside of the DOM abstraction and has little in the way of magic syntax, etc. It's extreme fast to learn for someone with JS experience.

It isn't until you start layering on other libraries like Redux that things get complicated, but there is absolutely no requirement to do that.


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 really don't know about you and your age but those JavaScript frameworks that you feel trendy and something that must disappear sooner than later will be with us for long time. I don't know if you remember when companies built web apps using frames with javascripts to interact between a frame and another to reach only one of the capabilities you got nowadays with those javascript frameworks.

Translating that, there was a need for not reloading the entire web view on each user interaction so we had that back those days. Then frames were deprecated (meaning obsolete) for multiple reasons, the most important one being security (frame injection attacks).

The reason to be of this need was and is, of course, the user experience and performance (otherwise your entire view needs to be re-calculated by the dispatcher->controllers each time depending on user roles and permissions, requested resources, account type and so).

Then you got those javascript fameworks that not only lets you accomplish that on a monolith application but on a distributed one too as are built to work with API data. The "if something works for N then also works for 1" concept, instead on making something to work with 1 and repeat the entire process for N.

Those frameworks are not a trend because it's funny or something similar, Python is neither a trend (for adding a different trendy topic), there are implicit reasons behind each.

If you take business level applications (only to ignore what students, newbies, seniors projects at home and so) you'll see the usage of each technology and you can dig deep if you want to see where each is used to discern the benefits.

Do you think the companies will spend millions a year for developing something on a "trendy" framework or language? They analyzed all the points and at the end they discern what is better economically to the company. Translating economically to an IT department means lower development time, high scalability (to avoid tech debt as possible), better error detection and handling and lower development cycles to deploy more often (to increase the business capabilities of react to market changes) and so on


One reason why you do want to use React: to pay your bills .... there are tons of React jobs, it's freaking dominant in the job market :-)


That's the only reason I use it. React is horrible - honestly.


Horrible? That goes a bit far my friend, it sounds like you're trolling ... let's try to put the points you mentioned in perspective:

  • if React is really that bad, is Vue any better then, or Svelte, or any other SPA framework?

  • is the problem just with "SPA" for that matter? SPA are 'apps' really, so you say that apps aren't any good - how come people are downloading them by the millions?

  • if slow load time (time to first paint, whatever) is the problem, then what about SSR (Next.js) or SSG (Gatsby)? which fixes most of the issues I'd say

  • your argument "it's made by Facebook" must be a joke ... so your opinion about e.g. Vue or Svelte is more favorable then? (not made by a big company)

Vue, Svelte etc don't have to better for me to acknowledge that react is bad. I never said anything about SPAs, you're engaging in "WHATABOUTISM". And all the things you mentioned, SSR etc are clear examples to how horrible it is. It got to the point were we're reinventing the wheel, and doing it badly.

And It seems like you're replying to the wrong person.

Well I was only trying to clarify what point exactly you're trying to make, but never mind, no offense ...


What parts of it do you consider horrible? I'm genuinely interested.

I know I don't prefer some parts and some other frameworks might have better solutions in some areas, but I wouldn't really call any part of React horrible, let alone say that React as a whole is horrible.

I agree ...

If your React app is slow then you're probably doing it wrong (unnecessary re-renders etc).

And the bundle size of a React app doesn't have to be huge (use code splitting or SSR, and Preact is also an option) ... Angular is heavier I think, I don't have that much trust in those numbers, especially without sources or references.

And if React is horrible, is Vue or Svelte then also horrible? Or, if they aren't horrible, then why is only React horrible? More questions than answers ... :-)

React apps are slow because of the time complexity of VDOM. If you use for instance CanJS which has change-propagation based rendering this is substantially faster than React.

Funny because from the very beginning we always heard "React is fast (and small), VDOM is fast, and a good thing", and so on.

So how come it's now suddenly "slow" ? The answer is of course "relatively" speaking :-)

For 99% of ordinary use cases "React is slow" is a purely academic statement, we're talking about milliseconds. I imagine that only in some rare edge cases (lists with thousands of items?) would it be 'slow'.

I think it's mainly an academic issue, and of course you need to weigh that against the advantages of React (and against the other disadvantages, haha).

VDOM is only fast when compared to alternatives that are incapable of efficient DOM patching. When you compare the performance of VDOM to that of change-propagation based rendering, then suddenly VDOM falls flat on it's face. The time complexity difference between these two approaches is actually quite staggering; these are not minor millisecond differences, these are staggering performance differences. Say for instance you refresh data after an SSR call and want to reconcile any changes from the cached data that was printed to the page vs the live API data; in observable land only attributes that have actually changed result in change events, and it can be known by the data changes what parts of the DOM tree need to be re-rendered and how. If you shuffle a list and replace it when new data, that just shuffles around DOM nodes without any further overhead even if the source data is entirely new. The DOM changes are propagated from the data changes instead of deriving this from a VDOM diff and patching. It is vastly more performant, and much easier to reason about.

As far as the rest of React goes, the only thing that it really has going for it is the cult following it has. This whole notion that it makes apps simpler or enables more sophisticated SPA's is utter bullshit. Going all in on observables and using a proper observable implementation such as what CanJS has actually results in far simple applications that are much easier to reason about, that perform much better, that are much more succinct and above all else it makes it much easier to compose complex behavior that scales well.

I believe it's the case that you simply haven't seen how incredible well written observable-driven SPA's can be. If you had, you would know how bad React's shit stank. The juxtaposition is incredibly stark even if you entirely dismiss any performance factor. I say this all as someone who's built a prolific amount both in CanJS and in React and by combining the two (MobX is trash observables!). I would very much so love for React to be a better framework, but alas not being observable driven is an insurmountable design flaw that can never be reconciled. It is a cult choice that fundamentally lacks technical merit

Well maybe it's a matter of the state of the art having evolved and progressed so that VDOM, which was once our hero, is no longer the holy grail. But, my hunch is that for 95% of the apps and use cases the performance difference is probably negligible, i.e. it doesn't matter much.

If (for the majority of use cases) React was that awful and CanJS that superior, then how come that not everyone recognizes this apparently obvious fact? I believe you when you say that observables are a technically better solution, but probably not that much better in the majority of cases. If it's that obvious, and the difference is that huge, then for sure people would know about it by now?

My own criticism of React is quite different, namely that it's putting a lot of the burden of doing it "right" on the developer, hence the endless avalanche of complicated "patterns" - first HOCs and render props, now "hooks", and so on and so on - all of which must be mastered and applied correctly in order to build well-structured and performant React apps. If you do it wrong then you get performance problems (i.e. unnecessary re-renders) - so unlike for instance Vue, which has a lot more 'intelligence' built in, React is putting a lot of that burden on the developer.

Other example: Vue has things like routing and state management "built in" making it much more complete 'out of the box' - React lets devs grapple endlessly with iteration upon iteration of routing solutions and an infinite number of "alternatives" ... I don't want to mess around ad nauseam with alternative routing and state management libs, I just want to build an app!

React has become something of dark voodoo science and makes you jump through hoops for the sake of it, instead of it just being a tool that makes your life easier by keeping simple things easy and providing you with the tools you need (like Vue or Svelte).

But I digress ... the big payoff of mastering React is that it's used in a gazillion projects, has a huge community and ecosystem, and totally dominates the job market. Just that might be more than enough of a reason to go with it.

P.S. I could be wrong but I think that VueJS is also observable-based (although it uses VDOM as well). It's more intelligent about re-rendering, while React, as said, forces the developer to be aware of unnecessary re-renders. By the way, do you have an opinion about Svelte?


I usually shit off on the posts like "stop using xxx" but this time I decided to teach you why you are wrong. And what I'm about to tell you is applicable to angular and other frameworks too.

You are wrong because you may have learned how to code a react App but you don't know where to use it.
It's not meant to be the base of a public web page of for SEO landing pages. It's about scalability and easy-to-build front-end views consuming back-end APIs on a services or microservices architecture.

I also use React, and Angular, let's put the use cases on the table:

First the differences:
Angular is a full-fledged framework, while React is a library. React. js uses virtual DOM and one-way data binding while Angular operates on real DOM & two-way data binding. There's also a difference in bundle size (React's smaller) and speed (React works a bit faster).

We use Angular to provide a stand-alone App for a given department to manage their complex stuff.

We use React to provide a webApp to our customers. They are customers right now, no need to SEO but you want good speed due to user experience. What we did? Use Preact and optimize it as possible. Custom css framework, well optimized JS. Now we get a fast app that we didn't get using entire react or importing all unneeded react packages.

For example if you gonna code a form, why do you want the entire react form? you can pick another lighter or build your own if you're going for performance. If you don't need ALL features on a lib, don't load it to your project, that simple way you get better performance.

Of course you need SSR (Server Side Rendering) if you want to publish your APP public, for performance and SEO (also use a valid cache service and policy) as you need on a non-js webapp.

Also we have a third webapp which is made by html, scss and few js possible to obtain the fastest possible experience. Here's where SEO applies and where potential customers land.

Why you should use React?

Creating an App to your customers could be tricky and giving this "reactive" content to your customers improves the usability A LOT.
Contrary what you said, users (even on a 2G connection) will download a bunch of about, let's say 400Kb at the beggining, then they press a button and they doesn't need to load the entire page again, only a part of the content is replaced so this operation could take like 20kb. Then 15kb and then 25kb.

Without react you'll be reloading the entire page (lets say 200kb) 4 times.

400 + 20 + 15 + 25 = 500.

200 x 4 = 800.

well, appart from that if javascript is cached, those 2G people can use your react app when on wifi, and getting a faster experience when not later.

Of course there's ways fot all things to do to increase performance or another points like usability, accessibility and so.

If you want to use "plain html" (i mean no js) you'll need a back end that interacts with other APIs or that is a monolith app along your html (which could be fine depending on what you want to achieve).

There's no reason for "stop using framework/lib/methodology" unless there's something that covers the needs better.

If you learn something and you think it's shit, but there's millions of programmers across the world that uses that, think twice and say to yourself "if programmers are using that I'll try to understand where it fits before learning to code it as is", we are not silly, no one will be using things that doesn't fit well for the job or that are worse on every aspect than other alternatives (apart from Apple users).

The reasons for using something can fit into one of this (add some if i left something):

  • Cost (development time -> money)
  • Cost (computational, long term server spend -> money)
  • Scalability
  • Efficiency
  • Team background
  • Future refactoring costs

React permits you to build Apps on nice timings, the js computation happens on user's machine instead on yours, it's scalable and if coded well it's enough efficient too. Also the refactoring cost will be low due to componentization.

Now explain me why I should not be using react.


You're so wrong,

Without react you'll be reloading the entire page (lets say 200kb) 4 times.

400 + 20 + 15 + 25 = 500.

200 x 4 = 800.

There's something called caching


Yup, and do you even know how cache works?

If you visit each view for the first time your browser will need to create that cache AFTER downloading it, so the numbers are right for the first time you visit that web app and also for each time you visit it after cache lifetime ends or cache flush, which actually it's needed after each deployment into production so, on a modern development cycle will be each few days as min.

Think on how many times your customers' browsers will need to download the entire view and then create a new cache.

You clearly don't understand how the browser works, React apps are also susceptible to browser clearing cache. It's even worse with React apps, cause you'd have to download the whole bundle all over again, compared to just getting the single page for traditional websites.

?? on a "traditional" website you need to download the current view and all related assets (including scripts, styles, and resources such images, fonts or videos). The point here would be the size of that data in one compared to another which, coding a "traditional" website using Twitter's Bootstrap for example puts you in need to download jquery, bootstrap.js, bootstrap.css apart from your resources.

Same happen when you import packages into your react App, can't see the difference here.

Anyway as I told on the comment above react is not meant to being used for a public web page, it's meant to code web apps. And apart from that, regarding at what you are talking about, you don't know about how react works. You'll get the app first, then you only ask for content so the first load will be slower but the rest of each user interactions will be faster (no matter if it's 1 or 100000).

Of course using a simple html + css + few possible js your app will perform better. That's because Js needs to be evaluated and executed while js and css does not. If you read my posts you'll see i'm a big defender of using plain CSS for coding things that are usually done with js (modal windows, accordions and so) but that's another point, we're talking about react and where it fits because according to the OP, it's nowhere.

Do you like react? well, use it. Don't you like it? Don't use it. It's possible you've no use cases for react to fit, it's ok. Only note you're trying to argue about caching, which is a thing that has nothing to do when choosing one technology or another. You'll cache things with a policy or another, you'll add server side cache or not, caching services such cloudflare or none regardless of the tech you used to build your web app.

There's a limit where things are better with a technology or another. Facebook performs better on the newer react based version than ever performed without it for example.

You're the one that brought up asset loading, and I pointed that out. I use react, I kind of like it. But I still think, for most part of it - it's ridiculous.

Going the no-framework way would always beat going the react way, without doing any crazy optimizations. You can't argue that.

On the performance side? Yes it should of course, no doubt on that.
On scalability? Let me check your architecture first.
On development time (and cost)? Sure a big Not.

You can't generalize a method as good for everything


Don't take this seriously.
The author states "multi-thread javascript" in their bio.


Low blow, attacking their credibillity, Enders arguments are bad but Enders still deserver respect.

We should encourage people to make these posts so they get a chance to get their bias challenged, so they can improve.

This is not StackOverflow, it's okay to be wrong. :)


Sorry, but I disagree on each of those points. Nobody attacked each other. The author's arguments are bad indeed, and it address an issue the wrong way.

We should not encourage people to make posts with false statements and biased arguments, simply because they need to be "challenged", that's what questions and SO are for (you can also make questions in DEV). If you're not sure about what you're going to post, ask for feedback first, then post whatever result came out from that research. Blindly stating things that you believe are right, without doing any research first, is not ok.

Once you start reading the click-baiting title "Stop Using React", you expect some bold argument about it, and all you can find are biased comments about bad experiences with the tech. It's not me who say that, read the rest of the comments.

Making a jab at someone’s credibility is almost never a solid argument.

In fact it only feeds the fire that prevents sane discussion in my experience.

This post has problems, but unempathetic comments like these only make things worse.

Or worse yet, they start witch hunts, where the only winner is the people who get to feel self righteous over being right.

It’s just plain wrong, nothing positive is gained from it.

Actually, it's you who are making my comment look like something mean. It's a simple "tl;dr" and a note about a wrong fact (one of the rest) the OP states, which proves my point.

Don't over react to small things, it's simply a waste. Read the OP responses as well, for moments you can argue he/she is not taking things seriously.

If you see no positive thing out from it, you can always ignore and keep scrolling down. Even if you believe it's against the code of conduct, please, report it, but stop the drama right here please.

What scares me most about all this, is you're ignoring the fact that the whole post is biased and uses the wrong arguments to the real problem. Readers become miss informed.

I think our wires are crossed, you are clearly not getting my message, I do not know how to help that right now.

Best wishes from here. :)


If you are doing anything in JavaScript that needs multi-threading, you are using the wrong language and I will question your choices.

Not necessarily, I think most image processing web apps use web workers. There are legitimate reasons for doing that.

That isn't multi-threaded javascript either! You're simulating it, but javascript is not and won't ever be multi-threaded.

Simulation is good enough for me 🤠


All v8 engines run multi threads for javascript. It is only the event loop that is single threaded. Any async call places the work onto background process. When it is done, it gets loaded back onto the event loop thread and executed. We are ALL multithreaded js developers if we are using any modern chromium engine or writing anything in node


"Do you think some users are more important than others?"

Yes. The Venn diagram of "users with 2G feature phones who need to worry about the cost of 100kb of data" and "users who will become paying customers of the business" does not overlap at all.


Thinking that minorities aren't important is actually bad for governance. Some minorities may be vocal or belligerent, resulting in lawsuits.

Actually, I think you should try to serve all three groups (with some moderation, of course)

  • Poor minorities
  • Majority
  • High payers, but again, minorities

Again, I think there is a fourth group, middle income, but maybe vocal sometimes, you have to think about them as well.

This is just my thought on country governance...


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


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.


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

For gods sake, if you write it like that, you would never be hired as a react developer in the first place.

React has no attribute based syntax with the exception of modified attribute names like className and onClick. I guess there’s key as well, but looping is never done in the attributes. It’s done like it would be done everywhere else in javascript, in a for loop, functional iteration, or using while. This enables backend js and front js to look similar.

It’s lovely


Most of the points are just plain incorrect. My react app was estimated 0MB and 0 USD cost by the tool you reffered. It loads within a second or two. It doesnt load "everything and then its ready" because webpack is configured to split it and load on demand. Its fast. All issues you mention are far less dependant on the framework you use, than on the code quality.


That's awesome! You're a great developer. You are definitely not an average developer, and these points are based off the decisions that average developers make when using React.


I may agree on that. But then just please remove that clickbait title and write a proper one. You're talking about framework's ability to make it hard for beginners/average developers to make mistakes? Yes, that's a nice "feature", it's worth something, but its very low on the list of features that make a good framework. Or, guessing from comments below, you're talking about SPA technology in general? In that case, thats even less important. Or do you expect technology waits for an average developer to catch up? Never. Those able to increase profit with it will use it, others will just slowly drop out. If most cannot use it for profit, technology will drop out. Its as simple as that.
I'm progamming since before internet. Used web before Google and Facebook existd. Have done websites with pure html, then PHP, ASP, even Perl. Then apps (VSBasic, ASP, PHP, React, Angular,...) backends with many relational and nonrelational databases, had my own serves, used AWS, did microservices architecture and tradiotional ones... Blah, blah. I can tell you, I would NEVER EVER, both as an user or as a developer, go back to "traditional" webapps. Click, wait, click, wait, click, wait. Its a horror compared to SPAs (apps! Not webs). Thers really no point in listing all the reasons here. Most comments below that are supporting the headline just clearly display the lack of knowledge on the subject. Maybe author is just an average developer? Why not write a post "how can I stop being average developer" and work on it? Instead of bashing technology millions are happily using. Isn't it a bit egoistic too?

Tell me how React improves the user experience for you.

(I would describe myself as an above-average developer, if that matters to you, at least in the realm of web performance.)

Also: clickbait is fun.

Have u used Gmail before it becomming SPA?

Ah, I see. I do think Gmail is one of the few examples of a web app that should actually be a SPA.

Aaa, so title should be "let's bash React and SPA because it allows average developers not knowing it enough, to use them badly AND for projects that are not ment for it"?
Huh, I don't think we'll get far

But ok, let's play that game ;) A personal example. Jsperf is "traditional". I decided to make SPA version. While there's much more to it that UX, lets focus only on UX. Https://jsbench.me
Do you see any UX benefits? Should it be SPA (based on UX only)?
Note: its not mobile friendly yet. Its meant for desktop. Works, but mobile UX is not a priority at the moment


I think everything mentioned in the article isn't about React, but about developer decisions.

React itself isn't necessarily slow, expensive, inaccessible, or goes against the web. It's the decisions the developers in charge of the project make that may make it one (or all) of these.

This goes for any SPA framework. It's simply a tool, that if used properly for a given context, can make for a great UX (and DX).

If a tool is improperly used, such as building an SPA for a website that could really just be a simple backend driven site, then it's obviously going to be overkill and an unnecessary overhead for both users and developers.

On the other hand, there are many SPA's that are built specifically as an application that use web technology that could not provide the same UX that a traditional site cannot.

Again, it's about picking the right tools for the job, which leans on the developers of the project. So the title, IMO, should be "Why you should stop blanket using React and stop to think about your projects needs before deciding on your tech stack"

This goes for any SPA framework.

This does not go for any SPA framework. See: Preact. It is much easier to ship a slow, unresponsive website with React than with Preact because of the sheer JS download time (just using Preact as an example).

React itself isn't necessarily slow, expensive, inaccessible, or goes against the web. It's the decisions the developers in charge of the project make that may make it one (or all) of these.

I disagree. React is, by default, all of those things in the hands of the average developer, and it takes an above-average developer to keep a React web app from being slow, expensive, inaccessible, or against the web. The average developer will develop a slow website with React that should have been a simple backend driven site.

So the title, IMO, should be "Why you should stop blanket using React and stop to think about your projects needs before deciding on your tech stack"

I think that's too long for a title. I like the concept though. I understand your idea that React's performance depends on the developer using it, I just think that React's performance defaults to slow.


Read again as

It's the decisions the developers in charge of the project make that may make it one (or all) of these.

This goes for any SPA framework. It's simply a tool

My point being, it's up to the developers to understand the tool and decide whether or not it suits the project. React may be slower than Preact or Vue or Svelete, etc. but it has a rich and well established ecosystem which a lot of companies value and will prefer. I'm not arguing for or against React, all I'm saying is there's a lot to deciding on what your tech stack should be.

The average developer will develop a slow website with React that should have been a simple backend driven site.

Which can certainly be true and reiterates my point that developers need to choose the right tools for the job.


I see your article as a nice attempt at stirring controversy but it's doing nothing more. Vague arguments like it's slow, made by "those" people do not represent a valid case for anyone making a business decision why they shouldn't use React. Opinions and lack of exposure is not a valid ground to dismiss a technology.


I don't disagree however an article like this is worthless for a number of reasons.

  • Facebook
  • No alternatives shown.

We are pros who like to know the better way.


The post links to Preact.


The future is pure Web Components.

Maybe but web components have a LONG way to go before being useful at scale

Sure. If I used web components in my web app today, you know how I’d use them? Inside react.

Componentization is one benefit of react, but it’s not even the main benefit, none of which are accessible to web components

But web components don't need react. They're closer to the metal. Shadow Dom is not a react only concept.

Sorry, I strongly disagree. 1) they aren’t closer to bare metal in any meaningful sense. They are a browser api. No speed improvement. No faster processing. Bare metal is not even remotely a part of this conversation. ALSO.... who says bare metal is better??? EC2 containers far out perform bare metal servers in terms of scalability, flexibility, cost, and security. If it were a relevant consideration, I might say being away from bare metal is a usually a good thing, unless you prefer your development to be manually intensive, costly, and long form. 2) web components will never replace react because react offers much much more than just componentization and reusable code. How are you going to handle state throughout your web components? By hand. How are you going to ensure the DOM is fresh and up to date with new that state? By hand. How are you going to integrate new es without a transpiler? Your going to add one to your custom build system that you built by hand. Or your going to use es6 browser safe javascript or es5.

Also react is a library. Let’s not forget that there are dozens of frameworks built ontop of react. That simply is not ever going to happen for a native web api. It just isn’t. Never has. Never will. What will happen is that JSX May lose popularity and get somewhat replaced by web components. Even so, react will have a place: to declaratively serve up those components in an organized way that allows the developer to quickly construct UIs with those components and accurately display data and sync data changes and updates by rerendering on changes.

Web components vs react is a false dichotomy. React is a nail gun and JSX and Web Components are nails.

Doesn't make sense to me.
Chrome V8 needs zero outside help either declaritively or imperatively.

There's nothing rect does better than V8 to my k kwledge.

Do we write front end apis in front of existing apis to make things faster? If we do then that's bad architecture. That's you argument here. React sits in front of V8.

The entire React, Angular and Vue phenomenon has hit their peak reason for adoption other than legacy continuation and familiarity. This is known as 'Golden Handcuffs' Being chained to yesterday's architecture. It's not all bad as Cobol has shown. But Cobol today has little space in Greenfield projects.

As new DOM And ECMA standards arrive, 3rd party magic outside of the web component architecture diminishes.

They will not be cutting edge, like Jquery due to one single tech spec like QuerySelectorAll.

You’re not just writing code that will be visited on v8. You’re writing for a dozen different browsers of varying compatibility with modern javascript and react’s ecosystem allows for many build chains right out of the box (cra, gatsby, next... they all handle webpack/Babel config that works perfectly 99% of the time). No such ecosystem exists or will ever exist for web components.

Yes we write apis on top of apis on top of apis on top of apis. That’s software

Btw- comparing react to v8 is apples to oranges. V8 is an engine. Saying react doesn’t do anything better than v8 makes no sense at all. V8 provides an api for our javascript to move machine code through the browser, basically. React is a tool to write that javascript that the engine will consume. React does a lot of things v8 doesn’t and v8 does a lot of things that react doesn’t. In fact, they don’t do anything that the other one does. In fact v8 is written in c++ and react is javascript.

We’re waaaaay out in left field here

Why put react in front of a browser API? That's just one more layer.

No speed improvement, No faster processing

Means that React takes no time to process anything, simply not true.

EC2 containers

Have nothing to do with this discussion. Bare metal means direct interface with ECMA standards and in my case, Google's V8 engine. I never mentioned what hardware or software that it runs on. I'm talking about the direct interface to V8. React does nothing for V8 that V8 doesn't already do.

Web components will never replace React

That's true, just like C++, C# and Java never replaced Cobol. All four supporting imperative and declarative styles. Each claimed they were better, faster etc. Cobol (just like everything else) is it's own domain, it's own legacy framework, it's too big to die. Same is true for React.

Let's not forget that there are dozens of frameworks built on top.

I never said anything regarding this point; however there's probably 100,000 times more just plain old Javascript libraries available now than React components. Just because they are there means nothing except for picking React or any other [just because the eco system appears rich and there's something there desired]. One of the things I've found is that many of the open source offerings are rife with bad architecture, terrible api discoverability and even have large NPM liabilities. None of that part is discovered until after the component is prototyped.

React will live forever, for sure. I'm not saying it will die, I'm only saying that Web Components are a direct interface to V8 which to me is better! Remember, simple things like the new QuerySelectorAll killed JQuery in one day. But do you know that JQuery is still the #1 Framework in 2020? It's just living on it's legacy, just like Cobol.

The ECMA standards are beginning to catch up to the 3rd party solutions. When they do those solutions are self sunsetting except for those locked into the "adopted" framework of 5 years ago.

Best of All

Web Components do not rely on NPM!

You’re not just writing code that will be visited on v8.

Not true for us, we are writing only for Chrome and Edge currently both are V8.

Saying react doesn’t do anything better than v8 makes no sense at all.

Let me try to understand this: We have a V8 engine, Fined tuned to the max, and but we know that there are better things React does, merely by using the V8 Api's differently in some fashion? I don't believe that, what I believe though is that React wanted and did create it's own opinionated way of doing things. It covered the V8 Api to it's adopters to implement it's architecture. One of them being Custom Elements ala React way.


One solution to all this, use Next JS


Actually, I think of solution as using either

  • Traditional headful CMS's
  • Static site generators like Jekyll or Hugo. No JavaScript necessary, but can be an addition. I am bent towards Hugo with ESBuild, though.

when I was reading the article, I was just thinking about nextjs.

it solve all the problem he listed.


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.


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


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.


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.


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...


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.


I wanted to make the point that hundreds of millions of people cannot use web apps built with React. Maybe everyone got stuck on point #4?

People don't like being told that something that they like is bad, this is very natural and normal for all of us. I don't think it's just that people are getting stuck on #4. Rather, you have presented some of your points in a way that doesn't explicitly tie them back into your message, and that offers distracting inaccuracies that people may cling to in a form of mental self-defense.

For example, your point #1 states unilaterally that React is slow, citing only your own experience with it. Consider this point in isolation, especially as it's the first one that people will read. React was, in fact, built to improve the speed of SPAs (among other goals), and is successful at this in many scenarios. The reality is that React can be (and often is) slower than alternatives, particularly when it is used for use-cases that it was not designed for. So, from somebody else's perspective, you have requested that they change their behavior, and presented only your experience and a false generalization as the reason that they should change their behavior, which may actually come across as selfish on your part. It probably would have been more effective to present indisputable measurements.

Also consider that "slow" in terms of loading is different than "slow" in terms of runtime performance. People may not get the point of the article due to talking past each other.

I did link to more objective descriptions of React's performance, but I can see that starting with personal experience would bother people. Also, I can see that I focused way more on personal experience and kind of just made objective stats a little side note that I didn't emphasize enough.

I guess when I say "slow," runtime vs. loading doesn't matter because I'm thinking about people whose phones can't get past the loading time. But I didn't always state that explicitly. I have noticed that people care a lot about that distinction, which...I should as well. Do you think it would be wrong to say that distinction only exists depending on how good your connection is?


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



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.


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?


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.


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. 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.



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.


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.


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.


I think you are totally wrong and everyone should use React! And don't stop to try develop WebApps that feels like Native Apps! This is the dream of almost all Web Developers and React made it come true! Millions of dollars are made and Startups are built thanks to this library you tell us stop using it. I think every Website should feel and look like an App in 2020 and we need to stop building Sites that feel like Word Documents, and React made exactly this possible, Web Devs take more and more jobs from the Native devs and this is I think one reason for this post. Use React it is amazing!


Here's a little tip for you regarding the spinner speed, get faster internet. 🤣