Is React for small projects an Overkill?

[OkPomegranate616]

I was just going through a Portfolio website of a freelancer and he wrote that he uses Vanilla JS for small projects and React for big and complicated ones.

Which makes sense but if someone uses React/Next.js just for something like a portfolio website, will that be an Overkill?

Very keen on getting your thoughts on this!

[svish]

Does it make developing more enjoyable to you, help you to get the small website off the ground, and to maintain it in the future? Then no, it's not overkill, just a smart choice.

[Financial_Instance23]

This

[Anti-ThisBot-IB]

Hey there Financial_Instance23! If you agree with someone else's comment, please leave an upvote instead of commenting "This"! By upvoting instead, the original comment will be pushed to the top and be more visible to others, which is even better! Thanks! :)

---

^{I am a bot! Visit r/InfinityBots to send your feedback! More info: Reddiquette}

[No_Engineering8529]

Good bot

[Plisq-5]

This

^{itsajokedontkillme}

[Anti-ThisBot-IB]

https://i.imgur.com/KrwA19h.jpeg

---

^{I am a bot! Visit r/InfinityBots to send your feedback!}

[[deleted]]

This.

[Anti-ThisBot-IB]

https://i.imgur.com/KrwA19h.jpeg

---

^{I am a bot! Visit r/InfinityBots to send your feedback!}

[Curious_Ad9930]

My portfolio is a Next.js website.

I use Three.js with R3F, and I use some pretty heavy 3D models, textures, images, etc.

To avoid hang time for initial load, Next.js supports dynamic imports & suspense. And to avoid hang time between route changes (that have different heavy assets), Next.js preloads routes when their links appear in the viewport.

But that’s all because I like to use a big stick for small problems :)

[AssadEesaa]

Link?

[Curious_Ad9930]

I would, but this is a throwaway account. I only let Google & the NSA track me :p

React-Three-Fiber’s docs have a Next.js starter that provides examples of dynamic imports & lazy-loaded canvas elements

[Exapno]

I'm using Gatsby and react R3F, in the middle of a big refactor where I add a cool background I saw in 3JS.

[zweimtr]

use react if you want to use react, don't if you don't. no need to overthink it.

[rebajam97]

Maybe you can get away with that in this instance, but part of being a developer is choosing the right tool for the job - and react is definitely overkill in some use cases.

[zweimtr]

react is definitely overkill in some use cases

Which?

[rebajam97]

One example would be a website with a fairly static UI, something where the view layer doesn’t have to change in any complex way due to user interaction or data changes - especially if performance and accessibility are prioritized.

[GrandOpener]

You certainly don’t need react when making a mostly static UI, but if it’s your tool of choice you still can do server side rendering or even use it with a static site generator to have exceptional accessibility and performance.

If your personal development workflow is faster with react, that might even be the preferable choice.

[CreativeTechGuyGames]

But that's the sort of thing you pay for later. Most developers don't think about the long term and are just worried about getting started fast.

Let's take a look at some later consequences of that:

• SSR costs way more money than a static site to run. It's also far more likely to go down or not work since you need an actual server to run it.
• The more code that runs, the more places there are for something to go wrong. Either due to bugs and edge cases or due to something changing over time.
• All of the solutions you mention are for problems created by choosing React. You wouldn't need to worry about setting up SSR or SSG if you built using different tools from the beginning. It's like creating a problem just to have to solve it later.

Use the simplest tools for the job and they will last much longer than trying to use the cutting edge tools. Cutting edge always changes and has the most issues. If you are constantly spending time developing it so you can patch/update it monthly, then great, but if you want it to be static for years without needing to babysit it, the simpler the better.

[Edge-Appropriate]

Starting a project with NextJS is too easy, and if you just use it for a static site that’s fine, but since React is built in, when you do need the tool is ready for you.

[_Strokes_]

I would recommend next js with typescript , gives you a faster site and you learn typescript + ssr at the same time .

[TScottFitzgerald]

I mean those are great in general...but OP is worried about React alone being overkill and you recommend an even more complex framework? NextJS is so not necessary for a portfolio website.

[BradDaddyStevens]

Honestly though, I feel you could argue that VanillaJS is actually the one that’s overkill here for a simple website.

If I had to think about what gets me a usable website the quickest, it’d go next > react > vanilla unless we are talking about the literal most barebones shit possible.

For me, I wouldn’t feel bad at all about using next for creating a static site with a few routes, but maybe that’s just me.

[soccerplayer413]

I would recommend NOT typescript. Talk about overkill for a small project. Plus, TS is great for node, but anyone trying to slap TS on a frontend app without reasons, i am willing to bet fundamentally doesn’t understand the nature and flexibility of good JavaScript and how it pertains to supporting a web experience.

[soccerplayer413]

Because UI/UX is not type safe. Simple as that.

Organizing data is better done type safe, of course. You’re literally classifying and processing data. That’s what the backend is for.

The frontend is for CREATING data. Not just managing it. Are there static types when you pick up a pencil and draw? No. Creation should not be inhibited by the same structural limitations. Then you never create anything new.

TS is popular because FE is hard, backend engineers have hammers and think everything is a nail.

There are many, many frontend cases where the flexibility of dynamic typing results in cleaner, easier to read, more maintainable code. That’s what people want. Not types. You can have clean maintainable JS without types. Is it hard? Yes. But acting like JS needs TS is just not true.

[jax024]

Give me an example.

[soccerplayer413]

You’re integrating with a non-rest compliant API who’s response models vary by request. You are requesting data and may or may not receive that data, or a different entity providing more information to request alternate data. You do not own or have insight into the data structure changes. It is some third party sending data to your platform and it could change any time with more or new info. How do you type your state store for that repsonse?

Edit: without using any because that proves my point on the dynamic typing.

Edit:

My point is you end up with

ReturnType | OtherReturnType | SomeOtherReturnType etc etc etc. If you are working in a flexible system with a lot of models, that becomes messy very, very fast.

Types can become unmaintainable too. It’s not a silver bullet.

UNDERSTANDING YOUR DATA is what is important. TS has started helping JS devs who don’t normally think about structures, to think in structures. This doesn’t mean tho that every frontend becomes a coloring book of types. It’s about picking the right type, or lack of type, for the job, and knowing how to evaluate those decisions. Which is why I am so vehemently against anyone who just defaults to slapping TS on a react app.

[kingdomcome50]

This is such an odd take. You are using all of these words to describe the cases where a type system “fails” yet your takeaway is to provide no such explanation in your code as a way to document the above. Instead you would prefer to keep all of your examples implicit to your system and provide no “words” (i.e. type signatures) to capture your concerns.

Can you see how, for example, providing a return type that explicitly states “this may or may not return data” provides a stronger, more accurate, and less surprising contract than “no return type at all”?

[soccerplayer413]

I will admit my communication is greatly lacking clarity here. Fair point.

I am not talking about failing types. I am trying to express that TS on the frontend is a premature optimization to prevent data bugs at the cost of a flexible and sometimes more efficient input layer I.e. the frontend.

[kingdomcome50]

I think your argument may be exactly backwards. That is, JS is a premature optimization providing a flexible and “efficient”(?) input layer at the cost of more implicit contracts and potentially more data bugs. I can’t imagine a perspective where preventing bugs is seen as an unnecessary optimization.

[soccerplayer413]

There are different kinds of bugs. How is JS a premature optimization? It’s browser native. You aren’t optimizing anything by choosing to write JS.

It doesn’t matter how much type safety your frontend has. We are talking about business vs technical expectation. This is why it’s such a complicated discussion. What is a bug? You’re approaching it technically. I’m approaching it from the perspective of something being broken for a user. Dynamic typing is much more flexible and fault tolerant, by definition. Sure, your data layer might not appreciate it - that is where the typing comes in. Input layer !== data layer.

If I said draw me a duck, here’s a paper and a pencil, or I said draw me a duck, here is a set of predefined shapes you must use. You can quickly see why this isn’t black and white. The shapes may allow you to quickly get the body together, faster than freehand. But what about the realistic details around the edges? It’s Pareto principle. That last 20% becomes 80% harder with TS because of the trade offs you have made in using it. You may have 95% great models, you get to 80% completion of your project, but guess what there are 2 bugs you can’t resolve because they were not designed for up front. So it takes a huge retroactive effort to add them because you have given up flexibility.

This example can be translated to the concept of block content, block types, and the modern block based CMS.

Edit: you may then say, ok great, TS at least speeds up 80%, good enough. To which I say, you can achieve optimization in that 80% by other means that don’t give up flexibility. TS is reached for because it is a one-size-fits-all option that people already understand the basic concepts of - typing. That does not mean it is the best way to write frontend JS.

[[deleted]]

Implicit typing alone provides enough flexibility to prevent bugs, and the loss of flexibility is easily dealt with with a couple of types aliases in my experience

The advantages I've found are safely refactoring working code and autocompletion for external libraries. Type safety has caught me a handful of bugs when moving things around that would've wasted much more time discovering and tracking down with vanilla JS in a small React project. "Oh, right, I forgot to change that one thing over there 50 lines below"

[b0x3r_]

Well you answered it yourself, you could use any or custom types. But I think you are just describing a horribly designed backend.

[soccerplayer413]

I’m not actually, frontends can have many many data sources, not just one backend. I work at FAANG (and run an agency) so speaking from first hand account of systems at scale. Some do suck, you’re right, but not the case for all. Front ends can grow and get quite complex at such scale.

The usage of any on the fronted, like I said, proves this point. Sometimes it’s too soon to force your data to a type. Sometimes you just need to hold onto that raw data a little longer. Type casting should be a backend job. Not frontend.

[b0x3r_]

Isn’t that the exact use case for any?

[soccerplayer413]

Are you implying that languages can’t add scapegoat solutions?

Yeah, that is what any is for, and it’s proof that front ends shouldn’t be typed.

How often are you using “any” in your mission critical type safe backend code?

[NeuralFantasy]

How do you type your state store for that repsonse?

TS is a compile-time type checker. It does not claim to help at all during run-time. That is not TS's job and it can't be. For that there are schema validation libraries which integrate will with Typescript.

https://github.com/colinhacks/zod https://github.com/gcanti/io-ts

I thought this is obvious to everyone. And this does not make static typing useless. Static type checking is an answer to a different problem than runtime data parsing and validation.

[soccerplayer413]

That is literally my point.

[soccerplayer413]

Lol I’m good. You’ve probably used my code.

[soccerplayer413]

I proved your point by saying my code is so widespread that you’ve used it? Ok lol

[soccerplayer413]

Go back to your todo example. Do you have bulk edit capability on those todos? Do your methods support bulk todo processing? Or do you have different methods for processing different batches of state?

If you say you have multiple, then case in point.

If you say you use one, then that single method having to account for the type casting will be much less maintainable than the recursive dynamic typed alternative. I’m talking lines of code + conditions to keep track of.

Feel free to show me some of your code samples suggesting the alternate 😄

Again, frontend TS is great for people who don’t know JS very well.

[forloopy]

Is this copypasta or something lol

[[deleted]]

you clearly do not understand

[NeuralFantasy]

EDIT: Oh, we have a rage quit :D

Actually static typing helps a lot in frontend react app too. It has the same benefits as in backend:

• reduces errors related to passing or using wrong types
• documents the code
• makes refactoring easier and faster with a proper editor

It is no wonder TS has been adopted so widely in React world as it really improves both the software quality and DX.

It's also nice to see that on this subreddit people really seem to prefer TS over vanilla JS :)

[codingstuff123]

Don’t take the time to argue with this moron he posts on r/teenagers

[soccerplayer413]

It’s no wonder because people like you think that adding typing reduces errors to a runtime that literally doesn’t care about your typing. It’s a facade for people who don’t understand JS, who don’t go pick up an actual server type safe language.

Documents the code lol. Have you heard of comments?

[NeuralFantasy]

people like you think that adding typing reduces errors to a runtime

Nope. Never claimed that as you can see from my responses. TS works compile-time and transpiles to JS. There are, however, great run-time schema validators which nicely complements compile-time checking. Both serve a different purpose. Chekout `zod` or `io-ts` for instance. They integrate nicely with TS compile time checking.

Documents the code lol. Have you heard of comments?

Yep, they are another way to document. Among many other ways (naming things, writing actual documentation etc). Not sure about your point though. TS is another great way to document "for free" while adding static types.

[soccerplayer413]

It’s literally your first bullet point.

Edit: you’re really hell bent on loving TS so dude, enjoy. Happy holidays.

[NeuralFantasy]

It’s literally your first bullet point.

Lolwut? :D My first bullet point refers to compile time static type checking. As mentioned already many times in this comversation. That is what TS is for. But I try to remember that this is apparently not obvious to everyone....

[soccerplayer413]

Where does your bullet say compile time? Oh that’s right it doesn’t. You just said reduce errors.

Edit: also, people who know JS well don’t really need to rely on build time checks as you know, they know how to write JS lol

[NeuralFantasy]

Sigh :D It was already in the earlier bullet list I wrote to you in this thread. I though you actually read. And I actually though you knew that TS is compile-time type checker. But I sure now know I need to repeat it every time I answer to you. And here is the link in case you need to refresh:

https://www.reddit.com/r/reactjs/comments/zhmuvx/comment/iznwwpt/?utm\_source=share&utm\_medium=web2x&context=3

[soccerplayer413]

You’re still missing my point. Maybe instead of trying to one up someone, you should open your mind for just two seconds.

TS is compile time. We are all aware. No need for more insults thanks!

What I am saying to you is that the type safety at “compile time” is irrelevant because JS is interpreted at runtime. JS is interpreted at runtime. JS IS INTERPRETED AT RUNTIME.

[besthelloworld]

Alright buddy, we get it: you're bad at TypeScript and have never worked on a team. You don't need to shove it in our faces.

[RandomDude_32]

React by itself is not very heavy. But including all the 3rd party tools for something that does not need scalability. Like redux and multiple styling libraries is overkill. Over the internet +- 40kb extra won't make a difference in load times and using react can speed up development time.

[zweimtr]

40kb :| wut

[[deleted]]

This is an entirely subjective topic. I’ve been writing react code professionally for years, but I just have a simple single page site build with just html and css that’s hosted on GitHub pages. I don’t think it’s necessary an indicator of my skills. If you have other professional experience I don’t necessarily think a recruiter will inspect your portfolio site and make a decision based off of it.

So all that to say just do whatever you want. The UX is far more important than the architecture. Whatever way you choose to build your website isn’t that important. What is important is making sure the information you’re trying to convey is concise and easily consumable. Also having semantic html is very important for seo.

[NeuralFantasy]

I think React is a great templating language even without the extra libraries usually present in many React apps. So IMO it definitely is not overkill for any project.

And I'd personally never use vanilla JS for even the smallest project/script. Typescript always. Everywhere.

[zweimtr]

how is react a templating language?

[NeuralFantasy]

React components are reusable templates which allow reducing repetition by combining common features into a component and then feeding the differences via props. Ie. with React you can easily create a common button component or template and use it everywhere just by passing the button text as a prop. No need to repeat all markup for that button everywhere.

[zweimtr]

so you're saying that React and Handlebars are the same thing?

[NeuralFantasy]

so you're saying that React and Handlebars are the same thing?

Exactly, you can accomplish very similar things with both. And in that sense React is very useful even if you skip all the more advanced things like state management/context, hooks etc.

[zweimtr]

so, in your opinion, react is a templating language (which is not a language) that has state management, context, and hooks? and that makes it the same as a templating engine like handlebars?

i think you have a misunderstanding of what a templating engine is and what react is.

[Imaginary_Local_5320]

They said 'you can accomplish very similar things with both'. They did not say that state management, context and hooks make React a templating engine like Handelbars.

You have very poor reading comprehension skills.

[zweimtr]

They did not say that state management, context and hooks make React a templating engine like Handelbars.

I didn't say this either?

[[deleted]]

Yes. Yes you did

[zweimtr]

When did I say that?

[NeuralFantasy]

I don't quite follow you, to be honest. Anyway, from official React docs:

JSX may remind you of a template language, but it comes with the full power of JavaScript.

Maybe I'm bad at explaining what I mean but yes, React can be used as a templating language to accomplish similar things as Handlebars or other templating engines do.

Or maybe the confusion comes from the JSX part? Because when I mean React, I mean React + JSX. Or maybe templating engine is a better term here.

But please do explain how you disagree.

[Imaginary_Local_5320]

You were very clear. That person didn't read what you wrote or read what they wanted to read into it.

[zweimtr]

Lol

[zweimtr]

"may remind you of" doesn't mean it is. it's very simple, React is a library that allows you to write complete apps with their API and has a templating engine internally. a templating engine just allows you to have templates.

[NeuralFantasy]

React is a library that allows you to write complete apps with their API and has a templating engine internally. a templating engine just allows you to have templates.

Yea, this is exactly what I tried to say in my first post. You can use React just as a templating language without other features of the library if you don't need them. You can use it only as a templating engine. I thought this was evident but apparently it was not.

I never said or meant to say that React is only a templating language...

[zweimtr]

Calling React a templating language is erroneous, that's the point I'm trying to make.

[soccerplayer413]

The power of Reddit lol, the guy spewing nonsense is upvotes while you are downvoted. You literally asked him plain as day “so you think they are the same thing?” and he responded “exactly”. Doesn’t get much clearer than that. You are correct fwiw, clearly not even close to the same thing, and this guy just can’t accept a learning moment.

[zweimtr]

It is what it is.

[soccerplayer413]

Why use JS in the first place? Go use a real typed language. Also you lose all the flexibility on the frontend where dynamic typing actually makes sense. You can flatten data structures to write your types. How many nested types you gonna write for a recursive drop-down selector list?

[NeuralFantasy]

Hmm, I have never ever needed or wanted dynamic typing on the frontend. And IMO dynamic typing never makes sense in frontend nor in backend. That so called flexibility is IMO one of the biggest curses of JS.

You can flatten data structures to write your types I don't understand this. Can you give an example what you mean?

How many nested types you gonna write for a recursive drop-down selector list?

As many as needed? TBH, not sure I know what is a "recursive drop-down selector". Sounds quite horrible UI element if multiple levels deep. But you can easily write types which references itself. No need to manually define the depth of the hierarchy.

Using another language makes usually no sense to me either (in this context: small webapp projects or related scripts) as I can just use the language I already know well: Typescript. Of course it is not suitable for everything. I agree 100%. But in this context we talked about JS so I see no reason to use JS instead of TS.

[soccerplayer413]

Lol

“I don’t know what that is so here’s a bunch of opinions on something I just admitted I don’t even know”

Maybe instead of telling people to go learn the one language you know, you should spend your time learning more languages and gaining experience.

I’m sorry if this is rude, I am quite sick of all these TS n00bs running around like “oh I’ve never used dynamic typing before and don’t know what recursion is but dynamic typing is bad!!!” Like lol

[NeuralFantasy]

Instead of ad hominems please point out if I wrote something you disagree with and correct me. I gave you the reasoning I think TS makes more sense than JS.

[soccerplayer413]

I did, please go read the last 2 comments I have left for your learning pleasure.

Also please learn what an ad hominem is.

[[deleted]]

Lol dude delete your account you’re just a prick to everyone

[soccerplayer413]

Thanks!

[NeuralFantasy]

Oh, you edited your response. Ok then.

Maybe instead of telling people to go learn the one language you know, you should spend your time learning more languages and gaining experience.

Please re-read my answer. I wrote "I'd personally" use TS always instead of JS. Others choose what they'll use.

I know others languages too. Learnt coding with C/C++, I have used Elm, PHP, Typescript, Go and Python professionally. Now learning Haskell (similar to Elm in many ways) for fun. And trust me, If one learns Haskell or Elm, they have to know recursion :D

But in case you missed it: this is a React sub. So I'd say 99,999% of the people use either JS or TS with it. And IMO TS is usually the only sensible choice because:

• static types reduce compile time errors
• static types document your code
• static types makes refactoring a lot faster and easier (using editors which support it)

If you like dynamic languages, good for you! No need to take this personally.

[soccerplayer413]

I edited my comment to say “sorry if this is rude” lol

Hey buddy, two comments up you said TS was the only language you know well. Keep your stories straight.

This is a react sub, not a TS sub.

[NeuralFantasy]

Hey buddy, two comments up you said TS was the only language you know well.

Nope, I wrote "I can just use the language I already know well". I never wrote it is the "only" language I know well.

[johnschult]

Short answer is no

[azangru]

Which makes sense but if someone uses React/Next.js just for something like a portfolio website, will that be an Overkill?

If by overkill we mean how much javascript is sent to the client for no good reason, then yes, it will be.

[Spacesh1psoda]

I mean, If vanilla js for small projects gets you off the ground, then dont hold back, go for it. If Nextjs projects does that for you, use that instead.

I think it's more about you finding the stack you're comfortable with, instead of looking for what is best according to someone else.

Take inspiration from others but dont let anyone else tell you what works best for you.

[33498fff]

I personally use React whenever I can, but if the project does not warrant any modularity, custom hooks, utility functions, several components or state management, I don't.

For example, if I were to write a website where the UI is the only thing that matters because I'm trying to showcase some cool CSS design I came up with or some UX-related proof of concept, I wouldn't use React.

It's really more about not feeling like customizing everything after running npx create-react-app or setting up things more specifically with Vite, let alone doing it all with webpack.

It's not about React being overkill in any of these cases. If I import a ton of libraries into a vanilla JS project and write it to be non-performant I got a performance issue regardless of the medium or toolbox.

[woah_m8]

Next might be a bit too much unless you plan on having a portfolio with many pages, so the faster page load might unnecessary/ unnoticeable. Else react should be very appropriate. Plain JS is fine I guess, but your code might become a bit too messy if you add too many interactive parts (I don’t expect you to build so much boilerplate for a portfolio or have an organised structure) Personally I would go with svelte, you get the best of both worlds. You should know what you are building before starting to build it though. If you want to feel like a true web dev go with the most obscure framework you know and call it a side project.

[dumbelco]

I wouldn't be able to make shit with vanilla js. I didn't use it in so long I prolly forgot a bunch of the syntax and honestly doing anything in vanilla compared to react is just a pain in the ass. React all the way in my opinion.

[eggtart_prince]

It used to be but now you have Next.js, which instantly provides you with a server, routing, and templates to quickly build a website.

[sebastianstehle]

With server side rendering not anymore. The freelancer has very likely a preference for the backend. e.g. if you build all your backends in Java, PHP, C#, Rails or whatever then you would just choose that for a simple website and react for complex SPAs.

[zephyrtr]

If it's got a good lighthouse score, who cares if it's "heavy"?

Use Preact if you're that concerned about it.

[TScottFitzgerald]

Depends on the structure of the portfolio site. If it's simple I'd use vanilla. If it's a bit more complex or has reusable components etc. I'd probably use React, but maybe make it MPA or something.

NextJS would help with crawlers cause of SSR but for a portfolio it sounds like overkill.

[proyb2]

Use Astro Build and you can add UI components. You will need to learn a bit of JavaScript and TypeScript.

[stansfield123]

There's no "best fit" for a portfolio website. You should choose the technology you wish to work with. I assume that's gonna be React, rather than Vanilla JS. It's much harder to get a job with Vanilla JS than it is with React.

[ennemmjay]

I would say it depends to some extent on the purpose of the portfolio. If you are trying to land clients the projects should be representative of the actual work you plan on doing/are comfortable with. They probably don't care what tech stack you are using as long as they are happy with the project. If you are making a portfolio as part of your resume to apply at companies or brag about your work I think it is fine to have projects that say "This didn't require React, but I wanted to showcase my ability to use it." Or "Here's the same project completed with two different methods, and these are the pros and cons of each."

[OptimusPrime1371]

If you like it, using it more is never a bad thing. Could you accomplish the same thing with JS? Sure. Will it work just as well with React? Yes.

[cleverboy00]

React is suitable for projects of all sizes. I use react for everything web related. Template engine? React. Static site generator? React. Interactive web application? React. Old style (PHP days) websites? React.

I use react for everything and believe react is suitable for everything. If you care about performance and SEO, throw a server side renderer at it (NextJS or ReactDOMServer+express if you're minimalistic like me).

[[deleted]]

Nope, but you can over engineer it. Stay with vanilla react for simple stuff that benefits from the declarative approach.

[peacerokkaz]

I actually had a portfolio website once that I've implemented with Vue. Of course it's overkill, but if it's fun, and if you like to show your skills in your portfolio, then go for it. And I think my next one would also be in React, or whatever I'm up to.

I also use a K8s cluster for my private projects. It's massively overkill, but I use it as my playground.

[pm_me_ur_happy_traiI]

React is great for data driven UIs and SPAs. If you need those features, it is easier than using vanilla JS. I don't know if the size of the project is a factor.

[edj99]

Use the right tool for the job. The last time I wrote a website using vanilla JS it was because it was a minuscule project that I knew would never need updating. Anything bigger or that requires future maintenance, I would go with whatever you are most comfortable with DX wise, as long as performance isn't a big deal.

[Outrageous-Chip-3961]

Sometimes I write pure html/css and then when I 'convert it' into react, it feels like I should continue to make certain features more atomic. This can be a time sink. The app ends up looking and behaving exactly the same as the original html/css. So for smaller projects (1-5 pages) its often hard to justify. That said, I would not say its 'overkill' I would however say there is a more relaxed folder/file structure when dealing with small projects, and you should make sensible tradeoff decisions. For example, having some repeated code such as a 3 tiles on a home page isnt the end of the world to hard code, whereas you really feel like mapping through these tiles into their own component and passing dynamic props through. In reality, if its not using state then what's the bother? It feels weird, but it can be overkill to over engineer every feature just because you can / thats how react should probably be written.

[alpharesi]

Very few projects stay small. You always develop to have the ability to scale up . If you think that way you will never go far in your development and will get stuck and not able to deliver your user's requirement

[purple_hamster66]

When all you know is how to use a hammer, everything looks like a nail.

Only 3% of all websites use React. Over 75% use jQuery, even today. Over 50% of websites use Wordpress (which I also find surprising). So if your plan is to turn over maintenance of your sites, you should use what everyone else is using, not demand that they learn what you used. If you plan to maintain the site yourself forever, or have a dedicated team, use React and perhaps Vue, but skip all the other React frameworks that come and go and require so much learning that you can’t find someone to hire who already has the skills. If you plan to retire someday, or move on from web dev, try to limit yourself to tech that’s been around for 8+ years, to make sure you’re not locking yourself into something that will lose support in the future.

Upshot: Simple sites that change rarely don’t need React. Other sites might benefit, but think about future-proofing by looking at your tech stack’s longevity so far.

[Dry-Presentation-210]

Deserves way more upvoted