3. 自己紹介 : 塚野 龍馬 (@lxyuma) ● ServerSide寄りWeb Developer ○ 元々SIer出身:java/rubyで法人サービス開発してた ○ 今は、弊社でCGMを開発 ○ 技術Skill ■ 言語FW：Rails + Backbone ■ storage：MySQL + MongoDB ■ 他rails周辺技術 ● 趣味 ○ 旅行/音楽/美味しい物食べる事 ○ 去年は台湾とFrance行った(今年は国内巡ろう) ○ 2013年ハマったのは、あまちゃんと叛逆
3. なぜMarionette? Backboneを実際書いてみると色々悩む ● ①自由度が高過ぎ ○ Viewの親子や配置等、人によってバラバラで大変 ● ②用意されたmoduleだけでは足りない ○ 特にViewやRouterが汚れる ● ③同じsourceばかり膨大な量を書くハメに... =>これらを解決するためにMarionette 4. Marionetteの良い所 ● ①Viewの構成が整理されて分かり易くなる ○ Layout管理(Viewの配置)の仕組みがある ○ どのView使うかでViewの親子階層が明確に ● ②開発作業の効率化 ○ とにかく書く量が半分以下に激減！ ○ 量が少ないので、読むのも楽になる！ ● ③ソースが汚れない ○ routerとController分けてる！ ○ イベント連携の仕組みが整理されてる！ 5. 噂：抽象度 噂「抽象度が高すぎなんじゃない
Why Should I Use Backbone.Marionette Instead Of … ? There’s a question on StackOverflow from someone that wants to know what the real differences are between the various Backbone-based application frameworks. While I can’t really answer the question in terms of what the differences are, I can provide more insight in to why Marionette exists and what it provides that some of the other frameworks ma
JavaScript application development is a hot topic and people are wondering which framework they should pick. In this post I’m going to compare two of them. Marionette and Chaplin are frameworks on top of the popular Backbone.js library. Both seek to ease the development of single-page JavaScript applications. In such applications, the client performs tasks that were typically performed on the serv
以前書いた記事の反省を元にMarionetteに移行した。 思った以上に快適！ 大規模になったらMarionette.js使えとか書いているのは嘘で、普通にBackbone使うときは、初めから使うべき。 Backboneで一番恐ろしいのは、各現場/各開発者毎に異なるオレオレ実装。オレオレ実装作るコストに加え、使う人の思わぬバグや学習コストやスイッチングコスト等諸々考えると、特別な理由がない限りMarionetteみたいな既存のframework使うべき。 あんど。データバインディングを提供してくれる、stickitと一緒に使うと、より一層効果的。 めっちゃ、ソースコードの量が減って、ソースの意図が明快になった。悩みも少ない。工数も勿論減る。 ここから、幾つか思った事を、サッカー見ながらお酒飲みながら、ダラダラ書く。※ちなみに、日本vsオランダ戦見てる。 railsアプリでのjs周辺の作りの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
