【Java】 Java Web Application Framework 総合

1 名前：デフォルトの名無しさん [2012/06/03(日) 16:18:39.74 ] Java用のWeb Application Frameworkについて語るスレッド 海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない 開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを 比較しながら、最高のフレームワークを探してみるスレッド Web Application Framework　のリスト en.wikipedia.org/wiki/Comparison_of_web_application_frameworks 特徴の比較 en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features 486 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 02:21:25.71 ] こんな簡単なSQLで苦労するところ見ちゃうと学習コストが低いなんて信じられん qa.atmarkit.co.jp/q/2826 487 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 04:49:50.13 ] う〜ん規約に従っている限りHibernateのアノテーションの量なんてたいしたほどではないと おもうのだが。規約から外れるとマッピングの記述量が増えるのはRailsも一緒だし。 488 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:30:48.85 ] >>485 名前だけでなくGrailsはRailsとかなり似てるから楽でいいよ Javaを知っている人ならGrailsのが学習コストは低いとおもう。 >>484 日本の遅れたIT業界のことだから、ダメなのわかっててStruts2 に移行したりするんだろうなぁ 489 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:35:07.70 ] >>484 フレームワークなんか使うからこうなる。 490 名前：デフォルトの名無しさん [2013/04/04(木) 07:44:26.43 ] >>489 お前自身がEOLってことに気づこうな 491 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:49:20.30 ] Grails、確かに使いやすいのだがRailsに似せるのに頑張りすぎていてかえってJava観点では アレになっている部分も少なくないと思う。 例えばmappingsやtransientといったORMの定義、staticフィールドにRails風に記述できる ようになっているけれども、型安全じゃないし正直JPA風のアノテーションの方がシンプルで 良かった。まあHibernateで定義したドメインクラスをインポートすれば良いのだけど。 あとビミョーに謎な振る舞いに悩むこともある。先日もドメインクラスにコンストラクタを定義 して使っただけでDIが動かなくなって暫し悩んだ。 492 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:49:35.61 ] >>489 まだこのスレにいたのか 必死にフレームワーク否定してるけど何つかったことあるんだよ 493 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:56:46.99 ] >>488 Javaのフレームワークにはいつも期待を裏切られてるけど 最後の最後ということでやってみるよ。アドバイスありがとう 494 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:05:53.42 ] 作っては捨て作っては捨て こんなのシステム開発では使えないよ。 趣味のプログラミングなら好きにやってくれていいけどさ。 495 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:52:46.84 ] >>494 毎回作り直してる俺々フレームワークのことですね、わかります 496 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:58:09.84 ] WicketライクなFW普及してくれ〜 497 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:59:04.31 ] >>495 受託や派遣ばかりやってるからそういう発想になるんですね。わかります。 498 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 09:18:37.61 ] >>496 Wicket的な役回りはAngularJSとかブラウザ側でJSの時代だろ 499 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 11:52:00.96 ] >>493 まだGrailsのチュートリアルやってるレベルだけど 最新の2.2.1はエラー出たから、2.2.0で試すのがいいかもしれない。 v2.2.1だと、controller作成時に下のようなエラー出る 2.2.0なら大丈夫。 grails> create-controller hello | Error Error running script create-controller hello: _GrailsCompile_groovy$_run_closure1 (Use --stacktrace to see the full trace) grails> 指示通り、--stacktraceしてみると、 grails> --stacktrace | Error Error running script --stacktrace: Cannot invoke method findAll() on null object (NOTE: Stack trace has been fil tered. Use --verbose to see entire trace.) java.lang.NullPointerException: Cannot invoke method findAll() on null object at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1243) at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1243) | Error Error running script --stacktrace: Cannot invoke method findAll() on null object 500 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 20:48:10.99 ] JSFってFacelets+CDIだけやれるっけ？ バッキングビーンの思想は素晴らしいけど管理ビーンとCDIが別れてるのが糞すぎる 501 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:33:20.22 ] javascriptの時代が来る気がする 最近のjavascriptのライブラリは凄まじすぎるわ jqueryuiとか、datatablesとか、jquery.sheetとか マジでなんでもできるんだな サーバーサイドもNode.jsになるんじゃないかな ブラウザの開発ツールやらcloud9やらと、開発環境も整いつつあるし Javaは下火になりそう 502 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:35:35.96 ] フレームワーク乱立のせいだな 503 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:41:00.19 ] >>501 その3つどれもただのjQueryのプレゼンテーション層よりの機能じゃないか jQueryは他の言語のフレームワークでも連携させて使えるし、 サーバサイドが強いJavaとは強みのあるエリアがちがうよ 本格的なオブジェクト指向言語にすらなれてないJavascriptで 開発なんてしたくない 504 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:54:27.01 ] >>501 phpと争って削ってくれたらそれで十分な感じかな あいつらだけはマ名乗ったらいかんレベル 505 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:59:26.63 ] apache cgi javaとかあればなー 506 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 23:23:40.46 ] >>503 それがさ、今single page applicationとかってのが流行ってるらしくて サーバーサイドのコントローラの機能をクライアント側が吸収し始めてるんだよ ライブラリさえあれば普通に本格的なオブジェクト指向言語だし backbone.jsとかember.js見て驚愕した requirejsやらcommonjsやらでモジュールもできるし、ビルドツールもある qunitとかphantom.jsとかでテストも完備 サーバーサイドでormっぽいことも出来るみたいだし nodejsdb.org/ ちょっと首を突っ込みはじめたんだが、マジで最強かも ものすごいコミュニティができつつある 507 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:10:40.11 ] Javaのフレームワーク関連で こんなにもたくさんの名前が出て来ること自体が異常 他の言語はここまで乱立してないから入りやすい 508 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:24:26.24 ] >>507 javaはまだマシだと思う ほとんどspring一択だし、そこにplayあたりが割り込もうとしてるくらい ぶっちゃけjeeだけってのもありだし この点ではjavascriptのライブラリの乱立が一番ひどい 509 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:51:39.39 ] springjs hibernatejs なんかつよそう jsf も js が付いていることに気がついた。でもうんこ 510 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 01:11:50.38 ] 選択肢が無い方が幸せって人もいるけど俺はいやだな 511 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 06:32:32.04 ] 趣味の自分プロダクトならそれでいいけど フレームワークがコロコロ変わると チームメンバーが大変だろう 512 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 06:47:37.60 ] そこまでころころは変わらない。 513 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 07:02:04.46 ] オレオレフレームワークで検索するとPHP率が結構高いのね。 514 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 08:05:54.47 ] Javascriptは「Javascriptへコンパイルする言語」の乱立が酷いけどな 515 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 09:36:15.65 ] >>508 DIコンテナとして下のレイヤーでSpringを使ってるのは多いみたいだね GrailsもSpringをベースにして、HibernateやGroovyや 独自テンプレートエンジンなどを組み合わせたものだった。 VMwareがGrailsのバックについてるからSpringベースなのは当然かもしれないが。 >>510 選択肢は多いほうがいいね ドキュメントが整備されているという条件つきだけど。 JSはドキュメントも十分にないようなライブラリが1万以上あってカオスだわ 516 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:15:07.30 ] 2年前は、こんなにJSのフレームワークがいっぱい出てくるとは思わなかったわ たんにデコレーションする JQueryとprototype js と ext js しか知らなくて、 Backbone JS みたいにクライアントサイドでロジックまで制御するようなフレームワークが 出てくるなんて思わなかった(自分のスキルが低いのだろうが) 517 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:17:44.83 ] 俺はフレームワーク嫌いだからjQueryすら使わない 518 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:33:11.41 ] JSはただのライブラリであってフレームワークではないだろ 519 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:41:08.76 ] ネイティブが好き 520 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 13:47:27.52 ] Javaのフレームワークの乱立について指摘されてるのに JSのほうがもっと酷いからJavaの乱立はOK、というのはいかがなものか 521 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 13:53:42.65 ] >>518 MVCフレームワークが乱立してるよ todomvc.com/ 522 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:46:14.82 ] Node.jsはCPUを使う処理には弱いと書いてあるね。 シングルスレッドでしか使えない弱点が痛い。 グリーの宣伝（人材募集）みたいになっててアレな記事だけど。 codezine.jp/article/detail/6461?p=2 メリットはリアルタイム処理が強いことくらいかな でもソーシャルゲームとかチャットのようなリアルタイム性が 必要ないなら、Node.jsを使う意味は見当たらない。 JSは細かいライブラリが大量にあって情報追いかけるのがひたすらめんどくさいわ 現状は汎用的に使えるサーバサイドフレームワークって感じじゃなくて リアルタイム処理が必要な場面で使うものに見える。 523 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:49:07.16 ] 従来サーバ側のWebフレームワークが担ってきた役割、特にビューは クライアント側（JSに限らずObjCやJava含む）への移動が始まってる だからサーバ側もJAX-RS的なものでAPIだけ作る流れ これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる） 524 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:52:50.13 ] >>522 今はJavaでもNettyがあるし、その上に作られたNode.js風のVert.xもある Netty上に作られたErlang風のAkkaもあり、Akka上に作られたPlay!もある 技術的にはNode.jsを選ぶ理由はない 525 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:56:37.52 ] JAX-RSは地味によいものだと思う。 526 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:59:55.89 ] シングルスレッドとかありえねー 527 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:18:49.66 ] 逆だろ、単体ではシングルスレッドにしておき、 CPUコア数に応じてスケールさせたければ、プロセスを複数立ち上げておいて、 フロントのロードバランサーなりリバースプロクシで分散させればよい。 Nodeにしろ、こういったのは、パフォーマンスを上げるために、マルチスレッドではなく RubyのEventMachineみたいにイベント駆動にすることでパフォーマンスを上げようとするアプローチなんじゃないの？ って書いてて自分でも理解してないのだが、 マルチスレッドにしつつ、各スレッドは EventMachine 形式にしたら、もっといいんじゃないの？ と思うんだけど、併用できないんですか？ 528 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:35:47.71 ] 逆とか意味不明。シングルスレッドとか糞 529 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:44:10.18 ] シングルスレッドにはシングルスレッドの良さがある 同時1万接続をすいすい捌いてもメモリ256MBでおつりが来る これはマルチスレッドじゃ無理 クラウド（PaaS）ではこれがコスト面で効いてくる場合がある 要は適材適所の一つ 530 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:45:51.78 ] >>523 Viewがクライアント側に移動が始まっている、の意味がさっぱりわからんですわ。 例えばCRUDのうち、データ取得する(SELECT的)処理をするとして AP serverは、DBから得た結果を、htmlとマージして最終的にブラウザに 渡す必要があるのは何ら変わってないでしょう？ 要するにTemplateにデータを合成して、レスポンスを返す処理。 実際に、今の主流のMVCのフレームワークでも そういったViewのテンプレート処理を持ってるし、使ってるでしょう。 Node.jsをプッシュしてたひとと同じだと思うけど、「使われている事例がある」 というだけなのに、すべてそうなっていくかのように主張しているように見える。 531 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:50:45.64 ] >>529 ないない。 DB絡んだら1万同時接続なんて1台じゃ無理だし シングルスレッドならなおさら無理。 さらに256MBで足りるなんて妄想もいいところ 1万接続で256MBとか馬鹿な主張はいいかげんにしろといいたい 532 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:58:18.20 ] シングルスレッドはマルチスレッドになれないけど マルチスレッドはシングルスレッドになれるんだから シングルスレッドのほうがいいなんてありえない。 533 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:02:24.39 ] >>530 HTMLを返す必要がなくなってきてるってこと JSONだけ返しておけばあとはクライアント側でレンダリングする だからクライアント側のMVCフレームワークが注目なわけ 君だいぶ遅れてるみたいだから少しはキャッチアップしておいて損はないと思うよ 534 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:15:06.17 ] >>531 Node.jsじゃDB接続もノンブロッキングだし1スレッドで十分 DBとのやり取りってアプリ側はSQL投げて返ってくるまで待つだけじゃん？ だから影響はないよ もちろんDB側がボトルネックじゃない前提で >>532 用語の使い方の問題だな シングルスレッド: イベントループで複数の接続を扱うアーキテクチャ マルチスレッド:　 接続毎にワーカースレッドを使うアーキテクチャ まともな議論にならないなら用語変えた方がいいかもね 実際はNode.jsだってマルチスレッドだよ イベントループ以外のスレッドは持ってる 別にNode.jsプッシュしてるつもりはないんで 必要に応じて使ってるだけ 535 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:19:45.99 ] >>533 遅れてるとか馬鹿にしてるだけで答えになってないよ。 最終的にブラウザで表示されるhtmlはどうするんだよ HTMLを返す必要はなくなってきてなんてないから 536 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:21:03.02 ] bodyタグの中身は空でjsで全部書くってことでしょう。 537 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:24:45.46 ] >>536 それ非効率極まりないね あとJS無効にされてたらなにもレンダリングされないじゃないの。 プライベートブラウジング機能が搭載されてきてるから JS無効になってるなんてケースは増えてる。 538 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:27:03.82 ] フレームワークを使う人は開発効率のみ優先だから。 539 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:30:26.06 ] >>523 >>533 それはないと断言できる プログラムの前にキミはWebがわかってない 540 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:31:51.49 ] >>530 ViewはもともとウェブアプリケーションフレームワークによるHTML生成とウェブブラウザにる レンダリングの共同作業だったわけだけど、書かれるロジックがどんどんブラウザ側のJavaScript に引っ越ししつつあるというのは自分も解る。 ただ個人的にはウェブアプリケーションフレームワークでViewと呼ばれている部分よりもController と呼ばれている部分に書かれていたロジックがお引っ越ししている印象。 ウェブアプリのMVCは本来のMVCとは違うとかMVC2とか細かいツッコミは別として、大まかに ウェブアプリのCはURLマッピングで振り分けられたHTTPリクエストに応じてアクションを起こす 役割と、Vで表示されるデータをお膳立てするビューロジックの一部を担ってきたように思う。 これが前者に関しては最近はブラウザ上でSubmitボタンを押しても直接POSTリクエストが飛ぶの ではなく、ブラウザ上でJavaScriptがRESTリソース、言うなればMにアクセスするリクエストを 組み立ててAjaxでやりとりしてHTMLを書き換える。この場合ウェブアプリ側のCというのはURL にRESTリソースをバインドする程度のすごく薄いものになる。 後者に関しても例えばMの中に1万件あるデータをある属性で並べ替えて20番目から29番目を表示、 といったページングのためのビューロジックは大抵Cの中に書かれていた。ただこのロジックも最近 ではJavaScriptで書いて、AJAXをつかって動的にサーバから表示に必要なデータを取得する場合 も多いと思う。これもサーバ上のCからブラウザ上のJavaScriptにお引っ越ししている例。 541 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:38:33.99 ] >>539 同意。 他人を遅れてると馬鹿にして上から目線で発言してるわりに アーキテクチャと利点、欠点などがわかってないわ 542 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:39:43.33 ] フレームワーク厨はフレームワークさえ使えればなんでもいいんだよ。 君らもフレームワークをありがたがってないでネイティブに回帰すべき。 543 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:43:38.62 ] >>535 最初は静的なHTMLで始まる（Javaで返す必要はない） そこからロードされたJSがサーバからJSONを取得する JSONで得た情報をJSでレンダリングする そのためのJSで書かれたテンプレートエンジンもたくさんある うちはHandlebars使ってる まだそこまで極端なケースは少ないけど方向はこっち （Twitterみたいに後戻りするケースもあるし流動的かもしれんが） スマホのネイティブアプリとサーバ側が共有しやすいメリットも大きい つかうちはスマホアプリが先で後からブラウザ対応が増えてきてる ちなみに業務系はオンプレのJavaでStrutsベースのオレオレ、 それとは別にAWSでPHP、RoR、Node.jsを使ったサービスを並行してやってる わかってないといわれるならそうなんだろう 544 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:49:34.93 ] そうやって間違った方向に進んでしまうのがIT業界の悪いところだな。 545 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 17:16:33.84 ] >>540 >>543 Google mapとかの地図サイトのように ページの一部分を頻繁に読み込むようなサイトなら JSは使うだろうし、それくらいは当然知ってます。 ページ全部を毎回読み込むのは非効率だし ただ、MVCのある機能がブラウザ側に移動したというより、サーバとクライアントが 協調して動作するようなシステムが出てきたってだけの話だと思う。 結局、サーバサイドのフレームワークがなくなることはありえない。 >>523は、「分散」とかではなく「移動」といったうえで 「これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）」 なんて結論づけたから噛みついたわけ。 Strutsがクソなのは知ってるけど、そこからサーバサイドのMVCフレームワークが なくなっていくという話につなげられると まったく同意しかねる、ということ。 Ajax, jQuery必須にしてしまえば、ブラウザでJS切ったら使い物にならないし 有効であってもバージョンの互換性でエラーが出る。 開発のコストも無駄にかかる。デメリットも大きい。 だから全般的に移行することはありえない。 デメリットを補ってあまりあるメリットがあれば使われる、というだけ サーバだけでやるのか、サーバ＋クライアントでやるのか、 使い分けの問題であって、サーバのみでやるのが遅れているわけでもない。 セキュリティ上の理由でクライアントサイドで処理できないこともある。 546 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 17:20:06.75 ] まったくだ。ニコ動もクライアントでいろいろやりすぎて 糞使いにくくなってる。 つまり何事もネイティブで考えることが必要だ。 547 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 18:58:11.74 ] 中の人にはソレが段々と見えんくなってくるのでしょう。 548 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 19:24:11.12 ] JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。 ちなみにうちは、jQueryの利用的なことから一歩進んで、JSフレームワークのLOBアプリへの適用もやりはじめた。 今までJSで個別に処理を記述していたところを、フレームワークを使って、 RESTなAPIの結果でObserverなVMのメンバを更新、バィンディングでHTMLの表示を更新というレベルだけど。 549 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 20:45:01.83 ] >>548 > JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。 どの辺がまだまだ? 550 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 21:28:07.76 ] >>545 もちろん、なかなか消えはしないだろうけど、 徐々にviewの部分が移行していく流れだと思う 下手すると、cの部分も 本当に最後まで残るのは、モデル層だけだろう 551 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 21:41:16.25 ] 今後流れがjavascriptに来るだろうというのは 確実に分かる 現在のライブラリの乱立がその徴候 今はその動きの中にいる人だけが気がついてる状態だが これがやがて、本流になる 552 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 00:15:09.70 ] サーバーサイドがhtmlではなくxmlでデータを返すに留まり Ajaxで何でもやるなら既存のMVCフレームワークの延長でもできそうだな。 (ViewがXMLになり、XML/HTMLは互換性がある) GWTとかPlayみたいなオレオレ色の強い独善的FWよりそっちがいいかもしれん。 だがサーバーにフレームワークが必要ないって意味不明。 クライアント側でjavascriptがJSONからHTML組み立てる言われても 誰がクライアントに渡すJSON/XMLを作るんだ？ まさかクライアント側のjavascriptがSQL発行してjson作るのだろうか？ 553 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 00:35:34.78 ] 今後はクセモノであるHTTPセッションを クライアント側メモリに持ち込むのも増えていくだろうけど、 クライアントがスマフォとかだと大きいキャッシュデータとか無理だし サーバー側でセッション作る必要がある。 554 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:04:28.16 ] インタラクティブな処理が必要な場合に、 クライアントサイドでのタスクを増やすってのがJSの使いどころ このスレのJSやnode.js推してる人は、すべてクライアントサイドで やる方向にいくと思ってるところが大間違い。 デメリットがわかってない。 必要のない場所でまでJSでやったら開発コストも増すし ブラウザの互換性というやっかいな問題が現れる。 555 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:06:01.26 ] ダイナミックHTML時代のままで大いに結構 Ajaxまでは求めちゃいないよ 556 名前：keisuken mailto:sage [2013/04/06(土) 01:24:33.06 ] ちょっと勘違いもあるかなと思うけど、今後は両方で進んでいくことはほぼ間違いないと思うけどな。 * ブラウザがFORMでPOSTしサーバがHTMLを返す * ブラウザがAjaxでPOSTしサーバがJSON/HTMLを返す(JSONの場合はJavaScripotがDOMなどに適用する) RESTful坊は後者に偏りがちで * ブラウザの処理が重たくなる * JavaScriptに対応していない端末で動かない という欠点もあるんだけど * サーバ側がかなりシンプルになる(Web APIの提供) * 場合によってはレスポンスデータが小さくなる などの利点もあって別に間違った方法でもないし、実際そういうサイトはいくらでもある。 JavaScriptでの開発が煩雑になり、開発しにくくなるというのも間違っていないのだが、 Wicketみたいにある程度フレームワークが解決してくれることもあるし、 今時のJavaScriptライブラリ/フレームワークは昔より良くできていることが 多いので案外どうにでもなっちゃう印象ですね。 特にスマートフォン対応だとむしろJavaScriptを使わないことが(主にレスポンシブや アニメーション, レイテンシなどで)しょぼく感じてしまうケースもあるので もう無視できなくなってると思う。 557 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:30:00.65 ] HTMLを返す処理はなくならないが フレームワークの要不要はまた別問題だな 俺はいらんと思うけど 558 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:33:29.51 ] ブラウザで多くをやる方法は限界やデメリットがある以上、 サーバ側のフレームワークにとって代わることはない。 JavaのWebフレームワークのスレなのにスレ違いのレスばっかりになってる。 559 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:34:45.31 ] >>553 >今後はクセモノであるHTTPセッションを >クライアント側メモリに持ち込むのも増えていくだろうけど、 セキュリティホール確定。 クライアント側は当然偽装し放題ですよ。 ちなみに自分は常にJavaScriptはOFF（もちろんJavaAppletだのFlashだのも） なので、見えないページはムカつきつつ閉じてます。 わざわざ開く価値なんてないし。 560 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:36:37.41 ] >>558 JAX-RSだってJavaのWebフレームワークだからこの流れはスレ違いじゃない 自分の意見と違うからって排他的にならないでほしいね 561 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:12:52.30 ] >>559 いまどきJavaScriptをOFFとかありえないだろ。 商品リストのページングとかSession+Ajaxでやっていたようなものにも クライアント側が操作しても問題ないようなデータは結構あるぞ。 562 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:19:09.71 ] >>559個人がどうするかは>>559の自由だから放っておいてやれw ようはJS無効にしてるユーザを救うことによって得られる 利益とかかるコストをそれぞれのサイトがどう評価するかだ 563 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:24:58.73 ] クライアントJavaScriptでバリデーションをするとか嫌だな。 たとえば登録フォームだとパスワード半角英数8桁とか以外にも 同じ名前が既に登録されているのかとかチェックするときがありうる。 そうなるとデータベースとバリデーションが関連するわけで、 Ajaxを通すのは良いとしてもバリデーション自体は鯖側で行うべきだ。 564 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:51:01.86 ] クライアントから投げられる値なんて基本的に信頼できないからサーバ側でのバリデーションは いつまでたっても必須だよ。ただsubmitする前にキー入力に応じてダイナミックにバリデーション したい場合などはJavaScriptを使ってブラウザ上で「仮」バリデーションする場合もあるというだけ。 ただこれするには同じバリデーションロジックをJavaとJavaScriptでそれぞれ書くことになるので 二度手間になる。この点でGWTは地味に便利だった。Javaで書いたロジックをJavaScriptに変換して ブラウザ上で使うから二度手間にならないし、Java上でロジックを書き換えるとそのままクライアント 側のロジックにも反映されるからロジックの同期も楽。 というわけでJavaからJavaScriptへのコード変換はそろそろjavaxとして仕様化すべきだと思う。 あるいはJava -> JavaScriptの変換を行う定番トランスレーターがデファクトで決まるのでも良い。 565 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 04:45:17.33 ] >>564 で、だったらはじめからサーバーもjavascriptで書けばいいじゃん という流れになったりしてな node人気が出てきたみたいだし 566 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:06:19.09 ] >>563-564 そうそう。 セキュリティ上の理由で、サーバ側でやらないといけないもの があると書いたのはそういうValidationとか。 クライアントサイドのValidationは仮のチェックだね レスポンスを高めるだけのものでしかない。 クライアントに渡した時点で汚染された（信頼できない）データに なってしまうし、再度DBに入ってくるようなデータは渡したくない。 全部クライアントサイドでやる流れ、とか言ってる人は セキュリティの観点が頭にない。 567 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:17:19.79 ] >>566 バッカだねぇ、「全部」クライアントでやる流れなんて誰が書いた？ サーバ側でバリデーションが必須なんて当たり前すぎて議論の余地無しだよ JAX-RS使うとバリデーションできないとでも思ってる？ BeanValidatorはMVCフレームワークと密結合してるとでも思ってる？ レベル低すぎて相手にするのやめようと思ったけど想像以上の低さに驚いたよ 568 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:24:52.99 ] つーか「StrutsとJSPの時代が終わる」と書いた>>523でもJAX-RSのこと書いてるのに なんで>>545みたく「サーバサイドのフレームワークがなくなることはありえない」 なんて的外れの反論しちゃうのかねぇ あげくに「全部クライアントでやる流れ」とか誤読どころの話じゃないだろ こんな文盲で仕事できるのかね？ 569 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:26:42.29 ] >>567 自分の発言読み返してみろよ そう読み取られてもおかしくない表現してる >>523なんてアホ発言そのもの 他にもnode.jsの時代になってるだの妄想垂れ流しすぎ 570 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:27:53.82 ] >>568 おまえはJSスレに帰れよ 完全にスレ違い 571 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:29:14.15 ] 一度スマホのネイティブアプリとだけつながるサービスの開発でもやってみると （何が必要か考えるだけでも）知見も広がっていい経験になるんじゃないすかね？ 572 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:32:39.84 ] >>569 具体的に指摘してみろよ どこに「全部クライアントでやる流れ」と読み取られておかしくない発言がある？ Node.jsの時代になってるってのもどこにある？ 573 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:43:39.54 ] >>572 誤解されてもおかしくない表現力だよ 他の人もそうとらえてる人がいる。 >>543もあんただろうけど滅茶苦茶 ＞最初は静的なHTMLで始まる（Javaで返す必要はない） それができない場面もあることはすでに書かれていたよな？ ＞まだそこまで極端なケースは少ないけど方向はこっち ほら、ここで自分でいってるだろう。 使えない場面がたくさんあるのに「方向はこっち」とか言ってる。 あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。 自分ではないいうのなら自分のレス番号全部書くなりトリップつけないとわからない。 この板はIDでないから 574 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:55:48.45 ] >>573 > 他の人もそうとらえてる人がいる。 他の人じゃなくてさ、君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ > それができない場面もあることはすでに書かれていたよな？ できない場面「も」あるから何？ > 使えない場面がたくさんあるのに「方向はこっち」とか言ってる。 「たくさん」っていうのは君の主観だね > あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。 そもそもどのレスがNode.js推しなんだよ？ ちなみに>>524は俺だよ。Node.js推してるように読めるか？ 575 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:03:44.94 ] >>574 >>524は別人だと思ったよ 俺とかいわれてもIDでないしわからない。 ＞君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ 散々書いただろ。めんどくさいやつだな あんたの発言がどのレスだか判別つかないことくらいわかってくれ。 俺のレスもすべてはわからないだろう。 576 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:25:47.54 ] >>575 「散々書いた」ってどこにあるんだよw 具体的に指摘する気はないみたいだからこれ以上は追求しないが、 勝手に拡大解釈して文句をつけるのはもうやめてくれ 577 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:33:12.04 ] >>576 散々書いたってわからないって？ 俺もお前のレスがどれだかわかんないのよ IDでないから そういうしょうもない掲示板でまともな議論なんてできないの 578 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:37:32.20 ] >>577 あぁ、続ける気なんだ 別に「俺の」じゃなくていいからさ、君がどのレスのどの表現から 「全部クライアントでやる流れ」と読み取ったのか教えてよ 寝ぼけててもできる簡単なお仕事だろ？ 579 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:42:19.34 ] >>572 「APIだけ作る流れ」 「HTMLを返す必要がなくなってきてる」 580 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:42:23.42 ] >>576 ちなみに俺は「君が」書いたレスかどうかは「気にしないで」読み返したけど どこに「散々書いた」のか見つけられなかったよ 突然飛躍してるレスしか見あたらない 581 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:47:57.92 ] >>578 >580 しつこいなぁ、あんたも 「続ける気なんだ」どころか真逆だわ IDでないしょうもない掲示板でまともな議論なんてできないってかいたろうに IDでないんだから違う相手に反論してるなんてことあるだろ？ だからこれだけレスもついたし、検証作業なんてやりたくないの。 全員が正直に自分のレスを書いてトリップ書いたりしないと今となってはわからない。 582 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:49:57.54 ] >>579 それかよ（失笑） Twitterが「API」も提供してのはもちろん知ってるだろ？ Twitter4Jとかあることくらいは知ってるだろ？ そのAPIはHTML返さないのも知ってるだろ？ じゃあTwitterのAPI叩くとTwitterのサーバじゃバリデーションも行わず、 「全部クライアントでやる」と思ってる？ 違うだろ？冷静に考えてみてくれ 583 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:52:13.77 ] >>581 別に違う相手でも構わないよ >>579にしたってさっきまでの誰かと同じかどうかはどうでもいい それで議論できないなら半年ROMってろ 584 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:54:41.95 ] >>580 581 だけど>>579の人とは別人だぞｗ ほら、他の人も、サーバサイドが不要になりつつあると解釈してるだろ？ だれかJS押しの必死な人がいるように見えるわけ。 でも、IDでないから同一人物かすらもうわからないわけ。 くだらないだろ？ 無意味なレスばっかりになってる上にスレ違いだから、 クライアントJSの話題はJSのスレでやってくれ 585 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:56:09.01 ] >>582 スレ違い。荒らしになってる。 冷静にスレタイを読めとしか言えない 586 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:59:59.38 ] >>582 喧嘩してるとこ横レスして混乱させてすまんかった JSONを返す流れについていってないやつは遅れてるとか HTMLを返す仕事してるやつを小馬鹿にする発言もあったしなあ じゃあバリデーションやデータの受け渡し以外は 全部クライアント側でやる流れってことでいいの？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef