タグ

ブックマーク / mizchi.hatenablog.com (5)

  • なぜ僕は(2015年のフロントエンドで、makeではなく)gulpを選ぶのか - mizchi's blog

    http://d.hatena.ne.jp/m-hiyama/20150511/1431306678 の件 最初に 僕もgulpが今後生き残るかというと、かなり懐疑的です。開発パラダイムに合わせて変わっていくで、来年の段階で自分はgulp使えないなといっている可能性は十二分にあります。そのタイミングの一つはES6 import がHTTP2で並列ロードのオーバーヘッド無しで解決されるようになるタイミングでしょう。 根的な問題として、Web周りは標準化の関係で動きが遅いです。最新の仕様ではままならず、ブラウザ間の実装がまちまちで、また開発上の要求が多様なのでプリプロセッサで解決する文化が根付きました。プリプロセッサがいらなくなるぐらい個々の標準が洗練されればプリプロセッサも不要になりますが、そのような未来は、今の動きをみるに、あと15年は来ないように思えます。 とはいえ、ただひとつ言えるの

    なぜ僕は(2015年のフロントエンドで、makeではなく)gulpを選ぶのか - mizchi's blog
    naka-06_18
    naka-06_18 2015/05/11
    grunt は作者が 2年行方不明。gulp は差分を吐き出すのが得意、インクリメンタルビルドが出来、時間をかけずにすむ。 gulp と TypeScript は相性が悪い。gulp はプラグインをブラックリストする機構がある。
  • あなたがReactを使うべき理由 - mizchi's blog

    最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか? 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue

    あなたがReactを使うべき理由 - mizchi's blog
    naka-06_18
    naka-06_18 2014/09/03
    SVG で vDOM 使えると嬉しいかもなあ
  • #ガチ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化

    #ガチJS でJavaScriptとフロントエンドの未来について熱い話をした - mizchi's blog
    naka-06_18
    naka-06_18 2014/04/30
    熱い
  • 「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは? - mizchi's blog

    CoffeeScriptの関数は明示的にreturnするべき | CreativeStyle 当に遅いのか、それを確かめましょう。 適当にでっちあげたコードです f1 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j f2 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j return console.time "f1" for i in [1..100000] then f1() console.timeEnd "f1" console.time "f2" for i in [1..100000] then f2() console.timeEnd "f2" 実行してみます $ coffee hoge.coffee f1: 105ms f2: 4ms 約26倍違う、ということがわかります。

    「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは? - mizchi's blog
    naka-06_18
    naka-06_18 2013/12/16
    「「コードの速度が問題になるなら、その時はじめて最適化すべき」」
  • 力への意志 - mizchi's blog

    (この記事は闇 Advent Calendar 2013 - Adventar の8日目です。) コンプレックスの話をする。 僕がプログラミングを始めたのは、2008年の夏、大学1年の夏休みだった。大学のサークルの新歓を巡ったはいいが、どこもかしこも絶望的につまらなくて、当時エンジニアとネットウォッチャーしかいなかったTwitterをみていると、彼らがとても楽しそうに見えていた。 だから僕はTwitter漬けになって、一人でプログラミングの勉強をすることにした。大学では最低限の単位を確保しつつ、とりあえずなんでもいいからアプリを作るぞと、はてブで流れてきたホットそうな技術をひたすら手につけてみた。とにかく、新しそうなものをやるという戦略だった。 最初にやったことは、ゲーム用だったWindowsデスクトップマシンを潰して、ひたすらUbuntu8.04をインストールしては、Railsのサーバ

    力への意志 - mizchi's blog
    naka-06_18
    naka-06_18 2013/12/09
    元ネタ分からないけど、イイネ。
  • 1