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. He...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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
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.
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?
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.
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?
timkadlec.com/remembers/2020-04-21...
(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.
You're right. We can say the same thing about Wordpress too. That's a blogging tool but instead people try to use it for things it was not built for (apps, e-commerce, full site building). So just like I'm taking a stand to stay away from Wordpress, I'm making a stand to not use nor recommend react for anything else in the future.
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:
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.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)
Why Progressive Web Applications Are Not Single Page Applications
FYI: Eleventy was inspired by Jekyll but uses JS instead of Ruby.
That approach isn't recommended:
Why You Should Avoid Vue.js DOM Templates
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).
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
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
*.vuefile, with Parcel. It will internally usevue-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
github.com/MichaelCurrin/badge-gen...
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.
love2dev.com/blog/pwa-spa/
This confuses me greatly.
Are you referring to
<template>element?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).
Hydration
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!
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
in reference to
2013: Progressive Enhancement: Zed’s Dead, Baby
Despite progressive enhancement repeatedly being declared dead, in 2016 Jake Archibald stated
This illustrates that PWAs got their name from progressive 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:
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.
... or not? To me, it looks like we're trying to build around JavaScript's shortcomings instead of focusing on the real problem: the inefficient runtime (and arguably the programming language as well). And then there's one "progressive" feature that almost no-one talks about: JavaScript's backwards compatibility. It's a clunky language, with so many user agents, so many code paths and so many different optimizations that have to be built-in in so many different runtimes...
I don't think the current expectations match the state, power and limitations of the tools currently used to build web applications. Arguing about the right way to do this or that is ... almost pointless because it's fruitless, unless something is done about the language and the runtimes that can't keep with the pace of innovation and at this point are only being added upon, continuously, making them heavier and slower.
Why should the platform dictate how much code I can ship? Why do I have to target sub-standard UI+UX just so my app can load in a small enough frigging time that it doesn't look like it's dead to my users? I shouldn't have to worry about this. The platform should take care of this for me. Stream my code... do something!
Sorry for ranting. I didn't mean to. Imagine I was ironic and sarcastic the entire time. :)
At the core of the problem is that React doesn't play to the strengths of the platforms on the web.
Something like Sapper/Svelte does - though there still is room for improvement.
There is no one platform and there never will be - that is simply the nature of the web.
Tools don’t solve the web’s problems, they ARE the problem (2015):
Front end and back end (2015)
Familiar approaches for the backend or desktop simply don't apply to a situation where you have no control over the capabilities of the client device and the quality of the connection to it.
Well, one of the things I wanted to say is that this is the issue with the web platform: it lacks proper standardization and leadership. OK, so it's a varied collection of web platforms... does it have to be!? Especially if they are all doing the same thing basically?
This article needs more traffic: Where Web UI Libraries are Heading
Not really. Web standards define how browsers ought to behave on any platform and for the past years Google and Mozilla have been driving the standards process forward (with anyone else who might be willing to donate their effort).
For the time being Mozilla's future role is in question but "survival of the Web" is in Google's best interest which is why they keep pushing Chromium/Chrome forward (and are snarky about Apple/Safari (especially iOS)).
Granted it's not from an act of selflessness but for the time being the side product of the browser as an "Ad projector and Analytics gather" still enables the open and wide reach of the web (e.g. IndieWeb) (it's been my observation that Google's browser people on average tend to be more pragmatic than the framework people).
The post jQuery era gave rise to opinionated frameworks which use a boatload of JavaScript to promote their own design time vision (standard?)
without too much regard for the (client) runtime consequences. That was OK in the days of fat core desktops (the framework is restricted to a single thread) with solid, wired connections but is a bit presumptive with small core smart devices over flaky data networks. JavaScript was largely designed to script the browser (Python's success is partially based on popular libraries being implemented in C/C++ - and those don't have to squeeze through the network connection all of the time). The browser is the runtime - not the framework. Work should always be offloaded to the browser whenever possible - it's written in C/C++/Rust and the browser can offload some (non-JS) work to other threads.
Only recently some frameworks started to align more with the way browsers work in order to get away with less JavaScript - i.e. ship exactly as much JavaScript needed to accomplish the task, no less, no more.
Using the web is about its reach. The reason it has that reach is because it makes minimal assumptions about connection quality and client capability (single thread performance, available memory, screen size (responsive/mobile first design), etc.). Making minimal assumptions means anticipating a range of capabilities. Unpredictable connection quality requires that the web is resilient - and it's that particular flavour of fault tolerance that defines the architecture of browsers and how the web works.
Many people see UI frameworks as being at the core of "web apps". Frankly I think that Service Worker is much more important. Right now they are relegated to cache managers. However they can play a much larger role in making a site more "app-like". For a more involved example see:
Also current frameworks are still single/fat core centric. The UI framework belongs on the main thread but in order to leverage today's multi (small) core devices (e.g. Android) web apps need to use Web Workers more for non-UI work so that the UI can stay responsive. Then there is at least a chance that the web app's load can be distributed over multiple cores (The Free Lunch is Over (2004)).
They aren't.
Just look at Rendering on the Web - i.e. the range of rendering options. There is a continuous spectrum of architectures between a static web site and a web app. Web development covers a wide range of solutions. The issue is that people are always gravitating towards their golden hammer. They stick to the tools they are familiar with often applying them where they are less than ideal.
Thank you for your very informative answer and for shedding light on a complex topic.
Maybe I should reformulate my opinion. It's not that there's no standards or body to control the evolution of the web... I guess that's not what I meant. I know there are standards and the W3C, etc.
It's just that there's no clear solution to everyone's vision of what the web should be and should be able to do, and the sad part is that the only way the problem can be fixed is, if the web can find the perfect solution in order to become this one and only universal platform everyone wants it to be.
Otherwise we will always continue to hear these complaints about the tools and technologies we use and how they suck, when in fact they are NOT the problem, but only solutions to the real problems!
Maybe the web needs re-architecting from the ground up?
I believe the main issue is with the way we write and run code on the web. For example, having just one programming language and one code runtime is a huge detriment to the web platform. Let's hope WASM and WASI can fix that. And CSS... can't we do better than that? CSS shouldn't be a separate language IMO.
That is one of the problems.
There are lots of opinions of what people want the web to be for their own personal benefit. At the same time there seems to be very little willingness to accept what the web actually is and to understand why it got to be that way.
Perfect with reference to what?
If anything the web is an exercise of "the best we can do with the constraints we are currently operating under". That's what made it successful in the past and that is why it is still around after 31 years (1989).
Universal doesn't imply one or even a unified platform. The web succeeded so far because it was willing to compromise in the face of constraints set by technology and physics.
Real solutions accomodate all existing constraints. Solutions that ignore real constraints create problems.
Let's say that it was possible to come up with "the perfect" alternative (which is unlikely) - how would it be adopted in the current climate?
The web browser was transitioned onto smart/mobile devices because most customers want access to the web. If Apple removed Safari from iOS today likely a lot of people would be upset - perhaps enough to switch to a platform with web support.
However a new architecture would have very little content initially to generate consumer demand and if there is no opportunity for platform holders to directly profit from it, it's in their interest to not support it.
The web established itself during a unique window of opportunity. Something like it would have a lot more difficulties today. If the web made itself irrelevant we'd likely be back to multiple disparate platforms and walled gardens. The problem is that with mobile the web has to operate in an environment that is even more unreliable and hostile than the one it established itself in. The influx of less expensive devices into the market means that the average device is becoming less performant - even as flagship devices are still becoming more performant.
The web could quickly become irrelevant if the majority of web sites (and apps) indulge in technologies that focus on serving flagship devices with fast and clean network connections while neglecting service/user experience for mid to low-spec devices with less than perfect connections. If the majority of users have to rely on native apps even for casual engagement the reach and therefore appeal of the web is lost. And having to go through the app store for an app download is already beyond "casual".
Also in the past there have been efforts to "improve the web":
HTML, CSS and JavaScript on the other hand are still around today.
I think this has more to do with the expectations that are grounded in the experience of developing applications for desktop, device native and the back end which aren't constrained in the same way that developing for the web is. I think this is similar to the mindset that is addressed in Convenience over Correctness (2008) - developers wanting to treat a remote procedure call no different than a local function call - it's an unrealistic expectation given that there is so much more that can go wrong with a remote procedure call.
Earlier you wanted standardization. Now that you don't like the standard, you want choice (i.e. variation which can lead to fragmentation)?
While WASM is an important development I think people are overestimating its impact - again because they hope that it will bring web development closer to "traditional software development" - but WASM doesn't change the constraints that the web has to operate under. The most likely languages for WASM development will be C/C++/Rust, i.e. systems languages because they only need a skimpy "runtime".
Anything higher level than that will require a significantly larger runtime for download - e.g. Blazor has the .NET CLR (or a variation thereof) albatross around its neck. And multi-language development could require multiple runtimes. I suppose each execution context (page, worker) would require its own copy of the runtime, further increasing memory requirements for a client device. I'm not saying that this won't have interesting niche applications but I don't see these type of solutions having the same kind of reach as lean HTML/CSS/JS solutions with less demanding runtime requirements.
Why not?
HTML initially included visual design. But in the end it was decided that HTML's job was to structure content - not layout and styling. Windowing systems use programmatic layout managers. For browsers it was decided to go with a declarative language instead.
Granted experience with imperative programming doesn't prepare you for the demands of CSS. It was never meant to make sense to programmers but it seems to make sense to designers (You'd be better at css if you knew how it worked (2019), Don’t QWOP Your Way Through CSS (2017)).
And CSS can be managed on its own terms (ITCSS, BEMIT, CUBE CSS), it just requires a different approach than what most programmers are accustomed to.
Interesting arguments. I'll have to sit on them for a while. Thanks.
Because that means JavaScript on the backend.
NodeJS is amazing why not.
NodeJS isn't actually all the great. It's certainly a step up from PHP/Ruby/Java/Python, but nowadays there are better options. Rust Lang is like a million times better
What makes Rust so much better?
Many reasons: the safety guarantees are absolutely astonishing and this not only gives you confidence in the correctness of your work, but also enables rapid iterating where you can use the compiler as a pair programmer (for example, revealing everything affected by a breaking change); from a performance / resource utilization perspective its actually capable of besting C/C++; the use of zero cost abstractions makes code very succinct and makes powerful behavior very accessible (for example, see rayon parallel iterators); the trait system allows for combining behaviors in a really succinct fashion; implementing generically over traits is extremely powerful; it’s superbly expressive; the build system and formatting just work; it can be used just about anywhere; it makes multithreading concurrent programming easy; it’s fun to work with; the language teaches you to be a better engineer; the abstractions make things vastly more readable and generally once you understand the language it’s fairly easy to read code and to know what’s going on; Rust doesn’t have spaghetti code; Rust is so freaking reliable that runtime issues are basically nonexistent; Rust has libraries like Diesel that make it impossible to do invalid SQL queries and that guide you towards optimal design pattens; GraphQL API development on Rust is way easier than on other languages due to the trait system (see async GraphQL); Rust enables APIs that cannot be implemented incorrectly by design; Rust enables system level programming to be accessible; Rust removes the need for garbage collection; Rust can already do 100% of JS web APIs; Rust can generate Node modules via WASM bindgen; Rust WASM doesn’t need to be interpreted and hence runs instantly in web env thus vastly reducing time to first render; Rust is enabling a new generation of decentralized technologies....
I’m not really sure there is an end to this list. Rust is the most significant leap forward in language design ever. It is truly mind blowing.
Does not necessarily mean "javascript on the backend". It means you'll have nodeJS serving your pages, but it could be as lightweight as just accessing your APIs pulling the data and serving them, in some cases not even at runtime.
Your more heavyweight backend, REST API, microservices, etc. could still be developed as separated services, with Rust or anything else you like. If you are already looking at something like Rust for performance you are probably already going towards that kind of architecture anyways
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.
I found this to be a great guide from @_developit , jasonformat.com/application-holotypes, when deciding on how to architect your application.
I'm curious to know if there's any other tool to make complex websites, other than these SPA frameworks and jquery
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 just started going through the Svelte tutorial at svelte.dev/tutorial and it is blowing my mind. Declarative and unbelievably responsive. Genius.
Fantastic, and I look at this this (from the Svelte site):
"You can build your entire app with Svelte, or you can add it incrementally to an existing codebase. You can also ship components as standalone packages that work anywhere, without the overhead of a dependency on a conventional framework"
Yea after reviewing Svelte I would say it looks like a really great library. They are actually doing change-propagation based rendering here similarly to how CanJS works, which as I contend is vastly better than VDOM from a time-complexity perspective.
Also, regarding Yew & Seed; those just stand out as being promising libraries that are propped up by the unique strengths of Rust, but I would say they still leave quite a bit wanting. I think it's worth taking a second here to highlight Mogwai; as far as I'm aware, there is no frontend project in existence with a better rendering model, and their approach is perhaps the only approach faster than change-propagation based rendering. It's like 15x faster than React, and by virtue of it being entirely in WASM there's no JS parsing overhead. I'm fairly confident in saying that there is no framework technically capable of faster time-to-render than that of Mogwai
Cool, but you have to understand the use cases for which this makes a substantial/perceivable difference. For a large class of apps you won't really notice any difference, your screen would render in 0.05 seconds rather than in 0.1 seconds, if I may put it that way.
I'm not saying that there's no point in technical progress (there is, absolutely) but for most React projects it would probably be a bad idea to say "we got this new and faster framework here, let's rewrite our app from scratch".
Even for greenfield projects you might still choose React rather than Svelte or Yew simply because of the large number of devs who know it, and the because of the vastly larger community and ecosystem (answers on Stackoverflow, huge number of ready-made solutions/components/tools etcetera).
It also depends on your team of course, how technically competent are they, do they know Rust or WASM, and so on.
The point I just want to make is, when choosing a tech stack for a project you're normally looking at much more than sheer technical superiority.
You’re completely understating the performance differences. It’s more like going from 3000ms-400ms to 300ms-25ms; that’s a massive difference, which will have a major impact on user interaction. Furthermore, the initial time to first render is substantially affected by the parsing time when loading JS, whereas WASM compiles as it’s downloading and is ready immediately. Finally, a WASM app can be server side rendered by an edge working, allowing for low latency edge computing that’s both economical and scalable. These aren’t minor performance differences.
In any case, I definitely agree with your sentiment on why React is successful; it’s an 800lb gorilla, it’s safe, there’s a lot of resources to google your way out of a rabbit hole, there’s a lot out there to guide those in need of guidance, and there’s a lot of devs by virtue of boot camps etc.
In any case, I think it’s still worth learning things like Rust WASM / Mogwai / Yew because if you actually do know how to use these things and can build apps end to end yourself it’s a way to take on major tech players. If you're going to compete with an major tech company, you sort of need to go big
I'll definitely keep it in mind ... BTW Rust is brilliant :-)
Right!? I know more than a dozen programming languages, but all of them left so much wanting; Rust is truly the only language that left me in awe of its' brilliance. Lately I've been porting all of my NodeJS work over to Rust and I foresee it as being the sole backend language that I write in going forward. It's super empowering all you can do it with it: so far I've used it for GraphQL API development, lamda functions (13mb peak RAM, <5ms response from cold start mindblown), Redis Native Module development, EOS smart contacts, Holochain DAPPs, extending Postgres, creating NodeJS modules via WASM-bindgen and I feel like I'm only really scratching the surface here. I'm not sure how well you know Redis, but doing redis native modules via github.com/RedisLabsModules/redism... is actually a complete game changer and is applicable for so many use cases. I've never been so excited by a language
Great to hear ... put more of that stuff up on your Github? github.com/Bajix
It's all closed source. I don't do open source projects on the side anymore; instead I build companies, solo-author apps, and patent new inventions. Right now my most pressing priority is stopping coronavirus, and everything else takes lesser priority. This project I've been financing & working on with my dad for the past 7 years and we're trying to get this onto the market ASAP: youtube.com/watch?v=MuHWW-25mBw
Cool, understood ... nice, you're an innovator inventing stuff, we need more of those :-)
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.
👍
Exactly my thoughts. Thanks for a great read.
@steve
After reading all of these comments, I liked the one you have described. Others are just trying to win over other's opinions
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
CRAand 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...
Without CRA, we have to handle webpack manually. Fortunately the webpack config which was created by CRA is still adequate for my project. However, learning webpack, will be needed eventually.
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:
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
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?
I completely agree, also that code example shown is something I never encountered in 15+ react projects I worked on. It is not just the way you could write code then show the worst example you could think of, it also goes down to how you compose code and separate logic, data and ui also coupled with understanding how components work and how deep down the rabbit hole you want to go!
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.
I found out that spaghetti code comes from either devs who are trying to learn/understand something new or from seasoned spaghetti dev who doesn't bother to stick to good practices and is often lazy to read the documentation/guides before actually using something.
That also determines if someone would like to work with you or not if you are that second kind of dev.
Mmm seasoned spaghetti dev, my favorite 🤤🍝
Garbage In, Garbage Out. Don't blame the tool.
As a contrast, I really love JSX. I love how we use javascript's 'map' to render list. I don't know, maybe it's just me.
Then use htm instead. :)
github.com/developit/htm
One thing I know... I don't want to maintain the templates that you wrote,
but you will find my typed JSX easy to maintain yourself
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 agree, you can implement conditional bundle loading for separate parts of the app, lazy load data or load in background, same as gatsby loads on link hover so you have lazy loading and fast response.
It sadly often ends up with 'just ship it' mentality from management because numbers are important, not users. If you work in bad company that is.
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):
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,
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.
dev.to/ender_minyard/comment/14nd4
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
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.
TL;DR
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. :)
You never learned about multi-threaded JavaScript?
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
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".
Do people actually think this way? That scares me a bit.
I've been a fan of Preact. Thanks for showing me Unistore.
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.
You may also enjoy this article: radEventListener: a Tale of Client-side Framework Performance
Jason Miller also created a JSX alternative HTM.
"The fact that it's backed and used by a mega-corp gives people a sense of stability and sustainability."
The fact that it's backed and used by a mega-CORRUPT-corp makes me discard it regardless of the stability and sustainability it may offer me. It's a matter of principles. I apply the same for the rest of the FB stuff. I love VR but I refuse to use their oculus glasses even though these are the best. Unfortunately whatsapp is the only thing I cannot get rid of because I would be left alone ...
Sorry telegram, I love you anyway ...
Very easy, why people like to use it:
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.
Yeah of course this is your opinion like saying the planet is flat isn't gonna make it look factually less round any day like the very first point of your argument.
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)
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...
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
Yeah!
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
# markdown- 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.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 don't disagree however an article like this is worthless for a number of reasons.
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
Care to elaborate?
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.
Means that React takes no time to process anything, simply not true.
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.
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.
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!
Not true for us, we are writing only for Chrome and Edge currently both are V8.
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.
I don’t think you have a very good understanding of how a browser works. You brought up “closer to metal” which is a term for servers that are not containerized or partitioned.
You are right about ecma standards sun setting some features of libraries and frameworks, which is what happened to ember with their ember object.
But that’s not comparable to react as react doesn’t provide features you’d ever want in a browser engine. State management and/or integration with state management. Build tool chains. DOM updating. These are all things that will never be a part of javascript as a language because they aren’t language problems. They are problems that happen when you start building complexity.
This conversation is over from my side. Good day!
I think this statement is ridiculous.
Browsers manage their own state perfectly, in particular DOM updating. As far a build tools there are many other options unrelated to React.
Ok.
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 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).
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.
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
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.
Which can certainly be true and reiterates my point that developers need to choose the right tools for the job.
Agreed!
The definition of engineering isn't "solving problems with the tool you 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.
Sure, but doesn't fit all scenarios. Accessibility to everyone only matters if your target audience is everyone. Not all websites are intended for everyone or for the purpose of providing information.
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?
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.
One solution to all this, use Next JS
Actually, I think of solution as using either
when I was reading the article, I was just thinking about nextjs.
it solve all the problem he listed.
That's it!
OK, I have some anecdotal experiences as well.
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.
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.
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 think they use Turbolinks.
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?
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
I think you have to look at what you're building. For example Netflix is really big on React, and the JavaScript you're shipping to the user is much smaller in comparison to the CPU and bandwidth required to stream video.
I'd also say it comes into the other libraries people end up including into their bundles, for example Moment. React + React-Dom is only 38.5 KB where as Moment is 70 KB (both when minified and gzipped).
Well. Time for some 🔥
1. React is Slow
Of course, this is obvious. React IS SLOW. But its like telling don't use Python because C is faster . It isn't convenient . People use React because it helps in scalability of a Code base. I know you are going to point out "But look at Angular & Vue or even the newer Svelte which are faster than React". Seriously, I don't want to write 10 files of random BS or use something that is basically a language on its own to just get my app working. React isn't built for being the fastest UI solution. It is designed for a flexible, efficient & fast enough library for building a good UX on the client. And I know its kind of unfair to mention it since this post was written before November, but I feel like I need to mention React Server Components. Everyone thinks RSC is the newest buzz word to hype a dying library again. But they are are legit. They do decrease bundle size. The main performance bottle necks for React apps is not React the library's processing itself, but the amount of JS that needs to be run by the client or the UI template that uses JSX. (Like the time you provided in the benchmarks is script evaluation time). React Server Components solve this by giving you the option to send JS for a component. And RSCs can also solve....
React is expensive
First of all, let me put the slowest React site I have visited (new.reddit.com).
Results? $0.86 is the most expensive PostPaid (Canada). And for PrePaid? $0.54186435806274 in the US which is the Highest. That's hilariously cheap. And once you visit the website once, React itself is cached on the User's device therefore making the metric even more irrelevant. Also, Client Side Routing + React is actually cheaper for the end user than normal HTML. Lets take old & new Reddit again. Old Reddit uses a traditional MPA approach while new Reddit uses React to do client-side routing or SPA experience. For the metrics, I am choosing the HTML + JS.
For new Reddit on the initial load:
For old Reddit?
So it looks like Old Reddit with its traditional SSR approach is already better?
Huh, lets look at subsequent navigations:
New Reddit
So in total, only 590kb increased. Which is acceptable considering how unoptimized the new site is.
Now, old reddit.......
JS count looks familiar? This is the main advantage of client-side routing. Instead of re-downloading JS over the network, it is possible to load some things once and then subsequent navigations are faster/cheaper.
I know this is a very lite comparison, but think of how much data is saved when the user visits many pages. (a lot)
React is inaccessible
First of all, "inaccessible" isn't the right term here. "React is Slow" would've been a better statement, but I guess you needed some more points on why "React is bad" to add to this
<article>.Long story short: RSCs + Server Actions solve this well.
React goes against what the web was made for
This is the point I disagree with the most.
And this also makes me realize how game changing RSCs truly are. React in Next 13 allows for streaming HTML from the server. SO the UI becomes interactive faster & therefore improves the UX.
Also, "Stop treating websites like native apps". Yea, if we did this, we would loose:
People nowadays pretty much expect a native like feel from a web app. If we as developers don't create a good native-like UX, nobody is going to use the app
Also, client-side routing is a part of the "native-like experience" which has its benefits.
It's made by...those people
If you don't want to use React because Meta made it, fair enough. But I need to clarify that The people working on React are not the same people in the lawsuit.
Yes, Meta funds people who work on React & it "owns" it. (well, its OSS so no technically the OS community owns it) But that shouldn't stop anyone from using the technology that Meta has created.
And if next day I start hating Google, that doesn't mean I am going to stop using YouTube. Something is made because it solves some problems, and that is why people use React.
Stop telling me what to do. I don't care.
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/
The perception that we all need to be building spas for everything is the standard naive response of the industry as soon as something with some benefit becomes popular. It's really important to be able to question that knee-jerk reaction, which extends to everything in dev. When you've been around long enough, you realise that a lot of this stuff comes and goes anyway, despite all the action it gets.
What I've done since day one in this regard is default to normal web apps (ASP.net MVC, in my case) and figure out how to embed a spa into it when I feel it's appropriate. This is the concept of a mini-spa. You can have multiple mini-spas in one web app, which means they can be small and focused on solving a real problem where they are the better choice. So you don't have to go all in. This way, you're getting the best of both worlds. I tend to go for a mini-spa when an area of an app is more real-time, or the engagement needs to be deeper. Most CRUD nonsense gets zero benefit from spas.
Also, I really can't stand all these noisy frameworks. Good frameworks have awesome abstractions and the framework itself gets out of your way when you're coding. The best example of that in this space is Aurelia, which I strongly recommend.
Lastly, I have a real issue with these huge companies creating these frameworks and have absolutely zero liability. They could literally do anything they wanted to it for themselves, including ditch the framework with zero consequence to them. There are only 2 frameworks which are built as a part of a business offering, where the support of the framework is the core nature of the business. Those are Ember and Aurelia. You will find that those companies care a whole lot more about your developer experience, and the introduction of breaking changes. You simply can't compare. Aurelia was created by Rob Eisenberg, who is the creator of Caliburn and Caliburnn.Micro, which are notable for their ease of use and intelligent APIs. Building a great framework is a real skill, especially one which does not introduce a breaking change for years at a time, while constantly improving. That is special.
In my point of view, this is not against web framework or React, Just share some cases that I encounter with:
Sometimes I prefer text-based sites that without Javascript (Noscript) won't break the functionality.
In my point of view: SPA is to solve server's scalability that before serverless and CDNnetwork prospect. But SPA still solve server's scalability for medium company.
Pro:
Cons:
Here's a little tip for you regarding the spinner speed, get faster internet. 🤣
Honestly I thought this was a troll post, hence my sarcastic response.
I hear what you are saying, but none of these issues have anything to do with react if you really want to get to the core of the real issues. You can literally pick any tool, framework, corporation and replace React in this article.
It sounds like you want to fight inequality in the type of access some people have, and that's cool, but again nothing to do with React.
Personally I like React because coming from the backend, I like how you can build modular components just with React without having to use backend like php with modular html structure. If html offered a nice way to import html files then it would be a different story, but the current way of importing another html file is kinda cumbersome.
Besides that is nice to have components with all the gui, and logic together this is something you can't really do with plain html, or without using a good framework.
I can go on and on, but seems like you only care about one thing which is something I don't have an answer. All I can say is that's your mad at the wrong thing.
HTML modularity: webcomponents.dev/
There actually are frameworks, like Preact, that actually don't have the issues that React has. So no, you can't "literally pick any tool, framework, corporation and replace React in this article". I understand you like React, but you can accept that it is flawed and still like it :-)
If gaining 40Kb makes you happy, then so be it. They're only flaws to you, not me. Different perspectives. 😁
I'll definitely check out preact though.
@ender minyard - the HTML imports link you shared has this line at the top, in red - "HTML Imports are deprecated and was removed from Chrome in February 2020."
I think most browsers didn't even support that. Even if it worked I didn't like it too much. First you had to import html, then you had this ugly code to actually use it. What I was referring is something like in php. Where you create an html section for the header in one php file. And call it from index.php. This is where plain html comes short and frameworks pick up the slack.
Numbers correspond to those in the article:
<font>and<blink>tags. The experiences that we need to provide, such as offline-first never-reloaded mobile and desktop applications, are completely at odds with that. Attempts to modernize the platform in a somewhat compatible way, such as WebComponents have failed. Best thing we can hope for at this point would be headers that completely break old stuff.All in all, let's hope we get direct access to DOM from WASM before everyone is so fed up that all HTML permanently gets replaced by
<canvas>with WebGL.Which is when accessibility will truly be gone for good.
While a lot of these related to SPA's it's also just related to a sites overall page load size including media like photos and videos. While these should be optimised we're heavily held back by the web's transmission layer, HTTP, we should move towards less wasteful methods like IPFS where data is much more accessible and cached. This will ensure no time is wasted on downloading the same thing twice, even across several sites.
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
Because I am a lone developer, I had to learn both front-end and back-end. I picked React and Laravel to build a serious project that currently has a client candidate.
However, for back-end, I don't want to restrict myself to PHP, because I see Node.js is interesting to use at back-end. Using PHP means that we have to deal with Apache or Nginx with their different configuration complexity. Whereas Node.js (and the newcomer called Deno) is a platform that also serves as a web server that may not require complex configuration.
As for front-end, actually I am also interested in Angular, seeing that it is said to be suitable for large scale apps; unfortunately I don't have enough time to resume learning on it.
If you learn well a stack, you'll be able to pick knowledge on any other much more easily than knowing half of one, keep it going!
Thanks for reply.
One of the reason that preclude me from learning new stuffs/technologies is time (energy too). Currently my time is already occupied with a serious project that will force me to read more Apache documentation and probably Nginx doc too. As I said I am interested in Node.js and have a desire to build a prototype using some parts at back-end in my current Laravel project. It seems that I couldn't realize it, at least in near future.
Well you'll use either Apache or nginx so simply check the differences and pick one and go with that at this point. Learn about what you use and finish your product dev cycle, it does not matter if it's not the best, you'll be able to refactor later
I personally think that there is absolutely nothing wrong with using React. The problem is they way React code is being written. This is true for any framework or workflow you use to create your web applications.
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.
Since you are a full-stack dev and use Laravel for API as well, which approach/tech do you use and recommend : REST or GraphQL ?
My current Laravel app is a stand alone, in which all requests are handled in web routes not api routes. However, chances are that I will have to build APIs for integration with other apps.
There's no one to rule them all. You can use GraphQL with gRPC, or RESTful or... Depending on the needs of a project. My advice is to learn about and know the tech, then you can discern which stack is better for a job.
With GraphQL you can add a single endpoint for example but this could cause overheating on that endpoint. You can use services or microservices too with one or another.
Thanks for your advice.
One more question, for API authentication in Laravel : which tech/approach do you use/recommend : Passport, JWT, Sanctum or any other ? I am still considering which one I will use.
Again check the differences and the compatibility or support on both front and back current stack, pick one and don't look back
Well, I think all your points are valid, specially point 5. Web was meant to be html. In fact up until a few years back search engines only crawled links without running any js on the page. But with my experience I would say that you could broadly classify all web apps as below
For the public facing SEO sites, you need to build all your markup on the server. Whatever tech stack you use - php, jsp, nodejs, react etc; for the browser, its always html. For eg if you are going to create a blogging website, you will surely try to refrain from JS Frameworks since you will be creating pages on server side. There are hundreds of ways to improve performance of these kinds of apps.
For those apps which don't need SEO and do not require caching are best candidates for using frameworks like React, Angular, Vue etc. For example you are building an admin panel for a backend. You don't need it to be available for SEO. You have the restful APIs available, you can build a strong fast performing web app in quick time using a JS Framework.
Eventually its always about the use case. Nothing fits all.
Do you mean 2 things:
1. Web App Need SEO ? - Use server side tech like php, jsp, nodejs, Java , C#
2. Web App Don't Need SEO ? - Use Any
JS Frameworkslike Angular, React , Vue etcReact is shitty.
But, it did teach us all a lot of things.
And it seems like your list is a little surface-level. People say things like "we shouldn't have SPA's" - but clearly weren't around while we've been navigating this question for the last 10 years. It's the same thing as saying "jQuery" is silly... but not understanding the problems it solved. We couldn't just write
const site = (x)=> [...everything]a few years back.So - we think React was an interesting take on things - and we've learned from it - and it should go away. That being said, we love to drop in a little Vue on a PHP site. Sometimes you hit a wall with JS dom stuff - and having some chill little way of writing interfaces is fun. Is that too much JS? Is the loading spinner the biggest problem? And if we're going to build a real (actually used by people) application - that actually does things (not just a chat app from a tutorial that you forget about in a week) - then we're going to use Ember. Why? Because. If you don't know why - then you should take this as an opportunity to accept that you just haven't run into the problems it solves yet, or that you this tool isn't something you need yet. Advanced functionality (being stuffed into a web document) is a little tricky. But Progressive Web Apps are the future. So, we'll have to meet the challenges. If you cobble together a Vue or React app - you'll soon see what a mess it will become. Try using React on a fast-paced marketing agency team and seeing how many insane ways it can get written and what a mess it is. Yuck! Also - FB is the worst. (that doesn't meant that Apple and Google aren't also actively trying to create walled gardens and that they aren't also creepy...) - but FB is the worst. Their code has always been crap. Why decide to "trust this super ugly React thing?" Anyway... there's all types of websites. You gotta just use the right tools for the job. Most often - that tool is HTML. That's why we teach things in order of important at PE. We specifically say right on our website that we will NOT teach you React. Why - because it just never made it onto the list as "important." It should be the very last thing people learn - and only if their job absolutely demands it.
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).
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.
100% react is not a framework.
A few good points to keep in mind regarding mobile users, and definitely modern developers should not be afraid of the traditional request/response/repeat model of traditional web development. Not everything has to be a SPA.
However, point #1 (and the blog post it comes from) has a huge bias problem. Comparing the size and speed of "all" sites with JS with the size and speed of sites that use Angular, Vue, and React is apples and oranges. You may say that sites using those frameworks are more likely to be larger and involve more code, but you can just as easily flip it: sites that require larger, more complex code bases are more likely to use a framework or library, or exist as a SPA.
It's like the old adage says, "correlation does not mean causation".
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!
I also don't like frameworks. They are just useless and add more burden to your work. Like configuring a router. Using static HTML, CSS, JS is faster. What you need is the correct knowledge of HTML tags and stuff. JS Frameworks are just a bag of tools like postcss, UI frameworks, and more. These tools can be used without the framework. Wonder why people use frameworks
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.
Some points are interesting some are just too biased IMO.
A simple example you talk about the number of people still in 2G but if your market for your app is in a developed country than that is a point which has no value.
Talking about the goal of the app well the issue with React is people now want to use it for everything and anything which beats the purpose. Using React for a simple portfolio website might not be the best. However for live data which needs to be displayed it is much more suited. Some cases React is perfect for the job and other times its not. That is the role of a spec analysis to define the needs of a project.
Expensive? I'm sorry but I have to disagree! You can whip up a simple free tier server on amazon (free for a year) and deploy your react app there. You can then easily migrate to another server the next year. There are many other ways to have cheap hosting.
Technically everything goes against the web as originally it was made for the military
"These People" So what? React is open source if you are afraid their is something stealing all your data nothing stops you from going in the source and just changing it. React might have been created by facebook however there are many individuals who also contributed to the development since it is open source.
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
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
I'm part of 2 poeple:
1. I think it always depend on what you do.
Of course if you build a static website, you're not going to use React (or Angular, or VUE or Rails, etc.) just like you wouldn't cut a tree with a sheet of paper. Because it's inefficient.
There are lots of way to deliver fast Web App with a JS framework that will be useful for users. You wouldn't put a CMS that handle Big Data for use with a Galaxy S3 on a 2G network, because again: its inefficient. (The whole topic of poeple still using 2G is another discussion, point is, there is a limit to backward compatibility.)
2. Its good to not like something and start a discussion, but what do you propose as an alternative? Complaining for the sake of complaining is not a discussion and I think your writing skill would improve with that.
Anyway, that's my take on this
P. S.
Even tough I do use React and Angular for work, I have a profound hate for how they pack heavy files and create pages that are slow, but I usually try to find other solutions anyway to create something robust.
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 hate modern web development. I wish we could just make things faster and simpler for people instead of slower and more complicated. This is also not really an issue with React alone, all of them are quite bad.
We should stop putting so much focus on JavaScript for our UI/UX and instead turn our focus to CSS/SASS/SCSS. We need faster websites, it shouldn't matter what toolkit we use, as long as we are able to get the job done and done well.
"Performance is user experience."
One of the serious problem I got in my app was in data processing at the backend which could take very long, unacceptable time. It's obvious that it's not related to React at all. I am glad that I have solved the problem with query optimization for complex query that made a client candidate happy.
I am not a fan of React but what you said about SPAs seems wrong. SPA don't usually download all the site (including assets or HTML itself). A well-designed SPA would load the page as it needs using dynamic imports.
I SUPPORT it fully..
Since I have used React and it bites me in the a$$ each time
So I dont like it
Although I have not read the complete article XD
I support it fully😂
Did you read the React docs with the same dilligence? ;)
I guess so🤪🤪
Yeah, let's go back to '95 and do page reload in every click, let's not cache resources which are immutable.
"The Internet is a stream"
Who told you that? Read what internet is: en.wikipedia.org/wiki/Internet
btw, I'm working with Angular :)
Nice. But my question is: Is there a way to build a modern app:
This is the most clickbait-y, worst researched and laziest article I have ever read for such a long time. Honestly if you hate something just say it with your chest, you don't have to form such ridiculous and disingenuous opinions like these and decide to blast it on the internet.
Care to explain what react has to do with point #2?
Also point #3 is so fake news that I don't know if this is just a rant or you really have something serious to say
Overall I just agree with point #1 and #5
Only commenting to say, does anyone really care about 500 million 2g users or w/e... It's being shut down on roll outs and most of it has been shut down. 3g will be gone too soon. And starlink is launching which is going to change the world.
Users being on feature phones on 2g is a really poor argument to be making in 2020+. Within the next 10 years 500mbps will be the world wide average internet connection bandwidth.
I'm not going to roll backwards in time to support a bunch of 2g phones, doubt anyone else is either.
It seems you did not like my comment where I put the link of the video, Benjamin Awad did about this article as you plainly hide it.
Hopefully, you will try best to do not go all censorship on people with different views and allow anyone who might be interested, to see different takes to have freedom in the information.
Good day.
Another interesting view on the matter:
Should You Stop Using React
What do you suggest we use instead of React?
Vanilla JS.
I'd like you to watch this talk and this one too.
If you really need a framework: Sapper or Preact.
Coding a eCommerce website using
Vanilla JSwill cost more maintenance and more development time. I think thats why we need Javascript frameworks.What do you say about
Angular, Vue and svelteare they better ?Thank you for your prompt response.
I'd choose Phoenix Liveview over React or any JS SPA these days, it moves the state back onto the server where it belongs, pushes live state to the UI via web sockets. Has microsecond load times rather than expensive hydration times.Uses morphdom for tiny UI dom diffs rather than requiring the whole state of the world every time you communicate back with the server. Self healing, true concurrency, allows you to build complex functionality like chat in minutes etc etc, Have generators to build forms with validation from single line command line actions. Set up in minutes with a full postgres db, the list goes one.
this seems a little confused to me, blames react for things that react is not responsible for
no. 1 is only true if you are not using SSR
no. 2 and no. 3 might not be relevant to you at all, you might sell app to managers in Europe or USA, why should you care about an Indian guy with 2G connection? And even if you do, the true cost of react is about 35kB, every other kB on top of that is your own decision. And that 35kB is one time only, for every other request it is free. Is that too much? I don't really know, I don't care about Indian guys. No reason for me to stop using react because of those two points.
no 4 is not true at all, you can set your build in such a way that every page in your app has its own custom JS file, using only code you need for that particular page.
no. 5 is not technical, so I'll skip, it might be important for some but not for others. I used to drive my VW Golf happily, so...
Replace React to Preact and your problem will be fixed
I'm kinda disappointed that you are hiding comments that disagree with your point of view and mostly leave comments that agree with your points.
Ok, I know it is your post and you can hide comments, but I didn't attack you. Ok I maybe attacked you a little bit, but I gave arguments for each of the points you mentioned and didn't just blatantly insult you.
My comment got over 100 hearts from people so it was clearly a good comment, but you decided to hide it because I didn't agree with your points.
I respect your opinion and it's good that you have one, but I would appreciate if you would also respect other's opinion and not just hide those that don't really align with yours.
Makes this whole discussion seem one sided because you selectively hide stuff.
I've seen this argument before and by and large it's less to do with React and more with Javascript in general. You can look up more arguments on YouTube, there's a GOTO talk called "We don't need all that Javascript, do we?". A large part of it it's targeted at large frameworks, with React front and center.
But some points do sound crappy.
Without context, the statistic is meaningless. Sure, recent versions of React are slower than newer versions of Angular. But it's a relevant comparison only if: a) you do some breakdown per version and b) you benchmark the same site with same content in all but the framework in which it's rendered (eg: same images, etc). React it's faster than Angular up to version 4 but then it gets bigger in comparison and slower. All sites, what does it mean? Same type of dynamic web apps, or just static HTML or what? Like I said, no context.
Errr ... what? I guess that could be a concern in the US, where I heard there's still plenty of pay as you go ADSL, so if you have to transfer 500kb that's a measurable bill as opposed to unlimited broadband plans. I can't think of any place in Europe where that would apply, even for ADSL.
Again ... what? I've bene building webapps for 17 years, in the last 7 I've never, not once, worked for a customer concerned about feature phones (again, maybe a US or Africa concern, mostly?). or they capability to load JS. Which, as per above, it's not a React specific concern unless someone build feature phone browsers that somehow detect React and reject it. Also, this is not an issue to take with developers unless they develop their own product. Developing with feature phones in mind is expensive in itself because you're just about precluded from using JS in general, up to some basic stuff. In those cases I had to develop with this in mind, we ended up creating a separate basic application launched quite a bit later.
Also, on a general note, there's a difference between execution speed and load speed. For execution, just about any "virtual-DOM" framework like React and Angular will be slower than a native JS precompiled app like Svelte (which will also work in more environments).
True, though this refers to any rich interactive SPA. You might do something a partially loaded bit of static content, if that's how your application should work, but I wouldn't bend over backwards to try and do that in all circumstances. In most of my recent apps, useful stuff gets loaded remotely.
Also, to keep in mind, JS exists because it enables behaviours that are not possible with all the other technologies listed. We have more options now.
If what you need can be released on the market faster as a SPA, with reasonable performance for your target audience, then that's what matters.
Ok, but why is that even relevant? If you don't like those people, I supposed.
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.
To the author: if you're going to hide comments from anyone who dares to have a different opinion and share their criticism, just leave a note that only yes men are welcome to comment. Otherwise people might think that you're open to different points of view and you're clearly not.
From a technical perspective, CanJS is arguably the best JS framework at the moment all things considered. It has the best observable implementation of any JS framework hands down, and doing change-propagation based rendering is substantially more performant than React's VDOM will ever be. You can do SSR and make things progressively load, and in doing so optimized around startup time, SEO and speed. For all those ReactJS pushers out there, your shit stank and most of you don't know what the fuck you're talking about. The only thing that's good about ReactJS is that it has a large ecosystem; as a framework, it is strictly inferior to CanJS in every way. Unfortunately, fanboyism seems to put React (and others) on an underserved pedestal despite React lacking merit from an objective technical perspective. See bitovi.com/blog/change-propagation
Saying that others "don't know that the fuck they're talking about" and that their "shit stank", just because they happen to use and like and promote a different solution than theone you use and like and promote is fanboyism in its fullest, bro.
If what you want is more application than web site, go ahead and use such a rendering framework, because the advantages will easily outweigh the drawbacks. However, the opposite is true, too.
In addition all those points can be rectified, most of them by replacing react with preact and accessibility can be achieved rather easily.
Stop writing articles with catchy titles that tell developers what they need to do, it's just rude.
Or if you absolutely must, at least have the decency to research the topic and think of arguments that actually make sense. React-based SPAs are slower than the average website? Gosh, I'd never think of that! :) Tell you what: there's a ton of applications that are orders of magnitude slower than the slowest web browser running the heaviest SPA out there. Should we stop using them as well?
If you follow through this thought, then how many people do you lose by not translating it? By not translating into Mandarin and Hindi, you just lose around 20-30% of the world population.
I think most developers work for companies. Companies (primarily) care about making money. So caring about non-paying users (who are in my experience the most troublesome ones) is probably not your most important task.
I think your thoughts are very noble. I think the implementation is chaotic and non-deterministic. Having real companies that maintain a framework is not just disadvantages.
I recently switched to using VueJS for these reasons. React is actually quite expensive. In my own opinion, VueJS closely match what I believe the declarative, componentised web applications should look and work like.
A VueJS project using the single-file component architecture is much easier to reason about because each file contains all that is needed for that component, i.e the 3 parts of a compoent namely, the view, interactions and style. No two ReactJS application structure look like.
what i found funny is the creator himself when asked how much it takes to load he responded "well gzipped and minified..." if you have to say those words before saying how much space it takes client side, you are doing it wrong. there are plenty of reasons why react sucks, other than the terrible devs who made it. try harder
I want to response to 4. . Do you know most of the modern web Javascript framework support code-splitting ?
user don't need to download the whole SPA at first time. Most of the time, it don't need to download 7 seconds long.
Discord, reddit also use react to create their website, do you think them are slow ??
"5. It's made by...those people"
To be honest, that is so pretentious and discriminatory statement - what is wrong with it? Can you elaborate with your own opinion and your own research rather than articles on the Internet?
Facebook with React has made a huge step in web-development industry and moved the whole web-industry further.
Anyway, this post is so clickbait.
Sophomoric. React as a tool isn’t any of these things and it enables rapid development. SSR and code splitting come native in some react frameworks and gatsby is pushing the envelope of what’s possible using react.
The whole argument is garbage and based on a lack of understanding about what developers are actually doing with React. Entire suites of software with 100s of ui screens are being built on react, and shipped fast. Websites are only the tip of the ice berg about what react can be used for.
Stop reading Dev.to
It's really a cost benefit + risk analysis.
Arguments 1, 2, and 3 are effectively the same argument; How quickly can you get to interaction.
In fact, every argument you are making against react has been answered time and time again. It all comes down to how much effort are you willing to put into development to get there. You can hand craft every line of code and refuse to use someone else's "bloated" libraries. You can bash on companies that produce something popular because it doesn't fit your model of what the internet "should be". But the fact of the matter is that it's successful for a reason. Many sites are using it effectively. Many developers do have a high valuation of the tool and the underlying principals. At the end of the day it comes down to nuances in how individual teams architect their applications using know best practices. There will be teams that just jump on bright and shiny new platforms. That's not the fault of react or any other framework. That's existed since the beginning of frameworks and accelerated with the internet and how many people are producing one-offs and re-imaginings of... instead of improving existing or truly making something game changing.
It's as slow as any other javascript heavy (or image heavy) site. There are many things you can do to optimize that performance through pre-compiled static site generation of the react pages or server side rendering techniques, bundle optimization, caching techniques, defers and preloads and anticipatory loading, edge side includes, yada yada yada.
But how much money does a company want to spend getting to perfection versus getting to market and getting to market good?
I've seen shops that hand code as much as possible for the slimmest margin of users for zero gain other than "look what we did, isn't it cool". I've seen shops bloat their non-spa pages with dozens of jquery plugins and dojo libraries and extjs and layers of different css frameworks working against each other to try to get a certain look and feel. I've seen shops that used React in completely the wrong way on things that they could have generated in HTML in no time at all. What we have to focus on is not throwing everything out and labeling it as bad or dangerous, but picking through it and saying "here are the use cases where this is good and this is the benefit" and focusing on that. If you can point people to positive use cases then they get repeated. Otherwise you give them nothing but negativity by saying "[framework] is dangerous, don't use" and no realistic starting point for doing better.
I'm not going to lie, there is a learning curve to doing things right in React. But that's true of building websites in general. I've definitely seen people get burned by poor react implementations (eg a consumer marketing site with no SSR). It took me a few attempts to get a good system in place (SSR, code splitting, being careful about which dependencies you add, finding a good system for css). Once a good system is in place, we're really productive and the quality is good.
I use React for a lot of marketing pages. Some times it feels like overkill. But we're able to achieve a level of interactivity that would be impractical without a framework like React without that much additional overhead on the client.
If React means it's quicker to make a site that converts better, then use it. But the notion of "better" should be backed up by data. You should have a reason for using React.
Sounded like a cheap trick to attract visitors. more like a clickbaiting. It didn't have any sound logic. And the people who supported are mostly py, Java, Ruby, etc backend developers. The people who are not supporting your view is giving you negative publicity.
Do you think any other framework like vue/angular/backbone/ember/preact etc. are better? do you have data to support?
I think that there is validity to your points, but I think "Stop using React to make websites" would be a more accurate title / argument. To use one example to illustrate my point: while it's true that users leave websites when load time is slow, this is not (as?) applicable to web applications as usually a user is paying to use a web application because it does something that the user needs to do. In this context, front-loading the download of the javascript optimizes the rest of the user's experience interacting with the app. It's important to pick the correct technology in software development - if you are making a website that relies on SEO type things to be viable, yeah don't use a SPA (React / Angular / Vue), they have slow initial load time, they are poorly indexed by the Google crawler and by other search engines and therefore less likely to have high organic search rankings and there is a steep learning curve in order to do development.
It's easy to bash the current state of web development. You don't have a good understanding of the history of the web and how bad the UX is for server-generated pages. Fetching each page individually (HTML + CSS + JS) is a performance killer and users are much more prone to abandoning the site. Server-generated pages also place a heavy load on servers and is costly to scale.
You have a chip on your shoulder against Facebook, and some of that is justified. However, React is a solid SPA library and is superior to Angular in most every way. The numbers you listed don't line up with the real world. There are ways to address SPA load times such as lazy loading. The issues with SPAs aren't specific to React, and neither are the strategies to address them.
There are solutions like Preact, which is 3kb gzipped and for many users is a drop-in replacement to React.
WebGL app development is on the rise and all app state needs to be managed on a single page, so if you believe Apple and Facebook's next big product is going to have a market impact I'd be investing in projects like react-three-fiber or Svelte if React isn't your thing.
There is no other solution that offers nearly the ecosystem. For rapid prototype iteration, combined with NPM a strong React developer can build a professionally designed website faster than a designer can design it in Sketch -- or so many competent front end developers have claimed.
It's not React's fault, the real problem is actually the most web server assumes your site can be dynamically served like PHP whereas SPA only statically served.
That's my motivation of creating Kuda Web Server, which compresses and stores all compiled React app into RAM. Performance boost especially on server with HDD.
Please take a look: github.com/Thor-x86/kuda
He have to agree somewhat. React is pain as a new developer. It makes me wonder why do I have to do certain things when it can be easily done in html. But I still like react and understand the value React brings however this talk put things into perceptive:
You really don't need all that JavaScript, I Promise
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.
You can very easily write a SPA by using async calls to refresh parts of the page, without stepping into frameworks like React, Angular, or View. You can simply pull in your html ad hoc using the innerhtml property or go for a more structured approach like using WebRocketX against your favorite server side rendering framework for example Spring MVC, Ruby on Rails, Struts 2, Php etc. How did SPA and json only based transactions ever become synonmous? Its a mystery to me.
I built a Gatsby website and it is faster than a static site ( HTML + jQuery ).
I'm not a fan of jQuery!
I was a fan of Jquery years ago, even when Prototype was another option. Not now.
Hello Ender. I agree with most of what you write in your article, and I would like to know your opinion on Sapper, based on Svelte. sapper.svelte.dev/
In a few words, it is more a compiler than a framework, so your final code is pure JS with only the features you are using. The framework code simply doesn't exist at all in your final code.
Its speed is incredibly faster than React[1] in all means and it's SEO friendly, with SSR.
[1] youtube.com/watch?v=AdNJ3fydeao
I really would like to know your opinion! Thanks!
Lovely. Progressive enhancement and initial load experience are my main concerns.
As of now, Sapper + Preact are the “frameworks” I respect the most.
You could say the same thing about Vue or Angular. I think it all boils down to the question if a SPA vs Server Side Rendered site should be created.
If the latter is the case then something like NextJs or Nuxt is actually a good solution for React or Vue while keeping SEO and accessibility in mind.
...6. Promoters of React are cheap manipulators.
They called it "library" being aware that it is the obvious framework.
They also have inspired jQuery hate. What they are trying to do is to replace The Library with "library".
Well, if you want to develop an application that runs in any OS platform, viewport, is readily available and installable in any device, then a PWA SPA is the way to go. What else could one use to be so efficiently deployed and available to all asap? React has its draw backs, performance of initial load is dreadful, but with performance first design/implementation focus it's a great option. Sample app: yocasa.net
HTML with or without CSS was never meant to be the end and be all of good UI/UX. HTML + CSS + JAVASCRIPT is not the end and be all of good UI/UX. That is the root of the problem. We keep making ah so clever hacks to get around it and spend so much time and energy learning those, arguing about those, straining to make new ones, dreading the day we have to upgrade any working Web UI or convert to the latest great idea. Something is obviously quite wrong.
I think the problem is fitting multiple apps into one React app making it heavy and slow. Instead they should be split into multiple smaller apps like with GMail, Google Calendar etc.
I already stopped. It's just not appropriate for the types of websites I build.
Your concerns are very valid, and I agree are ignored by the web community more often than it is healthy.... however either you are marking React specifically for the clickbait title or don't know about some tools available on the React community. I assume is the second and give my two cents, hoping it would be useful for you or others facing a similar frustration (was my case as well).
As other people pointed out React !== SPAs, which is the culprit for most of your points. A web site and a web app are different things with different challenges and aimed to different audiences, so it doesn't make sense to try to develop sites as SPAs which is what I believe creates the scenario you describe.
If you are developing a mostly plain site, you may not need React or anything else but HTML/CSS/JS and a utility belt (that's why comparing to JQuery doesn't feel like apples to apples to me).
That being said, React is actually a lot more friendly for non-SPAs than its natural competitors (Angular, Vue). Being a library and not a framework, makes it possible to complete the toolset with other things than say Redux, etc. In particular:
I think the most crazy thing (and the only one) showed by this article: so many people take it seriously.
Would this discussion system below be as useful if it were not implemented with modern JS?
The last part just doesn't make any sense.
If you want to build a website that just serves content, like portfolios, blogs, news sites etc, then yeah... React, or any other SPA framework will not be a good choice.
But imagine building large, complex app that your customers will use as a tool and will expect native-like behaviour. Not a "todo app" from tutorial, but actual large commercial app built by a large team of developers. Add some real-time functionality to this app, like notifications, messaging etc. And remember, when you are working on commercial project, there will be always pressure to implement new features and fix bugs.
Good luck building that with vanilla javascript and static html.
After some time it will fall under one of two categories:
So don't stop, use React, use Angular, use static HTML. Just pick the right tool for your project.
It's so true. With modern SSGs and the portal tag, there's no reason to use React... I could see use cases for Wasm... But there seem to be better ways to solve the problems React solves.
use Vue js version 3! it is great!
Sounds like you have a pretty incomplete picture of why, or how to properly implement with React. Or, maybe you just thought this article would get a lot of bites with a title like that.
Too many people just don't understand the difference between websites (news, blogs, landing pages etc) and web applications (Gmail, Facebook, etc).
From what I have seen, an SPA approach is suitable for finance/accounting systems, KPI management systems, HRD management systems. I have experience in building finance/accounting systems for desktop non-web app before I turned to web dev, so I find SPA approach is suitable for building web app for KPI management system I handle currently.
One issue that is of my concern now is when the app grows larger. I use React, but I am considering learning Angular seeing that a lot of people said that Angular is more suitable for large scale apps.
What is your opinion of this ?
I find this article highly subjective and I don't agree with your point of view, sorry...
Svelte, any one ? Once you move to Svelte you see the beauty of the web again.. Svelte + Golang + MongoDB (Nice!!)
Such a boomer post and response thread. "Back in my day...." stop being so closed minded....
Try telling those to Facebook , Twich , Slack or Instagram. It would be nice if you put their comments in your article too.
I think the problem is with you, not with React.
You're confusing sites with apps.
"A web application (or web app) is an application software that runs on a web server, unlike computer-based software programs that are stored locally on the Operating System (OS) of the device. Web applications are accessed by the user through a web browser with an active internet connection. These applications are programmed using a client–server modeled structure—the user ("client") is provided services through an off-site server that is hosted by a third-party. "
cliffs - angular dev trying to make us change
I think Ben Awad made really good points why most of these points are negligible, and why you instead should continue using React.
youtu.be/PJ0QSJpJn2U
Should You Stop Using React
StimulusJS + Phoenix LiveView = Love
The Best Code is No Code At All 😎
anyone else remember Prof.Dr. Style?
The people who doesn't care anything about React reading the comments
honestly...
Nonsense arguments
I think Ben Awad made really good points debunking this article
React is incredibly fast. Its lightweight opinionated its great.
Am watching you... ? __ : __;
Still relevant in 2023. Try SvelteKit and never look back.
Who are you to tell me to stop using React? Man, I hate this clickbait titles
React is overkill for most websites. Very expensive to write and maintain. We instead use WebRocketX, with SpringMVC and it has worked out great for us.
Wow, this topic is very controversial. The topic has baited me in. The delicious content is not from the post itself but the comments. Turns out, I am joining the bait party...!
No documentation is on another page, it's the homepage itself. But, yes you are 100% correct.
If React is so bad, can then somebody explain to me, how come it is so popular and so widely used? Legit question (new to React).
The problem with using react or angular or vue is that you end up with two problems. The problem that you were originally trying to solve and the problem of learning the new framework.
How about no.
That's why the right framework is svelte.js !
It' rapid ans svelte and coding is easy.
For load times there's this thing called Preact that's a fast loading alternative to React. I'm not exactly sure of the disadvantages though
YES! Totally my opinion and promoting as good as I can! Stop using it!
i love react - no going back
Why I can't find thumbs down or dislike button?
Tell me where to find it and I will click right away,
ad 4 - Have you ever heard about code splitting?
Like seriously, just avoid the problem in the first in place
I don't you are well educated in React, and that is the cause of this article.
Hi Ender, , your arguments are weighty but i beg to differ with you. Well apart from No.5 but React is awesome !
this is spot on
In order to dev on React, you also need a $3K computer.