4 ms·

I understand (kinda) why SPAs came about. My question is; what incentive do companies have to revert to the more sane and simple technologies of htmx, hotwire e

I understand (kinda) why SPAs came about. My question is; what incentive do companies have to revert to the more sane and simple technologies of htmx, hotwire etc? I'm a rails dev and I love the framework but there's a realist in me that sees something akin to the phrase "markets can stay irrational for longer than you can stay solvent"

j45 3y ago
When technology decisions are too often made on signalling trendiness and shiny object syndrome, all organizations will eventually evolve out of this. Simple technologies leave innovation points to be spent in the problem and user instead of experimenting with new tech that is usually a rewrite of something else that’s already similar, except without the hardening and maturation
candiddevmike 3y ago
What's sane about swapping type safe, offline capable frontend code for spaghetti htmx/hotwire code?
- clivestaples 3y ago
  In the case of Rails, I lose type safety but also get a huge boost of productivity in other with extremely well-documented features: database migrations, testing, mailers, queues/jobs, file storage, rich text, authentication helpers (especially v7), etc. Re: spaghetti: I'm not sure my Rails setup is less neat and tidy than the React, Redux, Saga, GraphQL Typescript codebase of my 9-5 TBH. Could be just me though. EDIT: typo
- jack_riminton 3y ago
  I've yet to be given a single example of how Rails suffers without types, it's just not an issue Hotwire is the polar opposite of spaghetti code
  - boredtofears 3y ago
    Rails does better than the rest of the Ruby ecosystem without types because it has strong conventions, but if you’ve ever adopted a rails app that doesn’t follow these conventions (or follows different ones like in the 3.x days where they were less defined) refactoring things across an entire codebase can be a gargantuan task. Following variable life cycles in Ruby in general is much harder than a typed language. There are tools like pry for this sort of thing, but that’s more work than just having types with good ide integration.
  - joshspankit 3y ago
    As a sibling comment implies, it can be a huge issue if the existing codebase tosses out conventions. It’s underrated since devs mostly do it without thinking about it, but in enough cases you need to double-check the type before running any operation that requires a certain type. Unchecked it will either crash entirely or cause bugs so esoteric that they are very difficult to debug. I don’t think I’d categorize it as “how Rails suffers without types”, more like “stay away from the edges and you’ll be fine”, but it can still bite you hard if someone mis-steps.
    - jack_riminton 3y ago
      But I genuinely can't think of an example that is ever likely to arise, can you give me one? Anything I can think of will immediately throw an error or would be covered by the most basic of test suites
      - joshspankit 3y ago
        > immediately throw an error That’s exactly what we don’t want in production code. We want it to work without errors. An example: assign a variable to the output of a library function, then pass the variable in to a different function. Super basic, super common. One instance of that is calling the first function and expecting an array back but getting any one of ‘String’ (edge case that the library maintainer decided is a good idea) or ‘False’ (maintainer decided that’s what happens when something fails during the call). If you call ‘.each’ within the second function without verifying that the variable is iterable first the function will throw. (I’ve even seen a couple rare cases where a custom class responds to ‘.each’ but is not properly iterable). Most Ruby devs will “just” check before they call ‘.each’, or wrap the second call in a rescue block, but that’s exactly the sort of potential for misstep I’m talking about.
- naasking 3y ago
  Show the spaghetti?
- rchaud 3y ago
  Spaghetti in, spaghetti out. HTMX isn't going to spit out anything that wasn't already in your component.
- tomatofrank 3y ago
  Show me five use cases of offline web apps and I'll show you a liar ;)
klysm 3y ago
They aren’t more sane in all cases. You’ve left out the massively critical context of what’s being built.
bnchrch 3y ago
Simple is a changing target. In a one person team merging your server with your client and using HTMX can be simpler (depending on if the value is in your UX or in your logic/data). However as the team gets larger then I find having a clear separation between your API(s) and your Client(s) is much more simple and maintainable. Also it can unblock product decisions like offline mode or PWA's. Finally its worth stating that being in an SPA community like React can give you access to "economies of scale" in terms of the libraries available to save you time (Tables, animations, UI kits, Video players, etc.) allowing you to do more with less people.
- brtkdotse 3y ago
  > clear separation between your API(s) and your Client(s) The problem is that the SPA way of thinking has infiltrated every nook and cranny in this industry. The ratio of APIs vs clients consuming those APIs come scarily close to 1, at least with the customers I work with. Now you have to maintain two projects, two CI/CD pipelines, two hosting solutions, potentially two sets of languages and tooling…
  - Danjoe4 3y ago
    Yes. You should probably start with a monolith. If you really scale then toss the htmx FE, expose an API, and slap a react project on top. Django lends itself to this growth pattern very well.

j45 3y ago

When technology decisions are too often made on signalling trendiness and shiny object syndrome, all organizations will eventually evolve out of this. Simple technologies leave innovation points to be spent in the problem and user instead of experimenting with new tech that is usually a rewrite of something else that’s already similar, except without the hardening and maturation

candiddevmike 3y ago

What's sane about swapping type safe, offline capable frontend code for spaghetti htmx/hotwire code?

clivestaples 3y ago
In the case of Rails, I lose type safety but also get a huge boost of productivity in other with extremely well-documented features: database migrations, testing, mailers, queues/jobs, file storage, rich text, authentication helpers (especially v7), etc. Re: spaghetti: I'm not sure my Rails setup is less neat and tidy than the React, Redux, Saga, GraphQL Typescript codebase of my 9-5 TBH. Could be just me though. EDIT: typo
jack_riminton 3y ago
I've yet to be given a single example of how Rails suffers without types, it's just not an issue Hotwire is the polar opposite of spaghetti code
- boredtofears 3y ago
  Rails does better than the rest of the Ruby ecosystem without types because it has strong conventions, but if you’ve ever adopted a rails app that doesn’t follow these conventions (or follows different ones like in the 3.x days where they were less defined) refactoring things across an entire codebase can be a gargantuan task. Following variable life cycles in Ruby in general is much harder than a typed language. There are tools like pry for this sort of thing, but that’s more work than just having types with good ide integration.
- joshspankit 3y ago
  As a sibling comment implies, it can be a huge issue if the existing codebase tosses out conventions. It’s underrated since devs mostly do it without thinking about it, but in enough cases you need to double-check the type before running any operation that requires a certain type. Unchecked it will either crash entirely or cause bugs so esoteric that they are very difficult to debug. I don’t think I’d categorize it as “how Rails suffers without types”, more like “stay away from the edges and you’ll be fine”, but it can still bite you hard if someone mis-steps.
  - jack_riminton 3y ago
    But I genuinely can't think of an example that is ever likely to arise, can you give me one? Anything I can think of will immediately throw an error or would be covered by the most basic of test suites
    - joshspankit 3y ago
      > immediately throw an error That’s exactly what we don’t want in production code. We want it to work without errors. An example: assign a variable to the output of a library function, then pass the variable in to a different function. Super basic, super common. One instance of that is calling the first function and expecting an array back but getting any one of ‘String’ (edge case that the library maintainer decided is a good idea) or ‘False’ (maintainer decided that’s what happens when something fails during the call). If you call ‘.each’ within the second function without verifying that the variable is iterable first the function will throw. (I’ve even seen a couple rare cases where a custom class responds to ‘.each’ but is not properly iterable). Most Ruby devs will “just” check before they call ‘.each’, or wrap the second call in a rescue block, but that’s exactly the sort of potential for misstep I’m talking about.
naasking 3y ago
Show the spaghetti?
rchaud 3y ago
Spaghetti in, spaghetti out. HTMX isn't going to spit out anything that wasn't already in your component.
tomatofrank 3y ago
Show me five use cases of offline web apps and I'll show you a liar ;)

klysm 3y ago

They aren’t more sane in all cases. You’ve left out the massively critical context of what’s being built.

bnchrch 3y ago

Simple is a changing target. In a one person team merging your server with your client and using HTMX can be simpler (depending on if the value is in your UX or in your logic/data). However as the team gets larger then I find having a clear separation between your API(s) and your Client(s) is much more simple and maintainable. Also it can unblock product decisions like offline mode or PWA's. Finally its worth stating that being in an SPA community like React can give you access to "economies of scale" in terms of the libraries available to save you time (Tables, animations, UI kits, Video players, etc.) allowing you to do more with less people.

brtkdotse 3y ago
> clear separation between your API(s) and your Client(s) The problem is that the SPA way of thinking has infiltrated every nook and cranny in this industry. The ratio of APIs vs clients consuming those APIs come scarily close to 1, at least with the customers I work with. Now you have to maintain two projects, two CI/CD pipelines, two hosting solutions, potentially two sets of languages and tooling…
- Danjoe4 3y ago
  Yes. You should probably start with a monolith. If you really scale then toss the htmx FE, expose an API, and slap a react project on top. Django lends itself to this growth pattern very well.