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

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

on

  • 431 views

 

Statistics

Views

Total Views
431
Views on SlideShare
361
Embed Views
70

Actions

Likes
4
Downloads
0
Comments
0

2 Embeds 70

https://twitter.com 69
https://tweetdeck.twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 現在のWebフロントエンドの現状と愚痴と Mageについて by nobkz
  • はじめに
  • 自己紹介 • はなだ のぶかず • @nobkz • Technical Rockstars CTO • milkcocoaを作った人です • Kyushu.hx主催、Erlang読書会の人、Lisp福岡やりたいぽよ • スタートアップな人でつ。 • LispとHaxe/Haskell/OCaml • 言語設計やら、抽象化に興味がありまつ。 • Elmめっちょ気になる。
  • アジェンダ • フロントエンドの現状 • フロントエンド技術の問題点 • JSフロントエンドMV*フレームワークと, AltJS • Haxeの簡単な紹介と強力なマクロについて • Mageについて、設計、実装、 • 今後について
  • フロントエンドの現在の背景
  • “フロントエンドの現場は地獄です!” –とあるフロントエンドエンジニアより
  • フロントエンドエンジニアとは? • psdファイルとかから、HTMLやCSSをつくる • JSとかで、動的にアニメーションさせる。サイトに動きをつける • Flashでゲームつくる、最近はUnityになってる? • ブラウザだけじゃなくて、スマフォのネイティブもやる。 • サーバーは構築やら保守も時にする。 • JSでがんばってGUIする • 適切なIA/UI/UXデザイン • IE対応で死ぬ • 上記全部がフロントエンドの領域とか言われたりするので死ぬ。 • 今回は、HTML,CSS,JS + Haxe周りの話しでつ。
  • 最近のWebの認識 • フロントエンド、サーバーサイド、インフラ全方面で で技術的深化している • インフラは、仮想化、特に最近コンテナ仮想化が増え てきた。インフラのソフト化 • ログ解析、ビッグデータなどの扱い • フロントエンドのGUI,SPA化
  • フロントエンドの状況 • フロントエンドも適切なフレームワーク等、サーバー サイドエンジニアの片手間でできるようなものでは無 くなってきている • Webアプリはより、インタラクティブ文書では無くGUI 化の一途を遂げている • 「ちょっとJS書けば良い」時代は終わり、適切な設計 が必要になってきた。
  • フロントエンドの地獄化 • Webのフロントの肥大化(マークアップ,JS,CSS)の設計の必要性 • SPA化、GUI化 • 技術の更新の速さ、1年もしたら古い。 • いろいろ、フレームワークやらツールで新しいのがドンドン出てくる。 Grunt,Gulp,Brunch,Yeoman,Less,Sass,Compass,Anguler.js, • ブラウザの違い、OSの違い、端末の違い… • 画面サイズ • IE….IE….
  • 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=“comment"> div#header > h1.name <h2 class=“name first">nobkz</h2> </div> </header> header > div.comment > h2.name.first
  • すべてがグローバル <div id="header"> <div class=“warnning">注意!</div> </div> ! ..... ! <div id="contents"> <div class=“warnning">注意!</div> </div> .warnning {}
  • 抽象化機能、構造化機能が貧弱 • クラスで抽象化するしか無い。依存性が分かりづらい • コードの重複が多い • コードの意図が分かりづらい
  • 命名規則がやりずらい、面倒 • CSSはクラス命名規則で設計するしか無い • BEM? • クラス名が長くなりやすい。 .warninning-info 例 .block__element—warnning-info-normal
  • JSの問題点 • クラスが無くプロトタイプベースのオブジェクト指向 • thisのスコープ • 動的型付けである • コールバック地獄
  • クラスの機能 • JSにはクラスの機能が無い • なので、クラスと同等の機能を、プロトタイプ、また は、クロージャベースで作ることになる。 • 継承
  • 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); };
  • 動的型である • 論争になる。 • 型の網羅性がやっぱり欲しい時がある。
  • コールバック地獄 完全にネタ
  • AltJSとMV*フレームワーク
  • 設計とMVC • Webが肥大化しより、設計の必要性が出てきた • コードの量が多くなり、また、複数人開発のプロジェ クトも多くなる • 装飾的なコードと、ビジネスロジックの分離 • MV*フレームワークにより、生産性を上げ、より保守し やすくする。
  • MV*とは? • MVCと言えばいろいろなMVCがある。 • プラガブルMVC,MVP,MVVM,…… • また、MVC自体について明確なコンセンサスは存在し ない -> MVC自体の批判ができず、MVCの意味について 論争になりやすい • 今回は、その概念ひっくるめて、MV*とする。
  • MV* フレームワーク • JSでも設計が必要になってきた • jQueryとかで、設計を考え無いで、進めたりすると死ぬ • もちろん、JSのみでも、良い設計しさえすれば良いと は思っている(必ずしもフレームワークを使うべきでは 無い) • 設計に沿う選択ができれば生産性の向上、チームで設計 でコンセンサスがある程度取れたりする
  • AltJS • 良い設計をできるJSのエンジニアがあまりいない時 • JSに型やクラスが無いなどの、言語機能としての不足 • JSの構文に近いAltJS • 従来の言語をJSにコンパイルする
  • MV*フレームワーク + AltJSで選択が良いのか? • 最近、TypeScript + AltJSなどのMV*フレームワーク + AltJSの選択するプロジェクトが増えてきた。 • しかし、MV*フレームワークは、JSで書かれ、JSの抽象 に引っ張られやすい • そのため、JSのレイヤーを考えつつ、JSを書かないと いけない • AltJS言語独自で良い抽象化したライブラリが必要?
  • 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」という形にしたい。 • しかし、安易な抽象化はしない。低レベルが、書きやすく、理解 しやすいコードになるなら、無理に抽象化しない • コンポーネント指向であること。 • あえて、MV*的な具体的設計を考慮しない • UX的な手法を取り入れたい。
  • フロントエンド記述の横断的 • HTMLとCSSとJSの依存性の問題 • HTML + CSS + プログラムコードの横断的な、フレー ムワークを目指す • HTMLとCSSの同一のパッケージング • テンプレートとバインディング
  • 安易な抽象化をしない • できるだけ、レイヤーを薄くする • 学習コストを下げる • 機能、実装する必要性の基準を決める
  • 方針 • まずは、HTMLを、コンパイルして、そのHTMLを動的に構築するHaxeにoutputす る。 • CSSのプリプロセッサを構築し、CSSに機能をおぎなう。一応SASSなどの連携も 視野に入れている。 • CSSとHTMLの名前空間を共有する仕組みをつく • コンポーネント化し、構造的にUIを作れるようにする • データバインディング、FRP(勉強中)など? • Haxeのライブラリ化をすすめる。 • 直感的で扱いやすくするため、適切な抽象化設計をし、場合に寄っては再構築する
  • 現状の機能について • HTMLから、Haxeを出力する機能、 • HTML的な記述で、クラスをコンパイル時に生成 • CSSをプリプロセッサを作り、名前空間のためパッ ケージ機能を実装した • haxeでlib化しており、現在v0.2.0である。
  • 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="text" mage-var="input"> </div>' )) class SampleView{}
  • 自動生成された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(….){ } }
  • つかってみる。 • 簡単にデモしてみましょう var sampleView = new SampleView("first!"); base.component.appendChild(sampleView.nodes[0]); ! sampleView.input.addEventListener("change",function(e){ sampleView.message.nodeValue = sampleView.input.value; });
  • CSSライクな言語 • 名前空間を持つ package sample.view; ! p { color : red; } package sample.view; ! <div> <p>{{message}}</p> <input type="text" mage-var="input"> </div>
  • 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{}
  • 今後について、実装する機能
  • 今後実装する機能 • データバインド的な機能 • CSSバインド • アニメーション • UIコンポーネント機能
  • 今後について、その他 • 継続して開発していく。 • 現状の機能のみで、Webフロントエンドを置き変え、 問題点を洗い改善していく。 • Haxe -> JSのみならず、iphoneのObj-C、AndroidのJava のような言語にもコンパイルできるようにもなんとな くしたい(なんとなく)。
  • ありがとうございます