It is an abomination. I get that you have no choice but use Js in the browser, but you can use anything you want server side. Yet, people willingly choose to use one of the most horrific ecosystems out there.
This is why I’m kinda excited about WASM. With a WASM backend for GHC, you can now write almost the entire frontend logic in Haskell, with only some minor bindings on the JS side. I really wish that this happens at some point to eliminate the need for JS almost entirely, but I’m not that hopeful anymore.
Yeah, WASM definitely looks promising. It’s also worth noting that you can treat Js as a compile target using something like Elm or ClojureScript. These languages have decent semantics that insulate you from a lot of the underlying insanity. For example, stuff like equality works the way you’d expect it to. I’ve worked on a few large frontend apps with ClojureScript and it was pretty nice as long as you didn’t need to interop with the Js ecosystem.
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.
It is an abomination. I get that you have no choice but use Js in the browser, but you can use anything you want server side. Yet, people willingly choose to use one of the most horrific ecosystems out there.
This is why I’m kinda excited about WASM. With a WASM backend for GHC, you can now write almost the entire frontend logic in Haskell, with only some minor bindings on the JS side. I really wish that this happens at some point to eliminate the need for JS almost entirely, but I’m not that hopeful anymore.
Yeah, WASM definitely looks promising. It’s also worth noting that you can treat Js as a compile target using something like Elm or ClojureScript. These languages have decent semantics that insulate you from a lot of the underlying insanity. For example, stuff like equality works the way you’d expect it to. I’ve worked on a few large frontend apps with ClojureScript and it was pretty nice as long as you didn’t need to interop with the Js ecosystem.
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.