5 ms·

React feels pretty settled now, it's been out for 10+ years, hooks and functional components have become the standard. If you want to learn it I think it's at

React feels pretty settled now, it's been out for 10+ years, hooks and functional components have become the standard. If you want to learn it I think it's at a mature enough place. Popular libraries like redux have been rebuilt to use hooks and simplify the integration. I'd also check out Remix[0] if you wanted to get into a React framework. It's fairly new but extremely promising and easy to get up and running and even deployed anywhere (express server, cloud flare workers, deno, etc) [0] remix.run

ozzythecat 5y ago
The last time I did web development, I used Angular 1.2 or something like that. I had some forms and many different views that talked to some REST APIs. It was never clear to me why/when I would need React. I read and worked through some tutorials years ago, and while the reactive/one way flow pattern was nice, I never had a problem with Angular. I recognize there have been many versions of Angular since then. And there are several web development frameworks, complex build tooling, etc. etc. Meanwhile, I’m still writing services in Java that handle 20,000 requests per second for a service that brings in revenue in the billions of dollars a year. And I’m writing C++ (very straightforward, no templates, few uses of pointers, etc) for cross platform mobile code. I have some Spark pipelines all written in Scala. Meanwhile the web stack continues to evolve… new technologies all just for rendering web pages. I don’t understand why. Admittedly there’s far more complexity in our use cases today than the HTML I was writing in 1999, but much of it is unnecessary bloat from bored developers.
- montblanc 5y ago
  Old Angular wasn't such a bad framework actually...
  - KronisLV 5y ago
    Sometimes running into AngularJS was not too bad of an experience, since it's relatively simplistic when compared to what's needed to get it running (no complicated toolchain, such as with TS -> JS). But most of the times it's a pain, because of it not scaling well to larger projects. I've actually seen projects where controllers grow to the length of thousands of lines because the developers didn't feel comfortable with introducing new ones in the pre-existing codebase, due to how the scoping works, due to how they'd need to set up the data models and care about initialization of everything, as well as custom integrations with validation libraries and other JS cruft (due to it not quite being "battieries included", like the new Angular is). Now personally, i really liked how they did error messages (which gave you URLs that you could navigate to, with a bit of context in them; though it would be better with a locally hosted docs server), but a lot of things were awkward, such as their binding syntax: https://blog.krawaller.se/posts/dissecting-bindings-in-angularjs/ https://blog.krawaller.se/posts/dissecting-bindings-in-angul... Luckily, AngularJS seems to finally be dead, so we'll get to migrate to something else soon, hopefully. And the projects that won't will be red flags enough for the people who don't like such challenges to turn the other way - truly a litmus test of sorts.
berkes 5y ago
> hooks and functional components have become the standard Now if only the React ecosystem settled on standards too, that would be wonderful. But alas. There is flux, redux, mobx, hooks, routes, sagas, thunk, observable, styled components, emotion, tailwind, react-antd, axios, fetch and so on and so forth. Edit: on top of, obviously, webpacker, grunt, npm, yarn etc. Contrary to e.g. Rails, none of these come with React. You'll need to organize it all yourself (or go with something as react-boilerplate). You'll need at least some of these pieces to have something workable very early on. Things like redux or saga are not some "we've grown out of vanilla React and need additional tooling", they are essential to do things that practically every app needs: pages, communication with a backend, some styling, some consistency and deploying it to a public server.
- LAC-Tech 5y ago
  I'll make it really easy for you - ignore everything in that list except fetch. The rest is nasty, nasty bloat. Saga in particular is one of the most pointless and libraries I've ever seen. Total solution looking for a problem.
  - netghost 5y ago
    Working on a project with a significant number of sagas, I have to heartily agree with you. There are some very clever things you can do with them, but this really need to know all the ins and outs of it first, and by the time you've learned them you implemented a giant nightmare.
    - acemarke 5y ago
      We've been trying to generally discourage Redux users from using sagas in most cases. I've always felt that they were absolutely overkill for basic data fetching scenarios, and this is even more true now that data fetching libraries like RTK Query and React Query exist. Where sagas _do_ still make sense is highly complex async workflows, including responding to dispatched actions, "background thread"-type behavior, and lots of debouncing/throttling/etc. But yes, I've heard of plenty of cases where sagas made a codebase unreadable, and it's a shame that they get so heavily pushed by some early Redux users. FWIW, I've actually been working on designing a new "action listener middleware" that we'd like to ship in an upcoming version of Redux Toolkit. It started off as very simple callbacks, but by adding a few key primitive functions like `take`, `condition`, and `delay` I think we've been able to to come up with something that can handle maybe 75% of what sagas can do with a much smaller API surface and bundle size. I'd love to have you or anyone else using Redux take a look and give us some feedback on the current API design and let us know if there's other use cases it ought to cover: https://github.com/reduxjs/redux-toolkit/discussions/1648 https://github.com/reduxjs/redux-toolkit/discussions/1648
notJim 5y ago
> it's been out for 10+ years Oh god, I'm so old.
- danachow 5y ago
  It hasn’t been out for 10+ years. Even if you count the prototype FaxJS predecessor it’s barely 10 years old, and that was only a Facebook internal project.
panabee 5y ago
do you mind sharing your thoughts on vue? in particular, someone said react is better for building complex systems. do you agree with this opinion?
- jokethrowaway 5y ago
  vue and react are relatively close if you want to try something different I'd go with svelte
  - panabee 5y ago
    thanks for the reply! which is better for building complex systems?
    - bern4444 5y ago
      Any of them will allow you to build a complex system - vue, svelte, react and others. It's more important to pick one and just get started with it. You can do some reading about how they're different or their different philosophies but they all work. It's more important to get started. If you want to build something to learn a skill to get a job, react is the most popular. If you want to build something to learn something new, any of them are a good choice. Just get started.

ozzythecat 5y ago

The last time I did web development, I used Angular 1.2 or something like that. I had some forms and many different views that talked to some REST APIs. It was never clear to me why/when I would need React. I read and worked through some tutorials years ago, and while the reactive/one way flow pattern was nice, I never had a problem with Angular. I recognize there have been many versions of Angular since then. And there are several web development frameworks, complex build tooling, etc. etc. Meanwhile, I’m still writing services in Java that handle 20,000 requests per second for a service that brings in revenue in the billions of dollars a year. And I’m writing C++ (very straightforward, no templates, few uses of pointers, etc) for cross platform mobile code. I have some Spark pipelines all written in Scala. Meanwhile the web stack continues to evolve… new technologies all just for rendering web pages. I don’t understand why. Admittedly there’s far more complexity in our use cases today than the HTML I was writing in 1999, but much of it is unnecessary bloat from bored developers.

montblanc 5y ago
Old Angular wasn't such a bad framework actually...
- KronisLV 5y ago
  Sometimes running into AngularJS was not too bad of an experience, since it's relatively simplistic when compared to what's needed to get it running (no complicated toolchain, such as with TS -> JS). But most of the times it's a pain, because of it not scaling well to larger projects. I've actually seen projects where controllers grow to the length of thousands of lines because the developers didn't feel comfortable with introducing new ones in the pre-existing codebase, due to how the scoping works, due to how they'd need to set up the data models and care about initialization of everything, as well as custom integrations with validation libraries and other JS cruft (due to it not quite being "battieries included", like the new Angular is). Now personally, i really liked how they did error messages (which gave you URLs that you could navigate to, with a bit of context in them; though it would be better with a locally hosted docs server), but a lot of things were awkward, such as their binding syntax: https://blog.krawaller.se/posts/dissecting-bindings-in-angularjs/ https://blog.krawaller.se/posts/dissecting-bindings-in-angul... Luckily, AngularJS seems to finally be dead, so we'll get to migrate to something else soon, hopefully. And the projects that won't will be red flags enough for the people who don't like such challenges to turn the other way - truly a litmus test of sorts.

berkes 5y ago

> hooks and functional components have become the standard Now if only the React ecosystem settled on standards too, that would be wonderful. But alas. There is flux, redux, mobx, hooks, routes, sagas, thunk, observable, styled components, emotion, tailwind, react-antd, axios, fetch and so on and so forth. Edit: on top of, obviously, webpacker, grunt, npm, yarn etc. Contrary to e.g. Rails, none of these come with React. You'll need to organize it all yourself (or go with something as react-boilerplate). You'll need at least some of these pieces to have something workable very early on. Things like redux or saga are not some "we've grown out of vanilla React and need additional tooling", they are essential to do things that practically every app needs: pages, communication with a backend, some styling, some consistency and deploying it to a public server.

LAC-Tech 5y ago
I'll make it really easy for you - ignore everything in that list except fetch. The rest is nasty, nasty bloat. Saga in particular is one of the most pointless and libraries I've ever seen. Total solution looking for a problem.
- netghost 5y ago
  Working on a project with a significant number of sagas, I have to heartily agree with you. There are some very clever things you can do with them, but this really need to know all the ins and outs of it first, and by the time you've learned them you implemented a giant nightmare.
  - acemarke 5y ago
    We've been trying to generally discourage Redux users from using sagas in most cases. I've always felt that they were absolutely overkill for basic data fetching scenarios, and this is even more true now that data fetching libraries like RTK Query and React Query exist. Where sagas _do_ still make sense is highly complex async workflows, including responding to dispatched actions, "background thread"-type behavior, and lots of debouncing/throttling/etc. But yes, I've heard of plenty of cases where sagas made a codebase unreadable, and it's a shame that they get so heavily pushed by some early Redux users. FWIW, I've actually been working on designing a new "action listener middleware" that we'd like to ship in an upcoming version of Redux Toolkit. It started off as very simple callbacks, but by adding a few key primitive functions like `take`, `condition`, and `delay` I think we've been able to to come up with something that can handle maybe 75% of what sagas can do with a much smaller API surface and bundle size. I'd love to have you or anyone else using Redux take a look and give us some feedback on the current API design and let us know if there's other use cases it ought to cover: https://github.com/reduxjs/redux-toolkit/discussions/1648 https://github.com/reduxjs/redux-toolkit/discussions/1648

notJim 5y ago

> it's been out for 10+ years Oh god, I'm so old.

danachow 5y ago
It hasn’t been out for 10+ years. Even if you count the prototype FaxJS predecessor it’s barely 10 years old, and that was only a Facebook internal project.

panabee 5y ago

do you mind sharing your thoughts on vue? in particular, someone said react is better for building complex systems. do you agree with this opinion?

jokethrowaway 5y ago
vue and react are relatively close if you want to try something different I'd go with svelte
- panabee 5y ago
  thanks for the reply! which is better for building complex systems?
  - bern4444 5y ago
    Any of them will allow you to build a complex system - vue, svelte, react and others. It's more important to pick one and just get started with it. You can do some reading about how they're different or their different philosophies but they all work. It's more important to get started. If you want to build something to learn a skill to get a job, react is the most popular. If you want to build something to learn something new, any of them are a good choice. Just get started.