3 ms·

Hotwire is appropriate (I imagine you're not using actual Turbolinks which has been deprecated) with RoR or whatever stack you want, I agree it's great develope

Hotwire is appropriate (I imagine you're not using actual Turbolinks which has been deprecated) with RoR or whatever stack you want, I agree it's great developer experience (despite Ruby and Rails being painfully slow haha). I wonder which full-stack JS framework you used that you thought made life harder? One of the things that gets me mad is the idea of putting it all in one single box, as React is indeed very (needlessly) complex and so can be other libraries, but that doesn't mean the paradigm of JavaScript front-to-back is fundamentally flawed. edit: Something else I should've added to my comment is that the HTMX approach is terrible if you ever need more than just the web-client (i.e. a mobile app, native or otherwise) since you will now have to implement an API anyway, which you could've done in the first place by taking the usual approach to development.

tsuujin 3y ago
> I wonder which full-stack JS framework you used that you thought made life harder? I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor. They’re all cool until you have to actually maintain them. My favorite part is having to build my data models twice, one for the producer and one for the consumer. That’s totally never caused any headaches or slowed anyone down at all.
- doodlesdev 3y ago
  > I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor. That's quite a lot of libraries lol, I guess no one can say you just haven't found the right library I must admit I've used Hotwire much less than I should've, but I still feel comfortable with full-stack JavaScript (or rather, TypeScript). You said you migrated back to Turbo, what backend framework do you use? RoR with Hotwire is so nice, but I personally avoid it because of Ruby (not personally a fan), to be fair the same is true for most full-stack frameworks I avoid (such as Django/Python).
  - tsuujin 3y ago
    I’ve used turbolinks on a few backend driven projects, but mostly with rails, and hotwire replaced that nicely enough. I really only used it because from the users perspective it’s hard to tell that you’re not using a SPA. I really like the idea of systems like Phoenix’s LiveView as well, but I ask a lot of questions before I implement something like that. The majority of projects I’ve ever worked on didn’t really need that much interactivity and I strongly prefer the “sprinkle on JS when you actually need it” approach to web apps.
jdthedisciple 3y ago
Well which JS framework(s)/librar[y|ies] are you then using/advocating for, if you agree that React is needlessly complex?
- doodlesdev 3y ago
  I personally enjoy Svelte.
renerick 3y ago
> if you ever need more than just the web-client (i.e. a mobile app, native or otherwise) since you will now have to implement an API anyway, which you could've done in the first place Unless your new client is a hybrid/webview/electron application, it's a trap. APIs for web, for native and public API have different sets of constraints in terms of authentication, versioning, even features are probably gonna be different. And it's not like building an API after you built web would be complicated. Unless you put your business logic right into controllers/handlers, making an API would be just making a new endpoint that calls to existing application services. It's not free, it may not be trivial, but like other comment said, if you can afford a new client, you probably can afford an API for it

tsuujin 3y ago

> I wonder which full-stack JS framework you used that you thought made life harder? I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor. They’re all cool until you have to actually maintain them. My favorite part is having to build my data models twice, one for the producer and one for the consumer. That’s totally never caused any headaches or slowed anyone down at all.

doodlesdev 3y ago
> I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor. That's quite a lot of libraries lol, I guess no one can say you just haven't found the right library I must admit I've used Hotwire much less than I should've, but I still feel comfortable with full-stack JavaScript (or rather, TypeScript). You said you migrated back to Turbo, what backend framework do you use? RoR with Hotwire is so nice, but I personally avoid it because of Ruby (not personally a fan), to be fair the same is true for most full-stack frameworks I avoid (such as Django/Python).
- tsuujin 3y ago
  I’ve used turbolinks on a few backend driven projects, but mostly with rails, and hotwire replaced that nicely enough. I really only used it because from the users perspective it’s hard to tell that you’re not using a SPA. I really like the idea of systems like Phoenix’s LiveView as well, but I ask a lot of questions before I implement something like that. The majority of projects I’ve ever worked on didn’t really need that much interactivity and I strongly prefer the “sprinkle on JS when you actually need it” approach to web apps.

jdthedisciple 3y ago

Well which JS framework(s)/librar[y|ies] are you then using/advocating for, if you agree that React is needlessly complex?

doodlesdev 3y ago
I personally enjoy Svelte.

renerick 3y ago

> if you ever need more than just the web-client (i.e. a mobile app, native or otherwise) since you will now have to implement an API anyway, which you could've done in the first place Unless your new client is a hybrid/webview/electron application, it's a trap. APIs for web, for native and public API have different sets of constraints in terms of authentication, versioning, even features are probably gonna be different. And it's not like building an API after you built web would be complicated. Unless you put your business logic right into controllers/handlers, making an API would be just making a new endpoint that calls to existing application services. It's not free, it may not be trivial, but like other comment said, if you can afford a new client, you probably can afford an API for it