Installation in a browser via npm?

[John Slegers]

In your documentation, I find the following info :

Installation

In a browser:

Via npm:

npm install array.from

Example

var from = require('array.from');
var assert = require('assert');

assert.deepEqual(from('abc'), ['a', 'b', 'c']);

...

I find this confusing.

Are you saying I can only use your polyfill in an environment with support for CommonJS style modules?

What about projects that don't use modular JavaScript or projects that use AMD modules?

Basically, how can I include your polyfill in projects that don't use a Node.js / NPM based build process?

[Jordan Harband]

Projects that don't use modular JavaScript are going to be unable to use most things; they need to upgrade to this decade's encapsulation approaches.

Projects using AMD need to use a bundler (browserify, webpack, etc) to transform imported CJS modules to AMD - something they should already be used to, since virtually everything is available in CJS and not AMD.

The majority of projects use node-style CJS, via a bundler (browserify, webpack, etc), and thus they handle npm deps just fine.

The way modern web dev is done is a node-based build process that uses CJS + a bundler. You can use something like https://wzrd.in in the meantime, but you're doing yourself a disservice by not adapting to modern best practices.

[John Slegers]

Projects that don't use modular JavaScript are going to be unable to use most things; they need to upgrade to this decade's encapsulation approaches.

I'm not a fan of hype driven development. Nor am I a fan for one-size-fits-all approaches.

Different projects have different requirements, and "this decade's encapsulation approaches" simply aren't suitable for all projects.

Projects using AMD need to use a bundler (browserify, webpack, etc) to transform imported CJS modules to AMD - something they should already be used to, since virtually everything is available in CJS and not AMD.

Synchonous modules as src code and monolithic files as dist code isn't a suitable approach for all types of projects. If you are building complex multi-page applications with shared dependencies, asynchronous modules loaded - at least partially - on-demand are still a better approach.

The product I work on professionally is a framework intended for building such applications. With the first version of the product going back to the days when Dojo was still hot, both the src code and dist code are currently available only as AMD modules. And while we are considering moving our src code to ES6 modules, I don't see that happening in 2017.

The majority of projects use node-style CJS, via a bundler (browserify, webpack, etc), and thus they handle npm deps just fine.

I never understood why that's become so common these days. Especially for small projects, it makes JS development for the browser much more complicated than it needs to be!

JavaScript programming was so much simpler when all you need to do to add a new dependency to your JavaScript was copy-paste a folder into a directory and add a <script> tag to your HTML.

JavaScript programming was so much simpler when you didn't also need to learn the package manager or build tool of the month and you didn't have abstraction layer upon abstraction layer pile up beneath your source code that makes you lose touch with what's happening under the hood.

Every day, the insanity of making your code work in both Netscape6 and IE4 back in the good old days of the early WWW seems less and less insane when comparing it with the Rube Goldberg machines many modern build chains have turned into...

[Jordan Harband]

Different projects have different requirements, and "this decade's encapsulation approaches" simply aren't suitable for all projects.

Using a module system isn't hype, it's decades of best practices - not using one is forever going to be an incompetent approach, and using one is absolutely appropriate for all projects, in the past and the future.

currently available only as AMD modules

If you want to use AMD, great - but using AMD in a world where the vast majority of the JS ecosystem is using CJS simply means you have to adapt your build process to consumer CJS modules and convert them to AMD - it's a cost of doing business as an AMD user. Nothing to be done about that.

I never understood why that's become so common these days.
none the less, that's the way everything's done these days.

I'm sorry you're frustrated; if you truly are unable to institute a build process for some reason, https://wzrd.in/standalone/array.from@latest is available for you. If you're stuck on AMD, you can manually browserify and amdify the module and vendor the resulting bundle. If you're doing what everyone else is doing, you can simply import or require this package and everything will work out of the box.

If you can think of a way to improve the readme that doesn't involve "explaining the state of modern web dev" or "teaching people how to consume [CJS] modules off of npm, the largest package manager on the planet", PRs are more than welcome!

[John Slegers]

Using a module system isn't hype, it's decades of best practices - not using one is forever going to be an incompetent approach, and using one is absolutely appropriate for all projects, in the past and the future.

If all you need JS for is <500 lines of code to be executed behind your DOM events, with or without the framework of the month as a dependency, a module system that doesn't allow you to run your JS code without first pushing it through the build system of the month means just more cruft to deal with, increasing complexity & maintenance needs rather than decreasing it.

Unless I'm working on big projects, I prefer my code to be directly executable in any browser, which makes debugging my code and rolling it out so much easier than having it push through a build system every time I change on line of code. Also, I prefer my src code to differ as little as possible from my dist code, as it makes me more in tune with the code the actual end user will be running when it doesn't need to be transpiled from ES6 or TypeScript to JavaScript - or whatever the cool kids are doing these days...

If you want to use AMD, great - but using AMD in a world where the vast majority of the JS ecosystem is using CJS simply means you have to adapt your build process to consumer CJS modules and convert them to AMD - it's a cost of doing business as an AMD user.

Why not distribute your code - at least optionally - as UMD modules? At least then you give the freedom to people to use whichever module system that's most suitable for their project... whether that's CJS, AMD or no module system at all!

If it would be just up to me, all of the JS code here at the office would be converted from AMD to UMD.

I'm sorry you're frustrated; if you truly are unable to institute a build process for some reason, https://wzrd.in/standalone/array.from@latest is available for you.

I would prefer my polyfills not to be minified during debug. Minification & bundling of dependencies are a transformation process I do happen to support and that I'd like to take care of myself.

Still, it's better than nothing, I guess... So, thanks for the link 👍

If you can think of a way to improve the readme that doesn't involve "explaining the state of modern web dev" or "teaching people how to consume [CJS] modules off of npm, the largest package manager on the planet", PRs are more than welcome!

I'm sorry, but forcing people to use an NPM / Node.js based build chain just to be able to use a friggin' polyfill is just insane. Whatever happened to common sense in this world?

JS projects never were supported to look like this :

[Jordan Harband]

That's how everything in the JS ecosystem works now - it is no longer tenable, and never will again be tenable, to have all code be directly executable in a browser.

[John Slegers]

That's how everything in the JS ecosystem works now - it is no longer tenable, and never will again be tenable, to have all code be directly executable in a browser.

Being able to write code that just works directly in the browser without having to build, compile or transpile it is one of the things that made JavaScript so popular and so fun to write code in.

Needing to first build and transpile your JavaScript code simply to be able to execute it in a browser even when it's supposed to be run only in the browser simply doesn't make any sense to me. Yes, I know that's what all the cool kids are doing now, but that doesn't mean it makes sense for the majority of JavaScript dev projects out there.

What IMO is not tenable in the long run, are over-engineered, cruft-laden build chains that rely on way more dependencies than needed, many of which are chosen because of hype rather than because of added value. I mean...

1. One day everyone is just writing jQuery plugins, using Yui Compressor to minify the plugins and shell scripts for bundling them
2. The next, everyone starts writing native cross-browser ES5 AMD modules, with Lodash as their main util library, using Require.js for AMD loading, minification and bundling
3. After that, everyone moves to AngularJS-powered ES6 that gets transpiled with Traceur and is written as CJS modules that get bundled with Grunt and Browserify and released as a Bower package
4. Then, everyone ditches AngularJS for ReactJS, Traceur for Babel, Grunt for Gulp, Browserify for Webpack and Bower for NPM
5. Now, people are starting to move from CJS modules to ES6 modules, replace Webpack with Rollup, ditch Gulp for plain Node scripts and use Yarn instead of NPM
6. After that? You tell me...

Many - if not most - of these choices are driven more by hype than whatever little value they add to the tool chain. In fact, they often add mostly cruft and have little to no real added value.

I do NOT consider that improvement! Sure, I like the idea of using Node.js / NPM build scripts for minifying and bundling your source code. I'm all in favor of automation and sending an optimized version of your code to be browser... but when the JavaScript code you write needs transpilation and a whole bunch of other transformations just to be able to run it in the browser, it feels to me like you've taken things a few steps too far and you need to take a few steps back to realize you've over-engineered your build chain.