5 ms·

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,

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.

rikroots 6y ago
> 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/ https://scrawl-v8.rikweb.org.uk/ [2] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3] - https://github.com/parcel-bundler/parcel/issues/3269 https://github.com/parcel-bundler/parcel/issues/3269

rikroots 6y ago

> 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/ https://scrawl-v8.rikweb.org.uk/ [2] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3] - https://github.com/parcel-bundler/parcel/issues/3269 https://github.com/parcel-bundler/parcel/issues/3269