This is really short. I think my complaints, compiled into an article, would probably fill out an article five or ten times as long.<p>There’s just so much shit. Everyone made their own system. There’s .js .ts .mjs .cjs extensions. Theres’s tsc and jest and npx and create-react-app. These are just the tip of the iceberg. If I try to update the build system to use newer versions of the software, all sorts of stuff will break. The really shocking part, for me, is that I feel like it’s easier to set up my build system for C than for JS.
The node ecosystem doesn't have a tooling problem. Frontend development has had a tooling problem since the introduction of React and Angular, and TypeScript. One might argue that goes back as far as CoffeeScript. But can we stop boosting these "OMG this was too hard" posts?<p>TypeScript (tsc) should display a hide-able message on invocation that states: "TypeScript isn't straightforward. It's a vast ecosystem all its own that accommodates several million developer's individual needs. It can be overwhelming. You don't have to use it."<p>I won't opine on the dumpster fire that is ESM support in Node - that's a completely separate topic and head-through-wall session.
I have lost whole consecutive weeks to WebPack. It made me wish I could go back to something wholesome and healthy, like template metaprogramming in C++.<p>"I'm making progress, boss. The error output from the build is smaller than the input source code now."
Rant: could we please stop referring to a collection of <X> as an ecosystem? Node has a collection or environment of tools, frameworks and libraries to support it. An ecosystem is something living, a biological system, typically with a set of symbiotic properties within it.<p>The trend is the same in business. Stripe no longer has business partners; they have an “ecosystem.” The same with banks that provide wholesale banking services through a set of retail businesses - they are no longer wholesale banks but “ecosystem players”. This kind of jargon really dilutes the meaning of words and makes it hard to understand what is really meant.<p>Rant over, sorry.<p>Apart from my rant, it’s funny to see Node and JavaScript doing what almost killed Perl 20 years ago. There are so many ways of doing things, so many bespoke frameworks and packages (doing OO in Perl, anyone?), so many odd dialects that it fragmented the language and people got frustrated. The same is happening to JS right now, although with some important differences. There is hardly a fragmentation of usage via formal “dialects” in JS; rather, the problem is in the sprawl of libraries and “infrastructure” services, many of which are solved problems (e.g. Gulp reinventing what Make is really good at; Yarn reinventing what npm is supposed to do, etc). The supposed “ecosystem” is fragmenting day by day from its inherent complexity, and it’s exactly what caused web developers to flee from Perl to more simple, consistent alternatives.
> Node is a problem<p>Fixed it for you.<p>The node ecosystem embodies mediocrity. There is no design, no testing, no stability, no benchmarks, no RFCs, no plan to produce a coherent product. Instead, you're giving a half baked set of features that are abandoned within 8-12 months. Not invented here syndrome runs wild, and over-engineering any solution is seen as a mark of accomplishment.<p>Simple things, like displaying static text, now require 25mb of js files for whatever framework the author is currently playing around with as a hobby. I miss the days of the web where you could just load a page in under 25kb.
Tooling in the JS ecosystem (specially frontend) is very frustrating. It's just layers on top of layers with a weak foundation and a whole set of annoying incompatibilities between them.
The transition to ES6 modules made this much worse. Before that, for a npm package you could basically just call tsc on your entry point and then type `npm publish`. Now with the ES6 situation various dependencies and common packages demand <i>you</i> upgrade to ES6, and customers also ask for import syntax so their builds can do “tree shaking”. I maintain a Emscripten-based typescript library and the Emscripten wrapper code is allergic to ES6 imports - everything breaks if you do that since it removes various node globals. I wasted hours trying to figure out a way around, or a fix in Emscripten itself before giving up.
It’s funny I’ve been looking at industrial strength build systems like Bazel (language independent build tool from Google) recently the past few months just to get an idea of how things work in that world.<p>One of the things happening in that community at the moment was their second major attempt to bring the JavaScript / Typescript and Node ecosystem onboard as a semi official language. It has been a 4 year effort so far and they had to make a bunch of compromises along the way as you can see in the design section of the projects readme here <a href="https://github.com/aspect-build/rules_js" rel="nofollow">https://github.com/aspect-build/rules_js</a><p>Watching the walls they would continually run into where the answer would essentially be “Node is very unlike other language runtimes” was illuminating and I suddenly started to understand why projects like Deno want to actually leave Node behind as a fundamentally unfixable mess and start again with a bit more planning this time around to avoid all of those issues.
T'was all fine until folks had to come up with useless typescript and modules and webpack churn and Es2015+ bloat. It's not like we didn't warn them to turn JavaScript into Java; for some of us getting away from Java bloat was the entire point of node.js. Well that, and because CommonJS was portable, or used to be at least. If you want a typed language, just use one, rather than foobaring JavaScript or Python into something they just aren't, a fool's errand.
The problems start with frameworks that require custom compilers and non-standard module systems.<p>If you use vanilla JS in standard modules most of this goes away.
I'm pretty happy with just vanilla JavaScript.<p>I don't do typescript, I don't use frameworks (unless you consider express to be a framework).<p>I use vanilla web components on the front end, if I need reactivity and frequent re-renders I might sprinkle in a bit of lit-html, depending on the component.<p>Debugging and development are brain dead simple, just sticking to the standards.<p>I had a new developer come into my code base and he said "I couldn't believe it at first, you just write something and it does it... Wow!".<p>He was so used to piles of frameworks and build systems and stuff, he'd never been in a code base that just... ran.
I just checked my most recent frontend project that uses Typescript as much as possible. Here's how it works:<p>- src/.ts: Compile with esbuild in webpack<p>- tests/.test.ts: Compiled with babel<p>- jest.config.ts: Compiled with ts-node<p>- webpack.config.ts: Compiled with ts-node<p>In an ideal world, one tool should do everything but I doubt that will ever happen
I use pnpm and Sveltekit and have none of these problems. Everything just works, and it’s rare anything related to tooling takes longer than 1second to accomplish.<p>Being on OSX helps a lot with the “just works” part though.
It’s still early days, but I have been working on this…<p>There are scaffolding tools that help configure all the JavaScript frontend stuff you need, but the problem is you run them once and you can’t ever run them again to change/add stuff.<p>So I built Confgen which is sort of like create-react-app except it’s idempotent:<p><a href="https://github.com/erikpukinskis/confgen" rel="nofollow">https://github.com/erikpukinskis/confgen</a><p>It’s very alpha, but I would love to get ideas/ bug reports on GitHub.<p>It’s also currently Vite-only, but I’m open to a possible webpack/babel mode in the future.
Keep in mind that most of these are just rants about the developer experience, which is sacrificed in exchange for faster iteration and deployments on majority of business use cases.<p>As a Node.js developer myself I even noticed that some of the best solutions is nodejs plus other language.<p>Examples<p>uwebsockets.js uses some c++ code. it is faster and has better api than express, fastify, hapi, koa, and has builtin websockets support.<p>esbuild uses golang code. it is faster than webpack and babel for bundling and minifying javascript code.
Understandable frustrations but without a comparison to other major languages in the same domain its a bit moot.<p>Is it just the Node ecosystem that has these types of problems?
my big gripe with npm is that the global packages overshadow the local packages... I can't understand when that would be a good option other than maybe having an <i>option</i> to do so but not being the default. I can't think of another package manager that does this.<p>oh that and installing thousands of packages in the project root instead of a sensible place that could be shared per version like bundler and rubygems.
Interested if anyone is using a jsconfig.json and jsdoc comments to do ts typechecking. I found it really easy to setup, I got a lot out of the extra checks, but the practice never really took off with the team of js devs.<p><a href="https://code.visualstudio.com/docs/languages/jsconfig" rel="nofollow">https://code.visualstudio.com/docs/languages/jsconfig</a>
I saw the author was using vite, they have a mode to help you build a library that would mitigate their woes. Check it out!<p><a href="https://vitejs.dev/guide/build.html#library-mode" rel="nofollow">https://vitejs.dev/guide/build.html#library-mode</a>
So what is the "recommended" way to build libraries using TypeScript? I've heard that tsdx <a href="https://tsdx.io/" rel="nofollow">https://tsdx.io/</a> is quite good
I've started using plain old CDN-served React/jQuery/Lodash to do everything, with no build system, and daring my employer to fire me. So far so good.