Yet, people willingly choose to use one of the most horrific ecosystems out there.
So far I have heard the following explanations for going full-stack JS
Ability to re-use business logic in back-end and front-end
Reduced context switching (though with frameworks that’s less true)
You don’t have to recruit developers proficient in your back-end language in addition to Javascript
Personally, having worked on a full-stack Typescript project for the past year, I kinda miss the maturity of Java’s ecosystem: there is usually one mature and well-maintained library that does its job really well ; while in Javascript-land there are multiple libraries for a single job, each with varying quality and maturity, and most of them are no longer maintained.
Those are the arguments I’ve seen most commonly as well. In practice, I don’t find they hold up in practice either. The downsides of having a janky foundation for the backend far outweigh any perceived benefits of having a single full stack platform. Also, async style is just far more painful to work with.
Yeah, the janky foundation made me and my boss wish we chose Java for the back-end multiple times. I like async / await (or coroutines in Kotlin-land), it’s easier to wrap my head around than Promises / Futures and I thought I would miss Reactive Programming, but not that much.
Coroutines are indeed much easier to work with, and I find it shocking that they didn’t catch on in Js world. In general though, I find plain sync code is just much easier to reason about and far less error prone. If you can keep IO at the edges, async’s not too bad, but in a lot of cases you need to do some IO deep within your logic, and that’s when things start to fall apart. Now you have to make everything async, error handling in particular becomes a pain. I think having async is nice as an opt in, but it shouldn’t be the default.
So far I have heard the following explanations for going full-stack JS
Ability to re-use business logic in back-end and front-end
Reduced context switching (though with frameworks that’s less true)
You don’t have to recruit developers proficient in your back-end language in addition to Javascript
Personally, having worked on a full-stack Typescript project for the past year, I kinda miss the maturity of Java’s ecosystem: there is usually one mature and well-maintained library that does its job really well ; while in Javascript-land there are multiple libraries for a single job, each with varying quality and maturity, and most of them are no longer maintained.
Those are the arguments I’ve seen most commonly as well. In practice, I don’t find they hold up in practice either. The downsides of having a janky foundation for the backend far outweigh any perceived benefits of having a single full stack platform. Also, async style is just far more painful to work with.
Yeah, the janky foundation made me and my boss wish we chose Java for the back-end multiple times. I like async / await (or coroutines in Kotlin-land), it’s easier to wrap my head around than Promises / Futures and I thought I would miss Reactive Programming, but not that much.
Coroutines are indeed much easier to work with, and I find it shocking that they didn’t catch on in Js world. In general though, I find plain sync code is just much easier to reason about and far less error prone. If you can keep IO at the edges, async’s not too bad, but in a lot of cases you need to do some IO deep within your logic, and that’s when things start to fall apart. Now you have to make everything async, error handling in particular becomes a pain. I think having async is nice as an opt in, but it shouldn’t be the default.