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?
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.
If deadlifting is stopping you from going to the gym then go to the gym and just don’t deadlift.
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.
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.
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.
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).
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.
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.
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.
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.
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]
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.
That being said, it's probably much easier to learn and more fun to use some of the alternatives.
(I spend all day in react and like it, but understand people’s reactions.)
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.
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.