タグ

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

  • やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog

    と思う次第である。以下理由。 JavaScript, GUI設計の今 JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。近年は npm というプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。 React/ReduxAngular によって、Flux/MVVMという抽象パターンが枯れてきたように思う。(この際、現場はまだ jQuery だぞ、みたいな話は無視する)。要は View は State の写像である、ということに尽きる。State はシリアライズ可能(JSON)で、Flux Action/Rx.Observable の Event Stream を入力とし、それ

    やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog
  • フロントエンドへの複雑化について、一つの視点 - mizchi's blog

    これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日に複雑化するフロントエンド技術海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記

    フロントエンドへの複雑化について、一つの視点 - mizchi's blog
  • スターエンジニアはキラーアプリを生み出すのか? - mizchi's blog

    Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌 は内容自体はどうしようもないのだけど、テーマ自体は自分も日頃悩んでいたものなので書き出してみる。あ、そういえば行方不明のmalaさんは一昨日のハッカソンで振り向いたらいたんで大丈夫です。 キラーアプリの出現と技術的イノベーションに相関あるかと言われたらあるとは思うけど枯れた技術の水平思考的な余地も十分あるんでキラーアプリが必ずしも技術的なイノベーションを果たしている必要はない。ただし技術優位がない場合は企画レベルで制限かかるので、それを許容するかどうかという話— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 技術的イノベーションによって可能になったサービスはたくさんあって、たとえばデータベースを使った動的なウェブサービス、2000年前ごろにPerl CGIが現実的な速度で動くようになってから増えた

    スターエンジニアはキラーアプリを生み出すのか? - mizchi's blog
  • あなたが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
  • CSS勉強するだるさ - mizchi's blog

    そろそろ勉強しないトナーと思いつつもだるくなる原因列挙する 前提 お前はJS書いてればいいよと甘やかされてきたので仕事で書いた量は少ない リフロー、ペイント等の表示制御系とパフォーマンス周りだけはそれなりに知ってる position: absolute や visibility: hidden とか 簡単な装飾はできる 段組とかの知識があんまりない わからないこと 解法が一つではなく、最適解がわからない 数こなせばわかる気がするが時間かかってだるい すでにあるサイトを参考にするもそれが正しいのかよくわからない 正解が(プログラマ的感覚だと)醜くみえる たとえば中央寄せ たとえば段組 このrelative指定は当に必要なのか…みたいな ググって引っかかる資料のレベルが低い 古のspacer.gifとか未だに引っ掛かる これはJSと同じ問題なので2010~の資料しかみないようにする 楽できそ

    CSS勉強するだるさ - mizchi's blog
    animist
    animist 2015/01/08
    CSS 確かにメッチャむずい
  • Angularが嫌い - mizchi's blog

    僕は当にAngularが嫌いで、もはや許せないレベルに達していて、今ではもう当に使いたくない。 イカ理由。 APIがほんっっっっっとうに糞 趣味の問題といえばそうでもあるが僕は糞だと思う 実装が黒魔術 良識あるJSエンジニアなら Function.prototype.toString() しない 実際に一部のクロージャが破壊されてて挙動が直感に反する DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない Googleだから許される、みたいなコミュニティの驕りが当に嫌 Angularの都合だけでChromeでObject.observeを前倒しするのやめろ Angularの内部モジュール同士が密結合 DI, module, factory, それぞれ大きなテーマなのに密結合 使いはじめるとAngularをやめることが困難 パフォーマン

    Angularが嫌い - mizchi's blog
  • #ガチ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
  • グランブルーファンタジーのコードをちょっと読んでみた - mizchi's blog

    なんかすごい無茶してますね。 HTML5で普通に読めるので、適当に読んでみた。都合が悪ければ言ってください > Cygamesさん 大雑把にコールしてるライブラリは "jquery","underscore","backbone","easeljs","tweenjs","soundjs","movieclip","preloadjs","loadmanager","pex","typist", "flexslider","finger","socketio","subroute","uaparser" require.js 全体的にrequire.jsに強く依存している。require.jsは r.js使ってまとめてminifyできるんだけど、今回はそれをしていなくて、uglifyか何かで難読化されているだけ。なんだけど、圧縮できない文字列ベースで依存関係を表現しているため、外部から非常

    グランブルーファンタジーのコードをちょっと読んでみた - mizchi's blog
  • 「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
    animist
    animist 2013/12/16
    元エントリは「自動生成されたコードが読みづらくなってデバッグを阻害するから」と言う理由の方が個人的には納得できた。もちろんそれも、そんならハナからJS直書けよ、という話ではありうる。
  • 1