JavaScriptの文化とleftpadの話とpadStartについて - from scratch

無駄にラノベみたいに長いタイトル書いちゃったんですが、まぁやっぱり一言くらいは残しておくかと思ったので書きます。長いのでまとめだけでも見てもらえると良いかもしれません。 leftpadの話はかなり大事になっていて、Node.js界隈を中心としてその他のOSSをやっている全体的に話が波及しています。幾つかの記事を読みました。今回はJSの文化と歴史についてちょっとずつ書いていこうかなと思います。 本の虫: npmからkikとその他諸々が消されたまとめ 江添さんの話はすごくよくまとまっていて、ネタも含めた上で一番面白い話になっていました、ここで言われている下記の疑問に答えていこうと思います。 もっと憂うべきパッケージがある。isArrayだ。このパッケージは一日88万回もダウンロードされていて、2016年2月だけの一ヶ月間に1800万回もダウンロードされていて、72個ものNPMパッケージが依存し

[nazoking]

leftPadが単体ライブラリなのはブラウザの転送量減らしたいからで、コピペしないのはコピペの方が管理が大変だからやで

[mizchi]

leftpadだけじゃなくて便利なユーティリティ群まとめたライブラリつくるぜ！ってのでロックインされて地獄を見てきた界隈なので、最近の単目的なライブラリにわかれてるのはいいと思う。それを使うかは別の話

[teramako]

JSの諸問題はたいてい歴史的経緯と実行環境を選べない特殊性なんだよね。不満を見かけても知ってる側からすると苦笑しつつ黙るしかない

[koseki]

複数のpolyfillを統合しない限り、npmは脆弱なままってことだよね。npmに限らずだけど、依存ライブラリ数をネガティブな指標として使えるように、リポジトリで表示してほしい。 http://postd.cc/kill-your-dependencies/

[t-wada]

今回の left-pad 騒動の背景にあった JavaScript 特有の事情について明晰に説明されていて素晴らしいエントリ

[vanbraam]

いや知りたいのはなぜコピペしないかという事で.ライセンスに則ってコピペなりrepackageする事は不可能なのだろうか?;転送量が理由なら,(jQuery等含め)凡ゆるpackageが細切れになってても良いと思うが実際にはそうなってない

[amagitakayosi]

なぜleft-padのようなパッケージが使われているのかを解説してる

[ichiro2015]

polyfillパッケージとかstringutilsとかならわかるけど、どんな理由であろうと数行程度のパッケージに依存するべきではないな

[mieki256]

こうなってくると、Flash・ActionScriptのほうが各ブラウザの実装に影響されなくて済む分楽だったのでは。ジョブズのせいで皆が依存地獄に足を突っ込む羽目になってない？

[yuhi_as]

言語仕様策定の際に依存パッケージ数を参考にするのは確かに良さそう

[taka-oh]

javascriptの歴史的背景

[animist]

おそらく誰か別な人

[kmizushima]

理屈として筋は通ってるけど、じゃあ今現在そうなってるのがその理屈の通りなのか単なるgdgdの果てなのかは、歴史を検証してみないとわからない気がするがどうだろう。

[clworld]

その機能がどのくらい一般的に使えるのかよくわからない問題 確かにJavascript書こうとすると良くあって疲れる。

[muddydixon]

いいまとめ。だし、ポリシーが主張されていていい話。よーちゃんかっこいい

[moccos_info]

“『foo機能が存在するかどうかを調べて無かったら内部的に代替手段を用意する』事を polyfillと呼んだりponyfillと言ったりする”

[VoQn]

「疎結合」と「Less is More」の果てが「水と砂で固めた城」になる皮肉みたいな課題に聞こえたりする

[kyab]

"そういうライブラリが浸透していくことで言語仕様策定者側はユーザーにとって必要な機能がわかる、ライブラリを元に仕様を決めていくための指針ができる" これはこれで正しい文化に思える。boostとかも。

[rryu]

コードの大半が罠回避と環境ごとの分岐だったりするやつは、あまり他のものと混ぜたくないというのもある気がする。

[hylom]

今のnpmだと依存するパッケージはWebサイト見ればDepenciesに書いてあるしGitHubでもpackages.jsonを見れば分かるよ

[t-tanaka]

互換性への配慮は理解できる。個人的な疑問は「なぜisArrayだけで独立したパッケージになっているか」で，「なぜオブジェクトの種類を判別するis～をまとめたパッケージ」になっていないか，ということだ。

[watermaze]

ここに書かれているようなご立派な理由じゃなくて、遥か昔にどこかの誰かが書いたpackage.jsonを無批判に延々とコピーし続けたからというのが真相じゃないかな

[barlog]

+1

[ledsun]

npm界隈（のさらに一部）では、開放/閉鎖原則をnpmパッケージ単位でやっている。閉鎖のためにはユーザーが多いパッケージが有利。開放のためにはインタフェースが少ないパッケージが有利

[plane25]

“行数自体は関係なく、 polyfill/ponyfill を使って書いていたほうが全体的に整合が取りやすいことが多いから書いている” 依存の影響を考えるより依存してた方が楽なんだよなあ こういうことも起きるけど

[noonworks]

フーム

[toruuetani]

良記事。互換性との戦いはいつまで続くんかね

[kazutomo]

結論: 実行するランタイムが不定な環境においてインタープリタは糞

[mas-higa]

polyfill を使う文化

[georgew]

polyfill を使う文化 こそがJavaScriptでOSSのコードをロードする文化であり、多数のパッケージに依存する原因 > ブラウザーという足枷がある環境を踏まえないと理解し難い。

[FunnyBunnyDizzy]

jsはロードするモジュールの量が通信量やパフォーマンスに直結するから、こういう小さいモジュールが歓迎されるんだろうな。なるほどなー

[lost_and_found]

"この polyfill を使う文化 こそがJavaScriptでOSSのコードをロードする文化であり、多数のパッケージに依存する原因である。"

[ruicc]

Polyfill

[rgfx]

ありがたや

[tettekete37564]

JSって本当にTinyな状態で広まりすぎ。Netscape 社の功罪。

[aiko876roll]

jsが、というより、古い環境に合わせないと行けないつらみの話だったかー

[Rockridge]

「polyfillを使う文化こそがJavaScriptでOSSのコードをロードする文化であり、多数のパッケージに依存する原因」。該当のpolyfillを削除し、徐々に新しい関数を適用していくことで、Webは急に壊れることなく使えているという。