3 ms·

> 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 accep

> 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.

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.