![つかってみる。
• 簡単にデモしてみましょう
var sampleView = new SampleView("first!");
base.component.appendChild(sampleView.nodes[0]);
!
sampleView.input.addEventListener("change",function(e){
sampleView.message.nodeValue = sampleView.input.value;
});](https://image.slidesharecdn.com/mage-140928231615-phpapp01/85/Web-Haxe-Mage-46-320.jpg)
現在のWebフロントエンドの現状と愚痴と、それに対するHaxeフロントエンドライブラリMageについて
- 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について、設計、実装、 • 今後について
- 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. ありがとうございます