JSフレームワーク四方山話

まとめ人はJS弱者ですが、面白そうなのでまとめてみました。
0
kmd @kmd

片手間でcanvas&jsでブラウザ上quartz(限りなくしょぼいvar.)みたいなの試作してるけど、んもーprocessing.jsでいいんじゃねーーのってなってる

2011-01-20 15:30:24
ぼうくん | VoQn 🎨 @VoQn

@kmd processing.js そのものがクソ重く、Processing の機能全部再現できるように不要なコードたくさん保持してるから、目的に合うだけの最小限の js コード書いた方がマシだよ

2011-01-20 15:44:43
ぼうくん | VoQn 🎨 @VoQn

jQuery なんかも目的のWebサイト制作におけるユースケース的に機能過多になるケースは多くて、DOMくらい自前で操作コード書いた方がマシになるパタンは多い

2011-01-20 15:47:15
文殊堂 @monjudoh

@VoQn むしろ今逆のことを実感してる。DOM操作やevent管理以外にやりたいことがいっぱいある場合、その部分ではjQueryとその生態系が全く無力っていうパターン。

2011-01-20 16:11:49
ぼうくん | VoQn 🎨 @VoQn

@monjudoh jQが役不足になっていくっていう事例を聞いた事が無いのでそれは新鮮な話。今度聞いてみたい

2011-01-20 16:13:14
文殊堂 @monjudoh

@VoQn 単純なWebアプリであればDOM(HTMLとして提供)、単純なデータ(JSONとして提供、JavaScript上ではArray,Objectのネストした構造として保持)だけしか使わないので足りないところをjQueryが埋めてくれて神みたいに見えるが、

2011-01-20 16:15:08
文殊堂 @monjudoh

@VoQn 複雑になるとクライアントサイドでもmodelを構築しないといけないので

2011-01-20 16:15:46
文殊堂 @monjudoh

もりもりチューニングしてて少なくともアプリケーションコードではforEachとfor文に書き換えるメリットは感じなかった。というのもforEach使用箇所で時間がクソ長い所はforEach→forに置き換えるべきところではなくリニアサーチから他の方法に置き換えるべき箇所だったので

2011-01-20 16:18:55
文殊堂 @monjudoh

ものによるがライブラリの場合は全件どうしても舐めないといけないシチュエーションが多いと思うのでforEach→forのチューニングが有効な箇所は結構あるんだろうというのは理解できる

2011-01-20 16:20:22
文殊堂 @monjudoh

しかしまあパフォーマンスカリカリチューンだけを以てその言語でのプログラミングの本質みたいにいうのは微妙だなあ。その言語ならではの抽象化とか、抽象化の支援とかもめっちゃ重要やん。

2011-01-20 16:25:00
文殊堂 @monjudoh

メタプログラミングRubyが出版されずハイパフォーマンスRubyとかばっかり出版されるRuby界とかあったら嫌じゃん。

2011-01-20 16:25:18
文殊堂 @monjudoh

まあ今度iPad向けの仕事するときには多分uupaa.js使う

2011-01-20 16:28:28
文殊堂 @monjudoh

スマートフォン用とかでマシンスペック低め&&エフェクト重要とかならuupaa.js使うし、社内システムとかで抽象度上げないと管理しきれない複雑さを持っているWebアプリを使う場合はjQuery使う(が、足りない)

2011-01-20 16:30:58
超循環評価器 @hagino3000

@VoQn jQは簡単なページでしか使わないなー。Chaos Proxy Viewerみたいなやっつけおもちゃとか。

2011-01-20 16:58:19
ぼうくん | VoQn 🎨 @VoQn

@hagino3000 やっぱりEasyにプロトタイプ作るとかそういうのが無難な使い方なのかな

2011-01-20 17:05:34
超循環評価器 @hagino3000

@VoQn クライアント側でActiveRecordみたいな物が欲しいなら、senchaだろうし。jQueryだといろいろ足りない物があるので、不足してる所を自作しまくる必要がある。あくまで、サーバー側のコードを極限まで減らしてクライアントサイドJSで全てやりたい人間の意見だけど

2011-01-20 17:16:14
文殊堂 @monjudoh

uupaa.jsって部分部分細切れで使えないん?uu.readyとかめっちゃ需要あるとおもうんだけど

2011-01-20 17:09:46
文殊堂 @monjudoh

@hagino3000 構造が複雑だとサーバサイドで頑張っててもクライアントサイドでもがんばらないといけない。サーバサイドで複雑なassociationを持ったmodelを定義してる場合、クライアントサイドでもそれのミラー的なものがないと、部分変更した際に整合性取れない。

2011-01-20 17:18:34
文殊堂 @monjudoh

あらためて眺めてみるとバラして個別機能それぞれを手軽に導入できるようにして欲しいと思うことこの上なし "uupaa.js と jQuery を機能を中心にざっくりと比較 - latest log" http://is.gd/UE6Yl4

2011-01-20 17:30:10
もう暑くってェ グッタリしちゃってェ…んじに🐈にゃーん🍓🫐🍅🌽🍈🍆🥒🍇🦝 @uupaa

@monjudoh ビルドツールで使わないとこはoffできるよ //{@oreore ... //}@oreore って書いて upa.php -off oreore で oreore 部分丸っとカットできる。そゆことでなくて?

2011-01-20 17:31:58
文殊堂 @monjudoh

@uupaa 最初にデカイのありきで使わないところoffに出来るのより、個別提供されてるのをビルドツールでall in oneに出来る方が嬉しいのですよ。

2011-01-20 17:33:55
文殊堂 @monjudoh

@uupaa あ、もちろん切り離せる部分についてはですが

2011-01-20 17:34:14
文殊堂 @monjudoh

@azu_re カスタムビルドサイトなしでも、バラバラ版とall in one版が別々に提供されているとかでも割と助かると思うのだ

2011-01-20 17:38:16
文殊堂 @monjudoh

hogehoge.js all in one(でかい)しか提供されてないとhogehoge.jsを導入するわけではないがなんとか機能がほしいっていうときに選択肢から外れちゃうんだよね

2011-01-20 17:39:12
文殊堂 @monjudoh

肥大化を続けるjQueryについても同様

2011-01-20 17:39:25