HACKER Q&A
📣 kirso

Should I even bother with React?


Geniunly curious and not competent to answer this myself.

I am a hobbyist. I don't intend to take a career in front-end (maybe in a decade) and just hacking away on my own small projects using external APIs. It is probably for another post but after being scared of coding for such a long time, it seems so interesting and kind of a new world (despite the frustrations obviously).

The thing is, I came quite late to it and learned the basics of HTML, CSS, JS whilst finally delving into React which has been... welll confusing. It generally feels like an overkill and learning new things about it not enjoyable anymore as a beginner.

I have delved into Svelte in the past week and it just has been a completely different story. I am not associated with them, and I am not trying to promote it as I want to just ask whether React felt as frustrating as for me or am I missing something?


  👤 _fat_santa Accepted Answer ✓
React is a very heavy handed framework. There are many things in react that are React specific like state, effects, context, etc. For large projects its fantastic because you would want all those things but for smaller projects it's complete overkill unless you're already familiar with it.

I suggest you look at these frameworks:

* Vue: Personally have never used it but from everything I heard, it's much easier and more straightforward than React.

* Svelte: I've used this framework and it's amazing. Intuitive and very fast. Some things are specific to svelte and sveltekit but for the most part you are writing plain HTML, CSS and JS code.

* SolidJS: Also have never used this but heard good things about it. It uses JSX tags just like react does but it's far far simpler.

There's also Preact but it's main selling point is to be a "lighter" React, so expect similar complexity here.


👤 idontwantthis
For a hobby, don’t use anything that stops you from producing.

If deadlifting is stopping you from going to the gym then go to the gym and just don’t deadlift.


👤 wruza
React as a library (and a rendering idiom) is not complex enough for you to not decide for yourself whether to use it or not.

But “React” community practices include approaches that you may find anywhere on why..yagni..cargocult..bizarre spectrum. Even it’s own state management routines require you to think orthogonally to everything you know and used before. So as a rendering engine it’s okay, and maybe the best due to its widespread nature, but I wouldn’t go any deeper than that.

On the pro side, React isn’t tightly coupled to its state, so you can connect your own state to its rendering cycle. If your hobby is making products, not frameworks or meta-things, it has no value for you in my opinion. Stick with svelte, vue or lesser frameworks like mithril, whichever fits your needs better.

This opinion comes from a guy who avoided web ui like hell, but had to take a dive 3 years ago. Since then I used vue, mithril, react, researched multiple lesser/toy frameworks. Before that I was using Gtk/Gdk, Qt, Wx, AppKit, UIKit at work, and was toying with many desktop/mobile ui frameworks including the ones created by myself. Frankly, React feels like a pile of… idk it’s not even BS, something completely out of this world. As if someone learned nothing but js and html, read about FP and made first insecure steps into this journey.


👤 ddek
As someone who knows react fairly well, I'd generally say yes. Building off a component library like Material UI or Chakra I can making basic SPA's is like playing with lego. If all I need is a frontend to a service that, say, plays MIDI recordings on a raspberry pi attached to my digital piano; this is perfect.

The upside is the components are so compose-able once you have them (buttons, forms etc) it's easy to build apps. Also the fundamental idea, UI as a function of state, makes the app much simpler, because invalid states are harder to reach (generally presuming typescript).

The downside is it is quite large time investment to become proficient. The 'UI as a function of state' idea makes some simple things (anything with side effects) awkward, because the raw idiom doesn't allow for it. There are also rabbit holes of complexity you can easily get stuck in, like redux or integrating rxjs, because the simpler ways aren't always obvious.

I feel like the function of state stuff is the tacit knowledge part that is actually most important but I'm kinda skipping it. The bit I like the most is the lego bricks. Building web apps with component libraries and not having to think at all about HTML or CSS if I lower my standards a bit.


👤 kitsunesoba
Even as someone who’s been writing code for around 15 years and has worked as a dev for 7 years, I really wish something like React was built into browsers.

All of the external tooling required is a huge turnoff… I wish it weren’t necessary. If I could just fire up a browser and plain text editor and start writing a reactive web app with zero dependencies like I do for plain HTML/CSS/JS sites that would be like a dream.


👤 IceDane
You should probably try to understand why React(and other similar frameworks) were created.

If you have very little experience and have only built simple things, the disadvantages of building a web application using traditional imperative DOM manipulation won't be clear to you. But as soon as you start building something complicated, these disadvantages start to show themselves pretty fast.

Imagine that your application is complicated and needs data from many different API calls and has a lot of state which can cause it to do different things at different times. With simple DOM manipulation, you will end up with a codebase where nearly any part of it can be doing modifications to the DOM, regardless of what else is happening, and you will probably spend quite a bit of time fixing bugs from, say, two async functions running at different times and thus resulting in a broken DOM or something.

To remedy this, you take a step back and you figure that you should probably build an abstraction which takes care of this. You do things in stages: 1. Do all async work 2. process data 3. render UI from data. Now things are certainly a bit simpler and you've avoided the DOM race conditions, but you're running into performance issues, because you're re-rendering your entire application from scratch every time you get new data.

You can optimize this on a case-by-case basis and try to ensure that some of it can happen in parallel, but to do it generically, you essentially have to do reconciliation.. and at this point, you're already halfway to writing something like react/angular/vue, just minus the millions of manhours that have gone into those frameworks to make them work as well and as efficiently as they do.

I think that you should do whatever you feel like doing because that will give you the best experience. But I think picking up something like React will definitely benefit you in the long run, and if you ever decide to try to do this professionally, it is pretty unlikely you'll find a place that builds serious web apps using vanilla JS / CSS / HTML(and even if you did, you probably don't want to work there).


👤 eyelidlessness
In the past I would recommend React because it was exceedingly simple, but easily adaptable to any kind of complexity you might bring to it. Today, it is definitely more complex than it ought to be.

To be honest, I think it’s best to learn React without hooks first. Hooks are very confusing from the start, with far too many rules and too much ceremony for an API that looks simple. Without hooks:

- Most components are pure functions of props, which is why React was appealing in the first place

- You can manage state however you like, again React’s original value proposition

- You’re encouraged to actually isolate those cases! This is woefully uncommon in many React codebases.


👤 schwartzworld
There's a point that I haven't seen made on the thread yet.

React requires a very particular mental model. You define a state for your app and your view is a function of that state. Most of nuance of writing react has to do with deciding where state belongs and how to model it. This is very powerful.

I believe it is worth learning React to grok this model alone, and you can absolutely apply it to other frameworks and even other aspects of building apps.


👤 ramoz
Theres no reason for you to learn React. You’d probably end up doing some cool things with it, but eventually it becomes exhausting the larger your thing becomes. State management in react will ruin any fun you might have.

👤 ilaksh
I'm going to say something unpopular: it is possible to build and deploy real applications with just plain JavaScript and HTML. Not even Svelte and TypeScript. Just Javascript. I don't even use a CSS framework.

Yeah you are allowed to do that if you are a hobbyist, or if you are like me and a solo developer of a product. We are allowed because no one can stop us.

Component frameworks are useful though, and it is likely that if you bring in another developer to your project at a later date they will want to do it over in React or whatever flavor-of-the-month they like.

In my opinion, if this happens it's okay, because by that time there will be new frameworks and web languages that are popular (e.g., suddenly next year all the cool kids build websites in Ocaml, Dream 3.0 and web assembly) and the old framework you used won't even necessary be relevant anymore. Also no one really wants to pick up another person's large codebase anyway. They will be happy to do it over their own way.


👤 azeirah
As a hobbyist, just do whatever you feel most comfortable with.

React is designed for businesses to work on large applications. It can be nice to use if you know it well enough, but you certainly don't need it.

There is nothing you can do with React that you can't do with other frameworks, or even in vanilla js. It can make certain things easier, like testing UI components due to its functional design (ie, a component will always be exactly the same given the same input), and going back and forward through time is harder to do without React-adjacent libraries like redux.

Don't worry about it. Sometimes vanilla js or other frameworks are honestly just faster or better suited, especially if you work alone.


👤 sysadm1n
If you're learning React just to get a job, you're doing it wrong, since recruiters are always changing their requirements. They will add `proficient in Svelte` just to annoy you, (after having learning React) and now you're no longer relevant to them.

That's why I say: stick to the baseline of HTML, CSS, & JS. Learn to write vanilla JS for common things, maybe learn UmbrellaJS[0] for syntactic sugar and manipulating the DOM.

Oh and learn some APIs to do back-end stuff too. And for forms, there's loads of projects out there to automate that[1]

[0] https://umbrellajs.com/

[1] https://www.producthunt.com/search?q=forms


👤 adamleithp
As someone who’s used both extensively:

Svelte is just perfect for small to medium projects. I’ve never used Svelte in a professional team environment though. And that’s where React is best- enterprise environment with a team.

For hobby; svelte 100% Less boilerplate, super easy set up and you write less code in general.


👤 monroewalker
I agree with the others about the shortcomings of React, but one thing to consider is the benefits of it's popularity. You'll find way more tutorials, articles, forums, etc for solving a problem in React than for any of the others. Not to say the other frameworks and tools don't have considerably large user bases and helpful communities - they certainly do - but you're just more likely to find solutions to niche problems when you Google. And if you can't find something on Google, you have a larger community of users that might respond to a request for help with your scenario. Plus there are more components and plugins than for other frameworks.

That being said, it's probably much easier to learn and more fun to use some of the alternatives.


👤 engineerDave
If you have a good framework behind your project, e.g. Rails, Phoenix. You probably don't need it. I'm a primarily a ruby/Rails developer who is slowly switching to Elixir/Phoenix, and I find myself reaching for React when I need to do very complex User Interface components, mostly Rails. Most of my Phoenix apps so far haven't had big UI components. Outside of that Rails' or Phoenix's built in unobtrusive JS, the new hotwire stuff, or Phoenix's live view is more than sufficient IME. If you're doing a JS based single page app then perhaps but it's pretty complicated and there are probably easier options.

👤 meitros
I would take a look at vue and see what you think. It should be simpler and feel more familiar, and it’s been around long enough that folks have made complex frontends with end.

(I spend all day in react and like it, but understand people’s reactions.)


👤 scotty79
If it doesn't feel right for you skip it for now.

Only after you get frustrated by adhoc nature of all the frameworks that rely on arbitrarily hacking html syntax and get lost in tangle of event listeners, triggering who knows what and when and in what order and state distributed over various html tags you might come to appreciate react revolutionary model and its exceptional consistency and composability.


👤 gobr
I think the best way to know this is going through the React Tutorial, https://reactjs.org/tutorial/tutorial.html, and then decide for yourself.

👤 mlboss
It is an overkill unless you need highly dynamic web pages. I would start with server side rendering provided by rails/django. Dynamic components can be added later using hotwire/htmx.

👤 duxup
I work with React every day.

As a hobbyist, if you’re getting what you want out of vanilla JS, stick with that.

There’s no reason to chase all the frameworks if you’re already accomplishing what you want.


👤 dave4420
If React doesn’t click for you, Svelte does, and you’re not looking to make a career out of it soon either way, just go with Svelte.

👤 Epskampie
I’d say trust your gut. You actually tried both, wich os more than most would do, and you like svelte better. Why look further?

👤 DLA
I’d have a look at how far you can go with AlpineJS. Love it’s simplicity to add robust interactivity to web pages.

👤 gfykvfyxgc
Do what makes you happy …. that’s what makes software development fun.

👤 andrewfromx
If you have the option go for https://www.vugu.org/ and use the go language. Much better language started by google in 2006 vs JavaScript which was started in I think 1995?