13 ms·

Ask HN: Should I even bother with React?

• Epskampie 5y ago
  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?
  • kirso 5y ago
    Guess, I thought I was missing something ¯\_(ツ)_/¯ but you are right!
• idontwantthis 5y ago
  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.
  • kirso 5y ago
    Yesssir, thats kind of a philosophy I am looking at. Was just wondering where to spend time React vs Svelte wise...
• dave4420 5y ago
  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.
• azeirah 5y ago
  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.
• wruza 5y ago
  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.
  • _fat_santa 5y ago
    > 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?
    • wruza 5y ago
      It’s just too much to tell on a forum. You may start here https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaBindings/CocoaBindings.html 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”.
• andrewfromx 5y ago
  If you have the option go for https://www.vugu.org/ 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?
• mlboss 5y ago
  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.
• adamleithp 5y ago
  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.
• duxup 5y ago
  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.
• meitros 5y ago
  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.)
  • _fat_santa 5y ago
    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.
    • IceDane 5y ago
      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.
  • IceDane 5y ago
    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.
• _fat_santa 5y ago
  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.
  • tartakovsky 5y ago
    Why did Gatsbyjs not make this list?
    • yurishimo 5y ago
      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.
  • lloydatkinson 5y ago
    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.
• IceDane 5y ago
  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).
  • kirso 5y ago
    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.
• ramoz 5y ago
  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.
  • kirso 5y ago
    Funny that you mentioned it, thats where it went wrong for me :)
• gfykvfyxgc 5y ago
  Do what makes you happy …. that’s what makes software development fun.
• deleted 5y ago
  [deleted]
• ddek 5y ago
  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.
  • gexla 5y ago
    Does this person need to be building an SPA though?
  • kirso 5y ago
    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 ¯\_(ツ)_/¯
• kitsunesoba 5y ago
  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.
  • ilaksh 5y ago
    You mean like Web Components?
    • kitsunesoba 5y ago
      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?
• DLA 5y ago
  I’d have a look at how far you can go with AlpineJS. Love it’s simplicity to add robust interactivity to web pages.
• scotty79 5y ago
  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.
• schwartzworld 5y ago
  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.
• ilaksh 5y ago
  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.
  • kirso 5y ago
    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 :)
• deleted 5y ago
  [deleted]
• gobr 5y ago
  I think the best way to know this is going through the React Tutorial, https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html, and then decide for yourself.
• eyelidlessness 5y ago
  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.
  • pictur 5y ago
    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.
    • eyelidlessness 5y ago
      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.
  • kirso 5y ago
    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 :)
• engineerDave 5y ago
  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.
  • kirso 5y ago
    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!
• sysadm1n 5y ago
  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/ https://umbrellajs.com/ [1] https://www.producthunt.com/search?q=forms https://www.producthunt.com/search?q=forms
• monroewalker 5y ago
  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.