This is actually pretty funny. I coded javascript for a solid ~18 years (I stopped about 3 years ago) and the majority of the concerns in this list are from the past 10 years. What I find glaringly absent, which would have been present if this were written in 2013, is the absence of polyfills.<p>What other things that were JS nightmares in 2013 have largely ceased to exist? (Only to be replaced by this funny list.)<p>This is my favorite part: "You stop to count how many tools and parsers work on your codebase: TypeScript, esbuild, swc, babel, eslint, prettier, jest, webpack, rollup, terser. You are not sure if you missed any. You are not sure if you want to know. The level of pain is so high you forget about anything else."
Every time I start up a new JavaScript (well, TypeScript) project, I go through the usual routine.<p>Usually it's a front-end project, so I'll pick my framework. Usually React, although I've been wanting to try out Svelte.<p>Next my bundler, which used to be create-react-app, or some other Webpack wrapper. Today, Vite is the best choice because it works pretty well without much configuration, and it supports all of the major frameworks which is quite nice.<p>I'll be sure to install and configure the TypeScript compiler, which is usually copy-pasting from a template. I always make sure to target the latest well-supported version of JS and use ESM modules, because I like being on the bleeding edge.<p>Next up I setup linters -- eslint + prettier. They do a good job. I have to configure eslint so that it plays nice with Prettier, and I also have to configure eslint for TypeScript and add any other plugins that the project might need, e.g. those for React. I usually like to setup some kind of pre-commit hook to run Prettier and eslint before committing, which saves time.<p>Additionally, I always install my IDE extensions and try to create a .devcontainer file or add list of recommended extensions so that both myself and others can setup their IDEs in the future. I tend to not configure eslint much and just use off-the-shelf configurations because I don't care about the style, I just want consistency in the code and mistakes to be caught.<p>Next up I setup my unit tests, usually jest or vitest or similar. Lots more configuration for TypeScript and whatever, and also usually a set of eslint rules.<p>Then I want a CSS framework. I like tailwind, so I install that and styled-components and twin.macro so that it all works nicely with React. Fonts and icons are often needed too, so I install a plugin for Google Fonts and whatever font library.<p>Anyway, after about a day of doing the above I'm ready to program. Why is it so much work? Why isn't there something that just works for 90% of the use cases? So many people are using Vite + TypeScript + [React|Vue|Svelte] + [eslint|prettier] + [tailwind|bootstrap] + [jest|vitest]. Why isn't there some non-configurable library that just does everything for me?
This is yet another case of people saying "JavaScript" when they mean "a bunch of Node ecosystem junk". Right out of the gate:<p>> It’s time for your test. You are sitting in front of a computer. The test is simple: you have to open a package.json file and read it.<p>And it continues in that vein. For all the stuff mentioned, there's actually almost nothing that has anything to do with JS per se.
I appreciate the playful tone, it's good to be reminded of these pain points after the first few layers of skin and nerve endings have burned away.<p>On the flip side, I can throw a hungry junior dev with a new macbook into the deep end, and they can be productive within a day. They don't have to know anything about containers, .net, nginx, or the top 100 most common command line tools. When they hit an issue they can just google it.
"I followed the instructions and it said I didn't have grunt installed. Now I'm
an old guy so I didn't really know what grunt was and my grunt files weren't
right or something. So I googled a bit and I found out what grunt was.
Grunt's... I still don't really know what it is."
--Joe Armstrong, <a href="https://www.youtube.com/watch?v=lKXe3HUG2l4">https://www.youtube.com/watch?v=lKXe3HUG2l4</a><p>The other day I ran `gem install wayback_machine_downloader`. I never liked Ruby the language enough to get into its ecosystem, but I note that said ecosystem has from an outside perspective remained remarkably stable. gem is still the thing to use (dear god Python what became of you), Rails is still around... I'm waiting to work on a new project with a complex enough front-end that justifies more than 0-30 lines of JS, then I can be happier with HTMX instead of whatever giant framework is most popular these days.
This is not about javascript, this is about npm.<p>I detest npm and avoid it at all costs preceisely because of all this junk (personally I use Deno, but at work we use something like bazel with a monorepo that means we don't need npm), but I find Javascript/Typescript a lovely language to program in and it is my absolute number 1 goto language for anything.<p>It makes me sad when people say "javascript sucks!" but actually they mean that using npm to build react applications suck. Modern Javascript/typescript is an absolute joy to code in.
It feels as if JavaScript (and its ecosystem) has left us all with PTSD that makes us unable to appreciate the comedy on this post. So much “serious” discussion around a funny piece. Feel free to dissect it as you may, but keep in mind its true intent: humour.
I will be honest, the first ecosystem I started in was node, and I absolutely think that those that I learned later had their insane share of issues too.<p>Haskell has proven very hard to use cross machine, installing it on MacOS in 2019 was painful, the ecosystem is painful to handle, there's a huge macro/extension confusion, language isn't very retro compatible while you can generally expect 2010 JS to work in 2023 out of the box.<p>Even creating a full fledged docker image, codespace/gitpod-like proves difficult, the base one provided by GitHub kinda sucks and has issues.<p>C has proven generally okay to work on most platforms but the language is honestly complex and the sheer amount of knowledge of systems (in all possible meanings of the word), produces non-portable code that doesn't fit most usecases of general programming.<p>I could go on, but everyone who has tried several languages knows that we all suffer and will always suffer with several shortcomings in all kind of ecosystems.<p>Php has always been one that I've never got to setup a project in less than few days.<p>Elm is the less painful but the ecosystem suffers from its own degree of benevolent dictator's state and rate of development.
I'm a polyglot developer who likes to think they're comfortable in a wide range of programming paradigms and languages across both frontend and backend.<p>This is pretty much exactly my reaction any time I see a package.json longer than ~20 lines.
[Old school JS developer reading the article and suffering PTSD and flashbacks]<p>I must not fear.<p>Fear is the mind-killer.<p>Fear is the little-death that brings total obliteration.<p>I will face my fear.<p>I will permit it to pass over me and through me.<p>And when it has gone past, I will turn the inner eye to see its path.<p>Where the fear has gone there will be nothing.<p>Only I will remain.<p>[Finishes reading the article and realizes they survived, but now all sweaty]
JavaScript tooling it bad. So many half-ready choices. I tried to set up TypeScript project for last few days. It's a major pain. I originally wanted to use multi-module project: 1 node.js server, 1 webapp and shared code. I spent too much time trying to figure out all those things, TypeScript moduleResolutions and whatnot just to throw it all away. To hell with it. Yesterday I tried to understand how would I generate type-safe server code from OpenAPI spec. No way. zod, yup, ajv, wtf, but just dumb simple openapi generator which can generate code even for Ada, but node.js does not exist.<p>I love TypeScript, I love node, but I so much hate all the associated tooling. It's incredibly terrible. I don't want to make a single choice. I want a single build system which does everything good enough. I want a single "Spring Boot" framework which does everything good enough. I want a single linter, which built into my IDE and does not require me to exclude my dist folder. I don't want to configure my TypeScript compiler, it should be smart enough to configure itself. I don't want to spend days reading about project references, npm workspaces and other stuff. I want to create few folders like I do with maven and it's just works. I don't want to browse 10 different libraries for typings (why is it even needed for typescript???). I want things like JSON parsing and validation to be built into language or stdlib.<p>I hate go language. But their tooling is so right that I can withstand all those `if err != nil` every second line.
What would be the <i>minimal but modern</i> setup to develop web apps that use javascript to good effect in conjunction with an agnostic server stack.<p>I am intrigued by "less js is more fun" approaches like htmx and alpine.js but that still leaves a range of options on how to organize things and some may bring you dangerously close to what OP describes.
>The type is set to module. This has something to do with the migration from requires to imports. Why do we have to care about this, again? The extensive pain you’ve experienced trying to importing ES5 modules from ESM modules and vice versa overwhelms you again.<p>Would anything truly have been lost if Node simply ignored ESM?<p>The half-measure seems, abstractly, worse than announcing that Node was all-in on ESM, deprecating CJS by a certain LTS release, as the end-user has no real notion of the ultimate destination of ESM in a Node project; what is the struggle for?.
So many of these points feel like superficial pains that are really quite optional. So many things don’t actually matter beyond offending our sensibilities.
It's 2023 and NPM still doesn't support a comma after the last item in a list, and no comments. It's still stuck to the same old JSON version that it used on day one.<p>Also, I started with `grunt` before using `gulp`. And I used `bower_components` to build a website. I try not to remember too much though. There is only so much that therapy helps.<p>I just do Rust now. It's not perfect by any means but at least there is design there.
> Oh, dear jest. […] Properly configuring it with ESM and TypeScript was a PhD science project.<p>No kidding, I had to do this recently. It was a trek and a half.
And here I was thinking the first thing about version was going to mention that v0.x.x (major 0) semver packages are considered "unstable" and every update to the version string, even minor or patch numbers, is considered a major update, by the logic that determines whether or not to update the package/which compatible highest version to install
I have a new side project and I started coding it in Deno just to try something now, but not too far from the tree.<p>Not having to worry about setting up TS, bundling, linting is a breath of fresh air. No node_modules, just a depts.ts file to manage my imports. This also means no yarn, NPM or PNPM to decide.<p>It still has a learning curve sometimes because some tooling is not mature enough, but it's nice figuring out that I don't need PM2 just a systemd service to keep the process alive.
I've said it before, but the node build tool ecosystem looks like any project in any language where no one was around to tell a bright young developer "no"
> Every time you modify dependency list, some of the dependencies print out screens-worth of messages to your console, asking for donations, warning about breaking changes.
Every time I get close to being tempted to try out JavaScript again for anything beyond basic DOM manipulation, I read something like this and slowly back out of there, trying to avoid any eye contact.
As a Java developer, why the hell does Javascript still doesn't have a equivalent of Gradle or Maven? An extensible build tool that does it all and uses sensible defaults?
The article was fine until this part near the end:<p>> engines prominently lists node. And while you hate it with the depth of your soul, you are not going to Bun or Deno because you know this will not stop the pain. This will only make the pain worse.<p>Deno will make the pain worse?<p>Nearly every complaint in the article could have been solved by using Deno.<p>- Package.json, no such thing for Deno (not unless you go out of your way to infect Deno with it)<p>- main, browser, and fs don't matter in Deno since Deno's APIs are based on browser APIs.<p>- type, module, requires, and imports doesn't matter in Deno since it shares the same import API as browsers.<p>- scripts, doesn't matter since all Deno projects have the same tools built-in (benchmarker, bundler, compiler, formatted, linter, task runner, test runner, etc...)<p>- watchman doesn't matter since deno has watch support built in<p>- dependencies doesn't matter anywhere near as much because Deno comes with a standard library<p>- left-pad doesn't matter because it's part of the language<p>- moment.js doesn't matter since you can just use the browsers built-in Temporal api<p>- resolutions, dev-dependencies don't matter for the same reason that dependencies doesn't matter<p>- eslint doesn't matter since deno has a linter<p>- postcss matters less because modern css is great<p>- jest doesn't matter because deno includes a test runner<p>- no need to work out typescript installation with your dependencies because deno includes typescript and has less dependencies<p>The only things not solved by using deno is version and name, which are universal concerns amongst all projects, not just the js ecosystem.