Browser JavaScript におけるコンポーネント化の大波(ES Modulesとプラグイン)
ツイート貼っただけですけども
MozillaがHTTPSを前提とした機能追加を行うと宣言したように、今後はES Modulesを前提とした機能追加がありえるのだけど、ESMに対応する標準的な解が存在しないRailsはどうするんだろね。現状はjs系はバンドラの使用が大前提で、フルマネージドが足かせ状態になってる
— コラーゲンたっぷりさん (@uupaa) 2018年1月22日
こちらです:
今日リリース予定のChrome64でESMを無効化するフラグ chrome://flags#enable-module-scripts が無くなりESMが常時有効化されます。いよいよ<script type=“module”>を活用する時代に突入するため我々も変化しつつ前進ですよ
— コラーゲンたっぷりさん (@uupaa) 2018年1月22日
jsを1つにバンドルしてガチガチに拘束するのが前提のマネージドなフレームワークは、時代にそぐわなくなってしまったね
— コラーゲンたっぷりさん (@uupaa) 2018年1月22日
ES Modules についてまとめた。https://t.co/foG0l1pRua
— コラーゲンたっぷりさん (@uupaa) 2018年1月23日
default export 構文と import() を使った Pluggable module pattern についても追記したよ。https://t.co/K2FnO9ocpi
ここ半年ほどは、 require(…) なコードを一切書かなくなったね。
— コラーゲンたっぷりさん (@uupaa) 2018年1月23日
生の ES Modules や Dynamic import は「サーバ側で特定のディレクトリ以下の js は全部まとめて1つにすればいいじゃん」というこれまでの発想や、それを体現したフレームワークとは相性がとても悪いです。
そのままでは水と油なので、暫くはマイグレーションのための仕組みが必要となりますが、それは又の機会に。
Solve the ESC key big problem in MacVim with New MBP TouchBar. (remap F1 to ESC and always displaying Fn keys)
新型MBP with TouchBar 購入直後は荒ぶってました。キーボードとかESCキーに対して。
(ა✘﹏✘)ა カラビナーーどのーーー
(ა✘﹏✘)ა ひぃぃEE、VimでESCキーがちゃんと押せないーー ミスタッチしまくるー
(ა✘﹏✘)ა VimからESCキーとったら何がのこるんじゃーー
当時は、だいぶ荒れてました。
現在の設定
あれから半年…色々手をつくした結果、現在はこのような設定で乗り切っています。
Key repeat setting
defaults write -g InitialKeyRepeat -int 12 defaults write -g KeyRepeat -int 3
これ以下の値にすると、キー詰まりや爆走するのでこれでガマン
defaults read -g KeyRepeat > 3 defaults read -g InitialKeyRepeat > 12
Always displaying Function keys
MacVim を操作中は、Fn キーを常に表示する。
Remap F1 key to ESC key in MacVim
F1 を押した場合に ESC として扱う
Kill the calculator
電卓表示中は、謎のバグによりESCキーが効きません。電卓を殺します。
(ა✘﹏✘)ა もっと良い設定があったら教えてください
WebApp/2 作ってます。HTTP/2 + ESModules は安くて速くて美味しいよ!
最近 WebApp/2 というのを作ってます。
WebApp/2 は2012年頃から温めていた「ES6 + ESModules を使い、開発初期〜中期は Bundler や Transpiler を使用せずに開発を進められるようにしたい」というアイデアを具現化したものです(細かい仕様は wiki にあります)。
作り始めて20日ほどですが、昨日までの WebApp/2 には、以下の課題や疑問が存在しました。
- WebApp/2 は一般的なトレンド
[要出典]
から大きくJUMPしている。世の中には webpack, babel, browserify を前提に書かれた ES5/ES6 なコードが大量にあるが、それらを ES6+ESModulesに変換するための シンプルで将来取り外しが効くマイグレーションパスが見つかっていない - ファイルを事前結合しない場合の パフォーマンスのトレードオフがどれ位あるのか? そして、それは 許容できる範囲に収まっているのか?
- アセットパイプラインの煩わしさから開放されるというプラスの側面 と パフォーマンスのトレードオフというマイナスの側面 の存在を他の人に説明した時に、どのように受け取られるのか?
最初の課題については、rollup.js で解決できる事が分かりました。
ESModulesが存在しなかった頃の、webpack,babel,browserifyの利用を前提に書かれたES5/ES6のレガシーなコードをES6に変換して事前結合しbundle.jsを作成するrollup.jsの存在を知ったので、古い環境向けにはそちらで対応することにした
— コラーゲンたっぷりさん (@uupaa) 2017年5月30日
rollup.js がなかったら自分で同じようなのを書くとこだった
— コラーゲンたっぷりさん (@uupaa) 2017年5月30日
そして、多くの方々が気になるであろう、
パフォーマンスのトレードオフについても許容出来る範囲に収まっており、アセットパイプラインが不要という説明に対しても予想よりもポジティブな反応がありました。
お隣さんに旧来の方式(bundler)とWebApp/2(HTTP/2)のそれぞれの実際の動作を、DevToolsのNetworkタブを開いて説明した。個別にjsを読み込んでもパフォーマンスデメリットが0〜10%しかないのに、アセットパイプラインが不要というメリットを絶賛された
— コラーゲンたっぷりさん (@uupaa) 2017年5月29日
ESModules に乗っかると、bundeler も transpiler も sourceMap も minify もコンパイラも、開発初期〜中期まで必要ありません(そのまま本番にデプロイも可能です)。
従来の魔窟化したビルド環境を今後も使っていくか、HTTP/2 + ESModules のパワーを信じるかどうかはアナタ次第です。
"デバッグしてください", "パフォーマンスチューニングしてもらってもいいですか?" とJavaScriptが難読化された状態のページのURLを渡してくる人に、伝えなきゃならない事がある
webpackを使ったサイト、極端にデバッグしずらい (外部ライブラリが eval(文字列) の形で埋め込まれる)ので、はっきり言って大キライだったりする
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
見知らぬコードが minifyされ、さらに eval されているのをデバッグしろとか、暴力にも等しい要求なんだよね。そりゃキライになるよ
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
「環境Aの言語Bで書かれたコードを言語Fに変換した、環境C/D/Eで動くと思うのでデバッグしろ」というのも極端にデバッグしづらいという理由から避けるようにしている。
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
デバッガビリティに問題がある環境は、心がすり減るのでイヤ(時給1万円なら頑張る
js minifyあるある
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
A「パフォーマンスに問題があるのでコードを見てくれませんか?
u「はい
u「minify+evalされているので追えません。生のコードみせてもらっていいですか?
A「今のままでは無理ですか?
u「無限に時間がかかりますがそれでもいいですか?
これな
ブレークポイントも貼れないような環境を渡されても、こちらで出来る事は非常に少ないし、スクロールするだけでDevToolsが固まったりする場合は、こちらのストレスは10分で致死量を超えます
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
10分ほどで致死量のストレスを受けるので、時給1万円でも安い(と思う
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
SafariのDevToolsはChromeのように頑強ではないので、すぐに死ぬ。
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
そしてパフォーマンスが悪いコードほどSafariでうまく動かない。
つまりパフォーマンスが悪くてSafariで動かずminifyされているコードを渡されるとデバッグがそもそも不可能な事がよくある
はい、伝わりましたでしょうか。
— コラーゲンたっぷりさん (@uupaa) 2017年4月19日
“デバッグしてください” “パフォーマンスチューニングしてもらってもいいですか?” とJavaScriptが難読化された状態のページのURLを渡された場合に、依頼された側は(恐らく)以下の方法で解決を試みます。
- Minify をほどいた状態の JavaScript をローカルに保存し、難読化されたコードの意味的な解読とコードの流れを何となく読み取る
- コードの実際の動作を確認するために、 Charles などの LocalProxy を使い、Minifyされたコードと解読したコードを差し替え、DevTools上で動かしてみる
- DevTools が謎の理由で死亡する場合や、コードを表示するだけでUIの応答性が極端に悪くなるほど巨大な JavaScript の塊(10万行を超えるコード)対しては、まずはコードをDevToolsが耐えられるサイズに分割する
- minify + eval されているコードの一部を差し替える場合は、DevToolsによってはevalの内部に対しブレークポイントが張れない場合があるため、さらにほどき、動く状態にしてからブレークポイントを張ったり、printfデバッグ用のコードを追加する
はい、聡明な諸氏であればお分かりのように、Minify前のコードを提示してくれたら、このような無駄な苦労はそもそも発生しない のです。
時間は有効に活用したいですね。
webpackを使ってて極端にデバッグしづらいサイトが大キライ のとこは、webpackを使ってCSSや画像がBase64化された状態でjsと一緒に埋め込まれている事が多々あり、DevToolsがそれによって悲鳴を上げるから。ですね。
webpack を使って全部一つに混ぜる → 生成された bundle.js が死ぬほどデカくなる → DevToolsで開けない/DevToolsの反応が死ぬ → オマエを殺して俺も死ぬ。 の構図です。
JavaScript で記号プログラミング
息抜きに、JavaScript で記号プログラミング を Qiita に投稿してみました。
JavaScript で記号プログラミングは、(僕の中で)JavaScript がまだ盛り上がっていた頃(2005〜2013年頃)の話題です。とても懐かしい感じがします。
200x年ごろのJavaScript界隈といえば、集団で力をあわせて一つの大きな目標を達成する感じではなく
- コンパイルせずに利用できるのが JavaScript の良いところだ
- カバレッジとか気にするな。カバレッジってそもそも何だ
- テストは書きたい人が書けばいい
- クソコードでも要は動けばいい
という、ルール無用で、一寸先は闇のような主張が闊歩する魔界だったように記憶しています。昨今のJavaScriptとはだいぶ趣が違いますね。
“どんなに汚いコードでも動けばいい” と主張するスピードスターやバーサーカープログラマーも最近は老化やLinterツールの普及によりめっきり減ってきましたが、まだかなり多くの個体の存在が確認されています。
そのような方へのアンチテーゼとして記号プログラミングというジャンルが存在するとかしないとか(要出典)。
このような動作環境や言語仕様の重箱を過度につつくようなトリッキーなコードに頼らず、誰にでも読みやすいコードを書くように心がけたいですね(自戒)。
GitHub pages の公開ディレクトリを master /docs に設定し Symlink を作ったら色々捗るかと思ったらダメでした
先ごろ、github-pages として公開するディレクトリを masterブランチの docs に設定することが可能になりました。
(これまでは gh-pages と呼ばれる別ブランチを用意し、そちらに必要なファイルを都度 publish する必要がありました)
そこで
(〜・◇・)〜 github シンボリックリンクをある程度理解してくれるから、もしかしてリンク作れば、master や develop ブランチに追加したファイルを docs から参照可能できたりしないかなぁ?
と考えた (ε・◇・)з ← コイツがおったそうな。
github-pages で /docs を作成+公開し /lib/a.js を /docs/index.html から参照しようとリンクを作成( ln -s ../lib lib )し <script src=“lib/a.js”> するとエラーになる。
— コラーゲンたっぷりさん (@uupaa) 2016年9月22日
さてどうすれば…
具体的なエラーはこちら
github-pages docs/ 以下に ln -s でリンク張って同じ master リポジトリと docs でファイルを共有する戦略はいまのところ上手くいかず。実体置かないとだめなんかなぁ…
— コラーゲンたっぷりさん (@uupaa) 2016年9月22日
github-pages を /docs に設定した時に、
— コラーゲンたっぷりさん (@uupaa) 2016年9月22日
ln -s で作成したシンボリックリンクを置けば、いい感じになるかと思ったらダメで、
/docs 以下に実体を置く必要がありましたhttps://t.co/gPIu9ExuOj
こういう感じ
リンクだと無理そうなので、
https://github.com/uupaa/WebGLDetector.js/tree/master/docs
のように必要なファイルをコピーして設置することに。
https://github.com/uupaa/WebGLDetector.js/tree/master/docs
を公開したページはこちら。
他人の書いたコードは難しい(純ポエム
他人が書いたコードは何故難しいのか
— コラーゲンたっぷりさん (@uupaa) 2016年9月21日
・契約プログラミング(型システム)
・コメントによる表現力の補完
・図式
・簡易で合理的なSyntax( != 記号プログラミング)
などを施しても、なぜ読みづらいのか。
ここ30年でこの部分は進化してない?
という原点回帰な思考実験
他人の書いたコードは難しい
— コラーゲンたっぷりさん (@uupaa) 2016年9月21日
→自分が理解する必要が無い部分まで見ているからだ(知りたがり過ぎ
→再利用ではなく、最初から他人に使ってもらう前提で設計
→よくテストされ仕様が説明されている公開部品を黒箱として扱えば良い(Modules
→難しさから解放されつつある ← いまここ
コードは見られたら負け。コードで動作を説明したら負け。それは「他人のコードは難しい」「引き継ぎ難しい(そもそも引き継ぎ不能」問題を辿ってしまう。コードが仕様書というのは最下層のレベルhttps://t.co/fxzUOxscubhttps://t.co/Y2giittULU
— コラーゲンたっぷりさん (@uupaa) 2016年9月21日
詳細な説明は抜きで「大丈夫。ちゃんと動くから」でサラッと済ます事ができる技術。それこそが技術力(徳/信頼)なのではないか
— コラーゲンたっぷりさん (@uupaa) 2016年9月21日