6 ms·

It’s really not more productive. Working with react has a higher barrier of entry (something which is becoming less true over time given that many templates et

It’s really not more productive. Working with react has a higher barrier of entry (something which is becoming less true over time given that many templates etc exist for it), but if you want to be producing pages and functionality, a good react dev will run leagues around even an a exceptionally good jquery dev. I’m solid at both and we are talking a dev cycle that is magnitudes faster once you are set up reasonably well. There’s a reason it’s popular. Typescript makes a lot of testing unnecessary and gives many guarantees on robustness. React makes it a breeze to create complex state full components. Nextjs makes it super easy to deploy all this to a web app and quickly create new pages.

pier25 2y ago
> a good react dev will run leagues around even an a exceptionally good jquery dev It probably depends on the use case, no? If you only need links, forms, and data tables what advantage does React have over SSR + jQuery?
- morbicer 2y ago
  Non-spaghetti dynamic forms and their validation (yes you need to validate on server as well). Reusable components that can be tested in isolation. Type support. That leads to easier evolution and refactoring. With good architecture you can go mobile with react-native.
  - pier25 2y ago
    Most modern backend frameworks provide components, types, and validation. Laravel, Dotnet, Rails, etc.
- klysm 2y ago
  Composabilty and abstraction. I can bang out a react form in our app in minutes just by defining the shape of the fields. All the loading states are handled automatically. Mutations and refreshing data works out of the box. Navigating between pages is instant. Data is cached even when navigating between pages. Some pages that require many user inputs utilize optimistic updates to afford very low latency feedback. React makes all of that easy to compose. I tell it how to render my state, and I write code that updates state.
  - thunky 2y ago
    > Composabilty and abstraction Also possible without react with far less complexity.
    - lmm 2y ago
      It really isn't, unless you go full server-side session (with something like Wicket), and the latency of that is usually unacceptable these days.
      - thunky 2y ago
        I think you and the sibling may have missed the requirements up thread: If you only need links, forms, and data tables
        lmm 2y ago
        In my experience even something you thought was a basic form will usually have some kind of UI state (e.g. one input that then enables/disables another input).
        thunky 2y ago
        Can't that be done in one or two lines of jQuery?
        lmm 2y ago
        Yes, of course. And then you add one or two more lines of jQuery. And then another few lines to deal with the client-side and server-side state getting out of sync. And then... Is putting in a couple of lines of JS that has no knowledge of the backend-managed good enough for small one-off pages? Maybe. But it's definitely not composable and abstractable, which was the original claim.
        thunky 2y ago
swatcoder 2y ago
For as much as you're right, your taking a very narrow short-term view of productivity. The maintenance demands for using a heavy, evolving framework and a large graph of churning dependencies are tremendous and perpetual. While you can make meaningful wins on delivery time for a new feature, once "you are set up reasonably well", you've impliclty introduced new costs that don't apply to "vanilla" code that stays closer to established standards and only includes code it actually uses. That's not to argue that vanilla is strictly better (both have a place), but just to acknowledge a latent but significant tradeoff that your comment seems to ignore.
- pier25 2y ago
  > and a large graph of churning dependencies are tremendous and perpetual Absolutely. This the reason I'm moving on from JS in the backend. You're constantly stitching up dependencies which might be abandoned and/or become incompatible at any moment.
- whstl 2y ago
  > The maintenance demands for using a heavy, evolving framework and a large graph of churning dependencies are tremendous and perpetual Counterpoint: If you replace a frontend framework with backend components, as has been suggested a few times in this thread, those frameworks are even larger, and a lot of the basic functionality provided by React (such as components) is often provided by third-party packages. Sure, if you're using something like jQuery, then it's smaller and more stable, but the functionality is limited compared to both backend and frontend frameworks. Which of course might be 100% appropriate depending on the use case.
- imtringued 2y ago
  I'm still working on a project that uses jQuery in 2024 and it is a horribly bad fit and maintenance nightmare. I would prefer predictable new costs over random global effects in combination with duplicated server-side and client-side code that can blow up at any time.

pier25 2y ago

> a good react dev will run leagues around even an a exceptionally good jquery dev It probably depends on the use case, no? If you only need links, forms, and data tables what advantage does React have over SSR + jQuery?

morbicer 2y ago
Non-spaghetti dynamic forms and their validation (yes you need to validate on server as well). Reusable components that can be tested in isolation. Type support. That leads to easier evolution and refactoring. With good architecture you can go mobile with react-native.
- pier25 2y ago
  Most modern backend frameworks provide components, types, and validation. Laravel, Dotnet, Rails, etc.
klysm 2y ago
Composabilty and abstraction. I can bang out a react form in our app in minutes just by defining the shape of the fields. All the loading states are handled automatically. Mutations and refreshing data works out of the box. Navigating between pages is instant. Data is cached even when navigating between pages. Some pages that require many user inputs utilize optimistic updates to afford very low latency feedback. React makes all of that easy to compose. I tell it how to render my state, and I write code that updates state.
- thunky 2y ago
  > Composabilty and abstraction Also possible without react with far less complexity.
  - lmm 2y ago
    It really isn't, unless you go full server-side session (with something like Wicket), and the latency of that is usually unacceptable these days.
    - thunky 2y ago
      I think you and the sibling may have missed the requirements up thread: If you only need links, forms, and data tables
      - lmm 2y ago
        In my experience even something you thought was a basic form will usually have some kind of UI state (e.g. one input that then enables/disables another input).
        thunky 2y ago
        Can't that be done in one or two lines of jQuery?
        lmm 2y ago
        Yes, of course. And then you add one or two more lines of jQuery. And then another few lines to deal with the client-side and server-side state getting out of sync. And then... Is putting in a couple of lines of JS that has no knowledge of the backend-managed good enough for small one-off pages? Maybe. But it's definitely not composable and abstractable, which was the original claim.
        thunky 2y ago

swatcoder 2y ago

For as much as you're right, your taking a very narrow short-term view of productivity. The maintenance demands for using a heavy, evolving framework and a large graph of churning dependencies are tremendous and perpetual. While you can make meaningful wins on delivery time for a new feature, once "you are set up reasonably well", you've impliclty introduced new costs that don't apply to "vanilla" code that stays closer to established standards and only includes code it actually uses. That's not to argue that vanilla is strictly better (both have a place), but just to acknowledge a latent but significant tradeoff that your comment seems to ignore.

pier25 2y ago
> and a large graph of churning dependencies are tremendous and perpetual Absolutely. This the reason I'm moving on from JS in the backend. You're constantly stitching up dependencies which might be abandoned and/or become incompatible at any moment.
whstl 2y ago
> The maintenance demands for using a heavy, evolving framework and a large graph of churning dependencies are tremendous and perpetual Counterpoint: If you replace a frontend framework with backend components, as has been suggested a few times in this thread, those frameworks are even larger, and a lot of the basic functionality provided by React (such as components) is often provided by third-party packages. Sure, if you're using something like jQuery, then it's smaller and more stable, but the functionality is limited compared to both backend and frontend frameworks. Which of course might be 100% appropriate depending on the use case.
imtringued 2y ago
I'm still working on a project that uses jQuery in 2024 and it is a horribly bad fit and maintenance nightmare. I would prefer predictable new costs over random global effects in combination with duplicated server-side and client-side code that can blow up at any time.