The problems? Less and less of the real meaning of any program is visible to me as time goes on. There’s so much implicit in the run time namespace and semantic environment that has no visible connection to the code you’re editing. We keep adding tooling that allows us to more easily express our intentions for a given volume of code. But when the result is not what we expected, it’s becoming harder and harder to know where to make adjustments.
The constant drive towards interchangeability, compartmentalisation, and composability currently (and I think maybe always) causes all the interface points between the parts to trend towards the lowest-common-denominator. This is a darwinian process that is driven by a positive feedback loop, and does have some benefits - it allow us to evolve the individual parts.
I can change from webpack to browserify to rollup with relative ease, because they do a specific job with a dumb interface of plain text source code. This competition leads to them being better than they otherwise would be.
But the problem with this approach is that there’s no feedback from your “bundler” to let Babel know the rules about module resolution, so that it can in turn make better decisions, nor is there a way for it to let Flowtype know about what you’ll actually get from an attempted import, should the bundler be doing anything remotely out of the ordinary, like Facebook’s globally-unique-filename-modules, or webpack’s stupid “import css” chicanery. There’s no way for rollup to get access to all the information Flowtype has collected about the entire call graph to let it make better decisions about what can be thrown away.
Don’t get me started on god-damned testing “libraries” that require special launchers and fill the global namespace with garbage so that your tests can “read kind of like really poor english”
And when something goes wrong? You might need to simply locate and fix a typo in an import, that for some reason wasn’t brought to your attention by literally 3 different tools which each parsed and analyzed your entire program during build. Or, you might need to make a change in any one of 6 different .config files in any number of locations, all of which are poorly documented, none of which will tell you when you’ve put a typo in there – they simply carry on as if that part of the configuration does not exist.
And when you’re looking at a 60-thousand line file of transpiled code, glommed together with everything else dragged in via 700 transitive dependencies, and you need to diagnose and fix the fact there are two slightly different versions of React in the one file with no information about how they got there…
…you might wish you’d been a carpenter. As I keep saying, I’m not angry… just disappointed.
The TL;DR of what you said in my own opinions:
A good lang lets developers write good software, not novice developers write any software.
Compiling JS seems like a hilariously ridiculous exercise that gets in the way of debugging, deploying, and compatibility. Note: Bundlers/etc like browserify are reasonable.
Writing tests with “English” is nonsensical, English is horribly contextual and nuanced.
People seem to use so many tools that they can’t just write code. If you don’t know explicitly what your tool is doing, don’t use it. I know what a hammer does, so I’ll use it. I don’t know what Entomology Forceps are for so I don’t use them. Don’t buy a hardware store if all you need is a screw driver.
People seem to use so many tools that they can’t just write code.
Correct. Many developers seem to not want to be programmers, but rather technicians, who assemble pre-made parts and then (endlessly) diagnose the contraption they’ve made: “but, this is the fastest HTML templater right now, it’s worth all this trouble!”
There’s a real element of consumerism here, too. Part of me suspects that lots of business problems are boring and ill-specified, which causes people to seek out intellectual stimulation elsewhere, even if it’s in problems of their own making.
That has to be one of the more insightful lines I’ve ever read about programming languages.
I’m anxious of the day we all look back and think “Oh no, that was a huge mistake.”
Little late on that in JS, now aren’t we?
The thing that made promises “click” for me was to realize that, to the end user, it really doesn’t matter in many cases why the page didn’t render when a promise failed. DB on fire? Unable to reach microservice? Type error? Doesn’t matter.
The promise code got so much simpler when I a) started programming the happy path and b) made functions that were easily composable. Writing code for the preferred case and stopping caring about the specifics of why something failed and just making sure it could be undone did wonders. Writing functions that took like one or two params and did the needful so I could .then them in a clear data transform pipeline was amazing.
So, basically, when I started trying to write Erlang/Elixir in JS.
And then I remembered that JS was fucking stupid and I should try to stick to languages that wouldn’t cause brain cancer.
You probably care about the difference between a service failure and code errors when your server gets put into an unknowable state, and remains up.
The thing is, with a different implementation like righto, you CAN only code the happy path, AND you get the the distinction, AND you can use err-back APIs, AND you can use promises. There are very few downsides.
“Little late on that in JS, now aren’t we?” - lol
Just a few things:
I wrote this about 3 years ago, and yes, it’s absolutely a rant.
Animations are still non-trivial to make extremely performant, and there are many caveats, but the core point is that the DOM isn’t slow (creation and mutation of DOM nodes), which it isn’t.