Hacker News new | ask | show | jobs
by akdor1154 1568 days ago
My first boss had an often repeated mantra in code reviews: "akdor, don't fight the damn language!"

If you're using Python, write with Python concepts. In C#, write C#. In F#, write F#. Etc etc.

React has many many great ideas. But they are perpetually fighting the language. Here we have a great demonstration of stuff that is built in to any ml-legacy language being hacked into js in a way that the transformation happens in the user's browser in a scripting language at runtime! It's both genius and ridiculously inefficient and alien.

Don't fight the damn language.

3 comments

Which is all good and well, but the language is fighting the language. If you don’t believe me, just look at active tc39 proposals. JavaScript is increasingly becoming a compilation target and writing it idiomatically is increasingly a mishmash of preferences.
God I wish TC39 would treat JavaScript as a compilation target, but they do seem to keep adding new complex features for end-developers (which, as you say, are mixing up what it even means to code in the language: the class-oriented stuff in a prototype-based language is causing a whack-a-mole of syntax complexity to regain what they lost, such as with decorators) that of course every implementation will have to support (which alone should be a reason to try to only add features and behaviors to the browser that absolutely could not possibly be simulated effectively in code: browsers should be easy for a few people to implement, like a JVM, with most users using nothing but JS and canvas, generated as a compilation target... but, instead they are spiraling behemoths of complexity with ever-burgeoning CSS and HTML features that even Microsoft had to finally tap out of bothering to maintain).
> JavaScript is increasingly becoming a compilation target

JavaScript is the browser's machine code; having it as a compilation target makes at least as much sense as having an Intel chip as a compilation target.

I hope you mean this in the manner that usually we _don't_ target Intel chips, and instead target the x86_64 ISA.

Sure, it's possible to target JS, but in the general-case it's wildly inefficient, and requires mental gymnastics compared to something like WASM. This is likely why people are bothering with WASM at all, rather than accepting JS as "the browser's machine code."

Wouldn't it make more sense to have WebAssembly as a compilation target?
Once it has access to the DOM, sure
The progressive C++ification of JS is scary and exciting in equal measure.
Reasonable advice to an extent, but sometimes the language is crap and you should fight it. If everyone had followed your boss's advice we'd still all be using `var` and `for in`.
> in the user's browser in a scripting language at runtime

ok, but it will just get compiled down to machine code?