4 ms·

If you have discipline, probably none. The difference is developer behavior that each framework encourages. While htmx/turbo focus in just couple of helpers a

If you have discipline, probably none. The difference is developer behavior that each framework encourages. While htmx/turbo focus in just couple of helpers and then leave you with the full HTML/JS, in a react ecosystem you end having with 3 party components, and a state management system and build system that will change in 10 months. I don't say it isn't justify and that it have its pros, but it's a rabbit hole in my experience, where you easily end fighting with the framework than focusing on business.

mardifoufs 2y ago
Lol react has been more stable than rails.
gloosx 2y ago
yeah, just a couple of them, like 11 core html attributes and 25 additional html attributes, oh, also some events and also a JavaScript API. So easy to remember compared to 7 scary react hooks.
nosefurhairdo 2y ago
Huh, there hasn't been a significant change to our build system for our React application in the last ~5 years. Same is true for state management (redux). Our users include half of fortune 100 companies. Really don't understand the argument that React apps must be rewritten all the time. Most of our code is still old class components that still work in the latest version of React.
- CodeWriter23 2y ago
  I can’t speak to React. But with Vue it’s been like this. Vue 3 we’re not deprecating the Options API. And we’re not recommending the Composition API. But if you read into that you can mix and match the two, any pain you experience in the corner cases where they don’t play nice, well, that’s on you. All of your Vue 2 components might work but not really. Also the Vue 3 versions might happen. We’re switching from WebPack to Vite as the build system. (Does Vite actually use WebPack as a component, a question that lingers in the back of my mind) Oh and now the “CJS build” of Vite is deprecated so you’ll need to go from TypeScript 4 to 5. Your IDE may or may not work with the new Vue-specific tslint infra and when you’re done sussing that out now you find code that worked just fine in your previous build is rejected when you do a npm run build (no longer prod btw). Can you imagine needing to fix a bug requiring a dependency (upon dependency and so on and so on and so on) update on code you haven’t touched for a year and suddenly having a herd of Yak like that need shaving?
  - nosefurhairdo 2y ago
    Vite uses esbuild for fast dev builds and Rollup for production bundling, not webpack. Once the Rust port of Rollup is ready (called Rolldown) it is likely Vite will migrate both dev and prod bundling to that. Re: Typescript 4 => 5 that should be a trivial migration. All we needed was to bump our node version IIRC. And yes I can imagine the sort of bug you describe, because I'm the guy who fixes these sorts of things on my team. Usually just a few hours of head banging once or twice a year. Though the apps I've built on Vite have never required this. Really cannot recommend Vite highly enough for web frontend tooling.
CodeWriter23 2y ago
Yes getting the JavaScript community to just STFU when it comes to revising for the sake of revising is an entirely different issue. Some day they will have to maintain something they haven’t touched in 5 years and then they will learn. Well, some of them.

mardifoufs 2y ago

Lol react has been more stable than rails.

gloosx 2y ago

yeah, just a couple of them, like 11 core html attributes and 25 additional html attributes, oh, also some events and also a JavaScript API. So easy to remember compared to 7 scary react hooks.

nosefurhairdo 2y ago

Huh, there hasn't been a significant change to our build system for our React application in the last ~5 years. Same is true for state management (redux). Our users include half of fortune 100 companies. Really don't understand the argument that React apps must be rewritten all the time. Most of our code is still old class components that still work in the latest version of React.

CodeWriter23 2y ago
I can’t speak to React. But with Vue it’s been like this. Vue 3 we’re not deprecating the Options API. And we’re not recommending the Composition API. But if you read into that you can mix and match the two, any pain you experience in the corner cases where they don’t play nice, well, that’s on you. All of your Vue 2 components might work but not really. Also the Vue 3 versions might happen. We’re switching from WebPack to Vite as the build system. (Does Vite actually use WebPack as a component, a question that lingers in the back of my mind) Oh and now the “CJS build” of Vite is deprecated so you’ll need to go from TypeScript 4 to 5. Your IDE may or may not work with the new Vue-specific tslint infra and when you’re done sussing that out now you find code that worked just fine in your previous build is rejected when you do a npm run build (no longer prod btw). Can you imagine needing to fix a bug requiring a dependency (upon dependency and so on and so on and so on) update on code you haven’t touched for a year and suddenly having a herd of Yak like that need shaving?
- nosefurhairdo 2y ago
  Vite uses esbuild for fast dev builds and Rollup for production bundling, not webpack. Once the Rust port of Rollup is ready (called Rolldown) it is likely Vite will migrate both dev and prod bundling to that. Re: Typescript 4 => 5 that should be a trivial migration. All we needed was to bump our node version IIRC. And yes I can imagine the sort of bug you describe, because I'm the guy who fixes these sorts of things on my team. Usually just a few hours of head banging once or twice a year. Though the apps I've built on Vite have never required this. Really cannot recommend Vite highly enough for web frontend tooling.

CodeWriter23 2y ago

Yes getting the JavaScript community to just STFU when it comes to revising for the sake of revising is an entirely different issue. Some day they will have to maintain something they haven’t touched in 5 years and then they will learn. Well, some of them.