I've done very little front end dev in JS for some years now, and am increasingly disappointed by the need for some installer or other to simply make use of JS projects. In particular, I was hoping to use Chart.js today, but the docs tell me that I must either use NPM, a CDN, or build the project myself:

If you download or clone the repository, you must build Chart.js to generate the dist files. Chart.js no longer comes with prebuilt release versions, so an alternative option to downloading the repo is strongly advised.

I expect this building process might produce a minified version of the JS, which seems somewhat helpful, but I wonder why this is a trend lately? My front-end friends have increasingly complicated JS development environments that automatically compile their JS every time they save a file using sass or less, etc. What advantages does this 'build' bring that justifies the extra moving parts?

IMHO, this seems to really complicate things unnecessarily by adding lots of moving parts and potential version conficts. PHP dev projects these days might make use of some combination of composer, npm, less, sass, and possibly a whole host of packages in a vendor directory.

    There are several reasons to use a build process for JS, but honestly they're most useful for frameworks like Vue, React, or Angular. For instance, writing Vue template files is a shortcut - using the vue npm plugin will transpile the es-6+ JavaScript and the template markup into actual JavaScript the browser can understand.

    For vanilla JavaScript the transpiling comes in handy. For instance, in much the same way that jQuery allows you to support AJAX in IE9+ without having to write both the XMLHttpRequest and ActiveXObject code, there are a tone of plugins that transpile, lint, and extend code, etc. In much the same way, Less and Sass offer functionality that CSS alone doesn't, and the respective npm plugins will likewise transpile the code out to CSS the browser understands.

    And yeah, minification and uglification are nice side-products you can build into the process.

    All that having been said, can be a pain in the butt to set up from scratch.

      11 days later

      maxxd There are several reasons to use a build process for JS, but honestly they're most useful for frameworks like Vue, React, or Angular. For instance, writing Vue template files is a shortcut - using the vue npm plugin will transpile the es-6+ JavaScript and the template markup into actual JavaScript the browser can understand.

      I'm currently using none of these. Nor does chart.js make use of them AFAIK.

      For vanilla JavaScript the transpiling comes in handy. For instance, in much the same way that jQuery allows you to support AJAX in IE9+ without having to write both the XMLHttpRequest and ActiveXObject code, there are a tone of plugins that transpile, lint, and extend code, etc. In much the same way, Less and Sass offer functionality that CSS alone doesn't, and the respective npm plugins will likewise transpile the code out to CSS the browser understands.

      I don't follow your explanation here. Yes, I want to use vanilla CSS. Yes, chart.js uses CSS. I'm not sure I see how plugins that transpile provide benefit?

        sneakyimp I'm currently using none of these. Nor does chart.js make use of them AFAIK

        Groovy. So don't use a build process - it's not a prerequisite. My comments were meant more generally about why it's taken root in the development world at large.

        I have to admit I hadn't checked the chart.js docs before I posted my post, but now I have and I'm a bit confused about your issue. Chart.js uses npm packages somewhere, so if you want to upload it to your own server you'll need to run the build in order to get all the third-party library files it relies on at some point.

        The documentation stresses that downloading and building the repo is strongly discouraged, so for this particular library use a CDN version. I assume you're not downloading and uploading a fresh copy of jQuery for every site you're building, so this really shouldn't be an alien process right?

          maxxd I have to admit I hadn't checked the chart.js docs before I posted my post, but now I have and I'm a bit confused about your issue. Chart.js uses npm packages somewhere, so if you want to upload it to your own server you'll need to run the build in order to get all the third-party library files it relies on at some point.

          The documentation stresses that downloading and building the repo is strongly discouraged, so for this particular library use a CDN version. I assume you're not downloading and uploading a fresh copy of jQuery for every site you're building, so this really shouldn't be an alien process right?

          I'd much prefer not to have to build anything, and am not sure at this point why chart.js would need building or why they'd stop distributing builds -- or why they would strongly discourage building it yourself. Clearly, someone has to build it. What's wrong with building it yourself? Seems fishy to me.

          As for using a CDN version, this apparently requires you to enable third party cookies in your browser, which I always turn off immediately when setting up my computers. Also, will that CDN still exist in a few years? NOTE: current development project launched fifteen years ago, we are rebuilding from scratch because various technologies and data sources no longer exist.

          Will they start charging money for a license?

          And yes, I typically do download some version of jQuery when I use it on a site. That way, can be sure it won't change on me, and it's quite easy to update if I really need to.

            I get the lack of desire to build anything; as to why they've stopped "distributing builds", that's probably because they've updated the code and it has other dependencies now and they're distributing it through an npm package instead of offering hosted downloads from their site - less overhead and headache.

            As for the CDN, they're using some pretty well respected names, but I completely understand your concerns. I've seen situations where a npm package is installed to a project, then checked in to version control on the off chance that the developer pulls the package and no-one steps in to pick it up. There are also some online registries that will duplicate packages for precisely this situation.

            sneakyimp As for using a CDN version, this apparently requires you to enable third party cookies in your browser, which I always turn off immediately when setting up my computers.

            I turn off third-party cookies as well, and I've never heard of this being an issue. I'll typically use jsDeliver or cdnjs, both of which carry Chart.js.

            Honestly, for your situation and to address you're concerns, I'd recommend just use npm to install the library - it's exactly like downloading the library and all it's dependencies into your project, except that it's done automatically and put in a directory named node_modules.

                Write a Reply...