Here’s what I think: if you are building websites, you don’t need React (in most cases).
I have been building websites for over nine years now. As I get more experienced, I use fewer libraries and frameworks and rely on good old HTML, CSS, and vanilla JavaScript. I think you should consider doing the same.
My rant about React
Ever since React came to the stage, I’ve been hearing, reading, and watching how great it is. I had a few attempts to learn it, but I failed every time. It is fair to say that I don’t understand it, so I cannot even rant about its features, shortcomings, or flaws.
What I can rant about is the hype. I mean, it’s not even hype after all these years. It is a necessary evil. Of course, I am exaggerating here, but maybe not.
I feel like 9 out of 10 job ads for a frontend developer mention React.
I don’t get it. Why would I need to use React if I am supposed to work on building websites? Are employers afraid that if you don’t know React that you wouldn’t be able to make a landing page? Would knowing React help you solve any problems when creating a new layout or template? I cannot think of any part of the website that would require React.
All these questions made me realize that I don’t need frameworks for my everyday work.
There might be a solution
Instead of adding React to every frontend job ad, employers should emphasize HTML, CSS, JavaScript, and accessibility skills. These four amigos are the only thing you need to make websites perform well, achieve a solid SEO score, and allow every user to consume the content.
Brad Frost wrote about front-of-the-frontend. Chris Coyier wrote about the great divide. I agree with both of them, but I would make the following distinction: web app developer and website developer.
The web app developer does need React or similar frameworks.
The website developer doesn’t need React or similar frameworks.
Of course, there are exceptions, but I am talking in general here.
I am in a situation where I don’t need to apply to new positions and choose my employer often, but I keep my eye on job ads frequently. I sympathize with developers who are capable of building solid websites but struggle to find a job because of the lack of React skills. I know at least one person who would be thankful if React skill wouldn’t be listed so often — a friend of mine (and my mentee) with whom I share the office these days.
I propose a simple solution: if the job is about building sites, please stop adding React as a required skill unless absolutely necessary. It might be helpful to use the website developer term, too.
Conclusion
Knowing React could only make you a better developer, and I am not saying you shouldn’t learn it. However, I am saying that it is not needed in most cases if your goal is to build websites.
I hope more people would realize how powerful HTML, CSS, and JavaScript are and that these come with the most features that you’ll ever need for building a website. Simpler is usually better.
Top comments (148)
Frameworks are for ease of development and coding. using react may not be mandatory but it will help you have well organized and faster website than those with pure HTML,CSS and vanilla javascript. at the end of my comment you are right tho.
Absolutely agree with you.Not only this but also the fact react adds a sense of scalability to your applications/sites.So you can grow easily using this frameworks without any hassle.Plus there are thousands of developers already building more and more packages and functionalities for react so it becomes a go-to stop for many developers.
faster?
bundlephobia.com/package/react-dom...
bundlephobia.com/package/lit@2.0.0...
The idea that a react application will necessarily be faster than one written in plain javascript seems quite absurd to me. There's no magic behind react; it's ultimately still just javascript and any competent developer will be able to write an application without a framework that's as fast and even faster given enough time. Development speed is the interesting measurement here, not application performance.
In terms of faster, I am still of the opinion that your plain css, html and J's will perform better
I recommend every junior developer start out by building a few websites from scratch (vanilla js/css/html).
Only THEN can you understand the benefit of what any framework brings to the table. Otherwise you can't differentiate between what's doing what.
Having said that, React/Vue/Ng/Svelte are popular frameworks because:
In one word, frameworks enforce STANDARDS, which are critical on team projects. There is also much flexibility there, so no they are not a silver bullet, and not even essential. But they do help a lot!
I'm at the point of applying vanilla JS to exercise projects after a few months of learning and I'm happy that when I started some friends told me to stick to vanilla before any framework, and of course I listened to their advice.
The only thing that's catching my eye at this point is Jquery, because I saw some easy solutions in Jquery vs vanilla JS.
But, until I'll have a good grasp and understanding of how and what can I use in order to finish my projects with JS, I won't move to any framework because I firmly believe that we need to crawl before walking or running.
These days, almost nothing is easier in jQuery unless you're targetting older browsers. Many "jQuery vs. Vanilla" examples specifically use very old APIs that are even less relevant now than however many years ago those comparisons were made.
Thanks for the tip. 👌
You're taking the right approach! A framework can only make something "easier", but you need to know what is "hard" first.
Going at this with a bit of unix philosophy: I think all these are very valuable things, but I'd much rather see them taken care of by different tools. Behind-the-scenes plumbing is really a task of its own, and should thus be taken care of by a distinct component.
The same goes for your other points, but one of them is specifically interesting: the "plugin system"; this is precisely what a module system on a language-level should do. A well built module should work almost like the plugins you're describing: pull them into your project somehow, maybe add minimal boilerplate, and have a new functionality that just works.
Lastly, the best practices part can also be achieved in a more modular way: using code standards and enforcing them with automation. No need for frameworks here; just throw a linter into your CI.
UNIX is a good analogy. Individual, specific tools can go a long way to abstracting out manual/redundant details. However, even the wiring up of these specialized tools can cause a high cognitive burden, which usually slows down the project development in a team environment. With a framework, you can point a new developer at good documentation to get them onboarded quickly for example.
I agree that languages can (and should) have a "plugin" system -- that doesn't mean frameworks shouldn't or can't too! It's a design principle more than a feature.
Not sure where to put this point, but many security "best practices" disappear from a developer's cognitive load because the framework just enforces them out-of-box. This cannot be understated. It's only a convenience, but a HUGE one.
Again, I'm not saying everyone has to use a framework for everything. I'm saying that there are definite reasons that frameworks are popular and useful. Marketing landing pages almost never need one, for example, but web apps bigger than one page typically do. My general advice is simple: don't use a framework unless you (might) need one for your project :) Like all good answers, "it depends".
Indeed. I wasn't so much trying to argue that frameworks, when they are built, shouldn't have a plugin system, but that we don't need frameworks for their plugin system, because most languages already have similar mechanisms.
As I mentioned, this can be mitigated to some extent using automation, like code linting and automatic testing, but even before that, smaller libraries can build their APIs around enforcing best practices just as frameworks can.
Not only that, but it's also that different people will draw the line at different places. 😁
Also malicious NPM security vulnerabilities.
There is always a trade off, but React applications are not noticeably slower if they're engineered properly.
Personally, the trade off on the JS frameworks is massive.
NPM modules alone is a mess. Most people install far too many dependencies and don't understand what the dependencies actually do.
Having a 5-10mb bundle is considered "normal", which is terrible for performance no matter how you slice it, because it's what hurts the FIRST page load.
Sure subsequent pages are faster and for an application where everyone hits the login page first this might be ok, but for websites it's not because people will be arriving on random pages from search engines.
To prove you don't need 300mb of node modules, i made taino.netlify.app it's 1 script file to build SPA websites and it's 13kb uncompressed, about 3kb when compressed. It also gets indexed by google [Search for "Taino JS" and you'll find it]
Most small business websites could do this and have a web presence without a dozen build tools, compilers and other nonsense.
I'm a React developer and I totally agree with you, for a simple website React is not needed and in fact is not recommended either. React is for complex scalable web apps with much dynamic content. For a website not too complex is more recommended to use a lighter framework like Svelte or just go on with web components (html, css and vanilla js). The problem is that recruiters, CEOs and other leaders of enterprises do not know about what exactly they need and just guide them selves by the trendings. And newbies or inexperienced developers just learn how to use a tool (React, Vue or any of this kind) and want to solve every single problem using that tool.
Agreed! I would go even further to say that React makes web components completely irrelevant
Na you are going too far on that statement. Using microfrontend architecture you can combine React components with common web components without any problems. I agree that you should not use React when you don't need it but React is a really great tool. Many devs complains a lot because React doesn't use html, intead it uses JSX, but once you understand JSX is a really satifying tool to use.
Ok bud. It's called an opinion. I think web components require way more boiler plate code than React components do and React gives you a whole lot more on top of that.
Yes that's true, but the thing is that web components and some sort of universal staffs. Like I said I love React and is the tools I use everyday, but not everything requires React, the good thing is that actually are other tools in top of React that allows you to do everything with it. But I think the real future is microfrontends, where you can combine components made in different technologies and build great things with all blended
I was in your shoes, saying why the hell I should use a web framework for a website? Then I realised two things:
Dynamic content, such as internationalisation, are easier to implement and optimize with frameworks.
There are built-in optimizations to benefit from, instead of implementing them yourself from scratch. For example, Gatsby, works on top of React, has very handy prefetching, lazy loading, and image optimisations. Sure, you can do these with plain JS too, but do you want to implement all these instead of just using someone elses work?
Apart from that, I agree with you that a software engineer should be mindful about tool selections and should avoid going overkill. Perfection lies in simplicity.
I definitely agree with you.
React makes life easier if you value time and speed.
I think the main issue here is a misunderstanding: one of the paradigms of react is that it makes it simple to share and re-use components. What managers often don't realize is that this also makes it difficult to write components to be shared and re-used. So they only see the benefit of react, but not the cost.
That being said, react can be helpful for more complex web apps, but for a normal website, it is maybe not an ideal choice.
By refusing to work with HTML and the DOM, React makes it harder to share and reuse components
That depends. It's simpler to share with other react-apps. With everyone else, not so much. In any case, it doesn't seem a coincidence that Facebook developed a framework based on a technical lock-in.
That's an interesting definition of "share" you got there
That's an interesting opinion you got there.
React native will be the death of the web.
We take it for granted that our grandchildren will have a world wide web, but it's not a given.
"Your tech stack doesn't matter, the only thing that's important is solving business needs" is how were going to lose the web to app stores, binary blobs, and (increasingly state controlled) proprietary silos.
Technology choices aren't neutral, they have a moral value. The open web, built on standards that belong to everyone, is a moral good. Whether or not future generations will benefit from that good is up to us as developers, at least in part.
Using pure HTML, CSS and JS may give you some headaches, if your project grows. This is mainly caused by the conceptual weakness of HTML, which was not designed for the things we do today. Do you think, its possible to create any website or web-app without the use of HTML?
In fact, it is! The html-dom-api exposes alle the functionality of HTML to javascript, so using HTML is actually a detour around creating your page content. About two years I tried this approach with the DML-project, first as an experiment, but it came out to work pretty well. In the meantime, several projects have been finished, from simple websites to more complex applications. Using JS on the DOM directly is quite fast and gives you new options like "strong encapsulation" without the overhead of a massive framework. A DOM element created within a JS class object is just exposed to this object, not to anything else. This is one of the many advantages.
In any case, this is an interesting approach you can check out, the project is open source and can be used for free. It was already presented on dev.to some time ago. So I appreciate your comments.
The sad thing is if you advertise a position for web development and ask for someone with HTML, CSS, JS, you do not have a good basis for what the developers are capable of. If you provide a framework when looking for engineers, you will know that they at least are capable in that framework, which implies that they know HTML, CSS, JS.
Yes vanilla is faster, but how long does it take to build robust webapps and fully featured web sites that require complex solutions?
Frameworks imply that an engineer has a base set of skills in addition to just knowing how to construct a static page with minimal dynamic content.
I am not sure about that implication about knowing JavaScript if React is known (anymore). I would have agreed with you until recently when I was introduced to a developer who supposedly knew React but that needed to be explained some rather basic JavaScript principles. That developer seemed to have come quite some way by being able to stitch React components together without actually knowing what's going on underneath.
That is just sad, frameworks should be icing on the knowledge of HTML, CSS, JS, not a replacement.
Couldn't agree more.
While true, it's also true that frameworks are a gateway to language learning.
Back in the day, mid-2000s, I was able to stitch together a pretty decent (at the time) web app using Ruby on Rails despite not knowing the Ruby language very well. Using RoR was a gateway to learning Ruby.
I think the same applies with things like React. It's a gateway for some to learning JS. I'm all for whatever gets people in the game.
I believe frameworks can be a gateway to learning the basics, but still I don't believe that only knowing the framework makes you a professional developer that someone would want to hire. The main point that I answered to was "If you provide a framework when looking for engineers, you will know that they at least are capable in that framework, which implies that they know HTML, CSS, JS."
(A quick side note): React isn't a framework but a library. Subtle (but relevant) difference. Next is a framework. React isn't controlling the boot of nothing. It's a library.
Apart this nitpick, I do agree with this post. Totally.
--
s. A guy developing in React