I used to have a 2G connection. In my experience React is better than the usual because I'd rather wait once for a long time rather than waiting for like a minute for each page
It just doesn’t matter. For those of you who are new, you’ll see this over and over again. Somebody at company xyz says something is bad. Ignore it, the knowledge you gain is what’s important. When you learn React, you learn about HTML, CSS, JavaScript as a language, how to make API calls, you can easily pick up Node, etc. If you have this base knowledge, it does not matter where you start or who says to use or not use something. It matters that you understand the concepts.
"Should you stop using React?" "Oh...so...Angular then??" "No...wait, that's not what I.." "npm install -g @angular/cli" "No Don't! That's even worse than Rea..." "ng new super-hardcore-javascript-bloated-app" "STOP! THINK ABOUT THE 2G!" "cd super-hardcore-javascript-bloated-app ng serve"
Those points against React are the least of the concerns. I'm old enough to remember the development community moving in the direction of separation of concerns. React not only goes against this idea but it bloats it with JSX and CSS in the ugliest manner possible. People would laugh at legacy ASP because of this and now it's the greatest thing since sliced bread. The worst of all is how React handles State. It's too long to explain in a post but being a developer for 25+ years, the first time I saw React, I almost threw up in my mouth. It sounds like the dev team said let's get HTML modularized BY ANY MEANS NECESSARY. even though your code turns in spaghetti and unreadable not to mention sprinkles of array mapping, reducing and passing event up the component chain. Nothing but a mess.
I love React, and enjoy programming in it. One of my recent projects (a Covid-19 tracker I built in React JS) helped me get hired at a medical university as a web developer, so it’s still worth working in, especially if you enjoy it. I have a number of personal projects I run in Django/React and I just enjoy the actual programming as well as using the apps themselves
@@Ahmadavocado Originally I was using Django to serve everything, but about 2 years ago I duplicated most of the functions through REST API, and since Covid-19, completely moved everything over to REST. My blog (a whole CMS I made from scratch) used to be served frontend and backend by Django, but now it’s all REST with a React front end. The Covid-19 app, however, is just a React JS file being served on a blank template HTML file, since it doesn’t use any databases. But I MUCH prefer React/Django, right now I’m working on a video game engine that moves all the enemy/map/audio/character data to components that communicate with the REST server, so the “game” is javascript while the data is REST. It’s so much more powerful that way.
@@JasonBoyce that’s nice to hear! My first project was a custom blog using Django as well haha. It was a totally newbie project but it got me started with Django and some JS basics to handle AJAX. The css was pretty bad and it lacked interactivity but it really made me fall in love with Django! Been pretty busy with school lately but I’m planning to learn react during the sem break and create more interesting projects soon.
@@Ahmadavocado Django is amazing, and there’s so much that can be done with it once you really start digging in. Especially if you switch to REST/React, because then CSS/JS etc all get freed up to run elsewhere, and you don’t need to mix your code bases. I worked on one project a few years ago that took every street tree in San Francisco (trees planted in sidewalks) , about 130,000 of them, and then built a frontend that you could use to figure out which trees were planted where, which ones were in the best conditions, you could select a GPS location and it would rank all the trees around your location, my coworkers would use it to skateboard around neighborhoods and mark sites where they would come back to plant trees later (they LOVED using the app on the phone while they skated), and the City used it when they met with neighborhood groups to talk about where they wanted to target their planting and the benefits it would give. INCREDIBLY useful project, that was ALL Django (frontend, css, js as well), and I would feel much more comfortable with that data in Django & Python than I would in Node or some other server
@@JasonBoyce That sounds amazing, and very practical, I'm inspired! Maybe I could work on something similar in my country haha. Can't wait to learn and progress to your level and beyond. Thanks for your help!
Yes for svelte. And sapper. Svelte eased me into framework world. I'm in no way experienced enough to give the pros and cons or it's nuances. But as a newbie I can appreciate the elegance of svelte. It somehow feels joyful writing svelte and kinda feels like a very meaningful extension to HTML, CSS and JS. I hope more youtubers try and shed some light on this lovely framework and not let it die out. And sapper too, it needs some love so bad. 😅
Any cues over why I would prefer Svelte over Vue? (other than any performance benefits if any - it barely applies in current world with ever increasing hardware computational potential in years to come)
@@krozaine I'm new to coding in general. So other experienced developers can probably answer your question better than me. The only thing I can say is, it feels intuitive. Especially for someone coming straight from HTML, CSS and JS. It's very subjective, I know. But that's all I can give you. If you can find some time do give svelte a try. Just jump in and find out if it makes sense for you. That's the best way to know. It's not a huge cognitive load.
Matheus I have no idea where you get ‘jerk’ from. Rich has developed a lot of phenomenal tools for Frontend dev. The list of Svelte contributors is rather large, the community is working hard to mature the environment. I’ve had nothing but great experiences with Rich. Super humble and he is really self deprecating. Also has a pretty dry British sense of humour.
Matheus what do you mean a jerk? Even though I’ve not met him in person but his contributions and talks pretty much says he is an intellectual and very humble person.
@@bawad I personally want to try migrating your reddit clone tutorial over to vue 3, once I'm finished with the next.js tutorial. Maybe I'll use it with Nuxt.js
@@Comphonia Maybe the person just migrated some small personal projects that he has for fun, not necessarily an app that is a business? This is definitely ok if you want to experiment and just see what is new in JS frameworks land. I also think that Svelte looks promising, but I'm not sure how it scales because I didn't actually use it to create anything more meaningful.
@Vizman216 I started off with Vue as well, but JSX/TSX looks way cleaner and more intuitive. I spend 6 months learning Vue, but React is drawing me in. Tryna get some advice from the god of React @benawad.
Well, autocomplete is better. Although there is an experimental feature you could turn on in vetur vscode extention that makes vue templating almost as good as tsx.
Comparing react to vue with python to c does not make sense. Python gives frameworks c does not, but vue gives a lot more than react and handles a lot more itself, and I think the article would make a stronger argument if it was comparing react to vue rather than react to html ot vanila js in general. React is somewhat built in progress which makes it prone to complexity and performance issues like state management (redux) which was made later on, however vue on the other hand comes with vuex out of the box and handles everything for you and dont get me start on css in jsx. Also it was very interesting that react was slower as I always thought it was faster which was the only reason I could have thought people would use it 😅, but for vue to be that much faster was something else 🤣
Used to be we wrote heavy applications that ran on computer networks. The best example being Windows applications running on PCs. To improve performance client server databases were implemented to move some of the processing from the client PC to the network server. Then the Internet showed up and all processing, not just data base access, was moved to the server while clients perform interface rendering, user input, and communications with remote servers. Turns out the Internet thing was a major success and technological improvement. So when people tout technologies that move processing from the server to the client, they are trying to turn back time. Today's computers and communications links are so unbelievably fast that everything is instantaneous unless you intentionally write slow implementations.
The argument that react is better if you have multiple pages is only valid for the first time the user loads the page.. beyond that, browser caching does hella good work. Browser can't cache dynamically loaded DOM elements from frameworks like react.
I also don't like that it's owned by facebook. Makes it kinda feel less pure. But that doesn't work as a justification for not using such a powerful tool. I just started learning React in school and you can be damn sure I'm going to be using it to make some sic projects.
Another note, no, static html does not have this finite boundary when it starts getting more expensive (especially in the case of React). Because with each request made through a JS framework, you are also adding a cost for that new data. Also, and this is kind of surprising to me that he didn't think about this; browsers does caching. If each static webpage hold images etc, some of the images will be cached, whereas in JS frameworks this is rarely the case (it can be, but i'd be surprised if people actually gave a sh*t about this, since a lot of Javascript "software" is so bad), because unless you actually programmatically code caching features so you don't ask for data you have already downloaded once you are now downloading things multiple times, because the data that is requested through a javascript framework is basically just binary data, the web browser has no idea what data is coming through essentially - the webbrowser although they are far more intelligent than they were back in the day, will have a much harder time figuring out if something is new or something which has already been displayed.
Hello Ben, I am a middle aged programmer working at a big consultancy company in Europe. I have mainly been doing SQL Server procedures for the last 20 years, but I like to learn new things and your videos really helped get me going with modern tools like JavaScript. I am now using something called Angular almost every day, and I've produced new functionality multiple times within a single year. Its really good, you should check it out. I think its a bit newer than what you talk about here but just like me you shoudnt be afraid to try it out.
Hey Ben I understand how to use full stack technologies to develop an application but could you do a tutorial on architecture? Like for example if I wanted to create a SaaS of my own, my next step would probably to do a pre-release and let a decent amount of users try it out for me and provide feedback. Obviously, if I'm going to allow 5k or 10k users to use my app out the gates I'd need some infrastructure to accommodate that. How do I select a database with scale? Should I use a full backend or cloud functions to limit my cost? How do I configure environment variables for CORS and whatnot across multiple deployments? Should I use a storage bucket or save files to my backend server's file system? How do I take Docker outside the scope of development into production? I'm just really confused if you could clarify these things.
Vanilla JavaScript gives great performance on modern engines. Moreover, use getelementbyid instead of queryselector, and insert complete DOMnodes in their intended order without unnecessary post-insert setattributes, if possible, and watch the performance go through the roof. The user has loaded the page, rerendered it to a new context and opened a couple of menus before the functionally-equivalent react version would even be available for interaction.
There was one valid argument in this entire document and you skipped it. It‘s not saying, that react is slower than regular JS (well actually it‘s implied, but yeah) it‘s comparing it to other frameworks like vue and angular. And react is much slower than those two.
Smaller bundle-size, but slower. Idk, it's not like the majority of your bundle is React itself. Tree-shaking and choosing dependencies smarter would go way further and preserve performance
Just a side note: React didn't invent SPAs. SPAs were born the very same day that element.style.display = "none" and XMLHttpRequest met on the same page, years before React was even a thing.
I think there is a point that nobody had made but that to me is an important reason to not use React or other JS framework: historical preservation. Nowadays thanks to sites like archive.org a lot of websites of the past that for reason are no longer online are still accessible. Trough that we can access information that have historical value, like what libraries does conserving old newspapers. With React or any other JS framework that would be impossible. They would need to render each pages in a browser and save the resulting HTML, but that operation would be too expensive.
Good video! Been watching a lot of you work and especially enjoyed the 18 hour full stack tutorial. Please do a video comparing React to Preact. Much smaller, practically the same feature set, and there are tools to build out already existing React code into Preact code with minimal code changes at the root of the project. I use it as a library for building React components which are injected already existing sites (which may or may not already be running a SPA framework) and it seems like a suitable, lighter alternative.
Use what makes sense. If it's a one page static site then don't use react (or any JavaScript Framework) if you are creating a large dynamic site then use what you need to get it done
a web site that was ONLY plain old HTML would be the most efficient on road warrior clients because road warrior clients cache all static content but if you try to build an interactive or multi page experience without a framework that worked seamlessly on a bunch of different engines for a bunch of different browsers in “just” JS, I doubt end users would be super happy with that either also, the bandwidth usage of all web browsing is COMPLETELY incomparable to multimedia streaming and all those applications that actually take bandwidth, and cutting down on those is a lot easier for an end user to do than it is for a web developer to swap frameworks
I want to cry with happiness when you post I hate posting this since i made it 421 now :( But the support comment is needed I was comment 420 cause i am your most baked fan ! Thanks for all the good content dude
Browsers cache images and other resources. just using a plain HTML / CSS site will be less data for modern browsers. This is just soydev's on copium when they talk about react being less data hungry for page navigation, compared to static pages. If you're wanting to use react but still wish to be mobile friendly, I'd recommend preact. Most features in react are just nice and are just bloat. This is just basic react, enough to build any web app.
React is the only major framework that doesn't support creating or consuming custom elements / web components or encapsulated styles or slots.. both Angular and Vue support that. Does react really make things easier? no, Higher order functions, passing components as props aren't easy concepts and bloats the DOM and makes debugging or optimising re-renders more difficult, same with hooks,, and developers abuse it all the time. Easy would be VueJS, no weird patterns to learn, other libraries simply come with better defaults, So he's not wrong to say that react goes against web standards.. Also you don't just load react, you load react, react-router, redux, compose, reselect, styled-components, some form library, axios, etc.. So despite "react" being marketed as only a component library, a react application size is not much different than that of an angular one, since angular ships with its own libraries for these.
Has anyone tried the new Tortoise-Shell library? It has an integrated terminal and CLI for nodeJS so just wondering if it's worth the look. Heard it is a great replacement for React and Vue
Hi! A certified Mobile Web Specialist here. Use service workers and right cache policy and you'll not even be loading HTML/CSS/JS again and again on different page loads. People are confused between PWAs and SPA frameworks. Both technologies can also work together to make sure these resources are downloaded only once and re-downloaded only when changed.
I still use react but I'm excitedly waiting for svelte to become the giant with the largest community. the compilation speed and the size of the bundles are satisfactory AF. Please make more videos of svelte so that the community continues to grow.
I think that's where everyone should be. I think Svelte is peak web development; It just sucks that because of the JS fatigue phenomenom, everybody decided to give up already and they just HAD to settle for React when there are so many better alternatives out there
@Ben Awad, Your points: 1. Why compare React to JS? Compare it to Vue which seems to be x2 faster. 2. You should compare it to Vue or Preact. I don't know the answer. Preact is a really small library truth to be told. When Svelte content is coming?
Looking at the size issues, I don't even think this is a problem to be solved on this layer, it's the transmission layer, HTTP which is very wasteful, we wouldn't have to care as much about bundle sizes if more browsers adopt IPFS instead.
Ben please make a detail roadmap how to become a full stack MERN + graphql + apollo + typescript developer. What area should I focus more and what to learn first. I try to do CSS, REACT, NODE all at a same time and it's seems to be counterproductive for me.
1) The first point the article made is that React is not only slower compared with vanilla js but also compared to other frameworks. 2) You will usually use less data visiting a website that does not use a framework because frameworks are bloated. Navigating between the pages will not require redownloading pages every time because the browser caches the page. 3) Users are very impatient and will usually leave quickly if it takes a long time to load. I agree that it can actually be a nicer experience to load once and then navigate smoothly without any further requests, however most users are not aware of this trade off, and will just get annoyed and leave if the page does not load fast enough. 4) You are right, this is not an argument. 5) If we will stop using the products of every company we don't like, we are probably going to be in a serious bind. However, a small group of companies yielding such great power it a terrible idea, and I do believe we should try and use alternative products if it is feasible. So if we can use an independent framework it will be better. By the way I use React, so i am not hating on it, but we should always keep an open mind and maybe check for better alternatives if they arise.
Articles like this only exist because we have a lot of new developers who don’t know vanilla JavaScript and only know how to build websites in X framework or library. Bootcamps are notorious for producing React developers and not JavaScript developers.
Tbh I learned vanilla JS for a whole year. Now I'm only focusing on react and I'm already forgetting basic JS syntax lol. People who go right to react r insane and wont last imho
@@BobbyBundlez LOL people who jump straight to React will absolutely last, vanilla javascript is very easy to switch back to, at least in terms of syntax.
literally any modern website/app has large bundle sizes, yeah, for blogs it can be overkill if you really think thousands of people with slow connections are relying on your blog loading in a few seconds.
I usually go another way: react mixes up styling, structure and behavior into a single JSX file. That speeds up prototyping and encourages coupling - something software engineers had headaches and learned to hate. The most expensive part of a successful software isn't get it up and running, but maintaining it over the time.
Exactly! I hate that React couples all of this because of their "Everything in JS" mentality; on the other hand I hate File Hell too, which leads me to the point that I think Vue got it right: use Single File Components where you use , and tags, resembling more traditional web development.
In terms of what's expensive, users with limited internet are mainly limited by streaming of videos and audio, not so much loading regular pages, which is a drop in the bucket, with or without React.
My point was kind of the same about point 4 that they never heard about code splitting I guess this point is kind of related to the point 2 that he maid. Anyway never quite understand why people make such comments like that without having enough research. It seems to me that he just used React at the title to get more views rather than talking about the javascript framework in general.
Kinda weird to say that people shouldn't use react cuz it's sponsored by Facebook. Does the person that wrote the article not using google or bing cuz Google and MS did some shady things?
Great video, Ben. React has tradeoffs. Whether those tradeoffs are a turnoff depends on the individual. To me: Github loading one second for each page > waiting 10 seconds on initial page load. That preference is subjective. The obvious answer to "HTML can be slow too!" is to cache HTML server-side + with service workers. HTML and JavaScript can both be cached with a service worker, but only one needs to be compiled and interpreted. Cached HTML does not give rise to the interactivity issues of server-side rendering, so the performance of the two should not be compared. Let's do some dead simple math on the HTML-being-expensive-as-JavaScript concept. The HTTP Archive found the median sum of transferred KB of all HTML documents requested by a tested page was 24.7 KB from October 15, 2016 to Aug 1, 2020. The HTTP Archive found the median sum of transferred KB of all external scripts requested by a tested page was 424.4 KB of JS for a single page.) I suggested in point 3 of the article that one should use Preact instead of React to address the issues raised in the article. If you simply use React because you enjoy the developer experience, use Preact instead. Sapper (Svelte) + htm = other good alternatives for people who hate vanilla JS. Thank you for reading :-)
For me every framework is like tool and you need to think what are you building first to decide what you will use. I tried Svelte it looks really good looking forward for your video about it :P
Every tools have their own purpose. Here's good fit based on my experience: Vanilla JS: Only use this to create classic documentation, unless you're chuck norris ReactJS: Good for complex app with a lot of components. You don't have to handle CSS and multiple HTML especially with react-material. VueJS: Need to handle CSS and HTML better? Use this instead. Laravel Blade (or other templating): Good use for lightweight multiple pages. Especially shopping site. AngularJS: Good for... I dunno, my head overheating everytime I learn Angular. Google use this by the way. Hope it helps, cheers!
I imagine being a react dev. Looking at a git repo which looks different every time. No rhyme or reason just a bunch of UNDOCUMENTED decisions. I mean you react devs never document anything you do. You pick libs and patterns out of thin air expecting the world to follow them. It would be cute if it weren't so sad.
Regarding the size, when you use a SPA, you can also cache allot more of the application compared to a multi page application (service workers, other caching types). Therefore, if you revisit the website multiple times, the benefit of using cached SPA will hugely outweigh the downsides. PS: This is not only for React, any SPA applications will benefit from it (Angular, Vue, etc).
If you're just going back and forth between pages i would assume the browser will cache them and just download the new ones. so it will be just 20kb per new page. So it will still be cheaper right?
Almost every website is different from the original intent of the web. HTTP is a document transfer protocol that just so happened to evolve into an application delivery system. I don't really see the validity of the argument that the web should be full of static html, just look at all of the top websites on the internet, such as this one. The web is constantly evolving and so should we. Having said that, of course you should limit the amount downloaded by the user and only use the libraries and frameworks that you need. If you have a large code base, then you can justify using react to help keep the code clean and to keep your sanity.
Hello Ben, I stumbled upon this video by accident (no a React guy or whatnot). I just wanted to ask this question: what is that other mic doing in the background? Much love
I live in a 2nd world country, unlimited 4G cost about the equivalent of 35-40 us$, in 5 years everyone will have unlimited or close to unlimited mobile data, so i dont think you should focus on data usage that much.
Of course, you don't want to download the whole database upfront so decoupling is so much important. Sites use databases in various ways so this matters contextually.
totally agree with you mate. i cannot understand people that says "hey, we should pick this framework because the bundles are 150k smaller". that's stupidity at its finest. we have faster internet connections everyday. nowdays a bundle of 5 MB can be downloaded in less than half a second. stop crying about bundle sizes, for god sake.
If we really want to make the data argument, navigate to literally any blog or news site and open your network tab and watch your requests blow the hell up with ad requests, css files, cdn requests, third party requests, etc. Javascript is the least of my concern for large data transfers.
Here's my take: 1. React is slow Javascript is an interpreted language, so any javascript will be slow 2. React is expensive The ads and trackers use way more bandwidth than the handful of kilobytes of javascript delivered to your browser 3. React is inaccessible
Haha great video. I was wondering about the 2G argument, in our country they gonna soon shutoff 3G soon. In most of the countries 2G is off anyway. You should actually stop using "high resolution streaming platforms" like youtube because there could be someone watching your video with a limited connection. And as always for any framework or language, you only go down the rabbit hole only if its neccessary. If you use plain javascript or c / c++ for the sake of native execution speed, thats not the best choice. In a real world project you need to take into account way more than pure execution speed. Like time to market, maintanance, availability of skilled poeple, existing opensource projects you depend on, etc. etc. So thanks again for the high resolution video :D
The "new" Facebook is built with React, Relay & GraphQL. If React is "small", "fast" and "inexpensive" enough for an enterprise app like Facebook, no one on earth should have issues with it from a performance perspective. If you're building the kind of app where React would cause headaches, you'd simply not use it to begin with and skip writing an article about it.
Ctrl C + Ctrl V 1. React is slow 2. React is expensive 3. React is inaccessible 4. React goes against what the web was made for 5. React is made by Facebook
I dont want to see go completely away, but Im tired of using websites misusing it! If your site is mostly text and images you don't need an expensive javascript framwork. These fancey animations aren't worth it!
i come from game dev and was peeking on UI dev every once in a while and I truly feel react is bringing the most positive innovations on the field, i prob won't ever use it (personally favor ssr and plain html / js) but i'll prob learn every big update
This article is a great example of black and white thinking: something is either good or bad, there's no in-between - which is almost never the case, because reality is nuanced. You should let _context_ guide your decisions when choosing dev tools for your projects. Quote: _“Do you think some users are more important than others? Do you care about reaching all users or only the wealthy ones?”_ Eh, almost every company in the world cares more about reaching and pleasing their primary target demographic than anyone else, it’s called prioritising. Ideally, you make everyone happy, but that’s close to impossible in practice. There’s always a trade-off when you pick your tools, and you gotta weigh the pros against the cons. If you’re building a website that is meant for a 3rd world country with 2G Internet and Windows XP, then your first thought probably shouldn't be “hey lets install a bunch of npm modules” Context is key 👈
I like Vue, *but* I have experience on React, it is great and confusing, *but* it's great for development due to the last dev community and not to say the large number of options coming with react( even though most of them are community supported), and lastly react native. If you are a web development who just wanna build an app React Native crushes it. Yes, it is far from native ( and flutter) but it gets the job done.
The author prefer to write in HTML, and does not have a clear understanding on why SPAs exists. He forgot to generalize that is the case for all leading SPAs and JS Libraries Quote ender minyard  Sep 15  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.
![FizzBuzz - You Suck at Coding [0]](http://i.ytimg.com/vi/mZWsyUKwTbg/mqdefault.jpg)
I used to have a 2G connection.
In my experience React is better than the usual because I'd rather wait once for a long time rather than waiting for like a minute for each page
Me, a venezuelan, can relate.
god I read this title as "you should stop using react" and had a heart attack
click bait
Vizman216 fake news
I guess some angular developers said yeah!!,I knew it XD
Maybe the title is missing a question mark?
+1, since I just learned it
TLDR: no, dont stop using react.
@Vizman216 what's your recommendation, professor?
@@johnyepthomi892 there's a framework by the most specialized company on the web, Google. I believe it's called Angular or something.
@@Amaraticando need more than that! Justify with more details react Vs angular
@@Amaraticando That no one likes to use.
@@alimertcakar1894 I like to use Angular :/ (not trashtalking about react anyway)
but what if I am an ex Facebook ex Google ex wife ex millionaire should I use React
swyx Ex technical lead?
swyx no you should use python 2 and php 5 😂
@Vizman216 # ha ha ha ha ..... Good reply............
Better watch techlead
@Vizman216 lmao nice one
Stop reacting to "Stop using React"
I like the reactions. They are fun to read/watch. I also like to see how people process my writing.
Should you stop reacting to "Stop reacting to 'Stop using React'"
@@mgjulesdev there is no need to react to Should you stop reacting to "Stop reacting to 'Stop using react'"
What are you doing here Usman 😂
@@buka.a 😂 I'm everywhere
Blog post: stop using react.
The entire react community: So you have chosen DEATH.
😂🤣
look who I found here?
No. We have chosen svelte
@@lsagar :p
lol
Pls make a video on this new library called "Angular"
😄
This Ben guy seems like he'll love Angular
😋
Angular is a framework bro
Angular was released in 2010. It's 2020 dude
It just doesn’t matter. For those of you who are new, you’ll see this over and over again. Somebody at company xyz says something is bad.
Ignore it, the knowledge you gain is what’s important. When you learn React, you learn about HTML, CSS, JavaScript as a language, how to make API calls, you can easily pick up Node, etc.
If you have this base knowledge, it does not matter where you start or who says to use or not use something. It matters that you understand the concepts.
This article barely has a real-world applicable point. The 2g thing is laughable
Agreed, like unless your user base is in Antarctica lol.
It loads forever on my 20 year old flip phone tho...
@@azenics Then its your problem, not mine.
You always have to make the general case faster no matter what.
In big parts of gerrmany there's only 2G, but yeah I get what you mean
"Should you stop using React?"
"Oh...so...Angular then??"
"No...wait, that's not what I.."
"npm install -g @angular/cli"
"No Don't! That's even worse than Rea..."
"ng new super-hardcore-javascript-bloated-app"
"STOP! THINK ABOUT THE 2G!"
"cd super-hardcore-javascript-bloated-app
ng serve"
Those points against React are the least of the concerns. I'm old enough to remember the development community moving in the direction of separation of concerns. React not only goes against this idea but it bloats it with JSX and CSS in the ugliest manner possible. People would laugh at legacy ASP because of this and now it's the greatest thing since sliced bread. The worst of all is how React handles State. It's too long to explain in a post but being a developer for 25+ years, the first time I saw React, I almost threw up in my mouth. It sounds like the dev team said let's get HTML modularized BY ANY MEANS NECESSARY. even though your code turns in spaghetti and unreadable not to mention sprinkles of array mapping, reducing and passing event up the component chain. Nothing but a mess.
Ben: "I don't do homework anymore"
Narrator: *He's lying*
Uso de aru!!
Using your 500kb + 10kp/page vs 20kb/page example the threshold is 50 pages.
QUICK MATH
I love React, and enjoy programming in it. One of my recent projects (a Covid-19 tracker I built in React JS) helped me get hired at a medical university as a web developer, so it’s still worth working in, especially if you enjoy it. I have a number of personal projects I run in Django/React and I just enjoy the actual programming as well as using the apps themselves
Do you use Django with react or Django REST API and just react to serve stuff
@@Ahmadavocado Originally I was using Django to serve everything, but about 2 years ago I duplicated most of the functions through REST API, and since Covid-19, completely moved everything over to REST. My blog (a whole CMS I made from scratch) used to be served frontend and backend by Django, but now it’s all REST with a React front end. The Covid-19 app, however, is just a React JS file being served on a blank template HTML file, since it doesn’t use any databases. But I MUCH prefer React/Django, right now I’m working on a video game engine that moves all the enemy/map/audio/character data to components that communicate with the REST server, so the “game” is javascript while the data is REST. It’s so much more powerful that way.
@@JasonBoyce that’s nice to hear! My first project was a custom blog using Django as well haha. It was a totally newbie project but it got me started with Django and some JS basics to handle AJAX. The css was pretty bad and it lacked interactivity but it really made me fall in love with Django!
Been pretty busy with school lately but I’m planning to learn react during the sem break and create more interesting projects soon.
@@Ahmadavocado Django is amazing, and there’s so much that can be done with it once you really start digging in. Especially if you switch to REST/React, because then CSS/JS etc all get freed up to run elsewhere, and you don’t need to mix your code bases. I worked on one project a few years ago that took every street tree in San Francisco (trees planted in sidewalks) , about 130,000 of them, and then built a frontend that you could use to figure out which trees were planted where, which ones were in the best conditions, you could select a GPS location and it would rank all the trees around your location, my coworkers would use it to skateboard around neighborhoods and mark sites where they would come back to plant trees later (they LOVED using the app on the phone while they skated), and the City used it when they met with neighborhood groups to talk about where they wanted to target their planting and the benefits it would give. INCREDIBLY useful project, that was ALL Django (frontend, css, js as well), and I would feel much more comfortable with that data in Django & Python than I would in Node or some other server
@@JasonBoyce That sounds amazing, and very practical, I'm inspired! Maybe I could work on something similar in my country haha. Can't wait to learn and progress to your level and beyond. Thanks for your help!
React can do no wrong. React can give me a black eye and I'd still tell the doctor I fell down the stairs.
Yes for svelte. And sapper.
Svelte eased me into framework world. I'm in no way experienced enough to give the pros and cons or it's nuances. But as a newbie I can appreciate the elegance of svelte. It somehow feels joyful writing svelte and kinda feels like a very meaningful extension to HTML, CSS and JS.
I hope more youtubers try and shed some light on this lovely framework and not let it die out.
And sapper too, it needs some love so bad. 😅
Any cues over why I would prefer Svelte over Vue? (other than any performance benefits if any - it barely applies in current world with ever increasing hardware computational potential in years to come)
@@krozaine I'm new to coding in general.
So other experienced developers can probably answer your question better than me.
The only thing I can say is, it feels intuitive. Especially for someone coming straight from HTML, CSS and JS. It's very subjective, I know. But that's all I can give you.
If you can find some time do give svelte a try.
Just jump in and find out if it makes sense for you. That's the best way to know. It's not a huge cognitive load.
Matheus I have no idea where you get ‘jerk’ from. Rich has developed a lot of phenomenal tools for Frontend dev. The list of Svelte contributors is rather large, the community is working hard to mature the environment. I’ve had nothing but great experiences with Rich. Super humble and he is really self deprecating. Also has a pretty dry British sense of humour.
+1 for happiness
Matheus what do you mean a jerk? Even though I’ve not met him in person but his contributions and talks pretty much says he is an intellectual and very humble person.
I'm so excited for your Svelte content!
Vue: *released 3.0*
Ben Awad:
what project should I make with Vue 3?
@@bawad do an online judge. Because why not?
@@bawad build the youtube!
@@bawad I personally want to try migrating your reddit clone tutorial over to vue 3, once I'm finished with the next.js tutorial. Maybe I'll use it with Nuxt.js
A poll to see what project you should make in vue3
BEN give the people what they need
static HTML vs React SPA mathematics reveal at 200K subs!!
It's just a simple system of equations
Oh hey, it's you!
Great video! Which Mic do you use?
I’m loving svelte and migrated my projects from react to svelte. Was so fun
Did it improve your perfomance and if so, then how much?
Svelte bundle with large projects works?
Good luck with job market?
@@lubeckable Not everyone is an unemployed web developer
@@Comphonia Maybe the person just migrated some small personal projects that he has for fun, not necessarily an app that is a business? This is definitely ok if you want to experiment and just see what is new in JS frameworks land.
I also think that Svelte looks promising, but I'm not sure how it scales because I didn't actually use it to create anything more meaningful.
Why do you prefer TSX (in React) over HTML templating (in Vue)?
Because it's better. (As a person who started with Vue)
@Vizman216 I started off with Vue as well, but JSX/TSX looks way cleaner and more intuitive. I spend 6 months learning Vue, but React is drawing me in.
Tryna get some advice from the god of React @benawad.
Well, autocomplete is better. Although there is an experimental feature you could turn on in vetur vscode extention that makes vue templating almost as good as tsx.
Comparing react to vue with python to c does not make sense. Python gives frameworks c does not, but vue gives a lot more than react and handles a lot more itself, and I think the article would make a stronger argument if it was comparing react to vue rather than react to html ot vanila js in general. React is somewhat built in progress which makes it prone to complexity and performance issues like state management (redux) which was made later on, however vue on the other hand comes with vuex out of the box and handles everything for you and dont get me start on css in jsx.
Also it was very interesting that react was slower as I always thought it was faster which was the only reason I could have thought people would use it 😅, but for vue to be that much faster was something else 🤣
Yes Svelte content, I am excited. I'm building a personal project with Sapper, Apollo Client & Postgraphile and things are going very well.
Wait a min this isnt techlead
Hahaha
Article might be written by techlead
techlead video would have been just over 10 minutes long. That's how you know it's not techlead.
@@jamespowers1382 Also, Ben didn't mention he is an ex-Google ex-Facebook ex-husband ex-millionaire
he looks like techlead. hahaha...
Used to be we wrote heavy applications that ran on computer networks. The best example being Windows applications running on PCs. To improve performance client server databases were implemented to move some of the processing from the client PC to the network server. Then the Internet showed up and all processing, not just data base access, was moved to the server while clients perform interface rendering, user input, and communications with remote servers. Turns out the Internet thing was a major success and technological improvement. So when people tout technologies that move processing from the server to the client, they are trying to turn back time. Today's computers and communications links are so unbelievably fast that everything is instantaneous unless you intentionally write slow implementations.
The argument that react is better if you have multiple pages is only valid for the first time the user loads the page.. beyond that, browser caching does hella good work. Browser can't cache dynamically loaded DOM elements from frameworks like react.
I also don't like that it's owned by facebook. Makes it kinda feel less pure. But that doesn't work as a justification for not using such a powerful tool. I just started learning React in school and you can be damn sure I'm going to be using it to make some sic projects.
Another note, no, static html does not have this finite boundary when it starts getting more expensive (especially in the case of React). Because with each request made through a JS framework, you are also adding a cost for that new data. Also, and this is kind of surprising to me that he didn't think about this; browsers does caching. If each static webpage hold images etc, some of the images will be cached, whereas in JS frameworks this is rarely the case (it can be, but i'd be surprised if people actually gave a sh*t about this, since a lot of Javascript "software" is so bad), because unless you actually programmatically code caching features so you don't ask for data you have already downloaded once you are now downloading things multiple times, because the data that is requested through a javascript framework is basically just binary data, the web browser has no idea what data is coming through essentially - the webbrowser although they are far more intelligent than they were back in the day, will have a much harder time figuring out if something is new or something which has already been displayed.
Hello Ben,
I am a middle aged programmer working at a big consultancy company in Europe. I have mainly been doing SQL Server procedures for the last 20 years, but I like to learn new things and your videos really helped get me going with modern tools like JavaScript. I am now using something called Angular almost every day, and I've produced new functionality multiple times within a single year. Its really good, you should check it out. I think its a bit newer than what you talk about here but just like me you shoudnt be afraid to try it out.
Hey Ben I understand how to use full stack technologies to develop an application but could you do a tutorial on architecture?
Like for example if I wanted to create a SaaS of my own, my next step would probably to do a pre-release and let a decent amount of users try it out for me and provide feedback. Obviously, if I'm going to allow 5k or 10k users to use my app out the gates I'd need some infrastructure to accommodate that. How do I select a database with scale? Should I use a full backend or cloud functions to limit my cost? How do I configure environment variables for CORS and whatnot across multiple deployments? Should I use a storage bucket or save files to my backend server's file system? How do I take Docker outside the scope of development into production? I'm just really confused if you could clarify these things.
Vanilla JavaScript gives great performance on modern engines. Moreover, use getelementbyid instead of queryselector, and insert complete DOMnodes in their intended order without unnecessary post-insert setattributes, if possible, and watch the performance go through the roof. The user has loaded the page, rerendered it to a new context and opened a couple of menus before the functionally-equivalent react version would even be available for interaction.
There was one valid argument in this entire document and you skipped it. It‘s not saying, that react is slower than regular JS (well actually it‘s implied, but yeah) it‘s comparing it to other frameworks like vue and angular. And react is much slower than those two.
What are your thoughts about preact?
Smaller bundle-size, but slower. Idk, it's not like the majority of your bundle is React itself. Tree-shaking and choosing dependencies smarter would go way further and preserve performance
1:59
that is not something react specific, you can do that with plain js.
just give the button an onclick event that does whatever you want.
Just a side note: React didn't invent SPAs. SPAs were born the very same day that element.style.display = "none" and XMLHttpRequest met on the same page, years before React was even a thing.
Alias React with Preact, problem solved. 5kb instead of 90+kb
This should be at top
cannot read property h of undefined.
I suggested in point 3 of the article that one should use Preact instead of React.
Where did you take your 90kB from? Also, Preact is slower. It's better to cut your bundle from elsewhere (such as non-ES libs)
I think there is a point that nobody had made but that to me is an important reason to not use React or other JS framework: historical preservation.
Nowadays thanks to sites like archive.org a lot of websites of the past that for reason are no longer online are still accessible. Trough that we can access information that have historical value, like what libraries does conserving old newspapers.
With React or any other JS framework that would be impossible. They would need to render each pages in a browser and save the resulting HTML, but that operation would be too expensive.
Good video! Been watching a lot of you work and especially enjoyed the 18 hour full stack tutorial.
Please do a video comparing React to Preact. Much smaller, practically the same feature set, and there are tools to build out already existing React code into Preact code with minimal code changes at the root of the project. I use it as a library for building React components which are injected already existing sites (which may or may not already be running a SPA framework) and it seems like a suitable, lighter alternative.
I am afraid to watch this video as I am learning react.
did you learn
You missed the "?"
Use what makes sense. If it's a one page static site then don't use react (or any JavaScript Framework) if you are creating a large dynamic site then use what you need to get it done
a web site that was ONLY plain old HTML would be the most efficient on road warrior clients because road warrior clients cache all static content
but if you try to build an interactive or multi page experience without a framework that worked seamlessly on a bunch of different engines for a bunch of different browsers in “just” JS, I doubt end users would be super happy with that either
also, the bandwidth usage of all web browsing is COMPLETELY incomparable to multimedia streaming and all those applications that actually take bandwidth, and cutting down on those is a lot easier for an end user to do than it is for a web developer to swap frameworks
OMG, I'm waiting for Svelte content!
I want to cry with happiness when you post
I hate posting this since i made it 421 now :(
But the support comment is needed
I was comment 420 cause i am your most baked fan !
Thanks for all the good content dude
3:25 that specific example woul use...... 48 page loads to break even.
Awesome videos, I don't get quite a bit of it but I'm getting there.
Browsers cache images and other resources. just using a plain HTML / CSS site will be less data for modern browsers. This is just soydev's on copium when they talk about react being less data hungry for page navigation, compared to static pages.
If you're wanting to use react but still wish to be mobile friendly, I'd recommend preact. Most features in react are just nice and are just bloat. This is just basic react, enough to build any web app.
React is the only major framework that doesn't support creating or consuming custom elements / web components or encapsulated styles or slots.. both Angular and Vue support that. Does react really make things easier? no, Higher order functions, passing components as props aren't easy concepts and bloats the DOM and makes debugging or optimising re-renders more difficult, same with hooks,, and developers abuse it all the time. Easy would be VueJS, no weird patterns to learn, other libraries simply come with better defaults, So he's not wrong to say that react goes against web standards..
Also you don't just load react, you load react, react-router, redux, compose, reselect, styled-components, some form library, axios, etc.. So despite "react" being marketed as only a component library, a react application size is not much different than that of an angular one, since angular ships with its own libraries for these.
Has anyone tried the new Tortoise-Shell library? It has an integrated terminal and CLI for nodeJS so just wondering if it's worth the look. Heard it is a great replacement for React and Vue
Hi! A certified Mobile Web Specialist here. Use service workers and right cache policy and you'll not even be loading HTML/CSS/JS again and again on different page loads.
People are confused between PWAs and SPA frameworks. Both technologies can also work together to make sure these resources are downloaded only once and re-downloaded only when changed.
I still use react but I'm excitedly waiting for svelte to become the giant with the largest community. the compilation speed and the size of the bundles are satisfactory AF.
Please make more videos of svelte so that the community continues to grow.
I think that's where everyone should be. I think Svelte is peak web development; It just sucks that because of the JS fatigue phenomenom, everybody decided to give up already and they just HAD to settle for React when there are so many better alternatives out there
No yet :c
15:52 caching exists... if done correctly it can prevent loading much data which will lead it to only having to download text which is not very large.
@Ben Awad, Your points:
1. Why compare React to JS? Compare it to Vue which seems to be x2 faster.
2. You should compare it to Vue or Preact. I don't know the answer. Preact is a really small library truth to be told.
When Svelte content is coming?
Looking at the size issues, I don't even think this is a problem to be solved on this layer, it's the transmission layer, HTTP which is very wasteful, we wouldn't have to care as much about bundle sizes if more browsers adopt IPFS instead.
Dude I love your videos. I've been in software development since 2001.
If you are so intrigued by svelte why not consider taking a look at preact? That would make a great video!
Ben please make a detail roadmap how to become a full stack MERN + graphql + apollo + typescript developer. What area should I focus more and what to learn first. I try to do CSS, REACT, NODE all at a same time and it's seems to be counterproductive for me.
1) The first point the article made is that React is not only slower compared with vanilla js but also compared to other frameworks.
2) You will usually use less data visiting a website that does not use a framework because frameworks are bloated. Navigating between the pages will not require redownloading pages every time because the browser caches the page.
3) Users are very impatient and will usually leave quickly if it takes a long time to load. I agree that it can actually be a nicer experience to load once and then navigate smoothly without any further requests, however most users are not aware of this trade off, and will just get annoyed and leave if the page does not load fast enough.
4) You are right, this is not an argument.
5) If we will stop using the products of every company we don't like, we are probably going to be in a serious bind.
However, a small group of companies yielding such great power it a terrible idea, and I do believe we should try and use alternative products if it is feasible. So if we can use an independent framework it will be better.
By the way I use React, so i am not hating on it, but we should always keep an open mind and maybe check for better alternatives if they arise.
"Everything is just a tradeoff" --- Soul of React
It's what a CSS teacher told me.
Articles like this only exist because we have a lot of new developers who don’t know vanilla JavaScript and only know how to build websites in X framework or library. Bootcamps are notorious for producing React developers and not JavaScript developers.
I wonder what the guy who literally only knows React will say.
Tbh I learned vanilla JS for a whole year. Now I'm only focusing on react and I'm already forgetting basic JS syntax lol. People who go right to react r insane and wont last imho
Start underReacting.
@@BobbyBundlez LOL people who jump straight to React will absolutely last, vanilla javascript is very easy to switch back to, at least in terms of syntax.
literally any modern website/app has large bundle sizes, yeah, for blogs it can be overkill if you really think thousands of people with slow connections are relying on your blog loading in a few seconds.
I usually go another way: react mixes up styling, structure and behavior into a single JSX file. That speeds up prototyping and encourages coupling - something software engineers had headaches and learned to hate. The most expensive part of a successful software isn't get it up and running, but maintaining it over the time.
Exactly! I hate that React couples all of this because of their "Everything in JS" mentality; on the other hand I hate File Hell too, which leads me to the point that I think Vue got it right: use Single File Components where you use , and tags, resembling more traditional web development.
Okay Ben you have to start using a noise cancellation app. KrispAi is a good choice. Please the bg noise in ur videos is pretty annoying.
you can have a website with server side rendering that actually loads in milliseconds.
Now svelte finally came into the scene... that's what I love.
In terms of what's expensive, users with limited internet are mainly limited by streaming of videos and audio, not so much loading regular pages, which is a drop in the bucket, with or without React.
My point was kind of the same about point 4 that they never heard about code splitting I guess this point is kind of related to the point 2 that he maid. Anyway never quite understand why people make such comments like that without having enough research. It seems to me that he just used React at the title to get more views rather than talking about the javascript framework in general.
Kinda weird to say that people shouldn't use react cuz it's sponsored by Facebook. Does the person that wrote the article not using google or bing cuz Google and MS did some shady things?
Great video, Ben.
React has tradeoffs. Whether those tradeoffs are a turnoff depends on the individual.
To me: Github loading one second for each page > waiting 10 seconds on initial page load. That preference is subjective.
The obvious answer to "HTML can be slow too!" is to cache HTML server-side + with service workers. HTML and JavaScript can both be cached with a service worker, but only one needs to be compiled and interpreted. Cached HTML does not give rise to the interactivity issues of server-side rendering, so the performance of the two should not be compared.
Let's do some dead simple math on the HTML-being-expensive-as-JavaScript concept.
The HTTP Archive found the median sum of transferred KB of all HTML documents requested by a tested page was 24.7 KB from October 15, 2016 to Aug 1, 2020. The HTTP Archive found the median sum of transferred KB of all external scripts requested by a tested page was
424.4 KB of JS for a single page.)
I suggested in point 3 of the article that one should use Preact instead of React to address the issues raised in the article. If you simply use React because you enjoy the developer experience, use Preact instead. Sapper (Svelte) + htm = other good alternatives for people who hate vanilla JS.
Thank you for reading :-)
For me every framework is like tool and you need to think what are you building first to decide what you will use. I tried Svelte it looks really good looking forward for your video about it :P
Can't wait for the Svelte content!
Every tools have their own purpose. Here's good fit based on my experience:
Vanilla JS:
Only use this to create classic documentation, unless you're chuck norris
ReactJS:
Good for complex app with a lot of components. You don't have to handle CSS and multiple HTML especially with react-material.
VueJS:
Need to handle CSS and HTML better? Use this instead.
Laravel Blade (or other templating):
Good use for lightweight multiple pages. Especially shopping site.
AngularJS:
Good for... I dunno, my head overheating everytime I learn Angular. Google use this by the way.
Hope it helps, cheers!
I was waiting for this. I almost doubted learning for a second. Imagine being an Angular developer lmao
:(
I imagine being a react dev. Looking at a git repo which looks different every time. No rhyme or reason just a bunch of UNDOCUMENTED decisions. I mean you react devs never document anything you do. You pick libs and patterns out of thin air expecting the world to follow them. It would be cute if it weren't so sad.
Regarding the size, when you use a SPA, you can also cache allot more of the application compared to a multi page application (service workers, other caching types). Therefore, if you revisit the website multiple times, the benefit of using cached SPA will hugely outweigh the downsides. PS: This is not only for React, any SPA applications will benefit from it (Angular, Vue, etc).
the entire process of loading a standard html page is cached. Going to a bunch of pages won't take longer on standard sites.
If you're just going back and forth between pages i would assume the browser will cache them and just download the new ones. so it will be just 20kb per new page.
So it will still be cheaper right?
Almost every website is different from the original intent of the web. HTTP is a document transfer protocol that just so happened to evolve into an application delivery system. I don't really see the validity of the argument that the web should be full of static html, just look at all of the top websites on the internet, such as this one. The web is constantly evolving and so should we.
Having said that, of course you should limit the amount downloaded by the user and only use the libraries and frameworks that you need. If you have a large code base, then you can justify using react to help keep the code clean and to keep your sanity.
Hello Ben,
I stumbled upon this video by accident (no a React guy or whatnot).
I just wanted to ask this question: what is that other mic doing in the background?
Much love
I live in a 2nd world country, unlimited 4G cost about the equivalent of 35-40 us$, in 5 years everyone will have unlimited or close to unlimited mobile data, so i dont think you should focus on data usage that much.
Of course, you don't want to download the whole database upfront so decoupling is so much important. Sites use databases in various ways so this matters contextually.
*Everyone is stop using react
*Meanwhile me who just got a very first job to do something with react: -..-
totally agree with you mate. i cannot understand people that says "hey, we should pick this framework
because the bundles are 150k smaller". that's stupidity at its finest. we have faster internet connections everyday. nowdays a bundle of 5 MB can be downloaded in less than half a second. stop crying about bundle sizes, for god sake.
The Vue video was awesome, I'd love to see a similar one with Svelte!
If we really want to make the data argument, navigate to literally any blog or news site and open your network tab and watch your requests blow the hell up with ad requests, css files, cdn requests, third party requests, etc. Javascript is the least of my concern for large data transfers.
It doesnt work for a little bit after ssr because you arent binding with the page. you are binding after load
Here's my take:
1. React is slow
Javascript is an interpreted language, so any javascript will be slow
2. React is expensive
The ads and trackers use way more bandwidth than the handful of kilobytes of javascript delivered to your browser
3. React is inaccessible
Very good video, congratulations! The best part is the ending lol
Haha great video. I was wondering about the 2G argument, in our country they gonna soon shutoff 3G soon. In most of the countries 2G is off anyway.
You should actually stop using "high resolution streaming platforms" like youtube because there could be someone watching your video with a limited connection.
And as always for any framework or language, you only go down the rabbit hole only if its neccessary. If you use plain javascript or c / c++ for the sake of native execution speed, thats not the best choice. In a real world project you need to take into account way more than pure execution speed. Like time to market, maintanance, availability of skilled poeple, existing opensource projects you depend on, etc. etc.
So thanks again for the high resolution video :D
The "new" Facebook is built with React, Relay & GraphQL. If React is "small", "fast" and "inexpensive" enough for an enterprise app like Facebook, no one on earth should have issues with it from a performance perspective. If you're building the kind of app where React would cause headaches, you'd simply not use it to begin with and skip writing an article about it.
Ctrl C + Ctrl V
1. React is slow
2. React is expensive
3. React is inaccessible
4. React goes against what the web was made for
5. React is made by Facebook
I dont want to see go completely away, but Im tired of using websites misusing it!
If your site is mostly text and images you don't need an expensive javascript framwork. These fancey animations aren't worth it!
Thank you Ben. Thanks a lot. Maybe that guy was only joking because all his points are so weak that I didn't even need someone to convince me
i come from game dev and was peeking on UI dev every once in a while and I truly feel react is bringing the most positive innovations on the field, i prob won't ever use it (personally favor ssr and plain html / js) but i'll prob learn every big update
This article is a great example of black and white thinking: something is either good or bad, there's no in-between - which is almost never the case, because reality is nuanced. You should let _context_ guide your decisions when choosing dev tools for your projects.
Quote: _“Do you think some users are more important than others? Do you care about reaching all users or only the wealthy ones?”_
Eh, almost every company in the world cares more about reaching and pleasing their primary target demographic than anyone else, it’s called prioritising. Ideally, you make everyone happy, but that’s close to impossible in practice. There’s always a trade-off when you pick your tools, and you gotta weigh the pros against the cons.
If you’re building a website that is meant for a 3rd world country with 2G Internet and Windows XP, then your first thought probably shouldn't be “hey lets install a bunch of npm modules”
Context is key 👈
Ben, ReactJS and JS is the same language. It's never okay to use React. Comparing the size to another bloated framework isn't a real comparison.
Is using Material-UI a way to bloat my code?
I really really hate bootstrap and I found more intuitive using Material.
I like Vue, *but* I have experience on React, it is great and confusing, *but* it's great for development due to the last dev community and not to say the large number of options coming with react( even though most of them are community supported), and lastly react native. If you are a web development who just wanna build an app React Native crushes it. Yes, it is far from native ( and flutter) but it gets the job done.
The author prefer to write in HTML, and does not have a clear understanding on why SPAs exists. He forgot to generalize that is the case for all leading SPAs and JS Libraries
Quote
ender minyard 
Sep 15

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.