Hacker News Reader

Comment by toyg | Hacker News Reader

I don't (think I) have much of a problem with JS syntax, generally speaking, but I'm often baffled by the surrounding ecosystem of build tools and "helpers". There are a million tutorials, all doing things slightly differently without really explaining why, and stuff breaks so often...

Any recommendation for something covering that sort of thing (npm, yarn, webpack...) in a more structured and in-depth way than "here's how to make a todo list in 10 minutes with some magical command that may or may not still work 3 months later"?

View on HN

I agree. Even just finding out what the tools are is ridiculously hard. Here's a list:

* NPM: Package / dependency manager. Also has some basic support for running scripts.

* Yarn: Very similar alternative to NPM.

* Babel: Transpiles modern Javascript to "old" Javascript, in case you need to support IE9 but want to use async/await or whatever. If you only support modern browsers you don't need this.

* Webpack: Originally it was for "bundling" Javascript files. You don't want to write all your code in a single file, but you often want to deliver it that way. Webpack reads the 'import' statements of all your files, and them converts them into a single file with emulated modules. Also helps when you are targeting a browser that doesn't support modules natively. However Webpack also comes with a load of "loaders" that can transform input files in various ways, e.g. allowing importing CSS files from Javascript, compiling Typescript, etc. So now it is kind of a big ugly build system.

* Node: The Javascript engine extracted from Chrome, plus a load of native APIs that let you do stuff you can't do in the browser because of security (write files, make TCP connections, etc).

* Electron: Basically Chrome plus Node. You can set it up so that your web pages can access the Node APIs inside Chrome, but you can also have them talk to an actual Node process via IPC.

A little npm actually goes quite a long way:

https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

https://github.com/keithamus/npm-scripts-example

Although you should probably prefer yarn these days (concepts should mostly transfer over).

As for tranformations/transpiling/minifying... You could use webpack - it is popular, but quite complex. I've found this a decent introduction to understand how it works:

https://www.freecodecamp.org/news/creating-a-production-read...

The good part about going that route, is that is quite explicit... You might get away with throwing out explicit in favour of convention - by using parcel instead:

https://github.com/parcel-bundler/parcel

(looks like gh readme is currently best entry point for 2.0 docs).

NPM is a pretty awful build tool really. In the only NPM project I work on we write a Python script as the build system, and the NPM scripts call that.

Don't really disagree with that. On the other hand, npm/yarn is generally a dependency you can't get away from - so if your needs aren't complex, I'd say in general, you're better off with a simple npm/yarn config, than pulling in another dependency.

Of course pulling in python in a python project is free, if python is tightly coupled to the js stuff anyway.

Often eg: the front end will be just js/ts - and reusable/useful without any python.

Yeah to be honest we don't use Python for anything other than the build system, but it is available on all our systems so it is easy to use, and I couldn't find anything better. I would have liked to be able to use Typescript, but there's no really good simple way to say "Node: compile and execute this typescript file, please don't save the output on disk anywhere, or try to read tsconfig.json or package.json or whatever".

> there's no really good simple way to say "Node: compile and execute this typescript file, please don't save the output on disk anywhere, or try to read tsconfig.json or package.json or whatever".

I guess there's no native typescript support for nodejs (so npx is out). Maybe deno can help?

https://deno.land/

> Supports TypeScript out of the box.

Thats clearly a sort of "now you have two problems" type solution - but if there's a desire to stick with ts as a language - it might be helpful? (to drop the python dependency).

Ed: hm, there's apparently ts-node : https://github.com/TypeStrong/ts-node

  npx ts-node script.ts

https://stackoverflow.com/a/33536053

I sympathize with this. I wanted to use, and slightly modify, a small web app I found on GitHub.

Despite it being client-side only, it used node. An older version, with older versions of webpack, Babel, and so on. And tons of now deprecated npm packages. It was only a couple of years old.

The only way I could make it work, after days of trying, was a docker container of an older Linux distro. I did try just upgrading packages, but the avalanche of dependency hell made that literally impossible.

I have not had this experience with any other language.

Edit: Noting I have had to update/upgrade older Perl, Python, etc, projects. And they weren't all easy. But they were at least possible. Dozens of things to chase down. Not hundreds.

I've had the opposite experience trying to get python and/or ruby not to trash my global environment and various things wanting the system to be setup for their versions and libraries. I like that NPM by default makes all dependencies local and npm lets you include your dev dependencies local to that project.

Note: I know their are magic incantations for python and ruby to get them to make everything project local but they aren't what python and ruby do by default.

Yeah, because package-lock.json files were never a thing.

As a backend developer getting his foot into frontend I feel you. Configuring TSLint with Prettier and all the plugins was tiresome only to learn few months later it's getting deprecated and you should move to ESlint. This article helped me bit, it explains "what is what" in modern JS ecosystem https://medium.com/the-node-js-collection/modern-javascript-...

Excellent article, I just hope that's kind of stable... every time I look into the JS it feels like I've never looked into JS before.

My honest opinion is that you should read the npm-cli docs[0], the babel docs[1] and the webpack docs[2]. I think that most tutorials want to skip to the "getting stuff done" bit, and learning these tools with a bit of granularity is well worth it for any serious Javascript project.

These three tools form the backbone of most modern Javascript projects. Understanding what they are, why they do what they do, and how to extend them is vital to being able to work with modern JS.

The docs, particularly the introductions are written for a fairly inexperienced audience and I find them easy to work with.

[0] https://docs.npmjs.com/cli/npm [1] https://babeljs.io/docs/en/ [2] https://webpack.js.org/concepts/

I'd recommend the Webpack tutorial by Andrew Mead, interestingly enough. It goes through all these tools and why they're needed, and you build out a simple config with Webpack and understand exactly what it does and why.

I'm interested in checking this tutorial out but I can't locale it anywhere. Got any links?

https://www.youtube.com/playlist?list=PLblA84xge2_zwxh3XJqy6...

Looks like I misremembered, it's actually by Colt Steele.

Thank you!

What do you think of it?

I really like it, actually. I finally had a free hour this afternoon to start getting into it. I'm only on video 6 so far but I've already learned quite a few things that I had missed and/or misunderstood previously. I've also sent it out to my team so that they can check it out next week, after the holidays, (and during work hours) to fill in some of the gaps they may have, as well. Thanks again for mentioning it and linking it!

Yeah, I'm in the same boat, I'm still struggling to figure out how to write a library in typescript and then use it as a browser library. I have a feeling that I just need a better understanding of the core concepts (modules, bundlers, etc..)

It's good to understand modules well. Understanding bundlers is less important and can be postponed. Just use let parcel do the transpiling and bundling for browsers.

It's quite simple actually. With native modules support you don't really need any of these helpers.

However, if you're concerned about users on older browsers, you can use Babel to "transpile" your code to equivalent code that older browsers can understand, often at the expense of size.

npm and yarn are simply 2 competing implementation for package management. Start with npm and you'll know it when you want yarn.

Webpack and other module bundlers are just tools to automate things like transpiling, code-transformation, bundle-splitting, minification which are not all that essential actually.

The point is all of these are extras. Think of them as enhancements/optimizations. If you have a solid understanding of JS you can write JS in a way that doesn't require any of this. I blame the tutorials out there that say you need this and that without many justifications that make it seem more complicated than it is.

> Webpack and other module bundlers are just tools to automate things like transpiling, code-transformation, bundle-splitting, minification which are not all that essential actually.

I wish this were true. My experience to illustrate the point:

I have a Javascript library[1] for working with the HTML5 <canvas> element. It's a nice library (in my opinion) but it is a bit on the large side. Also, I developed it as something that can be added to a website in the old-fashioned way, using a <script> tag.

However, most non-personal websites these days are built with toolchains which include code bundlers like Webpack (many React sites), Rollup (Svelte sites), Packet etc. Developers working on those sites don't want to add a <script> tag to their HTML file; they want all their Javascript npm-included or yarn-added so it can be shaken and bundled and tied up in ribbons and bows for delivery to the user's browser or device.

So I did the work of turning my library into an NPM package and tried building a toy project with a toolchain. The failure was embarrassing. It turns out that I was using a JS feature in my library code which isn't supported by any of the main bundlers (`import.meta`, for the curious[2]. I raised a ticket with one of the bundlers to see if they could add support in a future release[3] but it seems the feature is too obscure to care about.)

I sorted the problem by rewriting my library (in a very unsatisfactory, ugly way) to get bundlers to bundle the code. Now people can add my library to their React/Svelte/whatever project. But the whole learning episode left a bad taste in my mouth: Being tripped up by Vanilla JS is one thing; having your work trashed by the bundlers in the toolchain is just nasty!

[1] - https://scrawl-v8.rikweb.org.uk/

[2] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] - https://github.com/parcel-bundler/parcel/issues/3269

Reply on news.ycombinator.com