i want to see the original, where can i find source?
It's a comic by Hannah Hillam
I've recently started writing JS recently, after writing C, go, shell and ruby for years.
Ended up with this gem in my code:
var total = +qty + +pool[0] - +pool[1];I hate it.
Well, I love it! So there! Muahahhahahaahaa
Haha hey it brings in the money! I’m almost exclusively doing devops now (terraform makes me drool) but I can fix your php, ruby, js, give me anything man, I’ll learn it.
I just have no problems with the weirdness of js. I weirdly like it. Love receiving a comment on a PR “wtf why do you do it like this? This is much easier: something_i_already_tried”.
Anything is a nail if you hammer it hard enough.
Though modern JS is way better than what it was before, and in my opinion is evolving in a good direction. It also pays my bills, so I couldn't complain even if I wanted.
Member Node.js? I member.
I'm making an app with SvelteKit, the frontend and the backend at the same time, in Typescript, I love it.
The SvelteKit + TypeScript combo is such a breeze to work with!
And compared to other languages, JavaScript scores pretty well in performance benchmarks. It has a lot more going for it than people give it credit for.
Use TypeScript
It's a slight improvement, but you're still inheriting the whole Js ecosystem, tooling, and most of the quirks of Js. There are far better languages you can use on the server, so I really don't understand the appeal of using a Js based backend.
If rapid iteration is more important than performance or cost then you can more easily have a monolithic-ish build system that creates the client and the server from a single code base, or with shared code between them.
If you are trying to upgrade frontenders to be fullstack it’s an easier entry point.
Sometimes the performance characteristics of node actually is useful for serverless since a cold start and a hot start are not very different, closer to a fixed cost just to run a script when compared to something like dotnet which has slow cold starts but fast hot starts. Which is also why it sucks for most server code but on occasion this can be a useful characteristic.
If you want to do serverside rendering with client side hydration then it can be handy to implement the display logic once and run on both the client and the server (eg server side rendering react or vue etc)
Those are a handful of decent reasons but broadly speaking agree, it’s not the best choice if you care about cost and the benefits in the specific cases above are either rare or short lived.
Except really for SSRing with client hydrarion, that’s really the slam dunk case where it’s the more often than not correct choice due to the advantages of not duplicating logic.
The real reason why I often use server side JS is that it’s just faster to write in the first instance if I need to spin something up real quick or for infrequently invoked code where performance and cost don’t really matter. Of course for anything serious it’s a bad choice.
