DEV Community

loading...
Cover image for You don’t need React for building websites

You don’t need React for building websites

Silvestar Bistrović
Fearless web engineer, CSS developer, JAMstack enthusiast, WordPress theme specialist, author of UI Dev Newsletter, founder of CSS Auditors.
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 (151)

Collapse
galatagirmaye profile image
Galata Girmaye

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.

Collapse
jfbrennan profile image
Jordan Brennan

Definitely more organized, but not faster. Nothing is faster than pure HTML, CSS, and vanilla JavaScript.

Collapse
stojakovic99 profile image
Nikola Stojaković

There is always a trade off, but React applications are not noticeably slower if they're engineered properly.

Thread Thread
ravavyr profile image
Ravavyr

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.

Thread Thread
jfbrennan profile image
Jordan Brennan • Edited

The other speed often left out of the equation is workflow speed:

  • Pulling a larger repo (this impacts CI too not just your local workflow)
  • Waiting for more dependencies to install (also CI)
  • Resolving peer dependency issues (I was just doing that and had to take a break, which ironically is how I ended up here [anyone know why Vue 3.1.5 won't install?])
  • More tests to write and they take longer to run (also CI)
  • Longer build times (also CI)
  • More build errors (also CI)
  • More tools and plugins to manage
Thread Thread
ravavyr profile image
Ravavyr

I'll add some more:

  • When debugging you're mostly debugging React/Vue/Angular problems, not Javascript. Requiring someone to learn new syntax for methods that do exactly what vanilla JS does already is kinda dumb.
  • Not understanding dependencies leads to things breaking and you can't fix them unless someone on stack overflow solved it or your dependency actually has a community and active devs writing fixes. Again, vanilla JS problems all have solutions documented a thousand times over across the web.
  • SEO is not easy to implement without additional dependencies. A website needs proper SEO structure, why the frameworks don't make this the default [eg, every page must have a title, a description, a canonical url, and every link that opens a new window should have rel="noopener" on it, and a robots.txt and a sitemap.xml should be autogenerated by the framework. That's minimum.
  • On top of all of this accessibility is mostly forgotten, not even a foot note unless you're a large company, the frameworks could solve most of this by building it into their platform. Google and Facebook have the dev power to do it, but haven't.
Thread Thread
stojakovic99 profile image
Nikola Stojaković

NPM modules alone is a mess. Most people install far too many dependencies and don't understand what the dependencies actually do.

I agree that NPM modules are massive, but developers are those who should care that there aren't unnecessary modules installed on the project.

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.

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.

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.

And that's the reason why we have server side rendering. There are Gatsby and Next.js beside other solutions.

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.

That's nice but you need to count multiple things;

  • employing developers - how many React developers there are and how many Taino JS?
  • ecosystem - how many libraries exist for React and how many for Taino JS?
  • community - how big is React community and how big is Taino JS? How easy it is to get help when you're stuck? Who stands behind them?

Don't get me wrong, I'm not saying this to undermine Taino, I'm just talking about the way industry works.

Thread Thread
stojakovic99 profile image
Nikola Stojaković

When debugging you're mostly debugging React/Vue/Angular problems, not Javascript. Requiring someone to learn new syntax for methods that do exactly what vanilla JS does already is kinda dumb.

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.

Not understanding dependencies leads to things breaking and you can't fix them unless someone on stack overflow solved it or your dependency actually has a community and active devs writing fixes. Again, vanilla JS problems all have solutions documented a thousand times over across the web.

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?

SEO is not easy to implement without additional dependencies. A website needs proper SEO structure, why the frameworks don't make this the default [eg, every page must have a title, a description, a canonical url, and every link that opens a new window should have rel="noopener" on it, and a robots.txt and a sitemap.xml should be autogenerated by the framework. That's minimum.

I don't know, I find Gatsby pretty straightforward. It generates everything I need, from the pages to sitemap.xml.

On top of all of this accessibility is mostly forgotten, not even a foot note unless you're a large company, the frameworks could solve most of this by building it into their platform. Google and Facebook have the dev power to do it, but haven't.

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.

Thread Thread
stojakovic99 profile image
Nikola Stojaković

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.

Thread Thread
ravavyr profile image
Ravavyr

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.

Collapse
ferittuncer profile image
Ferit Tunçer

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
bello4 profile image
bello oladepo

I definitely agree with you.
React makes life easier if you value time and speed.

Collapse
hrithikrtiwari profile image
Hrithik Tiwari

It's just like buying the wheat and grinding it to make flour, when you have so many libraries out there and you can speed up your development ..why limit yourself

I feel this is just an excuse of limiting your learning

Collapse
ivanjeremic profile image
Ivan Jeremic

He means development is faster

Collapse
dacurse profile image
DaCurse • Edited

That is if you write your code perfectly.

Thread Thread
jfbrennan profile image
Jordan Brennan

Oh the same goes for React and all other frameworks. I've never seen sloppy React earn a "get out of jail free" card before. Not only that, but the raw overhead is inescapable.

Collapse
rutujr profile image
Rutuj Runwal

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.

Collapse
bennypowers profile image
Benny Powers 🇮🇱🇨🇦
Collapse
lukeshiru profile image
LUKESHIRU

I mean, you could also ... bundlephobia.com/package/preact@10... which is even smaller than lit x'D

Thread Thread
bennypowers profile image
Benny Powers 🇮🇱🇨🇦

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
lukeshiru profile image
LUKESHIRU

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
bennypowers profile image
Benny Powers 🇮🇱🇨🇦

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
lukeshiru profile image
LUKESHIRU

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

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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.

Collapse
emmanuelbenson profile image
Emmanuel Benson

In terms of faster, I am still of the opinion that your plain css, html and J's will perform better

Collapse
solsen_tl profile image
Steven Olsen

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!

Collapse
romeoks profile image
Romeo

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.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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
romeoks profile image
Romeo

Thanks for the tip. 👌

Collapse
solsen_tl profile image
Steven Olsen

You're taking the right approach! A framework can only make something "easier", but you need to know what is "hard" first.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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.

Collapse
solsen_tl profile image
Steven Olsen

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".

Thread Thread
darkwiiplayer profile image
DarkWiiPlayer

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.

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.

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.

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.

Like all good answers, "it depends".

Not only that, but it's also that different people will draw the line at different places. 😁

Collapse
jfbrennan profile image
Jordan Brennan

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!

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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"

Collapse
khorne07 profile image
Khorne07 • Edited

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.

Collapse
orofbrown profile image
Mike Young

Agreed! I would go even further to say that React makes web components completely irrelevant

Collapse
khorne07 profile image
Khorne07

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
orofbrown profile image
Mike Young

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
khorne07 profile image
Khorne07

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

Collapse
lexlohr profile image
Alex Lohr

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.

Collapse
bennypowers profile image
Benny Powers 🇮🇱🇨🇦

By refusing to work with HTML and the DOM, React makes it harder to share and reuse components

Collapse
lexlohr profile image
Alex Lohr • Edited

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
bennypowers profile image
Benny Powers 🇮🇱🇨🇦

That's an interesting definition of "share" you got there

Thread Thread
lexlohr profile image
Alex Lohr

That's an interesting opinion you got there.

Collapse
sandorturanszky profile image
SandorTuranszky • Edited

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.

Collapse
jwhenry3 profile image
Justin Henry

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.

Collapse
otacke profile image
Oliver Tacke

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.

Collapse
jwhenry3 profile image
Justin Henry

That is just sad, frameworks should be icing on the knowledge of HTML, CSS, JS, not a replacement.

Thread Thread
otacke profile image
Oliver Tacke

Couldn't agree more.

Thread Thread
shawnhansen profile image
Shawn Hansen

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.

Thread Thread
otacke profile image
Oliver Tacke

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."

Collapse
tomchambers2 profile image
Tom Chambers

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.

Collapse
starbist profile image
Silvestar Bistrović Author

Any of the sites in my portfolio is a non-React site: silvestar.codes/portfolio/.

Collapse
lukeshiru profile image
LUKESHIRU

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
mightycoderx profile image
MightyCoderX

Bruh, jQuery is just useless bloat nowadays for most small websites

Thread Thread
lukeshiru profile image
LUKESHIRU • Edited

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
starbist profile image
Silvestar Bistrović Author

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.

Collapse
rdentato profile image
Remo Dentato • Edited

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 :) )

Collapse
oniichan profile image
yoquiale

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.

Collapse
junihh profile image
Junior Hernandez • Edited

Same here but with Vue only

Collapse
puruvj profile image
PuruVJ

The amount of people in the comments who do not understand the difference between website and webapp is killing me 😔

Collapse
junihh profile image
Junior Hernandez

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.

Collapse
pozda profile image
Ivan Pozderac

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!

Collapse
darkwiiplayer profile image
DarkWiiPlayer

Honestly, I wouldn't call any SSG with more than 500 lines of code "minimalist"

Collapse
rangercoder99 profile image
RangerCoder99 • Edited

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!

Collapse
blowfish profile image
Blow Fish

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.

Collapse
cameronnickert profile image
cameron-nickert • Edited

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.

Collapse
paultechiesapp profile image
Paul Lee

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.

Collapse
sakethkowtha profile image
sakethk

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 🤔

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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.

Collapse
myk profile image
Mayank Yadav

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🐱‍👤________________________________

Collapse
iiianous profile image
Ian Mostar • Edited

The thing is if you're Frontend developer most likely you will 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.

Collapse
blackr1234 profile image
blackr1234 • Edited

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.

Collapse
pixelsoul profile image
Oliver Kelso

I stopped reading at "It is fair to say that I don’t understand it".

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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?

Collapse
lewiscowles1986 profile image
Lewis Cowles

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.

Collapse
zenulabidin profile image
Ali Sherief

Usually Bootstrap, jQuery and SASS gets the job done quite easily.

Collapse
ivanjeremic profile image
Ivan Jeremic

This sounds so 2009

Collapse
jackmellis profile image
Jack

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...

Collapse
jwp profile image
John Peters

So true, it's uncanny how some frameworks seem to live on eternally. Today there seems to no buzzing for Svelte, Lit, and even Html 5 web components. Go native or go home.

Hey I heard that web assembly has landed.
Good bye Angular and React, you were both opiniated chumps anyway.

Collapse
owenmelbz profile image
Owen Melbourne

@starbist The key puzzle piece you are missing is "the eco system" - It's not React itself, it's what it affords you to be able to do. e.g. Tools like NextJS are React based, React Native is React Based, hundreds of top quality libraries all require React.

Yes it's not needed - BUT if you choose to use it, you get access to the eco system which opens many doors.

Collapse
okabrionz profile image
Oka bRionZ

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.

Collapse
belevatini profile image
Rocky Bronzino

It is not hard to learn, but learning it made me dislike it even more. It is a silly solution to a problem that doesn't exist for real programmers. All frameworks are solutions to problems that only exist for unskilled coders. Unfortunately, the industry is comprised of 80% unskilled coders, so it appeals to the majority.

Collapse
zenull profile image
zenull

PayPal is using React and it's so slooow. Ever slow. Many huge companies rely on frameworks, sometimes a lot of frameworks and tools, that much so their websites are so overloaded with junk code. Speed is very very important and IMHO if a company has a lot of $$$ then everything should be better built strictly upon needs to maintain a clean code and fast loading.

Collapse
stevevail profile image
Steve-Vail

Thank you! I have attempted to learn REACT numerous times, every time falling short of being able to actually use it. I'm currently not looking for employment, but when I was, I hated seeing that 5 letter word in the their job requirements.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

The web app developer does need React or similar frameworks.

Arguably. I'm a very big fan of micro-frameworks and, while I don't have the experience in web applications to make a definitive statement in that area, mu suspicion is that, just as in most other areas, 90% of the benefit of a big framework like react could be achieved with 10% of the code / complexity (if not less).

Collapse
xarbit profile image
Jason Scurtu

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.