欄外/コラム

[azu]

入れる場所がない、関連する場所がない欄外的なコラムになりそうなまとめ場所。

メモ書きを書いておく場所なので、こういう話があると面白いのではという意見欲しい

[azu]

ECMAScriptとDOM APIの見分け方

これ確実な方法がないので、経験則や検索しろというのが答えになるけど、
ある程度の分別方法はある気はする。

• 表示が関係する -> DOM
• DOM Treeが関係する -> DOM
• 構文を扱う(asyncとかキーワードがでてくる) -> ECMAScript
• https://azu.github.io/ecmascript-version-detector/
• ぐぐる caniuse

『仕様ごとに覚えたらいい』って僕はよくいってます。整理しないでDOMとJavaScriptをまぜまぜに覚えていくとわけわからなくなっていくから。なんの仕様のなにをやろうとしているのかをはっきりさせた方がいいと思います。例えばJavaScriptを覚えたいんだったら、DOMとか忘れてJavaScriptだけを覚えた方がいいと思う。
-- JavaScriptビギナー編 | CodeGrid

を見ていてこういう話があると良さそう

[azu]

エラーの読み方

• 読者が何で躓くのかをよく見る
• 本当の初心者はエラー文を読まない/読めない(少なくても頻出するエラーパターンについては触れてもいい気がする)
• 実行環境は一つに絞っていいが、どのようにデバックするのかは触れる必要が出てくる
  https://github.com/asciidwango/js-primer/tree/master/meetings/2016-01-29

どこかの章で エラーを実際に出してみてそれの読み方を書く。
#93 エラーのキャッチ方法については try-catchでも扱うはずだけど、エラーは重要なので、単独で存在しててもいい気はする

JavaScript エラーリファレンス - JavaScript | MDN これを参照する

[januswel]

実行環境の話しがあると読む際により実感が得やすいかなと思いました。
オンラインで読む場合は jsFiddle で即時実行できるかと思いますが、紙面では何かガイドのようなものがあると嬉しいかと。

他には次のトピックが深掘りできるかと思います。

• サポートしている機能・文法の差異
  • 想定読者層を考えると差異が出るものについては扱わない ?
  • 現状の調べ方についてはふれてもよいかも
• 速度計測について
  • 速度の計測方法について触れるとより深い世界への扉になる

[lacolaco]

結局ブラウザで動かすことがメインになるので #9 の補足も含めて DOM based XSSの話とかあるといいのかなと思った

[azu]

パフォーマンス

#32 演算子や #53 型変換において、動的言語にもかかわらず型を意識した書き方について紹介しています。
JavaScriptは動的型付け言語ですが、動的型付け言語だからといって型を無視して書くわけでありません。
型を意識して書くことで、暗黙的な変換のような意図しない挙動を減らせたり、パフォーマンスにおけるメリットが得られる可能性がでてきます。
JavaScriptという言語は、ブラウザベンダごとの複数の実装が競争しているという特殊なものといえます。
リファレンスとしての実装ではなく競合となる実装であり、また同じECMAScriptという仕様を元に実装しているため言語機能としての違いがあるわけではありません。

そのため、同じ機能において差を付けるために実行速度は重要視されています。

例えば、WebKitでは次の記事のようにパフォーマンスの低下はいかなる理由があっても入れる事ができないという話などもある程度です。
(これはパフォーマンスが低下する機能を入れる際は、どう程度パフォーマンスがあがるコミットもするという話でもあります。Chromeも同じ)

• Performance Testing | WebKit

JavaScriptを書くことに置いてもブラウザ/JavaScriptエンジンが最大のパフォーマンスを発揮できるように書くことも大切な事と言えます。
このパフォーマンスを最大限発揮するという書き方は、多くの場合、暗黙的な型変換に頼らない、シグネチャーをダイナミックに変更しない、Shapeをダイナミックに変更しないといった型を意識したプログラミングにつながっています。

逆に、パフォーマンスを最大限発揮するコードを書くということは困難とも言えます。
理由としては、多種多様なJavaScriptエンジンと最適化手法が存在しているため、現時点では早いかもしれないが、その書き方は将来的に早いのかはまた別の問題となるためです。

このJavaScriptのパフォーマンスにおける一つの考え方としては、JavaScriptエンジンの最適化を妨げる書き方を避けるという事が、パフォーマンスの向上に繋がると考えられます。

そのため、最速のJavaScriptを目指すよりも、遅くならないJavaScriptの書き方を学ぶ方がメリットが大きいと思います。

• V8の最適化とIRHydraでの可視化とベンチマークについてのメモ | Web Scratch

[azu]

ESLintで学ぶプラクティス

• ESLintは更新されているベストプラクティスをまとめたドキュメント
• そのためESLintのルールはJavaScriptのプラクティスを学ぶドキュメントとして利用できる

[azu]

polyfill

• polyfillというものはJavaScriptの世界だと日常的に使われてるのが結構特徴的
• http://yosuke-furukawa.hatenablog.com/entry/2016/03/27/152500 みたいな話とも関係するけど
• 現実的に書籍にあるコードを動かす場合はpolyfillみたいなものを知る必要があるので、書籍自体はES2015がある前提だけど、ない前提の話をコラムに入れておきたい感じ

[azu]

📝 パーフェクトJavaScript と Classesを読んでいて、思った内容

JavaScriptはES5までは動的言語の性質?を使う事が正しいことであり、prototypeを書き換える事が正しい方法だという主張もありました。
以前は動的に書き換える事ができる性質をより上手く利用するのを是としてデザインであったとも言えるかもしれません。

しかし、現在は別のclassなどより宣言的な方法が存在しているため、今後はそれが悪手となるかもしれません。
今現在もJavaScriptには色々な流派が存在し、絶対的な正しさを見出すことは難しいかも知れません。
なぜそのような色々な主張がJavaScriptにはあるのかを軽く考えてみます。

JavaScriptは不完全な言語であり続けますが、進化する不完全な言語です。
後方互換性のために過去の挙動を変える事や安易に増やす事が難しいため、不完全な部分は残り続けます。
そのため、新たな仕様を追加/変更する際にはよく議論され、最大限最小なものが加わります。
言い換えれば、ちょっとづつ進化していく言語です。

なぜ、進化し続けるのかというとウェブブラウザで動いている言語という側面は大きいでしょう。
ブラウザがより多くの処理をするために言語の上で拡張し、場合によっては言語そのものを拡張するしていくためです。
しかし、それらの拡張も仕様という形に落とされ、合意を得たものだけが残っています。
支配的な一つの独自拡張の繰り返しは、その後滅びるという歴史を繰り返してきたためです。
そのためウェブブラザも競争しあうことを良しとしています。

同様にJavaScriptも一つの支配的な書き方や実装方法があるわけではありません。
しかも、JavaScript自体も変化し続けています。
そのため、私たちはその時々においてのベストな書き方を学ばなければなりません。
歴史を学び、変化を追求し続けるのは一つの方針と言えるでしょう。

[azu]

Transpilerで学ばない

BabelのようなTranspilerの結果はあくまで擬似的な再現なので、その変換結果で学ぼうとはしないこと
という話があると良さそう

[azu]

ブックマークレットとvoid

voidの説明をするならブックマークレットぐらいしかないレベル
なんでjavascript:voidにvoidが必要なのか | MemeTodo

[azu]

控えめなJavaScript - Wikipedia