フロントエンドにおいてModel-View-Controllerは死んだのか？ | POSTD
多くのフロントエンド開発者が 一方向のアーキテクチャ を採用し始めている中で、Model-View-Controller（MVC）に未来はあるのでしょうか。 状況を把握するために、まずはフロントエンドのアーキテクチャの進化を振り返ってみたいと思います。 過去4年にわたり、私は多数のWebプロジェクトに取り組み、フロントエンドの構築、そしてフロントエンドとフレームワークの統合に多くの時間を費やしてきました。 2010年以前は、従来のウェブサイトにDOM操作を追加する場合は大抵JavaScript（ jQuery が書かれたプログラミング言語）が使用されていました。当時の開発者はアーキテクチャ自体についてはそれほど気に掛けていなかったと思います。コードベースを構造化する場合、 Revealing module pattern のようなものがあれば十分でした。 現在、多くの議論が交わされているフ
複雑なJavaScriptアプリケーションを考えながら作る話
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
「片手間JavaScripter」にも知ってほしい、Vue.jsで実現するMVVMパターン、Fluxアーキテクチャとの距離 - builderscon tokyo 2016
「片手間JavaScripter」にも知ってほしい、Vue.jsで実現するMVVMパターン、Fluxアーキテクチャとの距離 accepted Abstract Vue.jsは、JavaScriptでMVVMパターンを実現するライブラリです。 このセッションでは、まず jQuery から始め、Vue.js による MVVM による PDS の導入、単方向データフローの導入による Flux アーキテクチャへの接近までをコード例を交えて見ていきます。 Vue.jsを題材にしますが、「Vue.jsの使い方チュートリアル」のようなものではなく、アーキテクチャ寄りの話題になります。「片手間 JavaScripter」だったわたしが、実践的な SPA を開発する中で得た知見を大放出します。
Flux と Component 〜 Vue.jsとVuexとVuex-connect - Qiita
グローバルステート及びそれに伴う周辺アクセサなどなど 開けた局所的な操作 所詮はグローバル 開けている必要のある局所的な操作と、開けている必要のない局所的な操作、圧倒的に後者のほうが多数だよね問題がある。死ぬ。 強いscope、明確なIN OUT(のはず) 閉じたモノリシックな操作 所詮はバケツリレー 大体の場合、親のコンポーネントはバケツで死ぬ。 ストレス度合い グローバルな問題は、臭いレベルの苦痛にとどまるが、破綻時の影響が計り知れない。 短期的な観測ではバケツリレーの方がストレス値は高い。 なのでまぁfluxに逃したくなる気持もわかるが、全部が全部flluxに流すだけなら「綺麗なjQuery」書いてる方がましになる。 閉じた部分、開けた部分をしっかり意識して運用する。 最近のユースケース Vue.js/Vuex で Flux運用をとっている。 親直ルートのコンポーネントは全てVuex
漫画で説明する Flux
Lin Clark 氏が “A cartoon guide to Flux” というタイトルでとてもわかりやすく Flux についての記事を投稿していました。この文章のなかでも書かれていますが Flux はとてもホットな話題です。しかし、まだまだ十分に理解されていない技術なので、著者の Lin Clark 氏に許可を頂いて翻訳させていただきました。何か間違いや分かりにくいところ、より良くするための助言などありましたら気軽に@sota0805 までコメントお願いします。 （以下、2015年9月29日に Lin Clark 氏によって書かれた “A cartoon guide to Flux” の翻訳です。） 漫画で説明する FluxFlux は現在のウェブ開発で最もよく理解されていない話題の１つです。このガイドでは誰もが理解できる方法で説明しようとしています。 問題はじめに Flux が解決
Vue.js + Vuexで開発をしてみよう！
Vue.js + Vuex = Magic コンポーネント指向とFlux architectureで始めるモダンフロントエンド こんにちは、フロントエンドエンジニアの蔀です。 ここ数年のフロントエンド開発の潮流の変化は急激で、雨後の筍のように色々なフレームワークが出てきていますね。 8月末には、Mediumでこんな記事が人気になりました。 The State Of JavaScript: Front-End Frameworks と銘打たれたこの記事は、React/Angular/Angular2/Ember/Vue/Backbone といった、近年流行しているJavaScriptフレームワークに関する興味、満足度、知名度などを調査して比較してくれています。 注目していただきたいのが、「Satisfaction（使ってみて満足したかどうか）」の項目です。 近年流行しているReact.jsと
JavaScript の難しさとは何か - mizchi's blog
JSの学習コスト高いかという問題、言語のコア自体はシンプルだが細かい == とかのハマりどころが多いのと、言語機能自体がシンプルすぎてエコシステムを理解してモジュールを扱うところに辿り着くのが大変、という問題に分類できる— 現場の声 (@mizchi) 2016年8月15日 jQueryの学習コストは、DOMはツリーなんだよという概念の獲得と DOM API の抽象サブセットを覚えるというだけで、2016年現在は jQueryによるUI設計論(ここが高まるとBackboneとかその辺)みたいなものに手を出す必要がないなら、そんなでもないんだろうな— 現場の声 (@mizchi) 2016年8月15日 Reactが難しいと言われる場合、仮想DOMという概念がやや難しい、というか非常にCS的なアルゴリズムとデータ構造が背景にあって、その上で単純なトップレベルAPIとアルゴリズムを理解してないと
10分で実装するFlux
10分で実装するFlux 自己紹介 azu @azu_re Web scratch, JSer.info Flux /flˈʌks/ Fluxとは Facebookが提唱したSmalltalk MVCの焼き直し CQRS(Command Query Responsibility Segregation)と類似 データが一方通行へ流れるようにするアーキテクチャ ウェブUIについてそれを適応する 今日の目的 小さなFluxの実装を作りながらFluxついて学ぶ Fluxの特徴: Unidirectional data flow 本当にデータが一方通行に流れるのかを確認する Fluxでよく見る図 登場人物 何か色々いる Action Creators, Dispatcher, Store, React Views... Dispatcher = EventEmitterと今回は考える もっと実装的
人気のFluxフレームワークReduxをさわってみた - マルシテイア
fluxフレームワーク、今は Redux が一番アツい様子なので触ってみた。 github.com (追記 2015-10-03 18:15 APIや用語が大幅に変わったので更新した) Redux の経緯 2015-05-30 に公開された "The Evolution of Flux Framework" という記事がある。 medium.com Reduxはその PoC 的な実装だったんだけど、実用的ということでめっちゃ流行っているみたい。 Initial commit も 2015-05-30 だった。 Initial commit · rackt/redux@8bc1465 · GitHub 最近の flux フレームワークだと fluxible と flummox が人気だったけど、 flummoxのページには 4.0 will likely be the last major
ReactとFluxの入門のためにArdaを使ってみた - タオルケット体操
FluxもReactもよくわからん状態で入門して今日一日泣きそうになってたのでメモ。 というかいわゆるJavaScriptMVCをガッツリ書いたこと自体がないです。 Arda、指輪物語由来っていうあたりがよさがありますね。 あと全体的に薄いので、FluxとReactの仕組みを学びつつ、他と組み合わせたりいざとなったら捨てたり出来そうなのでよさそうっぽいなっていう雑な考えでいじりはじめました。 また、せっかくなので今回はContext層をTypeScriptにしつつComponentをCoffeeScriptにしてTemplateをreact-jadeに分離する、作者推奨っぽい構成でやってみました。 全体的な構成は mizchi-sandbox/arda-starter-project · GitHub から持ってきた感じなので、ツールの設定など特に言及のない部分は同じだとおもっていただきた
関数型UIプログラミング - 標高+1m
Pasta(deprecated)とかkakahiakaとかcastorocaudaっていうのを2012年くらいからぽつぽつ作ってて、その時に考えていたこと。多分Fluxも同じことを考えてて思いついたんだと思ってる。あと継続ベースのWAF( Seasideとかkahuaとか )とも通じる部分がある。*1 狭義の関数型プログラミングには値と関数しかない*2ので状態が持てない。つまり入力から一意に出力が決まるプログラムしか書けない。つまりアプリケーション自体が一つの関数である必要が有る。 こういうアプリケーションの典型例としては、対話式でない単純なシェルスクリプトがある。完全にステートレスな(裏にDBがあったりしない)Webサーバの各エンドポイントとかも当てはまる。 $ echo hello hello このパラダイムで対話的UI(例えばWebフロントエンド)を作るには、シェルの役割を果たすフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する