1. 現在のWebフロントエンドの現状と愚痴と
Mageについて
by nobkz

2. はじめに

3. 自己紹介
• はなだ のぶかず
• @nobkz
• Technical Rockstars CTO
• milkcocoaを作った人です
• Kyushu.hx主催、Erlang読書会の人、Lisp福岡やりたいぽよ
• スタートアップな人でつ。
• LispとHaxe/Haskell/OCaml
• 言語設計やら、抽象化に興味がありまつ。
• Elmめっちょ気になる。

4. アジェンダ
• フロントエンドの現状
• フロントエンド技術の問題点
• JSフロントエンドMV*フレームワークと, AltJS
• Haxeの簡単な紹介と強力なマクロについて
• Mageについて、設計、実装、
• 今後について

5. フロントエンドの現在の背景

6. “フロントエンドの現場は地獄です!”
–とあるフロントエンドエンジニアより

7. フロントエンドエンジニアとは?
• psdファイルとかから、HTMLやCSSをつくる
• JSとかで、動的にアニメーションさせる。サイトに動きをつける
• Flashでゲームつくる、最近はUnityになってる?
• ブラウザだけじゃなくて、スマフォのネイティブもやる。
• サーバーは構築やら保守も時にする。
• JSでがんばってGUIする
• 適切なIA/UI/UXデザイン
• IE対応で死ぬ
• 上記全部がフロントエンドの領域とか言われたりするので死ぬ。
• 今回は、HTML,CSS,JS + Haxe周りの話しでつ。

8. 最近のWebの認識
• フロントエンド、サーバーサイド、インフラ全方面で
で技術的深化している
• インフラは、仮想化、特に最近コンテナ仮想化が増え
てきた。インフラのソフト化
• ログ解析、ビッグデータなどの扱い
• フロントエンドのGUI,SPA化

9. フロントエンドの状況
• フロントエンドも適切なフレームワーク等、サーバー
サイドエンジニアの片手間でできるようなものでは無
くなってきている
• Webアプリはより、インタラクティブ文書では無くGUI
化の一途を遂げている
• 「ちょっとJS書けば良い」時代は終わり、適切な設計
が必要になってきた。

10. フロントエンドの地獄化
• Webのフロントの肥大化(マークアップ,JS,CSS)の設計の必要性
• SPA化、GUI化
• 技術の更新の速さ、1年もしたら古い。
• いろいろ、フレームワークやらツールで新しいのがドンドン出てくる。
Grunt,Gulp,Brunch,Yeoman,Less,Sass,Compass,Anguler.js,
• ブラウザの違い、OSの違い、端末の違い…
• 画面サイズ
• IE….IE….

11. Webフロント技術の問題点

12. Webフロント技術の問題点
• ここでは、フロント技術の問題点をざっくり整理する
• 「問題点」とは言ったけど、SPAを作る上での問題点
であり、単純な簡単なwebサイトだったら、そこまで
問題では無いかもしれない

13. HTMLについて
• ブラウザでGUIを作りたいのだ!
• GUI作るとき「文書構造」なんて考えますか?
• HTMLは「文書」の為の言語

14. CSSの問題点
• HTMLへの依存
• すべてがグローバル
• 抽象化機能と構造化機能が貧弱
• 命名規則、設計しづらさ

15. HTML構造の依存
<div id="header">
<h1 class="name">nobkz</h1>
<div class="comment">
</div>
</div>
<header>
<div class=“comment">
div#header > h1.name
<h2 class=“name first">nobkz</h2>
</div>
</header>
header > div.comment > h2.name.first

16. すべてがグローバル
<div id="header">
<div class=“warnning">注意!</div>
</div>
!
.....
!
<div id="contents">
<div class=“warnning">注意!</div>
</div>
.warnning {}

17. 抽象化機能、構造化機能が貧弱
• クラスで抽象化するしか無い。依存性が分かりづらい
• コードの重複が多い
• コードの意図が分かりづらい

18. 命名規則がやりずらい、面倒
• CSSはクラス命名規則で設計するしか無い
• BEM?
• クラス名が長くなりやすい。
.warninning-info
例
.block__element—warnning-info-normal

19. JSの問題点
• クラスが無くプロトタイプベースのオブジェクト指向
• thisのスコープ
• 動的型付けである
• コールバック地獄

20. クラスの機能
• JSにはクラスの機能が無い
• なので、クラスと同等の機能を、プロトタイプ、また
は、クロージャベースで作ることになる。
• 継承

21. thisスコープ
• 初心者が良くやる罠
function Person(_name){
this.name = _name;
};
!
Person.prototype.sayName = function(){
console.log("hi : " + this.name );
};
!
Person.prototype.wait2TimeAndSayName = function(){
console.log("Wait!! I forget my name!!!");
setTimeout(function(){
console.log("ok! I remember it : " + this.name ); // エラー
},2000);
};

22. 動的型である
• 論争になる。
• 型の網羅性がやっぱり欲しい時がある。

23. コールバック地獄
完全にネタ

24. AltJSとMV*フレームワーク

25. 設計とMVC
• Webが肥大化しより、設計の必要性が出てきた
• コードの量が多くなり、また、複数人開発のプロジェ
クトも多くなる
• 装飾的なコードと、ビジネスロジックの分離
• MV*フレームワークにより、生産性を上げ、より保守し
やすくする。

26. MV*とは?
• MVCと言えばいろいろなMVCがある。
• プラガブルMVC,MVP,MVVM,……
• また、MVC自体について明確なコンセンサスは存在し
ない -> MVC自体の批判ができず、MVCの意味について
論争になりやすい
• 今回は、その概念ひっくるめて、MV*とする。

27. MV* フレームワーク
• JSでも設計が必要になってきた
• jQueryとかで、設計を考え無いで、進めたりすると死ぬ
• もちろん、JSのみでも、良い設計しさえすれば良いと
は思っている(必ずしもフレームワークを使うべきでは
無い)
• 設計に沿う選択ができれば生産性の向上、チームで設計
でコンセンサスがある程度取れたりする

28. AltJS
• 良い設計をできるJSのエンジニアがあまりいない時
• JSに型やクラスが無いなどの、言語機能としての不足
• JSの構文に近いAltJS
• 従来の言語をJSにコンパイルする

29. MV*フレームワーク + AltJSで選択が良いのか?
• 最近、TypeScript + AltJSなどのMV*フレームワーク +
AltJSの選択するプロジェクトが増えてきた。
• しかし、MV*フレームワークは、JSで書かれ、JSの抽象
に引っ張られやすい
• そのため、JSのレイヤーを考えつつ、JSを書かないと
いけない
• AltJS言語独自で良い抽象化したライブラリが必要?

30. TypeScriptについて
• TypeScriptは選択としては、アリかもしれません。
• けど、個人的に微妙。
• JSが嫌で、TypeScriptを書いているのであれば、JSの互
換言語であるべきでは無い。その結果JSの欠点を引き
ずっている
• あとコンパイルが遅い。すぐに動かして、見た目を見
たいのに、直ぐに見られないのは、非常に嫌だ。

31. Vanillaな勧め
• jQueryよりもはるかに速く動作するフレームワークがあ
る ーーー Vanillaだ
• もしJSでキチンと設計する技術が無いのであれば一度
は学習としてやるべき。
• 「RailsでSQLが分からないエンジニア」
• あくまで、「設計」を理解して、フレームワークを利
用するべきです。

32. Haxeの簡単な紹介とマクロ機構

33. Haxeとは?
• ActionScriptライクな記法
• 静的型付け
• 型推論
• OCamlで書かれている
• DOMも型で扱える!!!
• あとは、他スライド参照

34. マクロ
• コンパイル時になんとかする機能
• 構文を読み変えする機能
• 個人的にはDSLをこれで良く作る
• 別途スライドを用意

35. やはりLispが最強だな!
• Lispはコードとデータの同図像性がある。
• なので、コードをデータとして、プログラミング上で
そのまま、コードデータの変容が可能である。
• また、受理可能な構文の幅が広く、Haxeでの受理可能
な構文上でのコードの意味の読み変えが必要ないこと

36. Mageについて

37. Haxeでフレームワーク
• 弊社はHaxeの会社
• フロントエンドファーストな思想
• 最近、BaaSをリリースした( Milkcocoa )
• サンプルアプリがたくさん必要になった。
• JSには慣れてるけど、やっぱりHaxeで書きたい
• マクロ良いよ! マクロ!

38. 設計思想的なやつとか、方針やら
• 最終的には、HTML,CSS,JSをうまく隠蔽した、レイアウト可能な
「ライブラリ」or 「フレームワーク」の形をつくり、最終的には
「DSL」という形にしたい。
• しかし、安易な抽象化はしない。低レベルが、書きやすく、理解
しやすいコードになるなら、無理に抽象化しない
• コンポーネント指向であること。
• あえて、MV*的な具体的設計を考慮しない
• UX的な手法を取り入れたい。

39. フロントエンド記述の横断的
• HTMLとCSSとJSの依存性の問題
• HTML + CSS + プログラムコードの横断的な、フレー
ムワークを目指す
• HTMLとCSSの同一のパッケージング
• テンプレートとバインディング

40. 安易な抽象化をしない
• できるだけ、レイヤーを薄くする
• 学習コストを下げる
• 機能、実装する必要性の基準を決める

41. 方針
• まずは、HTMLを、コンパイルして、そのHTMLを動的に構築するHaxeにoutputす
る。
• CSSのプリプロセッサを構築し、CSSに機能をおぎなう。一応SASSなどの連携も
視野に入れている。
• CSSとHTMLの名前空間を共有する仕組みをつく
• コンポーネント化し、構造的にUIを作れるようにする
• データバインディング、FRP(勉強中)など?
• Haxeのライブラリ化をすすめる。
• 直感的で扱いやすくするため、適切な抽象化設計をし、場合に寄っては再構築する

42. 現状の機能について
• HTMLから、Haxeを出力する機能、
• HTML的な記述で、クラスをコンパイル時に生成
• CSSをプリプロセッサを作り、名前空間のためパッ
ケージ機能を実装した
• haxeでlib化しており、現在v0.2.0である。

43. HTMLライクな言語
package sample.view;
!
<div>
<p>{{message}}</p>
<input type="text" mage-var="input">
</div>

44. CompileHTML.generate
@:build(mage.CompileHTML.generate(
'package sample.view;
!
<div>
<p>{{message}}</p>
<input type="text" mage-var="input">
</div>'
))
class SampleView{}

45. 自動生成されたViewクラス
class SampleView{
public var nodes(default, null) : js.html.Node;
!
public var message : js.html.TextNode;
!
public var input : js.html.InputElement;
!
!
public var new(….){
}
}

46. つかってみる。
• 簡単にデモしてみましょう
var sampleView = new SampleView("first!");
base.component.appendChild(sampleView.nodes[0]);
!
sampleView.input.addEventListener("change",function(e){
sampleView.message.nodeValue = sampleView.input.value;
});

47. CSSライクな言語
• 名前空間を持つ
package sample.view;
!
p { color : red; }
package sample.view;
!
<div>
<p>{{message}}</p>
<input type="text" mage-var="input">
</div>

48. CompileCSS.generate
@:build(mage.CompileCSS.generate(
'package sample.view;
!
p { color : red; }'
))
@:build(mage.CompileHTML.generate(
'package sample.view;
!
<div>
<p>{{message}}</p>
<input type="text" mage-var="input">
</div>'
))
class SampleView{}

49. 今後について、実装する機能

50. 今後実装する機能
• データバインド的な機能
• CSSバインド
• アニメーション
• UIコンポーネント機能

51. 今後について、その他
• 継続して開発していく。
• 現状の機能のみで、Webフロントエンドを置き変え、
問題点を洗い改善していく。
• Haxe -> JSのみならず、iphoneのObj-C、AndroidのJava
のような言語にもコンパイルできるようにもなんとな
くしたい(なんとなく)。

52. ありがとうございます