公開日: 2014-10-19 変更日: 2015-12-06 Download PDF

世界のJavaScriptを読もう @ 2014

^目的: ウェブの世界は絶対変化するもの 変化する前提の行動が求める それをどうやって見ていくか、それを知ってどうするか

^ JavaScriptやブラウザ周りのリリースの状況はウェブの変化にあわせるように変化してきている。 どのように変化してきたか知り、どうやって変化を見ていくのか、そしてわたしたちはどう変化していくのかを考えよう。


アジェンダ

世界のJavaScriptを読もう @ 2012 の続編的なものです

  1. ブラウザやJavaScriptのリリースは変化してきている
  2. 私たちはどのように変化を知り見ていくのか
  3. そして私たちはどのように変化していくのか

[fit] 世界のJavaScriptを見る話

[fit] JSer.info 開始 2011年〜

^ JSer.infoを始めた2011年を一つの基準として考えて、 そこからブラウザやJavaScript等にどういう変化があったのかを振り替えつつ、"今"どういう変化が起きてるのかを見て行きたいと思います。


[fit] Browser


[fit] Browser Version @ 2011

JSer.info が開始した2011年ごろのブラウザバージョン


[fit] inline Internet Explorer 9

[fit] inline Mozilla Firefox 4

[fit] inline Google Chrome 8


[fit] inline Internet Explorer 9

  • 正常になってくるIE9がリリースされたころ
  • IE9 RTW Due Date, A Big Thank You, MIX11, and a Unicorn Named Frank | Charles | Channel 9
  • 日本だけ東北地方太平洋沖地震の影響で延期

[fit] inline Mozilla Firefox 4

Rapid Releaseが始まる直前


[fit] inline Google Chrome 8

いつものChromeです


[fit] Browser Version @ 2014

2014-11-01 現在のブラウザ


[fit] inline Internet Explorer 12

[fit] inline Mozilla Firefox 33

[fit] inline Google Chrome 38


[fit] inline Internet Explorer 9 -> 12

[fit] inline Mozilla Firefox 4 -> 33

[fit] inline Google Chrome 8 -> 38


Internet Explorerの開発方針も変わってきた

  • IEのDeveloperバージョンが先行公開
  • 今後開発予定の公開
    • status.modern.IE
  • UserVoiceでの開発優先度の意見募集
  • IEのサポートバージョンをOSで使える最新版だけに

^ Stay up-to-date with Internet Explorer - IEBlog - Site Home - MSDN Blogs


[fit] ヘッドレスブラウザの登場


PhantomJS

  • WebkitベースのJavaScriptコマンドラインツール「PhantomJS」 - JSer.info (2011)
  • SlimerJS (2013)
    • Firefox(Gecko)のヘッドレスブラウザ
  • sdesalas/trifleJS (2013)
    • IEのヘッドレスブラウザ

ヘッドレスブラウザ

  • PhantomJSが先行し広く普及した
  • PhantomJSのAPIがデファクトとなった
    • CasperJS
    • Nightmare

ブラウザリリースのまとめ

  • IE、Firefox、Chrome等のリリース周りは変化してきた
  • FirefoxとChromeはRapid Releaseへ
  • IEもIEらしさは残しつつ変化に対応しようとしてる
  • ヘッドレスブラウザなどツールとしてのブラウザがでてきた

[fit] そもそも何故リリース速度が上がったの?


高速リリースサイクルに関するよくある質問 | 次世代ブラウザ Firefox

Web ブラウザは、他のアプリケーションと異なり、Web という「生き物」を相手にしています。HTML5 や CSS3 など新たな標準技術が次々に考案され、ソーシャルメディアなどのトレンドも目まぐるしく変わっています。Web の進化するスピードが速くなっているので、これまでのように半年から 1 年周期のアップデートでは間に合わなくなっているのです。


ウェブの変化の早さ

  • ウェブの変化に対応するためにブラウザのリリース速度は上がった
  • ライブラリも変化/トレンドに対応するためリリース速度は上がってる

ライブラリのリリースの変化?

inline

^ 開発者の皆さんに近い所としてライブラリのリリース周りを見て行きたいと思います。


npmで公開されてるパッケージ

  • 公開されてるパッケージ数は増加傾向
  • gemやMavenよりも多い by Modulecounts

^ 更新数についてはデータがないので不明だが、体感的には更新数自体も増えている


fit, js-pacakge


リリース回数がとにかく増えた!

  • 原因は色々考えられる
  • ブラウザが変化したようにトレンドに対応するため
    • 新しいライブラリが色々出てくる
  • もう一つの要因 => Semantic Versioning!

Semantic Versioning(semver)の採用

  • 1 commit = 1 patch release をするライブラリが増えた
  • バージョンをあげることへの抵抗感が薄くなった
  • => 結果としてリリース回数が増える
  • => リリースノートの自動化が進んだ

^ JavaScriptのライブラリの多くは今セマンティクスバージョニングにてリリースしていってる。 リリースノートについては後ほど詳しくやります。


ライブラリとsemver

  • npmではバージョンはsemverとして解釈する
  • npmのエコシステムに載るにはsemverである方が自然
  • npmやbowerで公開するにはバージョンをあげる必要がある
  • => 結果としてリリース回数が増える

^ semverもあるし、そもそもバージョンをあげないとnpmやbowerなどのものは更新できないのでリリース回数が自然と増える。 1コミットで1パッチリリースする人も多いので、この辺まで来るとリリースノートは手動で書くのには無理がある。 そのためコミットベースの自動生成が増えてきたと考える。


Node.js 本体は?


Node.js 本体

  • Node.js本体のリリースが停滞してることが問題視されてきた
  • 一定期間でリリースされないので停滞しやすい
  • それを解決しようとNode Forwardがでてきた
  • これに対応しようとNode.js Advisory Boardが設置された
  • リリースを変えようとするとコミュニティも変わってくる

^ Node.jsのコミュニティに変化を与えるnode-forwardについて - from scratch

^ 詳しくはNode.js 日本ユーザグループ代表の@yousuke_furukawaさんに聞きましょう!


ECMAScript は?


ECMAScriptの進捗

  • JavaScriptの元となる標準仕様
  • ES Discussで議論される
  • tc39/tc39-notesに定期MTGのNoteが公開される
  • ES6の機能策定はほぼ完了
  • ES7の機能提案の段階

ECMAScript 7

feature-model releaseへ


ECMAScript 7

  • ES6とES7の策定は同時に進行している
  • ES7は機能毎の仕様策定を中心に進めている
    • feature-model release
  • 理由としてはもっとリリース速度をあげるため

-- 明日には使えなくなるES7トーク

^ ES7は機能レベルの仕様それぞれに策定のstageを設けていて、それが一定の段階になったらES7として取り込むようになっている。 このような事をする理由の一つがリリース速度の改善!


リリース傾向の変化まとめ

  • 変化はブラウザだけではなく言語まできてる :boom:
  • 言語もブラウザもライブラリもリリースが変わってきた
  • GitHubがかなり活用されている

^ ブラウザはRapid Releaseを取り入れリリース速度が上がった。 GitHubでのリリースの増加。 ECMAScriptの策定も機能毎に進めリリース速度をあげようとしている。JavaScriptの実装はブラウザが中心なので、やはり変化の中心はブラウザだと考えられる。


:watch: WATCH

どのように変化を知り見ていくのか

^ では私達はどのようにその変化を見ていくのか? 変化の中心であるGitHubとブラウザを中心に見ていこう。


:memo: リリースノートの変化

right


[fit] ブログとリリースノート

fill, yuiのリリースノート

^ 今も多くあるが、ブログでのリリースノートを書くスタイルが中心だった。 しかし、今はある程度の規模のライブラリでないとブログにリリースノートを書く人は少なくなってきた。


[fit] GitHubとリリースノート

fill

^ 最近ではGitHubにリリースノートを書くだけのケースが増えてきた あるいは、CHANGELOGを自動生成したもの(またはそれを両立したもの)


リリースノートの場所

ブログとGitHubどっちが多い?


fit

^ JSer.infoで紹介したリリースノートからの抜粋 GitHub上のReleseまたはCHANGELOGを紹介したものと それ以外の数を並べたもの。

^ JSer.infoで紹介するものはある程度規模のあるものが中心なので、 ブログスタイルもそこまで減っているという訳ではない。


リリースノートの場所(JSer.info調べ)

  • JSer.infoで紹介したもの(ある程度著名なものが中心)
  • ブログでのリリースノート自体はそこまで減ってない
  • GitHubでのリリースノートは増えている
    • CHANGELOGファイルを作成するケース
    • GitHub Releaseに書くケース

最近のリリースノートの変化

  • 小さいものほどGitHubのみにしかリリースノートを書かない
  • ライブラリはsemverを採用しリリース回数自体が増加
  • コミットからのリリースノートを自動生成
    • Git tagとGitHub ReleasesとCHANGELOG.mdの自動化

^ 小さいライブラリはtagを貼るだけのケースが多い。 また、そのときにコミット一覧をリリースノートに貼り付ける方式のリリースノートの自動化が多くなった。


リリースノートを見ていく方法も変化する

  • リリース方法が変化するので、見る方も変化する
  • まずリリースに気づけない問題が発生する
    • お世辞にもGitHubは追いやすい形式になってない
  • 変更履歴のコミット直接見る必要が出てくる
  • 対策をGitHubでライブラリのリリースを見ていくためのツールや方法 に書いた

^ リリースノートの書き方が変わってくると、それを読む側の意識も変わってこないと、そのライブラリの何が変わったのかわからなくなるケースが多い。 まだ仕組みが未成熟であるため、もっと改善していくとエコシステムが良くなると思う。


GitHubのタイムラインを読む

right,fit

  • リポジトリのWatchする
    • azu/github-reader
  • タイムラインを見る
    • azu/github-reader
  • 他の人がStarしたものを見る :star:
    • starseeker

^ GitHubでライブラリのリリースを見ていくためのツールや方法 の内容から


リリースノートを見る

right fit

  • GitHub ReleaseをRSS購読(Feedly)
    • azu/github-releases-to-feedly
  • Feedlyをバックエンドに使う -> any
    • IFTTT
  • GitHub Release -> CHANGELOG
    • azu/check_changelog_from_release
  • GitHub Release -> Version Diff
    • azu/show-diff-from-release

リリースノートまとめ

  • リリースノートの出し方も変化してる
  • ブログ以外にもGitHubが増えてきた
  • リリースはしやすくなったが、リリースはまだ見やすくない
  • リリースノートの仕組みが未成熟
  • リリースを見る側も工夫が必要になる

^GitHubにtagをつけてpushするだけというスタイルになったため、リリース速度は上がっている。 しかし、必然的にリリース回数があがりリリースノートが軽視されてる傾向がある。 もっとリリースノートを書こう。そのためにはリリースノートを書きやすい仕組みが必要だと考えてる。


[fit] 話はブラウザに戻って


現在のウェブの変化の中心はブラウザ!

  • ブラウザの変化を知ることができれば他の変化が見えるかも
  • ブラウザはベンダーがいるので公式の情報がある
    • ライブラリ等に比べれば安定した情報 :green_heart:
  • ブラウザごとにその安定した情報を見ていこう!

^ 安定した情報がある


IE, inline firefox,inline chrome,inline opera,inline inline

[fit] Browser Watcher


inline Internet Explorer

  • IEBlog (日本語版)
    • 公式ブログ
  • status.modern.IE
    • IEのロードマップや開発状態が機能別に公開されている
  • Hebikuzure's Tech Memo | 技術的覚書と情報 by @hebikuzure
    • IEBlogの翻訳やWindowsやIEの細かい挙動について書かれてる

inline status.modern.IE

  • Not currently planned : 今のところ予定なし
  • Under Consideration : 実装を検討、調査中
  • In Development : 開発中
  • Preview Release : プレビューリリース版に実装済み
  • IExx+: IEのバージョンxxから利用可能

-- status.modern.IEの見方 | Web Scratch

^ status.modern.IE を見ておけば、IEの開発状況が分かると言えるぐらい更新が活発なので見て損はない。


inline Firefox

  • Firefox Nightly News inline
    • FirefoxのNightlyの機能について
  • FxSiteCompat - MozillaWiki inline
    • Firefoxのリリース情報
  • Mozilla Hacks – the Web developer blog inline
    • Firefox中心に色々紹介 - HTML5 Rocksもそれに近い

inline Firefox

Mozilla Developer Street (modest)

- Mozilla Hacksの日本語訳やリリース情報が多い

^ その他詳しくはFirefox/Servoのコミッタである @saneyuki_s さんに聞きましょう!


inline Planet Mozilla

right fit, firefox

The Mozilla Blog Future Releases Mozilla Research Mozilla Security Blog Mozilla Privacy Blog Mozilla UX Mozilla Cloud Services JavaScript

^ 公式ブログがそれぞれジャンルごとに存在する。 Planet * というのは一時期流行った感じの関連するRSSをまとめたものを配信するアグリゲートの事。 Planet Feed Reader


inline Google Chrome

  • HTML5 Rocks
    • 大きめな新しい機能は大体ここで紹介される
  • Google Chrome Developers - Google+
    • Google+にGoogleの人がいる
  • JS.next
    • V8に実装された新しい機能について書かれてる

inline Planet Chrome

right,fit chrome

  • Google Chrome Blog
  • Chromium Blog
  • Chrome Releases
  • developer.chrome.com
  • DevTools Tips

^ V8やBlinkといったJavaScriptについてだと、公式のブログはそこまで読みやすくない。 後述するDev.Operaも見ることを薦めている。


#inline Chromium

Chromium is an open-source browser. -- http://www.chromium.org/

^ Google Chromeのオープンソース版というところ。 Chromeに入る機能の大体はここへコミットされる。(一部ChromeにあってChromiumないものもある。翻訳機能とか) V8 や Blink なども含まれているプロジェクトの総称。


#inline Chromium

  • Chromium Dashboard
    • IE, inline firefox,inline chrome,inline Chromiumを中心にブラウザの実装ステータス
  • Highlights from recent Chromium, Blink, Skia and v8 commits inline
    • Chromium等のコミットサマリ + Chromium DevTools inline
  • blink-dev - Google グループ
    • Intent to 〜 にBlinkに入る予定の機能が載る

^ Chromeを自力で追うとかんがえると何故かコミットやChromiumの開発者向けのところまで見ないといけない事がある。 Chromeは"リリース"という部分が分かりにくく感じる。


inline Opera

  • Dev.Opera inline inline
    • 現在のOperaはChromiumベースになってる
    • Chromium Blogより分かりやすい解説が載ってる
    • :heart: @mathias
  • Opera Desktop Team's blog - Opera Software
  • Upstreamed commits – Opera

inline WebKit

WebKit is an open source web browser engine. -- https://www.webkit.org/

^ SafariやiOS、Qt WebKit(PhantomJS)、WebKitGTK+等で使われるブラウザエンジンです。

^ 詳しくはWebKitコミッターでもある @Constellation さんに聞きましょう!


inline WebKit

  • Surfin' Safari - The WebKit Blog
    • 公式のブログ - 内部実装の話が多い
  • News and Updates - Apple Developer
    • AppleのNews - まれにSafariについてがある
  • Planet Igalia inline
    • Igalia社はWebKitやChromiumにコミットしてるコンサル企業

^ WebKitはChromiumと同様に実装よりの話が中心となる。 WebKitを使ったメジャーなブラウザはSafariぐらいで、Safariはあんまりそういうリリース書かないのでコミットを追っている人を見ていくのが中心になりやすい。


inline Webkit Watch

  • trac.webkit.org
    • WebKitのリポジトリ
  • WebKit Changesets · uupaa/Spec.js Wiki by @uupaa
    • iOSバージョン間のコミット差分がまとめられている
  • mobilexweb.com と sencha.com/blog/
    • iOSのアップデート時にWebKitのレポートを書いてる

Other Vendor

  • Web Platform Team Blog
    • Adobeのブログ - 主にCSS周りのコミットをしてる

Other

  • Can I use... Support tables for HTML5, CSS3, etc inline, github
    • IE, inline firefox,inline chrome,inline opera,inline ブラウザの実装状況がまとまってる
  • Browser Platform Status Tracker by @mayuki
    • inline status.modern.IE とinline Chromium Dashboardの差分
  • Echo JS - JavaScript News inline
    • HNスタイルのJavaScript特化ニュースサイト

^ Can I use...は多くの人が使ったことがあると思うサイトで、著名な機能については大体載っているのでまず最初に見ると把握がし易いです。 載っていない機能はSupport table suggestionsからVoteしたりPull Requestで追加したりも出来ます。 ベンダーに依存してるわけではなく、AutoprefixerやCompassなど幅広く利用されている。

^ Echo JSは結構いい感じの情報が流れてくるのでオススメ。 また体感的にはHNにただPostされるより、Echo JSにただPostされたほうが反応がある感じがする。


Meta Weekly

right, meta-weekly

Daily/Weekly/Monthlyで更新されてるサイトのまとめ

  • JavaScript Weekly inline
  • JSer.info inline

Person

  • @rockridge07
    • inline Mozilla関係のWatch
  • @myakura
    • inline inline はてなブックマーク + Google+

Meta-Meta

right

今は更新されててもいずれは死ぬ^1

^ GitHubやブラウザを中心にどこで変化がおきてることを知ることが大事という話をしましたが、いつまでも続くとは限らない


[fit] そして、私達はどう変化する?


人は変化する

  • ブラウザ、言語側は変化してきた
  • 言語は勝手に策定されてリリースされるわけではない
  • 結局は人が決めてるので、人が変化してきたと言える

誰がその変化を作ってるのか

^ 自分を変えるのは大変なので、周りの変化を感じのが手っ取り早い。 その一つとして変化を作ってる人達を見ていくのが近道。


引力 :earth_africa:

  • 変化を求める人の所には引力がある
  • 自然と情報が集まる
  • まずはそういう人たちを知ることが手っ取り早い

ターニングポイント :triangular_flag_on_post:

変化を作ってる人が集まる場所を考える


ターニングポイント

  1. GitHub
  2. BTS(Bug Tracking System)
  3. SNS

GitHub

right fit 90%

今の開発はGitHubなしでは成立してない


GitHub

  • ライブラリから仕様まで多種多様な開発が行われてる
  • 全てを追うことは無理なので諦めよう
    • 中の人でも全て見ようとすると迷子になる via Rebuild: 62
  • 通知メールのフィルターや工夫して乗り切ろう

^ Watchには抑制する力も必要。 何でも見て追おうとすると破綻する。 中の人も全てを応用にすると破綻するといってるので、 上手いバランスを見つけてやるのが大事。


BTS(Bug Tracking System)

inline fill, ie inline, chromium inline, mozilla inline, webkit

BTS

  • ブラウザのバグを見つけたときにやること - Please Sleep
  • Microsoft Connect
  • Issues - chromium
  • Bugzilla@Mozilla
  • WebKit Bugzilla
  • GitHubのリポジトリ(各種仕様)

^ IE以外はオープンソースであり、Issueも対外的にはオープンに公開されている。 IEに関してはstatus.modern.IEを通して開発状況をオープンにしてる。


BTS

  • ブラウザに実装予定/バグ等は大抵の場合チケットがある
  • 開発者は必ずここにいるはず
  • つまり、変化を作る人がいるはず

ウェブ開発者にはBTSは遠い

  • ウェブ開発者がブラウザのBTSを見る機会は少ない
  • その他だとWatcherぐらいしか見てない
  • しかし、ウェブ開発者からのフィードバックも求めてる

もっと身近なフィードバックへ

  • Specifiction
    • 仕様に対してどこに意見を言えばいいのかを解決する場所
  • webcompat.com
    • ウェブサイト/ブラウザの問題指摘をする場所
    • 「Firefox Mobileだとgmail.comでタッチ出来ない」

-- ウェブの仕様は今どこにあるのか? | Web Scratch


最新の情報を追うことの意味


フィードバックする機会を失う問題

  • ウェブの進化は早い(10分ぶり3度目)
  • でも、仕様策定者だけで全ては決めたくない
  • だから、ウェブ開発者にもフィードバックを求めてる
  • フィードバック側はその最新の情報に気づかないといけない
  • そうしないとフィードバックする機会を失う

^ 情報を知らないとフィードバック出来ないわけじゃない。 Specifictionはまさにそれを解決しようとしてる。 しかし、ある程度知ってないとフィードバックが心理的にしにくいという現状がある。

^ 今は過渡期だからという言葉片付けるのは簡単だけど、過渡期が終わったら理想が来るとは限らない


[fit] SNS


SNS

  • inline TwitterやGoogle+のようなSNS
  • フロー型のサービスは最新情報が流れやすい
    • 流れやすいけど、気づきにくい
  • 他のものと併用すればいい

^ 変化を感じるならSNSが一番お手軽。 ウェブの場合はオープンにやっていることが殆どなので、変化を作ってる人たちも多くはSNSにもいる。


その他

  • ブログ
  • メーリングリスト
  • メールマガジン^1
  • ポッドキャスト

^1: Meta Weekly

^ 情報源は色々あるはず、好きな形体とバランスを見極めよう。


大事なこと

  • 一番大事なのは追うことに無理をしないこと
  • 好きな方法で追うのが一番いい
    • 例) メールは嫌いなのでメーリングリストは見ない
  • 負荷がかかる方法は長続きしないから仕組みを変えるべき
  • 自分の好きな形に持ち込む事が大事

^ リリースを追うために自身が変化することは大切ではあるけど、無理はしてはいけない。 スクラップ、RSS、Notification、メールなど自分の好きな形に持ち込むことが大切。

^ 非連続性、非同期である事がストレスフリーである空間を作るのに役立ちそう。 ^ 取りこぼしが不安感があるなら取りこぼしを取る方法をいれ二回拾えばいい。


まとめ

  • 未来は突然やってこない
  • 最新の情報は変化の兆候捉えるための要素でしかない
  • 最新の情報を追う技術 = 変化兆候を捉える技術
  • 変化を作る人を見つけて見るのが一番
  • ものは使い分け、自分の好きな方法を使えばいい

[fit] おわり