これから先10年、フロントエンドに関する予言 - mizchi's blog
これは怪文書です ここから10年はWASMがDOMのGCインテグレーションを果たしてJSを置き換えるか、JSがWASMに追いつかれる前にまともな言語として進化しきれるかのチキンレースになる ES Modules のブラウザ実装が枯れた頃に先鋭化したフロントエンドツールセット群は一旦そこで破棄され、シンプル化への揺り戻しが起こる 仮想DOMはブラウザエンジンの何らかの処理で更新が隠蔽されるか専用のDOM更新APIができ、Reactのような実装の手を離れる WASMで git, vim, bashなどが porting されるにつれ、再びWebOSのようなものが試みられる TC39でJSの型アノテーションの構文だけだけ決めよう => V8 が型アノテーションを元にランタイムを最適化したぜ！ => 気づいたら標準化みたいな流れがある IE11のサポートは延長されず、MSがなんらかの強攻策に出る
ブログを書き続けること - mizchi's blog
昔から気をつけてることなのだけど、ある程度、ブログ、とくに技術テーマ以外の記事を書く頻度はコントロールしよう、と思っていた。具体的には、1ヶ月の間に2, 3回ホッテントリなどに入ることは問題ないが、2, 3ヶ月連続で耳目を引き続けるのは、避けた方がいいのではないか。とくに落ち着いて暮らしたいなら。 中長期的にあまりに注目を引き過ぎると、勝手に記事間の文脈を悪意を持って補完されたり、固定のウォッチ対象にされてしまったりすることがある。粘着なアンチは聞く耳を持たないので無視するに限るが、人間何に反感を持つかわからないもので、自分がコントロール出来ない要素をたくさん抱えると、書くことそのものが億劫になっていく。日常生活にも影響が出る。少なくとも僕は、自分が書いたものが自分のコントロール下から外れていないか、怖くなってエゴサーチばっかりしてしまう。 「悪意を持ったコメント」に対抗する方法は難しく、
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
「JavaScriptエンジニア養成読本」でCoffeeScriptについて書いた - mizchi's blog
kyo_agoさんに誘われて、CoffeeScriptについて1章書きました。 JavaScriptエンジニア養成読本［Webアプリ開発の定番構成Backbone.js＋CoffeeScript＋Gruntを1冊で習得！］：書籍案内｜技術評論社 他の章の紹介は他の著者さんに任せるとして、自分の書いた章について少し紹介。 JavaScriptエンジニア養成読本を書きました - watilde's blog 実践的CoffeeScript CoffeeScriptの言語仕様について、初心者でも誤解しないよう、言語マニアでも新しく学びがあるように書いたつもりです。 とくにオブジェクトや配列のパターンマッチ、CoffeeScript特有のオブジェクト指向のイディオム、大規模開発時のディレクトリ構成について実例を交えて書きました。 たとえばこんなコード module.exports = class
node.jsで Isomorphic フレームワーク作ってみようとしたら超辛かった - mizchi's blog
現状どんな実装があるかはここみてください Isomorphic JavaScript - The future of web app development 主張 Node.jsは現状フロントエンドユーティリティに最も適している Node.jsは一般にサーバーサイドでの運用は難しいし、自分もそう思う どうせやるなら、Node.jsにしかできないことをやるべきだ Node.jsのキラーアプリはRailsクローンではなく単体ソースからクライアント・サーバーのコードを同時に生成するIsomorphicフレームワークであるべきだ。 これだけは他のフレームワークには絶対に真似できないので、一応可能性は検証すべきだ 自分で実装することで、MeteorとかDerbyはなぜうまくいってないのかも考えたい というわけで Isomorphicなフレームワークを自分で作ってみたいと思っていた。 今ならせめてCo
Object.observeのGoogle Chromeでの先行実装とAngularについて - mizchi's blog
読みました。 Angularが好き - Can I do web? https://twitter.com/agektmr/status/519128909695045633 僕の中で、Object.observe なんてどうみてもangularのためじゃんって雰囲気が最初からあって、あまりにも当前だと思っていたので、さも事実のように書いてしまってました。 実際に検索してみたところ、その関係に実際に言及するような資料は発見できませんでした。この点は僕の想像でした。申し訳ありません。 ですが、検索すると僕以外にも多くの人がそう思っており、それなりに根拠もあります。なぜそう思っていたのか、その理由を提示します。 2012/06 Angularの公開リリース 2012/11 Object.observeの仕様の初出 http://wiki.ecmascript.org/doku.php?id=h
Angularが嫌い - mizchi's blog
僕は本当にAngularが嫌いで、もはや許せないレベルに達していて、今ではもう本当に使いたくない。 イカ理由。 APIがほんっっっっっとうに糞 趣味の問題といえばそうでもあるが僕は糞だと思う 実装が黒魔術 良識あるJSエンジニアなら Function.prototype.toString() しない 実際に一部のクロージャが破壊されてて挙動が直感に反する DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない Googleだから許される、みたいなコミュニティの驕りが本当に嫌 Angularの都合だけでChromeでObject.observeを前倒しするのやめろ Angularの内部モジュール同士が密結合 DI, module, factory, それぞれ大きなテーマなのに密結合 使いはじめるとAngularをやめることが困難 パフォーマン
ブログの書き方(我流) - mizchi's blog
主張したいフレーズを殴り書く 並べ替える 適切な接続詞で繋ぐ 通しで客観的に読んで、自分でツッコミ入れて足りないフレーズを補う 納得するまで4を繰り返す タイトルをつけて終了 主張が強い記事が多いのは書き方のせい。文体は直近で読んだ小説を真似して遊んでる。 参考
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
Vue.jsの次のバージョンはフルスクラッチで書き直される - mizchi's blog
一部でvue.jsのリポジトリに生えてた新しいブランチが話題になっていた。 Commits · yyx990803/vue というわけで作者にきいてみた @youyuxi Hey now are you doing new version prototype of vue.js? It will become breaking one?(of course I know it’s early stage yet)— 片手間以上 (@mizchi) 2014, 7月 10 @mizchi It will be breaking, but I'm trying to keep the API change to a minimum. It will fix a lot of edge cases in current version.— Evan You (@youyuxi) 2014, 7月
昔ながらの「片手間に書くJavaScript」の限界 - mizchi's blog
Javascriptを使うのをやめろ：Railsの時代遅れ云々についての結論 - Qiita この記事は、全体的に自分の業務以外の評価基準やトレンドを知らないんだなという感じで、わざわざ付き合うと精神的に消耗する感じがした。ただ、それが彼らの本職でない以上、自分もこの結論に至るのは仕方ないと感じている部分はある。 真の問題は、自分がレガシーなJavaScriptを書いているという自覚がない人間が、ここ数年の技術トレンドから乖離したコードを書き続けることで他のエンジニアやエコシステムそのものに悪影響を及ぼしているケースが散見されている。一行書く毎にグローバル汚染するスクリプトを見せられてもメンテ出来んと言われても、はいそうですねとしか言えないし、そういう人に最近のライブラリを触らせると遅くなるというのは、画面全体を一つのMustacheテンプレートにしてBackbone.Modelのパラメー
Swift ファーストインプレッション - mizchi's blog
とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV
論理的な設計と非論理的な人間 - mizchi's blog
TDD勢に叩かれそうな言葉で、「複雑すぎてテストできない」といいたくなるケースあるんだけど、「テストを想定してないので振る舞いが多用すぎて現実的にすべての振る舞いを確認できない」という、いわゆる設計が失敗してるコード、どう向き合ったらいいんでしょうか(都内・26歳・男性)— 俺は平気だよ (@mizchi) 2014, 5月 22 GUIアプリでテスト可能な設計するの、副作用が観測されないことが多いので、実質的に大量のバックドアを用意することになると思うんですよ。で、それってどうなのっていう。— 俺は平気だよ (@mizchi) 2014, 5月 22 MVVMがテストしやすいの、値に振る舞いが従属するので、値を確認すればいい、という建前があるからだけど、テストのためにMVVMを採用するのは本質的ではないと思うし、とはいえ何かしらの設計を講じないとMとVが密結合した構造を取るので、プログラ
最小最速で作るaltjs - mizchi's blog
最近、というか昨日からTypedCoffeeScriptの開発再開してAST 気分が盛り上がってるので、簡単なチュートリアルでも。 この記事でやること ASTの取得 ASTの生成 JavaScript の出力 やらないこと 構文解析 準備 適当にプロジェクト作ります。 $ mkdir tinyaltjs $ cd tinyaltjs $ npm init # 色々聞かれるけどEnter 連打で良い $ npm install escodegen esprima prettyjson --save esprima はJavaScript のコードをASTに変換。 escodegen は AST から JavaScript を生成。どっちもConstellationさん製 escodegenはConstellationさん製で、彼はesprimaにもコミットしてます。この界隈に来ると基本的に彼
ゴールデンウィークの成果報告 - mizchi's blog
誰とも会わなかった(完) 読んだ本 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (132件) を見る 5章まで読んだ。 ドメイン駆動、スキルツリーで言うと、オブジェクト指向Lv8ぐらいで解禁されるスキルのような印象を受けた。ストラテジーやMVCを理解してないと実装に至れない。ジャンルは違うけど、言語開発や、データベース設計、OS開発と同じように、一つのこじらせの極地にみえる(批判しているわけではない) 序盤は仕様理解(ドメイン理解)が大事でそれをチーム内で共通の言葉に落としてモデリングしましょうという話が続く。実際のドメイン駆動、値オ
Promise時代のJavaScriptの関数の処理/提供 - mizchi's blog
最近自分で非同期前提のプラグイン書くときはThenableな感じで書いてることが多い。 Thenableってのはどういうことかというと、typescirptのes6-promises では次のように定義してある。 interface Thenable<R> { then<U>(onFulfilled: (value: R) => Thenable<U>, onRejected: (error: any) => Thenable<U>): Thenable<U>; then<U>(onFulfilled: (value: R) => Thenable<U>, onRejected?: (error: any) => U): Thenable<U>; then<U>(onFulfilled: (value: R) => U, onRejected: (error: any) => Thenab
#ガチJS でJavaScriptとフロントエンドの未来について熱い話をした - mizchi's blog
(追記): このブログで一部のJSをgithubに置いてたら 「The website abuses rawgit.com」という警告が出てました。現在修正しました。ご迷惑おかけしました。 @kyo_agoさんの主催で、 @mizchi(シングルページ系フロントエンドJSer) と @damele0nさん(ゲーム系HTML5のJSer)でJavaScriptについて話をした。すごく有意義な話だったので、会話を思い出せる限り書いてみる。 このエントリを読む前にこの記事を読むと幸せになれる。 幸せになりたいソーシャルゲーム系Webフロントエンドエンジニアが本気で考える HTML GUI ツール第一回 - damelog このまとめは僕の主観であり、僕が理解できた部分と自分の発言を一番覚えてるのでどうしてもそれが多めになりますが、ご容赦ください。ついでに酒入ってる。 iOS SafariのIE化
JavaScriptの生きてるundefinedと死んでるundefined - mizchi's blog
JavaScriptの悪魔的な振る舞いの一つにundefinedがあると思う。 javascriptには存在するundefinedと存在しないundefinedがあるし、それはつまり [undefined].length => 1 だ— 俺は平気だよ (@mizchi) 2014, 4月 22 JavaScript、[undefined].length => 1 で arr = []; arr[0] = undefined; だけど、このとき前者のundefinedと後者のundefinedは性質的には別物ですよ— 俺は平気だよ (@mizchi) 2014, 4月 22 もう一つの例として、 obj = {}; のとき obj[‘a’] = undefined したとき、for i in obj するとイテレータが一回だけ回る。obj[‘a’] = undefined しても キーは消え
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog
Vue.jsは軽量なMVVMライブラリ。 vue.js http://vuejs.org/ 使ってみた感じ、かなり手触りがよいので、紹介する。 概要 handlebars風のテンプレートを書いて、DOMを展開する。普通のテンプレートエンジンと違い、$dataアクセッサを通じて値を書き換えることで、テンプレート展開後も値が同期する(!!!)。 一言で言うと軽量Angular。コード読んだ感じ、内部的にもAngularから大量にコードを持ってきた痕跡がある。$watchとdirective定義がキモなのは同じ。 とはいっても、軽量なのは使う側のAPI側だけで、内部実装はそれなりに重い。APIを軽量にすることで、Angularのデメリットである学習コスト部分を限りなく削ることを目標にしているんじゃないだろうか。 大雑把な使い方 テンプレートを書く。対応するデータ構造を書く。{foo: 'bar'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
