4 ms·

IMHO, part of this is that people have accepted the poor experience of non-realtime applications. But there's a huge UX improvement if the application responds

by treis 4y ago

IMHO, part of this is that people have accepted the poor experience of non-realtime applications. But there's a huge UX improvement if the application responds faster than users can input actions. Doesn't matter for all applications but if your users are going to spend significant time inputting data it makes a huge difference. Also IMHO, a flexible type system like Typescript makes development faster than without it. You can refactor faster, it catches silly mistakes, and you don't have to write as many tests. Rails does a lot of great things for you, but IMHO ultimately it's stuff you don't really need. If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps.

weaksauce 4y ago
with hotwire you get the benefit of having that SPA with quick responsiveness but with the much, much reduced complexity in stack with all the jankiness that that brings with it.
aantix 4y ago
>If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps. Simply not true. I've consulted on multiple teams across products built with Rails. Products that supported hundreds of millions of requests and generated a similar levels of revenue. Rails scales - programmer productivity, traffic. It scales.
- treis 4y ago
  >Simply not true. It's not true that I think it hurts more than it helps?
- RangerScience 4y ago
  One thing I've taken to pointing out, and it seems like you have way more experience with which to back it up - is that it's not just about scaling to millions, it's also about scaling from zero. Thoughts? :)
boredtofears 4y ago
> part of this is that people have accepted the poor experience of non-realtime applications my experience has taught me the exact opposite: people have accepted the poor experience of real time applications (client side crashes that bring down the entire page, half-baked routing that is essentially just rebuilding the browser navigator, inconsistent client vs server rendering processes). developers tend to completely stick their head in the sand when these issues are occurring. there's complete classes of problems that simply go away when you're not building an SPA. > Also IMHO, a flexible type system like Typescript makes development faster than without it. You can refactor faster in the long run, yes, but in the short term you're probably not going to get your mvp out faster because you chose TS
- treis 4y ago
  > people have accepted the poor experience of real time applications (client side crashes that bring down the entire page, half-baked routing that is essentially just rebuilding the browser navigator, inconsistent client vs server rendering processes). People complain about that stuff all the time. >stick their head in the sand when these issues are occurring. there's complete classes of problems that simply go away when you're not building an SPA. Well, yes. If you don't actually build a real time application you won't get the benefits of a real time application. >in the long run, yes, but in the short term you're probably not going to get your mvp out faster because you chose TS Once there's even a moderate level of complexity (i.e. 2-5 devs for 1+ months) the type system helps you catch issues. Even if it only saves you one 4 hour debugging session you come out ahead. That assumes you sit down and write out your MVP without any significant refactoring. If you do have to make changes then TS will save you significant time there. It also assumes that you're not writing tests that duplicate what a type system does. If you do write those tests then again I think you're slower. Rails does have the advantage of there generally being one "Rails way" of doing things. That can short circuit a lot of design discussions and other sorts of bikeshedding. But you can also just not do that and, IMHO, come out better.
  - boredtofears 4y ago
    > Well, yes. If you don't actually build a real time application you won't get the benefits of a real time application A rails application can be just as "real time" as any SPA, I don't think that definition really means anything. You get a distinct set of problems that come with SPA's that don't exist in a traditional server side rendered app that have nothing to do with how "real time" the app feels.

by treis 4y ago

weaksauce 4y ago

with hotwire you get the benefit of having that SPA with quick responsiveness but with the much, much reduced complexity in stack with all the jankiness that that brings with it.

aantix 4y ago

>If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps. Simply not true. I've consulted on multiple teams across products built with Rails. Products that supported hundreds of millions of requests and generated a similar levels of revenue. Rails scales - programmer productivity, traffic. It scales.

treis 4y ago
>Simply not true. It's not true that I think it hurts more than it helps?
RangerScience 4y ago
One thing I've taken to pointing out, and it seems like you have way more experience with which to back it up - is that it's not just about scaling to millions, it's also about scaling from zero. Thoughts? :)

boredtofears 4y ago

> part of this is that people have accepted the poor experience of non-realtime applications my experience has taught me the exact opposite: people have accepted the poor experience of real time applications (client side crashes that bring down the entire page, half-baked routing that is essentially just rebuilding the browser navigator, inconsistent client vs server rendering processes). developers tend to completely stick their head in the sand when these issues are occurring. there's complete classes of problems that simply go away when you're not building an SPA. > Also IMHO, a flexible type system like Typescript makes development faster than without it. You can refactor faster in the long run, yes, but in the short term you're probably not going to get your mvp out faster because you chose TS

treis 4y ago
> people have accepted the poor experience of real time applications (client side crashes that bring down the entire page, half-baked routing that is essentially just rebuilding the browser navigator, inconsistent client vs server rendering processes). People complain about that stuff all the time. >stick their head in the sand when these issues are occurring. there's complete classes of problems that simply go away when you're not building an SPA. Well, yes. If you don't actually build a real time application you won't get the benefits of a real time application. >in the long run, yes, but in the short term you're probably not going to get your mvp out faster because you chose TS Once there's even a moderate level of complexity (i.e. 2-5 devs for 1+ months) the type system helps you catch issues. Even if it only saves you one 4 hour debugging session you come out ahead. That assumes you sit down and write out your MVP without any significant refactoring. If you do have to make changes then TS will save you significant time there. It also assumes that you're not writing tests that duplicate what a type system does. If you do write those tests then again I think you're slower. Rails does have the advantage of there generally being one "Rails way" of doing things. That can short circuit a lot of design discussions and other sorts of bikeshedding. But you can also just not do that and, IMHO, come out better.
- boredtofears 4y ago
  > Well, yes. If you don't actually build a real time application you won't get the benefits of a real time application A rails application can be just as "real time" as any SPA, I don't think that definition really means anything. You get a distinct set of problems that come with SPA's that don't exist in a traditional server side rendered app that have nothing to do with how "real time" the app feels.