Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
現在のWebフロントエンドの現状と愚痴と 
Mageについて 
by nobkz
はじめに
自己紹介 
• はなだ のぶかず 
• @nobkz 
• Technical Rockstars CTO 
• milkcocoaを作った人です 
• Kyushu.hx主催、Erlang読書会の人、Lisp福岡やりたいぽよ 
• スタートア...
アジェンダ 
• フロントエンドの現状 
• フロントエンド技術の問題点 
• JSフロントエンドMV*フレームワークと, AltJS 
• Haxeの簡単な紹介と強力なマクロについて 
• Mageについて、設計、実装、 
• 今後について
フロントエンドの現在の背景
“フロントエンドの現場は地獄です!” 
–とあるフロントエンドエンジニアより
フロントエンドエンジニアとは? 
• psdファイルとかから、HTMLやCSSをつくる 
• JSとかで、動的にアニメーションさせる。サイトに動きをつける 
• Flashでゲームつくる、最近はUnityになってる? 
• ブラウザだけじゃなく...
最近のWebの認識 
• フロントエンド、サーバーサイド、インフラ全方面で 
で技術的深化している 
• インフラは、仮想化、特に最近コンテナ仮想化が増え 
てきた。インフラのソフト化 
• ログ解析、ビッグデータなどの扱い 
• フロントエン...
フロントエンドの状況 
• フロントエンドも適切なフレームワーク等、サーバー 
サイドエンジニアの片手間でできるようなものでは無 
くなってきている 
• Webアプリはより、インタラクティブ文書では無くGUI 
化の一途を遂げている 
• 「...
フロントエンドの地獄化 
• Webのフロントの肥大化(マークアップ,JS,CSS)の設計の必要性 
• SPA化、GUI化 
• 技術の更新の速さ、1年もしたら古い。 
• いろいろ、フレームワークやらツールで新しいのがドンドン出てくる。 
...
Webフロント技術の問題点
Webフロント技術の問題点 
• ここでは、フロント技術の問題点をざっくり整理する 
• 「問題点」とは言ったけど、SPAを作る上での問題点 
であり、単純な簡単なwebサイトだったら、そこまで 
問題では無いかもしれない
HTMLについて 
• ブラウザでGUIを作りたいのだ! 
• GUI作るとき「文書構造」なんて考えますか? 
• HTMLは「文書」の為の言語
CSSの問題点 
• HTMLへの依存 
• すべてがグローバル 
• 抽象化機能と構造化機能が貧弱 
• 命名規則、設計しづらさ
HTML構造の依存 
<div id="header"> 
<h1 class="name">nobkz</h1> 
<div class="comment"> 
</div> 
</div> 
<header> 
<div class=“co...
すべてがグローバル 
<div id="header"> 
<div class=“warnning">注意!</div> 
</div> 
! 
..... 
! 
<div id="contents"> 
<div class=“warnn...
抽象化機能、構造化機能が貧弱 
• クラスで抽象化するしか無い。依存性が分かりづらい 
• コードの重複が多い 
• コードの意図が分かりづらい
命名規則がやりずらい、面倒 
• CSSはクラス命名規則で設計するしか無い 
• BEM? 
• クラス名が長くなりやすい。 
.warninning-info 
例 
.block__element—warnning-info-normal
JSの問題点 
• クラスが無くプロトタイプベースのオブジェクト指向 
• thisのスコープ 
• 動的型付けである 
• コールバック地獄
クラスの機能 
• JSにはクラスの機能が無い 
• なので、クラスと同等の機能を、プロトタイプ、また 
は、クロージャベースで作ることになる。 
• 継承
thisスコープ 
• 初心者が良くやる罠 
function Person(_name){ 
this.name = _name; 
}; 
! 
Person.prototype.sayName = function(){ 
console...
動的型である 
• 論争になる。 
• 型の網羅性がやっぱり欲しい時がある。
コールバック地獄 
完全にネタ
AltJSとMV*フレームワーク
設計とMVC 
• Webが肥大化しより、設計の必要性が出てきた 
• コードの量が多くなり、また、複数人開発のプロジェ 
クトも多くなる 
• 装飾的なコードと、ビジネスロジックの分離 
• MV*フレームワークにより、生産性を上げ、より保守...
MV*とは? 
• MVCと言えばいろいろなMVCがある。 
• プラガブルMVC,MVP,MVVM,…… 
• また、MVC自体について明確なコンセンサスは存在し 
ない -> MVC自体の批判ができず、MVCの意味について 
論争になりやす...
MV* フレームワーク 
• JSでも設計が必要になってきた 
• jQueryとかで、設計を考え無いで、進めたりすると死ぬ 
• もちろん、JSのみでも、良い設計しさえすれば良いと 
は思っている(必ずしもフレームワークを使うべきでは 
無い...
AltJS 
• 良い設計をできるJSのエンジニアがあまりいない時 
• JSに型やクラスが無いなどの、言語機能としての不足 
• JSの構文に近いAltJS 
• 従来の言語をJSにコンパイルする
MV*フレームワーク + AltJSで選択が良いのか? 
• 最近、TypeScript + AltJSなどのMV*フレームワーク + 
AltJSの選択するプロジェクトが増えてきた。 
• しかし、MV*フレームワークは、JSで書かれ、JSの...
TypeScriptについて 
• TypeScriptは選択としては、アリかもしれません。 
• けど、個人的に微妙。 
• JSが嫌で、TypeScriptを書いているのであれば、JSの互 
換言語であるべきでは無い。その結果JSの欠点を引...
Vanillaな勧め 
• jQueryよりもはるかに速く動作するフレームワークがあ 
る ーーー Vanillaだ 
• もしJSでキチンと設計する技術が無いのであれば一度 
は学習としてやるべき。 
• 「RailsでSQLが分からないエン...
Haxeの簡単な紹介とマクロ機構
Haxeとは? 
• ActionScriptライクな記法 
• 静的型付け 
• 型推論 
• OCamlで書かれている 
• DOMも型で扱える!!! 
• あとは、他スライド参照
マクロ 
• コンパイル時になんとかする機能 
• 構文を読み変えする機能 
• 個人的にはDSLをこれで良く作る 
• 別途スライドを用意
やはりLispが最強だな! 
• Lispはコードとデータの同図像性がある。 
• なので、コードをデータとして、プログラミング上で 
そのまま、コードデータの変容が可能である。 
• また、受理可能な構文の幅が広く、Haxeでの受理可能 
な...
Mageについて
Haxeでフレームワーク 
• 弊社はHaxeの会社 
• フロントエンドファーストな思想 
• 最近、BaaSをリリースした( Milkcocoa ) 
• サンプルアプリがたくさん必要になった。 
• JSには慣れてるけど、やっぱりHaxe...
設計思想的なやつとか、方針やら 
• 最終的には、HTML,CSS,JSをうまく隠蔽した、レイアウト可能な 
「ライブラリ」or 「フレームワーク」の形をつくり、最終的には 
「DSL」という形にしたい。 
• しかし、安易な抽象化はしない。低...
フロントエンド記述の横断的 
• HTMLとCSSとJSの依存性の問題 
• HTML + CSS + プログラムコードの横断的な、フレー 
ムワークを目指す 
• HTMLとCSSの同一のパッケージング 
• テンプレートとバインディング
安易な抽象化をしない 
• できるだけ、レイヤーを薄くする 
• 学習コストを下げる 
• 機能、実装する必要性の基準を決める
方針 
• まずは、HTMLを、コンパイルして、そのHTMLを動的に構築するHaxeにoutputす 
る。 
• CSSのプリプロセッサを構築し、CSSに機能をおぎなう。一応SASSなどの連携も 
視野に入れている。 
• CSSとHTMLの...
現状の機能について 
• HTMLから、Haxeを出力する機能、 
• HTML的な記述で、クラスをコンパイル時に生成 
• CSSをプリプロセッサを作り、名前空間のためパッ 
ケージ機能を実装した 
• haxeでlib化しており、現在v0....
HTMLライクな言語 
package sample.view; 
! 
<div> 
<p>{{message}}</p> 
<input type="text" mage-var="input"> 
</div>
CompileHTML.generate 
@:build(mage.CompileHTML.generate( 
'package sample.view; 
! 
<div> 
<p>{{message}}</p> 
<input type...
自動生成されたViewクラス 
class SampleView{ 
public var nodes(default, null) : js.html.Node; 
! 
public var message : js.html.TextNo...
つかってみる。 
• 簡単にデモしてみましょう 
var sampleView = new SampleView("first!"); 
base.component.appendChild(sampleView.nodes[0]); 
! 
...
CSSライクな言語 
• 名前空間を持つ 
package sample.view; 
! 
p { color : red; } 
package sample.view; 
! 
<div> 
<p>{{message}}</p> 
<in...
CompileCSS.generate 
@:build(mage.CompileCSS.generate( 
'package sample.view; 
! 
p { color : red; }' 
)) 
@:build(mage.Co...
今後について、実装する機能
今後実装する機能 
• データバインド的な機能 
• CSSバインド 
• アニメーション 
• UIコンポーネント機能
今後について、その他 
• 継続して開発していく。 
• 現状の機能のみで、Webフロントエンドを置き変え、 
問題点を洗い改善していく。 
• Haxe -> JSのみならず、iphoneのObj-C、AndroidのJava 
のような言語...
ありがとうございます
Próxima SlideShare
Cargando en…5
×

現在のWebフロントエンドの現状と愚痴と、それに対するHaxeフロントエンドライブラリMageについて

10.185 visualizaciones

Publicado el

Publicado en: Software
  • Sé el primero en comentar

現在のWebフロントエンドの現状と愚痴と、それに対するHaxeフロントエンドライブラリMageについて

  1. 1. 現在のWebフロントエンドの現状と愚痴と Mageについて by nobkz
  2. 2. はじめに
  3. 3. 自己紹介 • はなだ のぶかず • @nobkz • Technical Rockstars CTO • milkcocoaを作った人です • Kyushu.hx主催、Erlang読書会の人、Lisp福岡やりたいぽよ • スタートアップな人でつ。 • LispとHaxe/Haskell/OCaml • 言語設計やら、抽象化に興味がありまつ。 • Elmめっちょ気になる。
  4. 4. アジェンダ • フロントエンドの現状 • フロントエンド技術の問題点 • JSフロントエンドMV*フレームワークと, AltJS • Haxeの簡単な紹介と強力なマクロについて • Mageについて、設計、実装、 • 今後について
  5. 5. フロントエンドの現在の背景
  6. 6. “フロントエンドの現場は地獄です!” –とあるフロントエンドエンジニアより
  7. 7. フロントエンドエンジニアとは? • psdファイルとかから、HTMLやCSSをつくる • JSとかで、動的にアニメーションさせる。サイトに動きをつける • Flashでゲームつくる、最近はUnityになってる? • ブラウザだけじゃなくて、スマフォのネイティブもやる。 • サーバーは構築やら保守も時にする。 • JSでがんばってGUIする • 適切なIA/UI/UXデザイン • IE対応で死ぬ • 上記全部がフロントエンドの領域とか言われたりするので死ぬ。 • 今回は、HTML,CSS,JS + Haxe周りの話しでつ。
  8. 8. 最近のWebの認識 • フロントエンド、サーバーサイド、インフラ全方面で で技術的深化している • インフラは、仮想化、特に最近コンテナ仮想化が増え てきた。インフラのソフト化 • ログ解析、ビッグデータなどの扱い • フロントエンドのGUI,SPA化
  9. 9. フロントエンドの状況 • フロントエンドも適切なフレームワーク等、サーバー サイドエンジニアの片手間でできるようなものでは無 くなってきている • Webアプリはより、インタラクティブ文書では無くGUI 化の一途を遂げている • 「ちょっとJS書けば良い」時代は終わり、適切な設計 が必要になってきた。
  10. 10. フロントエンドの地獄化 • Webのフロントの肥大化(マークアップ,JS,CSS)の設計の必要性 • SPA化、GUI化 • 技術の更新の速さ、1年もしたら古い。 • いろいろ、フレームワークやらツールで新しいのがドンドン出てくる。 Grunt,Gulp,Brunch,Yeoman,Less,Sass,Compass,Anguler.js, • ブラウザの違い、OSの違い、端末の違い… • 画面サイズ • IE….IE….
  11. 11. Webフロント技術の問題点
  12. 12. Webフロント技術の問題点 • ここでは、フロント技術の問題点をざっくり整理する • 「問題点」とは言ったけど、SPAを作る上での問題点 であり、単純な簡単なwebサイトだったら、そこまで 問題では無いかもしれない
  13. 13. HTMLについて • ブラウザでGUIを作りたいのだ! • GUI作るとき「文書構造」なんて考えますか? • HTMLは「文書」の為の言語
  14. 14. CSSの問題点 • HTMLへの依存 • すべてがグローバル • 抽象化機能と構造化機能が貧弱 • 命名規則、設計しづらさ
  15. 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. 16. すべてがグローバル <div id="header"> <div class=“warnning">注意!</div> </div> ! ..... ! <div id="contents"> <div class=“warnning">注意!</div> </div> .warnning {}
  17. 17. 抽象化機能、構造化機能が貧弱 • クラスで抽象化するしか無い。依存性が分かりづらい • コードの重複が多い • コードの意図が分かりづらい
  18. 18. 命名規則がやりずらい、面倒 • CSSはクラス命名規則で設計するしか無い • BEM? • クラス名が長くなりやすい。 .warninning-info 例 .block__element—warnning-info-normal
  19. 19. JSの問題点 • クラスが無くプロトタイプベースのオブジェクト指向 • thisのスコープ • 動的型付けである • コールバック地獄
  20. 20. クラスの機能 • JSにはクラスの機能が無い • なので、クラスと同等の機能を、プロトタイプ、また は、クロージャベースで作ることになる。 • 継承
  21. 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. 22. 動的型である • 論争になる。 • 型の網羅性がやっぱり欲しい時がある。
  23. 23. コールバック地獄 完全にネタ
  24. 24. AltJSとMV*フレームワーク
  25. 25. 設計とMVC • Webが肥大化しより、設計の必要性が出てきた • コードの量が多くなり、また、複数人開発のプロジェ クトも多くなる • 装飾的なコードと、ビジネスロジックの分離 • MV*フレームワークにより、生産性を上げ、より保守し やすくする。
  26. 26. MV*とは? • MVCと言えばいろいろなMVCがある。 • プラガブルMVC,MVP,MVVM,…… • また、MVC自体について明確なコンセンサスは存在し ない -> MVC自体の批判ができず、MVCの意味について 論争になりやすい • 今回は、その概念ひっくるめて、MV*とする。
  27. 27. MV* フレームワーク • JSでも設計が必要になってきた • jQueryとかで、設計を考え無いで、進めたりすると死ぬ • もちろん、JSのみでも、良い設計しさえすれば良いと は思っている(必ずしもフレームワークを使うべきでは 無い) • 設計に沿う選択ができれば生産性の向上、チームで設計 でコンセンサスがある程度取れたりする
  28. 28. AltJS • 良い設計をできるJSのエンジニアがあまりいない時 • JSに型やクラスが無いなどの、言語機能としての不足 • JSの構文に近いAltJS • 従来の言語をJSにコンパイルする
  29. 29. MV*フレームワーク + AltJSで選択が良いのか? • 最近、TypeScript + AltJSなどのMV*フレームワーク + AltJSの選択するプロジェクトが増えてきた。 • しかし、MV*フレームワークは、JSで書かれ、JSの抽象 に引っ張られやすい • そのため、JSのレイヤーを考えつつ、JSを書かないと いけない • AltJS言語独自で良い抽象化したライブラリが必要?
  30. 30. TypeScriptについて • TypeScriptは選択としては、アリかもしれません。 • けど、個人的に微妙。 • JSが嫌で、TypeScriptを書いているのであれば、JSの互 換言語であるべきでは無い。その結果JSの欠点を引き ずっている • あとコンパイルが遅い。すぐに動かして、見た目を見 たいのに、直ぐに見られないのは、非常に嫌だ。
  31. 31. Vanillaな勧め • jQueryよりもはるかに速く動作するフレームワークがあ る ーーー Vanillaだ • もしJSでキチンと設計する技術が無いのであれば一度 は学習としてやるべき。 • 「RailsでSQLが分からないエンジニア」 • あくまで、「設計」を理解して、フレームワークを利 用するべきです。
  32. 32. Haxeの簡単な紹介とマクロ機構
  33. 33. Haxeとは? • ActionScriptライクな記法 • 静的型付け • 型推論 • OCamlで書かれている • DOMも型で扱える!!! • あとは、他スライド参照
  34. 34. マクロ • コンパイル時になんとかする機能 • 構文を読み変えする機能 • 個人的にはDSLをこれで良く作る • 別途スライドを用意
  35. 35. やはりLispが最強だな! • Lispはコードとデータの同図像性がある。 • なので、コードをデータとして、プログラミング上で そのまま、コードデータの変容が可能である。 • また、受理可能な構文の幅が広く、Haxeでの受理可能 な構文上でのコードの意味の読み変えが必要ないこと
  36. 36. Mageについて
  37. 37. Haxeでフレームワーク • 弊社はHaxeの会社 • フロントエンドファーストな思想 • 最近、BaaSをリリースした( Milkcocoa ) • サンプルアプリがたくさん必要になった。 • JSには慣れてるけど、やっぱりHaxeで書きたい • マクロ良いよ! マクロ!
  38. 38. 設計思想的なやつとか、方針やら • 最終的には、HTML,CSS,JSをうまく隠蔽した、レイアウト可能な 「ライブラリ」or 「フレームワーク」の形をつくり、最終的には 「DSL」という形にしたい。 • しかし、安易な抽象化はしない。低レベルが、書きやすく、理解 しやすいコードになるなら、無理に抽象化しない • コンポーネント指向であること。 • あえて、MV*的な具体的設計を考慮しない • UX的な手法を取り入れたい。
  39. 39. フロントエンド記述の横断的 • HTMLとCSSとJSの依存性の問題 • HTML + CSS + プログラムコードの横断的な、フレー ムワークを目指す • HTMLとCSSの同一のパッケージング • テンプレートとバインディング
  40. 40. 安易な抽象化をしない • できるだけ、レイヤーを薄くする • 学習コストを下げる • 機能、実装する必要性の基準を決める
  41. 41. 方針 • まずは、HTMLを、コンパイルして、そのHTMLを動的に構築するHaxeにoutputす る。 • CSSのプリプロセッサを構築し、CSSに機能をおぎなう。一応SASSなどの連携も 視野に入れている。 • CSSとHTMLの名前空間を共有する仕組みをつく • コンポーネント化し、構造的にUIを作れるようにする • データバインディング、FRP(勉強中)など? • Haxeのライブラリ化をすすめる。 • 直感的で扱いやすくするため、適切な抽象化設計をし、場合に寄っては再構築する
  42. 42. 現状の機能について • HTMLから、Haxeを出力する機能、 • HTML的な記述で、クラスをコンパイル時に生成 • CSSをプリプロセッサを作り、名前空間のためパッ ケージ機能を実装した • haxeでlib化しており、現在v0.2.0である。
  43. 43. HTMLライクな言語 package sample.view; ! <div> <p>{{message}}</p> <input type="text" mage-var="input"> </div>
  44. 44. CompileHTML.generate @:build(mage.CompileHTML.generate( 'package sample.view; ! <div> <p>{{message}}</p> <input type="text" mage-var="input"> </div>' )) class SampleView{}
  45. 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. 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. 47. CSSライクな言語 • 名前空間を持つ package sample.view; ! p { color : red; } package sample.view; ! <div> <p>{{message}}</p> <input type="text" mage-var="input"> </div>
  48. 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. 49. 今後について、実装する機能
  50. 50. 今後実装する機能 • データバインド的な機能 • CSSバインド • アニメーション • UIコンポーネント機能
  51. 51. 今後について、その他 • 継続して開発していく。 • 現状の機能のみで、Webフロントエンドを置き変え、 問題点を洗い改善していく。 • Haxe -> JSのみならず、iphoneのObj-C、AndroidのJava のような言語にもコンパイルできるようにもなんとな くしたい(なんとなく)。
  52. 52. ありがとうございます

×