I thought I simply didn't understand React. I taught myself React and I still wish I could go back in time and make it like React never existed. Here's why.
1. It's slow
source: tim kadlec
53% of mobile users abandon websites that take longer than 3 seconds to load. For every additional second a page takes to load, 10 percent of users leave. Performance is user experience.
2. It's expensive
Put your React app into this testing tool: https://whatdoesmysitecost.com/.
Do you care about people who can't afford to pay for expensive websites on their data plan?
A lot of people have discussed how expensive JavaScript frameworks are, but it seems developers don't care about reaching all their potential users. I'm not the first person to make this point, but it seems like the message isn't getting through. Do you think some users are more important than others? Do you care about reaching all users or only the wealthy ones?
3. It's inaccessible
Hundreds of millions of users access the Internet from feature phones with a 2G connection. When you load all your JavaScript onto a feature phone, all the user sees is a spinning wheel.
There's so many articles, tools, and frameworks that help you develop for these users - but developers scorn them. Within the JavaScript subreddit, web workers are hated, even though they are one of the best tools we have for effectively developing apps on feature phones - scratch that, for all users!
If your app is fast on a feature phone, it will be blazing fast on an iPhone. When you develop with all users in mind, it improves the user experience for all users.
4. React goes against what the web was made for
Here's the general idea of React: you download all the JavaScript a website needs for like, seven seconds in a row without showing anything, but once you do that, you never have to download resources again, because you've made a single page application.
Is this how websites are supposed to be?
"The web is a streaming thing by default. You go to a page and it serves HTML. You'll start seeing it as it's downloaded. Same with images, video...You can do something with just a little bit of the response." - Jake Archibald
The Internet is a stream. React is not. I see it like this: React fights against the natural flow of the Internet.
Ditch React and become friends with the web. It's a web, interconnected, with resources coming from everywhere. Web apps are not like native apps that take 30 seconds to download before the user accesses the content. Stop treating webpages like native apps.
5. It's made by...those people
Just read this Wikipedia article. No, it's more than you expect.
Top comments (358)
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 :-)
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.
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 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
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more