You don’t need React for building websites
source link: https://dev.to/starbist/you-don-t-need-react-for-building-websites-455f
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
You don’t need React for building websites
Jul 27 Originally published at silvestar.codes
・3 min read
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.
Discussion (106)
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.
Definitely more organized, but not faster. Nothing is faster than pure HTML, CSS, and vanilla JavaScript.
There is always a trade off, but React applications are not noticeably slower if they're engineered properly.
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.
Thread
Thread
I definitely agree with you.
React makes life easier if you value time and speed.
He means development is faster
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.
CollapseExpand
I mean, you could also ... bundlephobia.com/package/preact@10... which is even smaller than lit x'D
Thread
Thread
Preact is a fine choice.
Lit has the advantage of running directly in the browser without need for transpilation. You can get that with preact using htm instead of jsx
But really it comes down to this: as the user of your components, I don't really care which library you used to write them, I only care if they work with my app.
React fails that test, preact and lit pass.
Thread
Thread
The main advantage you have with React compared to Preact or lit, is that you can reuse hooks, components and utils created for React in the DOM and in native (iOS/Android) as well. I still prefer to create a good PWA with Preact, but still that's one of the main "selling points".
It generally boils down to the requirements of the project and to try to not default to a framework like Angular or a library like React right away, and try to see which tool better fits your needs before you start coding.
PS: Nice one mentioning htm, great library sadly not as widely used as it should.
Thread
Thread
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.
Thread
Thread
I don't like mobile apps and Stores in general. If an app has a PWA version, that's the version I use. I was just pointing out that React Native is one of the main selling points of React... Sadly my personal preference has no power over the industry, so even if I prefer Preact and PWAs, people still use AppStores Dx
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
CollapseExpand
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:
- they take care of redundant plumbing in every project
- force some best practices including security (like no XSS/CSRF)
- have nice plugin systems for adding yet more time-saving libraries
- create a shared set of how-to-do's for teams (like code structure, unit testing, etc)
- hopefully reduce some code bloat / wiring due to abstractions and namespacing
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.
Thread
Thread
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".
CollapseExpand
I agree React or any framework is overkill for websites, but you're selling yourself short by sticking to just websites. You're the opposite of all those devs who are like "Must use React or I can't touch the project". Find a balance; you're stressing me out!
Dunno if that's what OP meant; I read it more like "Be an HTML/CSS/JS dev that knows react, not a react developer"
CollapseExpand
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.
CollapseExpand
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.
Thread
Thread
That's an interesting definition of "share" you got there
Thread
Thread
That's an interesting opinion you got there.
CollapseExpand
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.
Thread
Thread
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.
Thread
Thread
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
CollapseExpand
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.
Thread
Thread
Couldn't agree more.
Thread
Thread
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.
CollapseExpand
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 :) )
CollapseExpand
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/.
I mean, to be fair, they are all using either jQuery, Wordpress or both. Is not like you're doing "vanilla JS" on any of those.
Thread
Thread
Bruh, jQuery is just useless bloat nowadays for most small websites
Thread
Thread
I agree. I was pointing out that the author says he's not using React because you can just use JS, HTML and CSS, but he's using jQuery and WordPress...
Thread
Thread
Actually, I am using Vanilla JavaScript more often now. jQuery is something that was there before. I tend to ditch jQuery if that is possible.
CollapseExpand
I tried learning React because of the hype but was vastly disappointed. I hated the way it worked. Maybe I'm biased because I love both Vue and Angular's templating system and proper separation of code.
CollapseExpand
I am both web app and website developer so there's that.
I use 11ty for websites (this minimalism approach is IMHO best approach to use for websites), but also I am guilty for using GatsbyJS which is writing static sites with React.
But do you really need React for building websites? Not at all!
Honestly, I wouldn't call any SSG with more than 500 lines of code "minimalist"
CollapseExpand
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.
CollapseExpand
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.
CollapseExpand
You are absolutely correct, most of the developers face a lot of struggle in there early stage of learning React or some other frameworks...and even I faced because what I think is many developers just jump from JavaScript to the React without getting all concepts clear.
Why are these frameworks/Libraries come into existence when we can already make our website using HTML, CSS & JS. It is so because it makes the developers life much more easier by writing effective and much smaller code. And there are plenty of pros and cons too. But using some helping tool is just a add-on to your project.
______________________________Happy Coding🐱👤________________________________
CollapseExpand
What i feel is if a person knows react js definitely that person will have an idea on Ecmascript, Closures, npm / yarn, Webpack, Promises, Axios / fetch, Reusable components etc... This might be the reason 🤔
Dunno, haven't used react myself, but my experience with frameworks is that, even if they use the more advanced language features, they often also make it easier to cargo-cult your way through those features by blindly copying code patterns and understanding only their effect within the framework, but not their actual semantics on a language-level.
CollapseExpand
Using Next.js as a static generator for all my smaller web sites now it makes things more easy and lots of painfull extra stuff is done by Next.js! Also React components are more easy to work with like I only got a small part of 'html' not spend hours scrolling over 1000s of html code trying to find that comment in one ocean of div tags, I can repeat and reuse stuff and things like sass or tailwind are really easy to setup and use!
Plus things such as automatic image optimisation, incremental static regeneration make your life alot more easier. Imagine coding a framework just to do what a framework like NextJS can get it done in seconds.
Javascript ecosystem matters alot.
CollapseExpand
The thing is if your Frontend developer you're most likely build medium-to-large applications that scale. If you are using just that 3 (JS, HTML, CSS) stack it would make a huge mess, imagine hundreds and thousands of statics files/css nowhere to be re-used.
Vanilla stacks (JS, HTML, CSS) I will agree, it is good for small sites.
CollapseExpand
The amount of people in the comments who do not understand the difference between website and webapp is killing me 😔
The truth is that I still do not digest how there are people who do not differentiate between the overuse of what is necessary. My father used to say that "not all that glitters is gold" and using resources in projects that only make their entry into production complex just because others use them does not make sense.
CollapseExpand
The lack of pros and cons of React and vanilla JS, strong arguments concluded from your 9 years of web dev experience, some performance figures and code examples, this post is really pointless and has zero educational value.
I'd say the one/two-way data binding feature in modern web dev libraries is very useful. Managing states is easy in React and is easier compared to vanilla JS. Create-React-App also comes with Babel and Webpack that make our lives very easy from one end (development with the latest ES features) to another end (deployment with ease). One example is that JS files are cached if we do not change the url (e.g. by adding a timestamp query string ?v=yyyyMMdd) when we deploy changes in the JS files, and as a result end users may not be affected by the new changes when they reload the page. The bundled Webpack library does that for us automatically. We also want to write code with the latest ES syntax but still ensure that end users' web browsers are compatible. Babel does that for us. It is very easy to make code changes and immediately see results. The bundled live development server and hot reload module do that for us.
If you are not looking for React developers here to persuade you, then just be a die-hard vanilla JS developer until one day a JS library interests you. There is nothing wrong if you can make a living with vanilla JS without React, period.
CollapseExpand
I must admit it's been a while since I've made anything not using React. And I agree there is a distinct line between website and web apps. However, I see a lot of jobs that require React experience because these companies are making web apps not websites...
CollapseExpand
Usually Bootstrap, jQuery and SASS gets the job done quite easily.
CollapseExpand
I stopped reading at "It is fair to say that I don’t understand it".
That's weird because by that point it was already more than clear that what the article was trying to point out, didn't require any in-depth understanding of react.
Is there any point to coming to an articles comment section just to point out that you didn't read it, or did you just feel like showing off how edgy and disrespectful you are?
CollapseExpand
Hey Silvestar. Great to see you here;
I 100% agree react should not be a requirement, but I would encourage further learning adventures, even if just for the sake of learning.
I learned react back in 2015. I re-learned it in 2018, and in 2021 I'm still finding cool uses for it including accessibility for certain features (live chats).
I do not use Gatsby, 11ty, I have incredibly unkind views towards them having seen their use; but tools being misused is not an indictment of the technologies that they are created with.
CollapseExpand
So i notice you did not only bash frameworks but libs as well. You face a few problems when writing code on your own: you must maintain it on your own. You must security test it on your own. Writing imperative code makes your project a pain to work with for litterally everyone but the person who wrote it. You also are wasting time reverse engineering features that there is 100 libs for. Using frameworks and libs is not only for your sake, but for saving time, money and headaches for those who work on your code later. Perhaps after 9 years you have a mountain of files you just copy paste into your projects and call it a day, but everyome else will suffer for it. As for failing to learn react ... at this stage its litterally just a function that returns the html you love so much, and some extra functions you can call to get better, safer state management for free. If you throw yourself in to desperate solutions like redux i get it, however if you are at that stage you alredy have dozens of hours under your belt in react. Its not hard to learn, but imperative code IS hard to read
CollapseExpand
It is refreshing that you take a stance and for someone like me, I need to be reminded sometimes that you can create cool stuff without any frameworks. However, isn't the point that for webpages, you can surely do it with vanilla Javascript, CSS and HTML. But a lot of jobs where they need React frontend developers are for large webapps. I would say that these days React isn't necessarily enough. I see TypeScript mentioned A LOT here in Denmark, and Vue is almost just as popular as React around here...
CollapseExpand
I totally agree. The talks about React and some frameworks reducing work time should be personal opinions, which I personally disagree with. Structured codes, yes. Faster development, plain old Vanilla JS. I am a fan of that always!
CollapseExpand
Imo if you need a website (as you define it) built, just use Wix or Squarespace. As a full stack engineer, I have no problem recommending that to people.
But if you need something with just about any level of complexity beyond purely static content, frameworks are worth the very small sacrifices of performance and complexity you need. Even implementing routing and a site-wide header and footer makes frameworks worth it almost immediately.
I do think it's important to learn vanilla just so that you understand the capabilities and what's available under the hood, but frameworks ends up being entirely appropriate a good amount of applications.
CollapseExpand
So let me get this straight. You don't understand react and it benefits but you rant people to. It use it.... Ok let me set it straight fuck off.
When you have big teams is easier to use framework and from everything out there react gives you best equation of pros and cons.
And I will always prefer libraries like this instead of custom projects without documentation where is nightmare to understand why they did it like this...
And I don't say devs should not know the basics, I am saying don't hate something you even confess you don't undertand
CollapseExpand
I even don't know how to use javascript. But, i can appear on first page or sometimes ranked #1 on a keyword what i want on Google. And my website faster than most websites.
Job?, i opened a services to redesign, making a landing page, performance booster even without knowing what react.
I use JAMstack Hugo to build my client website and Headless CMS to manage contents. Instead of faster on build & performance, JAMstack has secured and i never heard my clients web got hacked anymore.
React? i need it ofc, and i still learning.
CollapseExpand
The virtualDOM from react is unbeatable compared to something like jQuery. It’s pretty easy and straight forward to design and develop a page in react by creating modules and applying a bit of style on each, don’t need bootstrap or what ever.
React takes care of the classes..
You can extend react pages pretty easy and restructure the modules too.
Then there is also GatsbyJS that makes react pretty easy..
I would never use plain html and JavaScript again, it’s a pain in the but.
CollapseExpand
React can help with organization, but it is more important to understand what makes for better programming design, such as following the SOLID principles. These principles can be followed in Vanilla JS or with a framework or library. Most web apps I work on are MPA using the Microsoft .NET stack. Not React's forté, so I use a consistent Vanilla JS approach for the front end more suited to the architecture. Modern JavaScript has resolved many of the problems that frameworks and libraries, such as jQuery, were used to solve in the past so working without a mature framework isn't as big a problem as it used to be.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK