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 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'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 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.
Not using tools to become more productive is a bad idea in general for any website.
Think of GatsbyJS for your website or blog. It is dead simple. And yet, using react does not introduce complexity nor does it make things complex for your blog. And you also benefit from easy deployment pipelines designed for this tool.
Sooner or later you end up reinventing the wheel by going vanilla JS. It's imperative to know JS fundamentals and understand well how FW and Libs work under the hood.
But using Vanilla JS just because React seems like an overkill is counter productive.
The idea of building custom FW died many years ago.
Companies ask for React because it is indeed a mature tool with great ecosystem.
When your project is built with a tool that most people know, finding people for your team is way easier than explaining how a custom framework works.
No matter what I build, my most important criteria is time to market, performance, SEO, scalability, cost of running and easy deployment.
Why use custom JS or CSS when I can use a well tested solid tools instead to save time both on development and fixing bugs.
(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
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."
I'll add some more:
I agree that NPM modules are massive, but developers are those who should care that there aren't unnecessary modules installed on the project.
5 to 10 MB bundle would be a disaster. This is something which should be watched on during optimization period before the launch. It's not normal at all.
And that's the reason why we have server side rendering. There are Gatsby and Next.js beside other solutions.
That's nice but you need to count multiple things;
Don't get me wrong, I'm not saying this to undermine Taino, I'm just talking about the way industry works.
This is true for using pretty much any library - does it mean people should stop using libraries at all and start writing everything from scratch? I don't think so.
Same question as above. Yes, working with dependencies is hard sometimes, but how do you think you can write modern web applications without additional dependencies?
I don't know, I find Gatsby pretty straightforward. It generates everything I need, from the pages to sitemap.xml.
You can use linter for this. It will warn you whenever you're making something which is not accessible. You can't really expect from UI libraries to have millions of things out of the box. Do one thing and do it great - that's the philosophy which libraries should follow in most cases.
These are pretty much all trade-offs you have to make when you're writing anything a bit more complex than a simple static website.
Gonna try to respond to each of these:
I agree, we shouldn't write EVERYTHING from scratch, but A LOT of npm packages are 5 lines of code that anyone CAN write and understand versus install and have no clue what it's doing.
WE CAN write modern web applications without a multitude of dependencies. indiegameshowcase.org is fully vanilla JS SPA [The frontend has tinymce, the rest is just javascript] with a NODE backend.
The backend has only the following dependencies:
"dependencies": {
"@pm2/io": "^5.0.0", [for logs]
"aws-sdk": "^2.962.0", [for file uploads]
"dotenv": "^10.0.0", [environment files]
"email-validator": "^2.0.4", [validate emails]
"express": "^4.17.1", [actual server stuff]
"express-blacklist": "^1.0.3",
"express-defend": "^1.0.9",
"express-rate-limit": "^5.3.0",
"express-session": "^1.17.2",
"mailersend": "^1.1.0", [send legit emails]
"multer": "^1.4.2", [upload files]
"mysql": "^2.18.1", [database]
"password-hash": "^1.2.2" [secure passwords]
}
I don't think it could be done with less without recreating a TON of code.
"Do one thing and do it great" is nice in theory, but in reality it causes far too much abstraction and you end up with 20 libraries written by 50 different developers and it's all code you don't understand. More often than not you can write the same functionality easily, but newbies don't know so they pile them on and you get a 15MB bundle. Google "React bundle size" and look how many articles are there just to tell people how to reduce it by removing crap they don't need, or worse, install more libraries to do it.
Linters make developers lazy because they stop understanding how to debug their code, and really most of the stuff linters do is pointless crap like "80 characters per line" or "new line at end of file" or "remove semi-colons"....like none of these things improve your code and basic syntax errors already show in VSCode and other editors.
Linters also do not teach you accessibility, they have automated rules you can follow, but this only does part of it. People think accessibility is just code rules, but there's an "experience" that you need to build for accessibility and that's 75% of it that most devs using tools for it, don't accomplish correctly.
Gatsby doesn't set up everything you need for SEO, and it's another package you install that you don't have a full understanding of, which isn't necessary. [Gatsby of course is useful for other reasons]
You don't have to agree. This is just my opinion from years of working with other people's code.
That's a problem I see with many frameworks/libraries today.
Even BEFORE knowing what we have to do, someone has decided that we need tons of lines of code we'll never use. Just because
<script src="..."/>seems cheap.Frameworks are great and libraries are life saving but using something just for the sake using it is becoming too much of an habit! (EOR = End of Rant :) )
A website of any real complexity is going to require a framework like React to manage state and divide up components. Yes of course you can built websites in vanilla javascript but you're going to either be writing your own framework from scratch or hit the limit of what's managable quite quickly. Some examples of sites you think should be built without frameworks would be helpful in making the argument.
Any of the sites in my portfolio is a non-React site: silvestar.codes/portfolio/.
There's benefits to React and it sounds like you have never been able to reap the benefits because you've never successfully used it. This is a silly article. Why use Kotlin when you can just use Java. Why use Java when you can use C++. Why use C++ when you can just use C. Why use C when you can just write assembly. Why write assembly when you can just write binary. You see how silly this is? We create new languages, tools, and frameworks overtime to make development easier. React is a solid framework that can speed up development and lower the complexity of your code. If you think Native JavaScript makes your code less complex, thats only because you're familiar with it. Overall, this article was nonsense.
Can't agree anymore. It is quite funny that in 2021, there are still people thinking that writing vanilla code like PHP without Laravel, JavaScript without React.JS, React.JS without Next.JS is not really feasible for long run. The main reason of developing a web app is for its portability not really for its simplicity.
Yes agreed that every new developer should learn the fundamental of how a Web application (HTML / CSS / JavaScript) is running on a web browser. But bear in mind, in the end of the day, the application has to be maintainable in the long run if it is going to scale up on business wise or on architectural wise.
For example, ok let say a business start with a simple website showing that he is selling bicycle a simple web portal build in Vanilla HTML, CSS and JavaScript, yes developer is super quick. After 2 months, there are new requirements coming in, the customer of the business requires e-commerce functionality from the website, yes the development team can continue to build it using vanilla HTML, CSS and JS for its cart and checkout functionalities. Another 2 months later, if the business requirement requires extension of functionality of cart function on let say adding B2B functionality for bulk purchases, RFQ function, bicycle stickers customisation features etc, is pure HTML, CSS and JS capable? Yes capable, how long does these development needs without any framework or any library? Business requirement will just be getting heavier and heavier.
We use React / Vue / Angular and many other more not because we can't type Vanilla JavaScript, it's because these frameworks are already a set of development toolkit to enhance the development experience, improve the robustness, simplicity of including the broad library of NPM, improve the maintainability for the real world development scenarios, etc.
So the reason of choosing vanilla HTML/CSS/JS for web-dev over frameworks/libraries is purely outdated.