片手間でcanvas&jsでブラウザ上quartz(限りなくしょぼいvar.)みたいなの試作してるけど、んもーprocessing.jsでいいんじゃねーーのってなってる
2011-01-20 15:30:24@kmd processing.js そのものがクソ重く、Processing の機能全部再現できるように不要なコードたくさん保持してるから、目的に合うだけの最小限の js コード書いた方がマシだよ
2011-01-20 15:44:43jQuery なんかも目的のWebサイト制作におけるユースケース的に機能過多になるケースは多くて、DOMくらい自前で操作コード書いた方がマシになるパタンは多い
2011-01-20 15:47:15@VoQn むしろ今逆のことを実感してる。DOM操作やevent管理以外にやりたいことがいっぱいある場合、その部分ではjQueryとその生態系が全く無力っていうパターン。
2011-01-20 16:11:49@VoQn 単純なWebアプリであればDOM(HTMLとして提供)、単純なデータ(JSONとして提供、JavaScript上ではArray,Objectのネストした構造として保持)だけしか使わないので足りないところをjQueryが埋めてくれて神みたいに見えるが、
2011-01-20 16:15:08もりもりチューニングしてて少なくともアプリケーションコードではforEachとfor文に書き換えるメリットは感じなかった。というのもforEach使用箇所で時間がクソ長い所はforEach→forに置き換えるべきところではなくリニアサーチから他の方法に置き換えるべき箇所だったので
2011-01-20 16:18:55ものによるがライブラリの場合は全件どうしても舐めないといけないシチュエーションが多いと思うのでforEach→forのチューニングが有効な箇所は結構あるんだろうというのは理解できる
2011-01-20 16:20:22しかしまあパフォーマンスカリカリチューンだけを以てその言語でのプログラミングの本質みたいにいうのは微妙だなあ。その言語ならではの抽象化とか、抽象化の支援とかもめっちゃ重要やん。
2011-01-20 16:25:00スマートフォン用とかでマシンスペック低め&&エフェクト重要とかならuupaa.js使うし、社内システムとかで抽象度上げないと管理しきれない複雑さを持っているWebアプリを使う場合はjQuery使う(が、足りない)
2011-01-20 16:30:58@VoQn クライアント側でActiveRecordみたいな物が欲しいなら、senchaだろうし。jQueryだといろいろ足りない物があるので、不足してる所を自作しまくる必要がある。あくまで、サーバー側のコードを極限まで減らしてクライアントサイドJSで全てやりたい人間の意見だけど
2011-01-20 17:16:14@hagino3000 構造が複雑だとサーバサイドで頑張っててもクライアントサイドでもがんばらないといけない。サーバサイドで複雑なassociationを持ったmodelを定義してる場合、クライアントサイドでもそれのミラー的なものがないと、部分変更した際に整合性取れない。
2011-01-20 17:18:34あらためて眺めてみるとバラして個別機能それぞれを手軽に導入できるようにして欲しいと思うことこの上なし "uupaa.js と jQuery を機能を中心にざっくりと比較 - latest log" http://is.gd/UE6Yl4
2011-01-20 17:30:10@monjudoh ビルドツールで使わないとこはoffできるよ //{@oreore ... //}@oreore って書いて upa.php -off oreore で oreore 部分丸っとカットできる。そゆことでなくて?
2011-01-20 17:31:58@uupaa 最初にデカイのありきで使わないところoffに出来るのより、個別提供されてるのをビルドツールでall in oneに出来る方が嬉しいのですよ。
2011-01-20 17:33:55hogehoge.js all in one(でかい)しか提供されてないとhogehoge.jsを導入するわけではないがなんとか機能がほしいっていうときに選択肢から外れちゃうんだよね
2011-01-20 17:39:12