[HN Gopher] The Node ecosystem (still) has tooling problems
___________________________________________________________________
The Node ecosystem (still) has tooling problems
Author : MaxLeiter
Score : 31 points
Date : 2022-07-30 20:17 UTC (2 hours ago)
(HTM) web link (maxleiter.com)
(TXT) w3m dump (maxleiter.com)
| andrew_ wrote:
| 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?
|
| 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."
|
| 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.
| jeroenhd wrote:
| What's the trouble with Typescript, exactly? The setup is
| relatively straighforward (at least, for Javascript tooling).
| Copy/paste a file or two and you're off to the races.
|
| In comparison any frontend framework is much more difficult to
| learn. Typescript itself is just Javascript with types and the
| fancy parts of the type system are rarely ever required.
| andrew_ wrote:
| I'm in agreement with you. But I'm also an old salt that's
| been using it for nearly 8 years. I completely understand how
| someone unfamiliar with the language and its nuances may be
| overwhelmed by the configuration options and the effects they
| have on compilation. The types system does take time to
| learn, especially for those that didn't come up on a strongly
| (or hell, even loosely) typed language.
|
| I also think there's enough resources out there for someone,
| who isn't in a hurry, to grok TS enough to put together a
| project that will compile. But skills and comprehension
| aren't uniform - I've seen many a junior fresh out of
| bootcamp look at a tsconfig.json file like it was voodoo.
| That's why I think it's fair to say "Hey, you don't have to
| use this."
| jitl wrote:
| 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 _you_ 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.
| moltar wrote:
| I think projen may solve the configuration and tooling woos. At
| least I hope it will.
| alexashka wrote:
| You're describing all command line tools and config files.
|
| Maybe people will discover GUIs one day, it's only been 30 years.
| andrew_ wrote:
| "Everything old is new again"
| tannhaeuser wrote:
| 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.
| interactivecode wrote:
| Understandable frustrations but without a comparison to other
| major languages in the same domain its a bit moot.
|
| Is it just the Node ecosystem that has these types of problems?
| josteink wrote:
| Node succeeded by "simply" being plain JS on V8 with a really
| small standard library. Easy! No nonsense! _Everyone_ knows
| this already!
|
| Unfortunately that left _everything else_ up to the community
| to solve: establishing a "good" standard library, building,
| debugging, packaging, bundling, dealing with the Node /Browser
| duality in a meaningful way, creating usable network
| frameworks, UI frameworks and surely much more.
|
| And they've all ended up reinventing that 100 times (like the
| curse of lisp) in 200 different ways, all recursively based on
| Node, while standing on the shoulder of non-giants trying to
| solve one of the other problems mentioned above, possibly
| standing on the shoulder of someone else who has already tried
| to solve what you are trying to solve now.
|
| Calling it a clusterfuck probably isn't sufficient, yet at the
| same time it seems to work, so it's simultaneously a sort of
| modern day miracle.
|
| Disclaimer: have set up quite a few node build-pipelines.
| yulaow wrote:
| Of npm (the online database of packages) I hate the fact they
| never forced a clear distinction between package meant to be
| used only in the backend with node, package meant to be used
| only on the fe inside a browser, and package which can be
| used in both. I mean just having a flag for that would be
| useful, simple and solve a lot of headaches
| andrew_ wrote:
| The beauty is that those distinctions _don 't_ exist. There
| are no limitations. There are also no guardrails or
| training wheels.
| antonvs wrote:
| In my experience, Node is worse than any of Java, Rust, or
| Haskell.
|
| I think a couple of reasons for that is that it's untyped, and
| not compiled. Both of those mean that basic correctness
| checking ends up happening on the user's machine, rather than
| the developer's.
| jitl wrote:
| > not compiled
|
| Ironic you say this, since the whole blogpost is complaining
| about setting up compiler pipeline to target NodeJS.
| weaksauce wrote:
| 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 _option_ to do so but not being
| the default. I can 't think of another package manager that does
| this.
|
| 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.
| GauntletWizard wrote:
| You can't do a package cache, because nasal demons erupt
| whenever you use a package that's not precisely equal and all
| packages use their own copies of all their dependencies.
|
| Sane package managers don't try to solve for this problem; they
| make it clear when you're using bad software.
| andrew_ wrote:
| The globally installed packages only take precedence over local
| packages when you run the binary name from the command line. To
| get that to stop, you'd have to add the local node_modules/.bin
| to the PATH. Additionally, if you run npx/yarn/pnpx in a
| package script, it will use the local binary.
|
| > 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.
|
| Look into pnpm. It does precisely this in a way that's
| compatible with node.
|
| Honestly the information is out there to address most people's
| gripes.
| klodolph wrote:
| This is really short. I think my complaints, compiled into an
| article, would probably fill out an article five or ten times as
| long.
|
| 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.
| ramesh31 wrote:
| It's beyond repair. The future is Rust, Go, and Deno.
| ravenstine wrote:
| Yes, there is a lot of shit, but stick to ES2015+ and you'll be
| mostly fine. No reason to continue with the .cjs .mjs crap.
| Either set "type": "module" or use Deno (the superior option)
| and don't look back. If others still want to use Common JS,
| that's their problem. Yeah, a lot of modules won't work out of
| the box because they're Common JS, and visa versa, but screw
| Common JS. That and goofy junkware like Gulp and Grunt which
| are overcomplicated, change their APIs frequently, and don't
| really do anything better than a Makefile. Ok, Gulp might be
| helpful if you're running Windows, but I pity those who still
| do web development on Windows without WSL2.
| andrew_ wrote:
| Gulp and Grunt? Are you a time traveler from 2012?
| jeroenhd wrote:
| Both still work fine to this day. I don't know what the
| exact (dis)advantages of the competing toolsets are, but if
| you know Gulp and Grunt then I don't see why you wouldn't
| use them.
| ravenstine wrote:
| Yeah Grunt is pretty ancient but Gulp is still used in many
| places.
| andrew_ wrote:
| I do almost exclusively backend and DX development on Node and
| it's a joy. None of the frontend world's problems.
|
| There is value in an ecosystem that lets you do it "your way,"
| rather than enforcing convention. It's not for everybody
| though.
| hugozap wrote:
| 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.
___________________________________________________________________
(page generated 2022-07-30 23:00 UTC)