5 ms·

Regarding #1, I strongly think that the JS community should come together and build out a library that fills the same role as Boost does for the C++ community.

by wrigby 11y ago

Regarding #1, I strongly think that the JS community should come together and build out a library that fills the same role as Boost does for the C++ community. Sort of a collection of things that are missing from the standard library. I suppose lodash and others aim for a similar purpose, but clearly left-pad-gate has shown us that they're not quite complete enough.

riffraff 11y ago
Or apache commons lang for java.
nemild 11y ago
Agreed, I think one issue is that great libraries for all use cases weren't available in the past so older libs built up these chain of dependencies, and this might be the wake up call that gets people to to a) create a few more unified libs (might be as simple as cherry picking top NPM micro libs + refactoring) and b) gets libraries to switch over to the new unified micro libs. You'll need both to happen - and that's the benefit of this controversy. Even so, I think the micro-library dogma might have gone too extreme, without many programmers realizing the cost it injected - and this controversy will likely also help with changing some developers dependency philosophy. More speculatively, I'll be interested to see if any of this leads to changes in the ECMAScript standard discussions in future years.
chickenfries 11y ago
There is an equivalent lodash function. Lodash is also nice because you can just include the function you need, a custom build, or the whole library. I use node but I've never felt the need to install a 1 line module.
sotojuan 11y ago
Lodash has a left pad function that can be installed individually. People just don't know/wasn't available before. I vote for lodash to become the new STL. It's even faster than native JS.
dcosson 11y ago
This ignores the fact that js libraries need to be downloaded on every run. Even if there were a great general-purpose string module that included the functionality, a micro-package like left-pad would be less to download if you didn't need the other stuff so I imagine some developers would still use it. It's almost ironic really, that js has the worst standard library situation of any popular language yet it would benefit the most from having a good one since it would save everyone bandwidth and page load time. Maybe someone can write an amazing replacement stdlib and we can all agree to include it from the same CDN so it'll be cached on every browser in the world... EDIT: I see from other comments that lodash functions can be required individually which I hadn't thought about. But the point still stands, every function that you use in a big project that could have been in the standard library is more to download.
- nshepperd 11y ago
  Sounds like all you need there is a compiler (people already use minifiers, right?) that would include or inline the used functions as appropriate and the cost would mainly go away? Or add in the "fetch this version from CDN" library loader code if it's a stdlib we expect to be cached and used by many js scripts.
- EvanPlaice 11y ago
  ES6 modules, combined with a tree shaking build tool solve this issue. You can install a hige library and the output source will only include the parts you use. Unfortunately, libs that provide function chaining via dynamically extwnding a prototype can't be optimized by tree shaking. The future :: function bind operator should provide a tree shaker friendly alternative.
- nemild 11y ago
  You seem to be optimizing size of download as the critical issue, when I think there are a few other optimization points that this controversy highlighted (e.g., quality of external codebase, security risk, maintainer risk, dependency management challenges). A main issue with the current system is that you're pulling in micro dependencies from a variety of different sources, instead of a few potentially highly reputable sources (fairly or not, I'd feel more comfortable with dependencies from the lodash maintainer, than from 50 different people). One solution obviously is a better standard library, but often to get there, the process is for devs to create common libraries - which over time are (partially) absorbed in language standards.
joesmo 11y ago
It already exists in the form of underscore/lodash. If the authors who used left-pad had looked at say underscore.string (https://www.npmjs.com/package/underscore.string https://www.npmjs.com/package/underscore.string), they'd have not only a pad function that works for left and right padding, but a whole slew of other useful (indispensable IMO) general functions and string functions. Next time they need a right-pad, they won't have to go looking for another extension or god-forbid actually copy and paste a 5 line function into their code. These libraries have been around for years and there is no excuse for not using them. Finally, there is no excuse for left-pad, even if no other alternatives were available, unless Copy/Paste functionality completely disappears off the face of the earth.

by wrigby 11y ago

riffraff 11y ago

Or apache commons lang for java.

nemild 11y ago

Agreed, I think one issue is that great libraries for all use cases weren't available in the past so older libs built up these chain of dependencies, and this might be the wake up call that gets people to to a) create a few more unified libs (might be as simple as cherry picking top NPM micro libs + refactoring) and b) gets libraries to switch over to the new unified micro libs. You'll need both to happen - and that's the benefit of this controversy. Even so, I think the micro-library dogma might have gone too extreme, without many programmers realizing the cost it injected - and this controversy will likely also help with changing some developers dependency philosophy. More speculatively, I'll be interested to see if any of this leads to changes in the ECMAScript standard discussions in future years.

chickenfries 11y ago

There is an equivalent lodash function. Lodash is also nice because you can just include the function you need, a custom build, or the whole library. I use node but I've never felt the need to install a 1 line module.

sotojuan 11y ago

Lodash has a left pad function that can be installed individually. People just don't know/wasn't available before. I vote for lodash to become the new STL. It's even faster than native JS.

dcosson 11y ago

This ignores the fact that js libraries need to be downloaded on every run. Even if there were a great general-purpose string module that included the functionality, a micro-package like left-pad would be less to download if you didn't need the other stuff so I imagine some developers would still use it. It's almost ironic really, that js has the worst standard library situation of any popular language yet it would benefit the most from having a good one since it would save everyone bandwidth and page load time. Maybe someone can write an amazing replacement stdlib and we can all agree to include it from the same CDN so it'll be cached on every browser in the world... EDIT: I see from other comments that lodash functions can be required individually which I hadn't thought about. But the point still stands, every function that you use in a big project that could have been in the standard library is more to download.

nshepperd 11y ago
Sounds like all you need there is a compiler (people already use minifiers, right?) that would include or inline the used functions as appropriate and the cost would mainly go away? Or add in the "fetch this version from CDN" library loader code if it's a stdlib we expect to be cached and used by many js scripts.
EvanPlaice 11y ago
ES6 modules, combined with a tree shaking build tool solve this issue. You can install a hige library and the output source will only include the parts you use. Unfortunately, libs that provide function chaining via dynamically extwnding a prototype can't be optimized by tree shaking. The future :: function bind operator should provide a tree shaker friendly alternative.
nemild 11y ago
You seem to be optimizing size of download as the critical issue, when I think there are a few other optimization points that this controversy highlighted (e.g., quality of external codebase, security risk, maintainer risk, dependency management challenges). A main issue with the current system is that you're pulling in micro dependencies from a variety of different sources, instead of a few potentially highly reputable sources (fairly or not, I'd feel more comfortable with dependencies from the lodash maintainer, than from 50 different people). One solution obviously is a better standard library, but often to get there, the process is for devs to create common libraries - which over time are (partially) absorbed in language standards.

joesmo 11y ago

It already exists in the form of underscore/lodash. If the authors who used left-pad had looked at say underscore.string (https://www.npmjs.com/package/underscore.string https://www.npmjs.com/package/underscore.string), they'd have not only a pad function that works for left and right padding, but a whole slew of other useful (indispensable IMO) general functions and string functions. Next time they need a right-pad, they won't have to go looking for another extension or god-forbid actually copy and paste a 5 line function into their code. These libraries have been around for years and there is no excuse for not using them. Finally, there is no excuse for left-pad, even if no other alternatives were available, unless Copy/Paste functionality completely disappears off the face of the earth.