Ask HN: Should I even bother with React?
55 comments
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.
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.
Why did Gatsbyjs not make this list?
Because Gatsby is built with React.
It’s also extremely opinionated and generally taking a backseat to tools like Next.js if your team wants an opinionated starting point.
It’s also extremely opinionated and generally taking a backseat to tools like Next.js if your team wants an opinionated starting point.
I’ve been using Vue since 2017 and unfortunately there is a sustained effort to make it more difficult to use and understand for vague and constantly redefined benefits.
The change is essentially a clone of reacts “hook” API, it’s called Composition API and it also makes reactivity now much more verbose again with no real explanations why it must be so.
I still consider the way most people using Vue to be the most productive - the retroactively named Options API where you have a simple object defining a component.
Initially it was advertised as “this should only be for advanced components perhaps the sort you’d find in a component library” but now it is “use it for everything lol”.
It is a shame that one of the things that appealed to developers and lead to its wide spread adoption due to its low friction approach is now so often overlooked or ignored because internally there’s a desire to have feature parity with React and all the downsides of that.
I also don’t believe the Typescript argument where they claim composition API has better support, with Vue 3, TS, and Options API I’ve yet to find any downsides.
These changes are troubling enough, but when you add in the constant build tooling churn (eg instead of making a breaking change to Vue CLI they’d rather suggest people use a whole different tool, while still maintaining both) or the fact that the Vue component testing library has some serious conflict of interest with Cypress the organisation that I believe has lead to poor judgment and deprecation of certain aspects of the unit testing library…
It certainly has been disappointing to see this happening. It makes me worried about the future of Vue with this deliberate fragmentation.
The change is essentially a clone of reacts “hook” API, it’s called Composition API and it also makes reactivity now much more verbose again with no real explanations why it must be so.
I still consider the way most people using Vue to be the most productive - the retroactively named Options API where you have a simple object defining a component.
Initially it was advertised as “this should only be for advanced components perhaps the sort you’d find in a component library” but now it is “use it for everything lol”.
It is a shame that one of the things that appealed to developers and lead to its wide spread adoption due to its low friction approach is now so often overlooked or ignored because internally there’s a desire to have feature parity with React and all the downsides of that.
I also don’t believe the Typescript argument where they claim composition API has better support, with Vue 3, TS, and Options API I’ve yet to find any downsides.
These changes are troubling enough, but when you add in the constant build tooling churn (eg instead of making a breaking change to Vue CLI they’d rather suggest people use a whole different tool, while still maintaining both) or the fact that the Vue component testing library has some serious conflict of interest with Cypress the organisation that I believe has lead to poor judgment and deprecation of certain aspects of the unit testing library…
It certainly has been disappointing to see this happening. It makes me worried about the future of Vue with this deliberate fragmentation.
I'm so glad to read this, because I feel like all I see anywhere about Vue is that it's "better than react"... and having used both extensively, that is most definitely not the case.
Like I said elsewhere, React is a set of extremely simple, foundational building blocks that groups of extremely smart people have thought very long and hard about. Vue is, IMO, like someone's knee-jerk reaction to not understanding React and deciding they would build their own framework that does things in ways they think make sense.
The result is just more redundant complexity, worse tooling and a horrible, dead ecosystem with awful libraries or components that are barely even usable.
Like I said elsewhere, React is a set of extremely simple, foundational building blocks that groups of extremely smart people have thought very long and hard about. Vue is, IMO, like someone's knee-jerk reaction to not understanding React and deciding they would build their own framework that does things in ways they think make sense.
The result is just more redundant complexity, worse tooling and a horrible, dead ecosystem with awful libraries or components that are barely even usable.
I definitely prefer Vue over React and I believe it’s still a better version of it but this composition api bullshit has really caused a lot of people to question the whole thing.
And by people I mean the actual developers using it in production, not the dozens of charlatans hyping the latest change or addition with millions of demonstrations at the latest conference of how composition api hello world is somehow better than what already exists.
Alienating the actual fans and users alike is a poor strategy.
——
As for the build tooling and dead ecosystem and poor components yes I absolutely agree, it’s a bit of a dumpster fire. There’s certainly good libraries and components but in comparison it’s miles away from react.
One of the things I strongly dislike about Vue is the fact it’s prototype is just freely floating around everywhere and all the plugins just attach garbage to it and then get users to do the same.
A strong lack of software engineering practices and competence means that on average many Vue libraries are absolutely horrible to use with equally awful code. In many cases it’s been better so simply have a quick scan of what a library or component is doing and then write a better version yourself - this time with actual unit tests and linted code.
For example, find some library that does something fancy with the DOM like a tooltip or some animation or some wrapper for a popular library.
The process is like this:
> Google for it and find 1 or 2 results
> One was last updated in 2017 and has “Vue2” in the package name (poor)
> the other mostly works and has a few hundred GitHub stars simply because it’s the only one
> use it and find some edge case that makes it useless
> also discover it doesn’t use slots (the actual way to do “composition”, much like reacts child render props to allow components to be inside others) meaning it’s now fully useless for your use case
> write your own version, based roughly on the code in the library - and read the unit tests to make sure you account for anything else you might not have thought about (if it even had any tests, most don’t because it was written by someone that barely knew what they was doing or is the kind of person who hates testing (because then they don’t have to be accountable) you have to argue with over the value of unit tests)
> job done, many days or weeks later
This poor ecosystem seems to go hand in hand with a vocal minority of Vue users that seem hopeless at trying to debug any of their issues or self inflicted bugs.
And by people I mean the actual developers using it in production, not the dozens of charlatans hyping the latest change or addition with millions of demonstrations at the latest conference of how composition api hello world is somehow better than what already exists.
Alienating the actual fans and users alike is a poor strategy.
——
As for the build tooling and dead ecosystem and poor components yes I absolutely agree, it’s a bit of a dumpster fire. There’s certainly good libraries and components but in comparison it’s miles away from react.
One of the things I strongly dislike about Vue is the fact it’s prototype is just freely floating around everywhere and all the plugins just attach garbage to it and then get users to do the same.
A strong lack of software engineering practices and competence means that on average many Vue libraries are absolutely horrible to use with equally awful code. In many cases it’s been better so simply have a quick scan of what a library or component is doing and then write a better version yourself - this time with actual unit tests and linted code.
For example, find some library that does something fancy with the DOM like a tooltip or some animation or some wrapper for a popular library.
The process is like this:
> Google for it and find 1 or 2 results
> One was last updated in 2017 and has “Vue2” in the package name (poor)
> the other mostly works and has a few hundred GitHub stars simply because it’s the only one
> use it and find some edge case that makes it useless
> also discover it doesn’t use slots (the actual way to do “composition”, much like reacts child render props to allow components to be inside others) meaning it’s now fully useless for your use case
> write your own version, based roughly on the code in the library - and read the unit tests to make sure you account for anything else you might not have thought about (if it even had any tests, most don’t because it was written by someone that barely knew what they was doing or is the kind of person who hates testing (because then they don’t have to be accountable) you have to argue with over the value of unit tests)
> job done, many days or weeks later
This poor ecosystem seems to go hand in hand with a vocal minority of Vue users that seem hopeless at trying to debug any of their issues or self inflicted bugs.
Solid is awesome. But while its reactivity is simpler than React hooks in that they have fewer rules (i.e. you can call them conditionally), it imposes other rules that people may find challenging (limits on destructuring, requiring functions where you might expect to be able to use a reference directly).
Preact is actually a good alternative not just for its size/perf advantages. It’s also significantly easier to read and understand the internals, which may help some learners find their way where they would otherwise get lost in React.
Preact is actually a good alternative not just for its size/perf advantages. It’s also significantly easier to read and understand the internals, which may help some learners find their way where they would otherwise get lost in React.
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.
If deadlifting is stopping you from going to the gym then go to the gym and just don’t deadlift.
Yesssir, thats kind of a philosophy I am looking at. Was just wondering where to spend time React vs Svelte wise...
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.
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.
> Even it’s own state management routines require you to think orthogonally to everything you know and used before
What do you mean by this? I've really only used React in my career so I don't have a frame of reference. Are you just talking about having to keep immutable state?
What do you mean by this? I've really only used React in my career so I don't have a frame of reference. Are you just talking about having to keep immutable state?
It’s just too much to tell on a forum. You may start here https://developer.apple.com/library/archive/documentation/Co... (it’s not really Apple specific, it just has good overview guides). If you want a quick answer, state lives apart from views and is controlled by either predefined or custom behavior. It also doesn’t have to be flat (which React endorses) and smeared over a hierarchy of tiny proxy “components” which cannot really live outside of that hierarchy. Also, cocoa way is not the only way, and React is compatible with other approaches, some of which react guys call “stores”.
Have you ever actually used React? I ask because the only way I can think of you writing the things you did is if you lack understanding of, well, react fundamentals. I don't think you understand what React does, or why or how it works if you think that react's state management is just some redundant complexity that it added just for shits and giggles.
If you mean React as a library, then yes, not at work though. If you mean React as the community does it, well no, too much repetitive code to do basic things.
I don't think you understand what React does
I’m afraid that anything I say here would lead you to think that I was jQuery, but no, I never wrote a line in it. I had these conversations before, so please excuse me for this digression. I know how React works, and I could build it myself, barring some optimizations. You are right, I don’t “get it”, but not in a sense of how it works, but why it does that. It solves the issue that exists in jQuery and other call-manual-update approaches, but that is not an issue in what I worked. It reinvents a wheel that was already there when it was born. I spent enough time with it and its community to check these ideas.
I’d like to hear what you have to say though. Maybe there is something I missed.
I don't think you understand what React does
I’m afraid that anything I say here would lead you to think that I was jQuery, but no, I never wrote a line in it. I had these conversations before, so please excuse me for this digression. I know how React works, and I could build it myself, barring some optimizations. You are right, I don’t “get it”, but not in a sense of how it works, but why it does that. It solves the issue that exists in jQuery and other call-manual-update approaches, but that is not an issue in what I worked. It reinvents a wheel that was already there when it was born. I spent enough time with it and its community to check these ideas.
I’d like to hear what you have to say though. Maybe there is something I missed.
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.
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.
I love the components part, my personal webiste is in Next.js but I really struggle to understand the "state mental model" and I guess thats what puts me off :)
Even from tutorial perspective, people tend to explain react like here is useState and if you do this, you can now update other parts. But I am a newbie so I guess its either sucking up and spending more time with it or just struggling with trying to solve the same things with more code in vanilla ¯\_(ツ)_/¯
Even from tutorial perspective, people tend to explain react like here is useState and if you do this, you can now update other parts. But I am a newbie so I guess its either sucking up and spending more time with it or just struggling with trying to solve the same things with more code in vanilla ¯\_(ツ)_/¯
Does this person need to be building an SPA though?
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.
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.
You mean like Web Components?
It looks like web components are a nice way to encapsulate components for reuse, which is great but it doesn’t seem like it would enable one to write React-like code without dependencies or an external toolchain… am I missing something?
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).
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).
Thanks for the extensive perspective. I totally agree that React seems like a use-case for enterprise and complex web apps. I would definitely find it beneficial to learn about it, but my time is limited and I only do it to build my small projects.
Thank you for the great examples on complexity though - was really helfpul to understand.
Thank you for the great examples on complexity though - was really helfpul to understand.
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.
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.
Wow I didn't even know thats possible.
On the isolation part, I feel like if Hooks were taught in a bit of a different way particularly with the isolation example, it would probably be less scary. I learned something new today :)
On the isolation part, I feel like if Hooks were taught in a bit of a different way particularly with the isolation example, it would probably be less scary. I learned something new today :)
I think it's not react that's complex. react ecosystem is very complex. There are so many options available as best practics that you can go. making the choices you really need, yeah that's the hard one.
I really do think React itself is complex, and its complexity keeps growing. There is a very simple subset, for sure, but all of these are challenging for mere mortals, either to learn or to use effectively:
- Hook rules in general
- Hook semantics for basically everything except useState
- Suspense
- Portals
- Server Components (I know it’s still considered “experimental”, but it’s already in use by large projects/meta-frameworks)
- Even the “new JSX transform” has a couple footguns
Of course you don’t have to use any of those, but for most real world front end projects that would likely mean reaching for ecosystem tools which, as you said, come with their own complexity and choice on a paralyzing scale.
- Hook rules in general
- Hook semantics for basically everything except useState
- Suspense
- Portals
- Server Components (I know it’s still considered “experimental”, but it’s already in use by large projects/meta-frameworks)
- Even the “new JSX transform” has a couple footguns
Of course you don’t have to use any of those, but for most real world front end projects that would likely mean reaching for ecosystem tools which, as you said, come with their own complexity and choice on a paralyzing scale.
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.
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.
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.
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.
For sure, I think if you can achieve certain things faster with a framework then why not as well? I guess if its a very simple app JS is totally enough and vanilla CSS as well. But if I would be say building a marketplace app, without the framework I would probably spend double the time and reinventing the wheel. That being said I agree that its not cool to constantly search for the next best framework - the thign is, I am looking for a first one :)
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.
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.
[deleted]
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
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
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.
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.
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.
That being said, it's probably much easier to learn and more fun to use some of the alternatives.
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.
Interesting, what made you go from Rails to Elixir? I always thought that Rails community is great and is a good fit for side-projects and micro-SaaS apps. But yeah, I would say in most cases vanilla JS is fine, and will depend on the case and complexity of the app itself!
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.)
(I spend all day in react and like it, but understand people’s reactions.)
I second this. React is a fantastic framework but does alot of things "it's own way" so unless you already know it, it's going to be much harder to get going with it.
In what way do you think that React does things "its own way" that Vue doesn't?
React is easily the simpler of the two, and Vue is the one that forces you to do things "its way" a lot more than React does.
If you're referring to being able to, say, interact with state by just mutating it.. well, that's because Vue has a built in reactive state system that works similar to Mobx.
In react, you can just use Mobx.. or recoil, or redux, or even your own custom state management system if you really wanted to(as long as it talks to react properly).. In vue? Maybe, sort of, but you've already bought into one heavy-handed abstraction which is their own reactive stack, so the best you can do is build on top of that.
React is easily the simpler of the two, and Vue is the one that forces you to do things "its way" a lot more than React does.
If you're referring to being able to, say, interact with state by just mutating it.. well, that's because Vue has a built in reactive state system that works similar to Mobx.
In react, you can just use Mobx.. or recoil, or redux, or even your own custom state management system if you really wanted to(as long as it talks to react properly).. In vue? Maybe, sort of, but you've already bought into one heavy-handed abstraction which is their own reactive stack, so the best you can do is build on top of that.
Vue is easily the more complicated of the two. React is basically a very, very minimal foundation for generating a DOM. Vue is like React but with a lot more batteries included.. and much worse abstractions, much worse ecosystem, worse tooling and at least IME, worse performance and harder to optimize.
React is basically: JSX, useEffect, useState(plus a couple more) and reconciliation. React is the result of a group of very talented people spending a lot of time thinking about what the core of a framework like this should be. There is a very good reason react doesn't have more bells and whistles, because it's basically at a local minimum(in terms of complexity). What we have are tiny, simple foundational building blocks from which we can build larger and more complicated abstractions. There is nothing else in this space that is as simple: Angular and Vue are both basically "react with more bells and whistles", and sveltejs requires an entire compiler and has its own share of problems.
React is basically: JSX, useEffect, useState(plus a couple more) and reconciliation. React is the result of a group of very talented people spending a lot of time thinking about what the core of a framework like this should be. There is a very good reason react doesn't have more bells and whistles, because it's basically at a local minimum(in terms of complexity). What we have are tiny, simple foundational building blocks from which we can build larger and more complicated abstractions. There is nothing else in this space that is as simple: Angular and Vue are both basically "react with more bells and whistles", and sveltejs requires an entire compiler and has its own share of problems.
There is. Mithril.js is much simpler than React, doesn’t reinvent wheels (onChange et al), loads faster, uses the same rendering method, is state-management agnostic, and integrates well with anything else. You seem like being sort of short-sighted by React hype against jQuery. Mithril is the core of immediate mode rendering reconciliated into DOM. React is too, but only in a sense, iff you use it’s preact version to undo synthetic events and skip its own state routines.
To save you an hour or so of reading its guide, the only key difference between Mithril and React is how VDOM updates are handled. Mithril always renders the entire “v-screen” on any vnode-related event out of an assumption that it changed something and DOM shouldn’t be too large in its div size. You can take it down with e.g. heavy svgs, but that is also true for vue, react, whatever. No framework can compare tens of thousands of vdoms efficiently, it’s always >= O(n). These cases are handled by mounting sub-apps at these points, so that redraws don’t descend and events don’t bubble up. React also advises against that and suggests “windowing”, also a very fresh and interesting approach (for those of course who still aren’t aware that it’s called a scroll view controller and is the core of all desktop ui frameworks since circa 1990).
To save you an hour or so of reading its guide, the only key difference between Mithril and React is how VDOM updates are handled. Mithril always renders the entire “v-screen” on any vnode-related event out of an assumption that it changed something and DOM shouldn’t be too large in its div size. You can take it down with e.g. heavy svgs, but that is also true for vue, react, whatever. No framework can compare tens of thousands of vdoms efficiently, it’s always >= O(n). These cases are handled by mounting sub-apps at these points, so that redraws don’t descend and events don’t bubble up. React also advises against that and suggests “windowing”, also a very fresh and interesting approach (for those of course who still aren’t aware that it’s called a scroll view controller and is the core of all desktop ui frameworks since circa 1990).
I wrote a bit of a rant about Vue if you’re interested further up the threads
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.
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.
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.
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.
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.
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.
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.
I’d have a look at how far you can go with AlpineJS. Love it’s simplicity to add robust interactivity to web pages.
[deleted]
Do what makes you happy …. that’s what makes software development fun.
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?
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?