[ctide]

Not really.

These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray to use in the browser.

Yes, these things _could_ technically apply to the browser, but it's not commonplace. In the node world, these are all things you deal with consistently.

[girvo]

> No one (at least, no one I know) is installing node modules like isArray to use in the browser.

Erm, well, considering the adoption rate of Browserify and Webpack, I'm going to disagree with you there. Especially considering React's momentum practically requiring some form of module builder.

[esailija]

Startup speed is terrible with that approach, each browserified module adds like 10x more code as boilerplate than something like isArray implementation would take. Then every module dependency is resolved dynamically at runtime, which will also quickly become a performance problem even when you aren't using micromodules.

[Klathmon]

I haven't touched browserify, but with webpack what you said could not be more false...

Webpack doesn't bundle at runtime, it doesn't add any amount of code overhead per module that I can easily measure, and it doesn't trash startup speed.

[nilliams]

Same goes for browserify. You can have lots of tiny modules and (watchify especially) is fast to re-build. And yeah perf of 'require' statements at run-time is a non-issue.

[15155]

> it doesn't add any amount of code overhead per module

It's something like tens of bytes (minified), FWIW, for the closure that each module gets put into.

[Klathmon]

Actually the only place you would install isArray is the browser...

Node has support for the built in isArray, and you only need that "micro module" if you want to support IE8