Java Web Application Framework総合　ver2

**デフォルトの名無しさん** · 2013/07/21(日) NY:AN:NY.AN

Java用のWeb Application Frameworkについて語るスレッド

海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド

前スレ
http://toro.2ch.net/test/read.cgi/tech/1338707919/

Web Application Framework　のリスト
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

特徴の比較
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features

**デフォルトの名無しさん** · 2014/04/26(土) 20:18:05.95

node.jsでサーバー書くより
ブラウザでjavaなりc#が動いてくれたほうがよっぽどありがたい

**デフォルトの名無しさん** · 2014/04/26(土) 21:29:20.02

>>357-358
SQLではないけどAWSのDynamoDBはブラウザのJSから直接アクセスするための機能が
既に備わってるからあながちあり得ないって事はない

http://aws.typepad.com/aws_japan/2013/11/fine-grained-access-control-for-amazon-dynamodb.html

セキュリティ的には現在のアプリサーバのように一つの権限で全ユーザの情報に
アクセスしてる方がリスクが高いという考え方もできなくはないしね

>>360
そうそう、世紀末くらいまではJavaに対しても>>359みたいな意見が普通だったよね
OSでいえばLinuxもそうだし、その前はWindows、更に前はUnixも基幹系では
使えないって意見が多数派だった
ハードでもPC(x86)サーバもUNIX(RISC)サーバも最初は同じ
それでも使う人達がでてくることでいずれ使えるようになってく
繰り返される歴史からはJSで基幹系作る日が来ないとはとても言えない
個人的に作りたいかどうかは別の話だがw

>>362
世界規模の決済系で使われてるってのは実績としてでかいよね

>>363
Dartがブラウザに乗れば一応それらに近いんじゃないかな

**デフォルトの名無しさん** · 2014/04/26(土) 21:42:46.56

あと動的言語かどうかはもちろん、生産性も基幹系で使うかどうかにはたいして影響ないよ
今基幹系で使われてる言語でもCやCOBOLは弱い片付けの言語だし生産性も高くない
それよりベンダのサポートとか人の集めやすさとか世界中で使われてる実績とか
技術とは無関係なところで決まりやすい(それを肯定したいわけじゃないが現実としてね)

**デフォルトの名無しさん** · 2014/04/26(土) 22:40:13.33

>>365
大規模開発での静的言語の優位性を否定するとかありえないわ

それとベンダサポートが重要なのはそのとおりだが
人気のある静的言語ほど大手のベンダーが関与してる割合が高い
C#もJavaもそう

動的言語はコンパイラ開発不要で個人レベルでも
作れるからOSSで言語が乱立する
頻繁に不要な仕様変更が入りメンテナンスコストが高くなる
開発生産性というのはバージョンアップなどのコストも含めての話

**デフォルトの名無しさん** · 2014/04/26(土) 23:26:36.12

>>366
優位性を否定してるんじゃなくて、その優位性が重要な要素とはならないって言ってる
まぁ、スレ違い気味だしわかれとはいわんよ

**デフォルトの名無しさん** · 2014/04/27(日) 00:08:06.48

>>363
silverlightやアプレットやってた人間からすると、それは絶対やだ。

**デフォルトの名無しさん** · 2014/04/27(日) 01:25:17.57

動的言語ってchar1単位で操作したりするの向いてないだろ
もうjavascriptを使うこと自体が目的化してるんじゃないか？

**デフォルトの名無しさん** · 2014/04/27(日) 01:33:26.98

>もうjavascriptを使うこと自体が目的化してるんじゃないか？

フロントエンド系やってる連中は、そんなことを目的にしてたら
デスマーチの深淵に落ちていくことくらいよく解ってるよ。
あいつらはいかに楽をするか自動化をするかってところが目的になってる。

「結果的」にブラウザ上でJavaScriptを動かすために
ローカルPCに仮想環境突っ込んでvagrant, chef, yoemanとかで
環境作って裏ではRubyが動いてたりもうカオス。
でもこの環境構築自体も今やコマンド一発とかそんな世界。

一部分では下手なサーバサイド開発よりも楽できる世界が構築されつつあるが
Webアニメーションとかやってる連中は相変わらず死んでるな。
Androidという魔物に挑んで力尽きていくやつらの亡骸が山積みだ。

**デフォルトの名無しさん** · 2014/04/27(日) 01:43:14.20

そもそもweb系でバイト単位の操作をすることはそんなに無い。
仮にそういうのを意識しないといけないことがあっても大体ライブラリでカバーできてるし。

**デフォルトの名無しさん** · 2014/04/27(日) 11:56:19.52

サーバ側でjavascriptを使うことがメルヘンなのだろう

**デフォルトの名無しさん** · 2014/04/27(日) 20:26:48.25

>>371
アプリケーション層で自由度の低い言語ってありえないだろ
構文解析コンテンツとか作れないじゃん

javascriptはかなり貧弱だから
頻繁に他の言語で実装されたプラグイン呼ぶことになる

そもそもjavascript自体が嫌われているのに
UI層と同じ言語を使いたいという動機だけではデメリットのほうが多いよ

**デフォルトの名無しさん** · 2014/04/27(日) 20:36:30.94

Google Apps scriptとか技術的にどこまで応用されるのか
見極めないといけないね。

**デフォルトの名無しさん** · 2014/04/27(日) 21:28:19.68

>>373
node.jsだとバイナリデータも扱うこともできるみたいだし、自由度が低いってことは無いと思う。
というか自由度を求めるんなら極端な話Cで全部書けばいいんじゃね？
用途とか目的とかコストとか考えた時、自由度はある程度切り捨てられるものだ。

サーバーサイドでnode.jsやらを使う利点は、学習コストが極端に低いこと。
なんせweb系やるならjavascriptはほぼ必須だから。

とはいえjavascriptで組みたくないってのは同意。

**デフォルトの名無しさん** · 2014/04/27(日) 22:23:43.64

TypeScriptいいよ

**デフォルトの名無しさん** · 2014/04/28(月) 09:43:29.05

altJS系の動きも、JSをサーバサイドで使うことより
もっと大規模開発に向いた言語でフロントエンドやりたいって人が多いと思う
結果的に1言語で十分になるならいいことかもしれんが

**デフォルトの名無しさん** · 2014/04/28(月) 14:01:38.33

ポストJSはDartが一番良さそうだけど（Javaのブラウザ用サブセット同然）
IEのシェアが圧倒的だから、googleの思惑通りにブラウザから
直に動かす言語としては普及させられない

代わりにMSがTypeScriptあたりをごり押しで普及させてくれれば良いのだが
あそこは相変わらず意味不明なことばかりに力を入れているな

**デフォルトの名無しさん** · 2014/04/29(火) 02:57:59.13

CoffeeScript, TypeScriptを仕事で使ってみて
結局素のJavaScriptとjQueryに戻ってしまった

**デフォルトの名無しさん** · 2014/04/29(火) 12:31:30.66

今のWebはごちゃごちゃ流行りものをやりすぎなんだよとしか言いようがないな。
大体どれも3年後、5年後には失笑されるような技術ばかり。

実験プロジェクト的なものがこの世に存在する意義はあると思うけど、
それらの拙速な製品への適用はほんと愚かだよ。

**デフォルトの名無しさん** · 2014/04/30(水) 03:20:47.67

ファッションやら家電に車とかで、今これがすごい！流行りはこれ！
みたいにブームを作って商売するのがこの界隈にも増えただけだと思うわ。
HTML5なんかまさにそれだと思う。
需要喚起って意味では良いのかもしれんが完全に手段が目的になってる気がする。
金稼げないと飯は食えんけどさ。

**デフォルトの名無しさん** · 2014/04/30(水) 03:30:41.63

Javaだってそうだったじゃん
Jakartaとかから次々と流行り物が出てきてJavaWorldなんかで特集されてみんなおっかけてたじゃん
Strutsだってそうやって流行ったものじゃん

**デフォルトの名無しさん** · 2014/04/30(水) 06:38:09.24

Javaも含めて言ってるんだろ

**デフォルトの名無しさん** · 2014/04/30(水) 08:39:19.02

土台となるjavascriptちゃんとしてればいいけど
phpがjavaの後追いしてるのと同じ不毛さを感じる

**デフォルトの名無しさん** · 2014/04/30(水) 09:10:41.01

例の脆弱性で、ようやくStruts1からの脱却が進みそうですな。

周りの人に聞いてみると、JavaEEが次のフレームワークのファーストチョイスっぽいね。理由は「標準」だかららしい。それじゃOracleの思う壺ですけどね（笑）

OpenSSLの事もあり、OSSのソフトウェアをなるべく避ける風潮が何と無く社内にあり、開発がやり辛くなりそう。

**デフォルトの名無しさん** · 2014/04/30(水) 10:10:27.63

今はJavaEEかSpringの2択のところが多いな。

**デフォルトの名無しさん** · 2014/04/30(水) 14:39:09.69

NEC製のオレオレフレームワーク使わされそう
ググったらオープンソースのフレームワーク組み合わせただけの糞なんだけど
これをIDEとして売り物にしてるっぽい。独自開発環境なんて開発工数減らすどころか増やすだけだろ
マジあほ

**デフォルトの名無しさん** · 2014/04/30(水) 17:48:30.62

その手の国産オレオレフレームワークって
たいていなんかの開発案件で使われたものを
「これ、ヨコ展開して製品化しよう！」とかって
上層部が思いついて出来上がる気がする

変にオープンソースをベースにしてたりするから
無駄な初期学習コストが出ちゃうのと何かあった場合に
コミュニティが蓄積してきたノウハウが使えなかったりして困る

**デフォルトの名無しさん** · 2014/05/04(日) 07:10:20.23

JAVAをつかったWEBアプリを作りたいなとおもっています。

JAVA標準Java EE 6で、JSF2.0を使えば楽にできるものなのかなとおもっています。
ASP.NETのUIコンポーネントモデルと似ているそうです。

今のところ、JSF（Java Server Faces）の話がないのはなぜですか。
JFS 1.Xは不安定らしいが、2は良いらしい。
http://gihyo.jp/news/report/2013/09/1901?page=2

なにかアドバイスがあればください。お願いします。

**デフォルトの名無しさん** · 2014/05/04(日) 09:48:13.90

>>389
サンプル作って比べるなり評価すればいいじゃん。
JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。

**デフォルトの名無しさん** · 2014/05/04(日) 09:55:34.05

>JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。

いや、このスレッドで、話が出ていないんすよ。
ctrl + f →JFS

**デフォルトの名無しさん** · 2014/05/04(日) 13:32:46.94

以前にＪＳＦの専用スレが立っていたはず。過去ログ探してみ

**デフォルトの名無しさん** · 2014/05/04(日) 13:36:42.43

あとWebProg板に関連しそうなスレが立っている。

Java EE part1
http://nozomi.2ch.net/test/read.cgi/php/1300634117/

**デフォルトの名無しさん** · 2014/05/04(日) 13:51:40.57

JSF2.0でprimefaces使うと確かに
簡単に結構リッチな画面が作れそう

ただJSFは仕組み上
サーバリソース食うんで利用者が多いような
サイトには向かない気がする

EE6だと
JAX-RSとjavascriptか
JSF2.0で画面作るんだと思う

前者は大変だがユーザー数だとか作り込む上で制約が少ない
後者はサクッと作れるが制約が多い

といったイメージ
間違ってたらごめん

**デフォルトの名無しさん** · 2014/05/04(日) 14:11:11.21

>>391
JSF2 は、ジェット戦闘機の時代に登場した、最強のレシプロ戦闘機っていう感じですかね。

JSF2 は、サーバ側で HTML を作る、Struts、JSF1、Tapestry、Wicket... などの旧来型の
Webアプリの集大成。
でも時代は、クライアントサイドで MVC が完結して、サーバーサイドは API に特化する
という方式に移りつつある。

移行コストが問題。従来型の Web アプリでいいなら、Servlet + JSP の延長線上にある
Spring MVC でいいかとなるし、どうせ新しいことを覚えなきゃいけないなら、
ExtJS + Rest API でやろうかねとなる。

**デフォルトの名無しさん** · 2014/05/04(日) 14:50:26.51

JSFって、戻るボタン押したらログイン画面に飛ばされる奴？

**デフォルトの名無しさん** · 2014/05/04(日) 15:09:02.38

以前SIerで企業や官公庁向けのWebアプリ開発の仕事してて
今はコンシューマ向けWebサービスの開発してるんだけど
SIerはほんと進歩が無いんだなと感じる。
もっとも、常に「枯れた（安定してる）技術」が重要視される
業界だから、進歩させる必要はないのかもしれないけど
開発者にとってはつまらないんじゃないか。

世間では叩かれまくってるソシャゲ屋なんかは、使ってる
要素技術や仕組み的にはけっこう最先端が多い。
どんどん新しいものを取り込んで実装していく。
不安定なものもあれば、すぐに廃れていくものだったりするんで
これはこれでリスキーだけど、サービス寿命は短いから
これでもいいんだろう。

**デフォルトの名無しさん** · 2014/05/04(日) 23:26:27.01

>>391
JSF 21レス/396レス
だが

**デフォルトの名無しさん** · 2014/05/05(月) 01:30:48.46

結局ここでJSFやらJavaEEもおっけーってことかな

スクリプトゴリゴリ書きたくないから
個人的にはJSF2に頑張って欲しい

**デフォルトの名無しさん** · 2014/05/05(月) 01:34:42.59

>>397
業務アプリにとっての「技術」は目的ではなく手段に過ぎないからな
目的が達成できるならレガシーな技術で十分
先端追いかけてくれる人たちがいるお陰で、周回遅れで安定した(枯れた)技術を採用できるとも思ってる
確かに技術屋には魅力はないだろうが、そういうもんだろう

**デフォルトの名無しさん** · 2014/05/05(月) 02:57:09.05

>>400

最新の技術に拘る訳じゃないが
新しい方が品質、生産性が高い場合もあるんじゃないかなぁ
学習コストっての問題はあるが・・・

**デフォルトの名無しさん** · 2014/05/05(月) 03:20:29.45

>>401
あると思う。
でも数多ある新技術がすべて宣伝通りのレベルに達しているかと言うと、期待はずれの技術もまた多いわけで
その辺はイノベーターさんやアーリーアダプターさん達の成果に頼ることになる

**デフォルトの名無しさん** · 2014/05/05(月) 10:46:41.45

JavaでいうとServlet+JSP以外信用できない
フレームワークは穴だらけ
新しいものは信用できない

**デフォルトの名無しさん** · 2014/05/05(月) 16:22:20.74

struts普及しすぎたせいで未だにstruts使ってるところ多い感じだ
ドヤ顔で独自フレームワーク開発してますとかほざいたくせにベースにstrutsとか寝ぼけてんのかよ

**デフォルトの名無しさん** · 2014/05/05(月) 23:41:08.23

strutsは普及しすぎたが故の脆弱性問題かね
OpenSSLといいIEといいこの手の話最近多いけど
他が安全っつうよりはマイナーなだけな感じ

ただオレオレFWが結局同じ問題を抱えてて
各々対処しないといかんのはダサいね

じゃあjavaEEなのかと言うとよくわからない
標準といえど旧EJBのような失敗作もあるし

**デフォルトの名無しさん** · 2014/05/05(月) 23:55:41.61

フレームワークは使ってるってだけでドヤ顔できるかな

**デフォルトの名無しさん** · 2014/05/06(火) 00:36:47.39

>>400
日本で業務系アプリやってる奴らは
周回遅れどころか10年以上遅れてるだろう
リリース後に1年もたてば十分に安定した技術になる。

ただ時代遅れで新しい技術についていけていないだけなのに
「枯れている」などという言葉で正当化しようとする

フレームワークの有り無しを論じていたり、Strutsがどうこうとか
日本だけ時間が15年くらい止まっている感じだな

**デフォルトの名無しさん** · 2014/05/06(火) 01:51:30.39

>>407
どうした？業務アプリに親でも殺されたのか？

**デフォルトの名無しさん** · 2014/05/06(火) 10:04:43.41

企業の場合、フレームワークにノウハウを詰め込んでる場合が多いから、土台が古くなってもなかなか変えられない。
下手に変えるとエラい目に会うからな。

**デフォルトの名無しさん** · 2014/05/06(火) 10:11:07.39

＞strutsは普及しすぎたが故の脆弱性問題かね
JSP系統全体の脆弱性じゃないの

Velocityとかで同じようなことは大丈夫なのかな

**デフォルトの名無しさん** · 2014/05/06(火) 12:34:59.61

OGNLとかBeanUtilsとか個別の要素のバグや仕様だから同じことしてたら問題はある

**デフォルトの名無しさん** · 2014/05/06(火) 15:00:56.09

欧米だと、業務系アプリでもどんどん新しい技術採用してるのにな
バックエンドはSpring+MySQLやnode.js+MariaDB、フロントはHTML5ベースで
backbone.jsやAngularJSにしてREST-APIで繋ぎ、サブシステム連携も充分とかさ

**デフォルトの名無しさん** · 2014/05/08(木) 20:14:41.32

>>393
プログラムとWebプログラミングとで板が分かれていたの知りませんでした。

>>394
JSF2.0は、MSのASP.NETみたいにできるそうです。
でも、MSはサービス運用でライセンスにお金が絡んで自由に使えないのでそんな技術は使いたくありません。
未来に自由をもたらすために、javaで行きます。

LAN内向けサービスなら使えそうですね。
リソースの問題も、今後JSFのバージョンがあがっていくにつれて改善されることを期待します。

>>395 >>399
>JSF2 は、... などの旧来型のWebアプリの集大成
今やJDKの標準技術になっているんですよね。

>JSF2に頑張って欲しい
同感です。

>クライアントサイドで MVC が完結して、サーバーサイドは API に特化するという方式に移りつつある。
余計に処理の流れが複雑になりそう・・
サーバの負担は軽くなりそうですね。

JFS2.0の書籍を大型の本屋に探しに行きましたが、一冊だけでした。
掌田津耶乃「EclipseではじめるJavaフレームワーク入門　第4版」が
JFS2.0を使ったプログラム例と詳細な解説が載ってました。

これ以外に、どうして売っていないのか不思議です。　（JFS2.0は、JDKの標準技術なのに。）
オイラリーのは、JSF1.0を対象に書かれていたので、対象外です。2004年初版でした。

**デフォルトの名無しさん** · 2014/05/08(木) 21:30:25.66

asp.netもasp.net MVCっていうサーブレットチックなものが主流になってる。

asp.netもjsfも柔軟性にかける割に生産性もそこまで高くないんだよね

**デフォルトの名無しさん** · 2014/05/08(木) 22:39:57.36

生産性が低いとは思わないけど、まあ、ぎょーむ屋さんがつまんねーLOBアプリをシコシコ作るの専用感はある。

**デフォルトの名無しさん** · 2014/05/09(金) 04:23:02.68

Struts2+Spring DIでStruts2のActionにDIするWebアプリケーションを作ってる。
このアプリの実行時に、DIされるべきフィールドがnullになっててヌルポが発生することがある。
アプリをコンパイルしなおしたらヌルポが発生する場所が毎回変わったりするので原因がよく
わからない。

Tomcatが利用できるメモリ容量を増やしたらヌルポが発生しなかったので、DIに必要な
メモリが足りないのが原因かと思ったんだが、そういうことってありうるのかしら？
みんなTomcatのメモリ容量はどのぐらいにしてる？

**デフォルトの名無しさん** · 2014/05/09(金) 04:36:52.76

>>414
asp.net MVCがサーブレットと同類のわけないだろ
お決まりの処理は最小限のコードで書ける
ASP.net MVCの生産性の方が圧倒的に上

>>413
掌田津耶乃の本はやめておけ
いろんな言語のフレームワークの本を書いているがどれも評価低い
内容が薄っぺらい、同著者のamazon レビューを見たほうがいい

＞これ以外に、どうして売っていないのか不思議です。

理由はJavaの技術は定番がなく分散してるから
膨大な時間をかけて本を書いても売れない、儲からない
日本語で書いたら日本人しか買わない
どうしても本で学びたければ英語で書かれたものを探したほうがいい

**デフォルトの名無しさん** · 2014/05/09(金) 04:41:29.70

>>416
いまさらStrutsとは

ヌルポにメモリが関係あるわけないだろ
物理メモリが足りなければ、HDD/SSDなどの仮想メモリが使われる

**デフォルトの名無しさん** · 2014/05/09(金) 05:03:29.99

>>418
うん、おれもStruts使いたくない。

やっぱ関係ないか。再現条件（ヌルポの発生場所）がころころ変わるんで悩んでる。
DIされるべきところがnullになるケースってなんかない？

**デフォルトの名無しさん** · 2014/05/09(金) 08:34:54.37

Spring使ってるのになぜStruts?しかも2とかありえねぇ。
馬鹿なの？アホなの？死ぬの？

SpringMVC使えよ。

**デフォルトの名無しさん** · 2014/05/09(金) 08:58:40.41

決定権無ければそれでやるしかないよね

**デフォルトの名無しさん** · 2014/05/09(金) 15:31:47.07

決定権がある人間が無能だと
こうやって現場が疲弊する見本だな

中途半端に要素技術を聞きかじってると
こうなるよな

**デフォルトの名無しさん** · 2014/05/09(金) 16:52:51.17

>>419 OutOfMemoryErrorをどっかで揉み消してるとか
>>418 PermGen上限を緩めてないなんてのはありがち

**デフォルトの名無しさん** · 2014/05/10(土) 09:12:05.20

>>420-422
お察しのとおり、途中から参加したプロジェクトなんで変えようがない。
Spring使うならSpringMVC使え、はもっともなんだろね。

>>423
MaxPermSizeを大きくするとヌルポが起きないので、そこかなーと思ってる。
OutOfMemoryErrorのもみ消しはしてないと思う。

**デフォルトの名無しさん** · 2014/05/10(土) 11:23:10.80

やっぱTomcat使ってるとこ多いよね

javaEE にするならTomEEでいいかな？

**デフォルトの名無しさん** · 2014/05/10(土) 11:50:16.02

Tomcatで十分だろ。意味わからん
オレオレアーキテクトのオレオレフレームとオレオレコンテナとか誰得だよ

**デフォルトの名無しさん** · 2014/05/10(土) 12:57:17.13

趣味ならなんでもおｋ

**デフォルトの名無しさん** · 2014/05/10(土) 13:05:01.57

将来が有望なWEBアプリのフレームワークって？

JFS2を推したいのだが・・・

他の技術では、HTMLを噛むのでコードが煩雑になりはしないかと躊躇する

**デフォルトの名無しさん** · 2014/05/10(土) 16:08:55.06

HTMLをサーバ側で作ってレスポンスに送り出すのか
サーバからは必要な情報だけJSONとかで取得して
ブラウザ側でDOM生成するかで何を使うかが変わってくるな

HTML自体の修正が必要な場合は、個人的好みとしては
後者のほうが修正から反映までの手間が少なくて好きだ。
サーバ側でやると、サーバ側もデプロイしなおしとかあるし

**デフォルトの名無しさん** · 2014/05/10(土) 16:18:20.94

最近は後者な流れじゃない？

**デフォルトの名無しさん** · 2014/05/10(土) 16:19:03.56

こいつ一昔前までseasar2押してたタイプだ

**デフォルトの名無しさん** · 2014/05/11(日) 15:40:23.86

>>429
>ブラウザ側でDOM生成する

せっかく、ASP.NETは、サーバー側で要求を受け付けて処理してHTMLを出力するうまい方法（抽象化されたサーバコントロール）を、
実現していたのに（JFS2みたいに）、今からはブラウザ側がHTMLを自分で作成するのですか。

ブラウザ側でHTMLをコントロールするタイプなら、
何が推しですか？

そういうタイプWEBアプリって、サーバーは基本的なプログラムとデータをクライアントに提供して、
クライアントがその基本的なプログラムを処理することで適切なHTMLを自分で組み立てる感じでしょうか。

**デフォルトの名無しさん** · 2014/05/11(日) 15:55:27.33

>>432
ブラウザ側でいろいろやるのは別に良い方法というわけじゃないよ

ただJavaの世界ではサーバサイドのフレームワークが
ろくでもないものばかりだから、そういう開発をやる人が出てきただけ

ASP.netやASP.net MVCに比べると開発に時間もかかるし
ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
セキュリティも低下する

**デフォルトの名無しさん** · 2014/05/11(日) 20:28:02.82

>ASP.netやASP.net MVCに比べると開発に時間もかかるし
>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

いまどきの大手SIerって、こういう時代遅れタイプで占められてるんだよな
だからStruts1が幅を効かせてきたわけだ

**デフォルトの名無しさん** · 2014/05/12(月) 00:07:44.85

>>433
>ただJavaの世界ではサーバサイドのフレームワークがろくでもないものばかりだから
>（ブラウザ側でいろいろやる）そういう開発をやる人が出てきただけ

結局は、消極的な理由なんですか。

近年のクライアントのパワーが上がってきたことと、
サーバーの負担を減らすために、クライアントサイドでhtml構成作業を行うようになったのだと思っていた。
あと、ポストバックをなくすために。

>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

ブラウザ環境で意図した動作をしないというのは困りものだな。

うーむ。
だったら、サーバーサイドのフレームワークとして、JFS2.xに期待するなあ。
なんだって、JDKの標準機能に組み入れられたのでしょ。
JFS2には将来性があると思う。

**デフォルトの名無しさん** · 2014/05/12(月) 00:09:39.92

>>417
>理由はJavaの技術は定番がなく分散してるから
>膨大な時間をかけて本を書いても売れない、儲からない
>どうしても本で学びたければ英語で書かれたものを探したほうがいい

JAVAって、いろいろ分散していて、いったい何が標準なのかぜんぜんわからないですものね。
JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
今後は、日本語で書かれた書籍も増えてくるかもしれないですね。

ほんと、期待しています。

ASP.NETはいいんだけど、運用保守にお金がお金がかかるかかる。ライセンス問題が非常にやっかい。
MSのご機嫌取りしなきゃいけなくなる。アプリの運用を人質にされて、MSに振り回されるのは勘弁。
なので、ASP.NETは将来を見越したら、取り組みたくないんだなあ。

**デフォルトの名無しさん** · 2014/05/12(月) 00:23:29.96

>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。

一応、そのあたりの差異を吸収することも目的の一部に含むのが
jQueryのようなJSのフレームワークなわけで
サーバーサイドの人間は何かというとJSを目の敵にするけど
どちらも使えたほうが、この先業界内で生き残っていける確率は上がるでしょ

企業的には「フルスタックエンジニア」なんて名前の便利屋や何でも屋を
求めるようになってきてるし。

**デフォルトの名無しさん** · 2014/05/12(月) 00:40:16.62

どうでもいいが「JFS」じゃなくて「JSF」な
JavaServer Faces（JavaとServerの間は空けないのがお約束）

**デフォルトの名無しさん** · 2014/05/12(月) 00:42:07.47

>フルスタックエンジニア

それでも、htmlやJAVA SCRIPTを触らなくても良い、高度に抽象化された一元的プログラミングをしたい・・・

**デフォルトの名無しさん** · 2014/05/12(月) 00:43:03.15

>>438
ありがとう

**デフォルトの名無しさん** · 2014/05/12(月) 01:00:32.81

>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。
というかバージョン変わったりブラウザが変わったりすると動作しなくなる可能性があるのはJAVAでも同じことだと思うけど違うの？

**デフォルトの名無しさん** · 2014/05/12(月) 01:14:18.80

>>441
Webアプリでクライアント側のJREは使わないでしょ
サーバサイドでJavaだから、サーバ側のアップグレードしなければ
バージョンアップのエラーは出ない

ブラウザ側でJSを多用するWebアプリは、ユーザのブラウザの種類や
バージョンに依存するようになってしまう

これはJSじゃなくてHTML/CSSの互換性の話だけど
XP時代にIE6用に設計した業務システムを作ってしまい、
悲惨な目にあった企業はたくさんあるのは有名な話。
OSのアップグレードやPCのリプレースもできなくなった。

クライアントブラウザの指定がしやすい業務システムであっても
なるべくサーバサイドでやるほうがあとあと問題は出にくいと思うよ

**デフォルトの名無しさん** · 2014/05/12(月) 01:20:14.46

>>442補足しておくと
ブラウザバージョンアップでレイアウトの崩れ程度は起こる可能性は
どの技術でもありうるけど、ブラウザ側でJSを使わなければ
エラー吐くような事態にはならないから新バージョンへの対応もしやすいということ

DartはもうIE9のサポートを打ち切ったらしい
ブラウザのバージョンアップですぐに動かなくなるようではだめだ
DartはJavaScriptに変換する言語ね

**デフォルトの名無しさん** · 2014/05/12(月) 01:27:57.76

>>442
ちょっとよく分からない。
サーバーサイドですべて出力するにしろ、ブラウザで動作するものを作るわけだよね？
JREで動作させるものじゃないとすると、結果はHTML出力とかになると思う。
だったらブラウザが新しくなったら動作しなくなるとかあるんじゃないの？

**444** · 2014/05/12(月) 01:30:28.95

>>443
見てなかった済まない。
しかし昔の業務用アプリならともかく、最近のものでJavascriptを一切使わないってありえないと思うんだけどな。

**デフォルトの名無しさん** · 2014/05/12(月) 01:41:02.37

>>445
このスレは昔ながらの業務アプリしか作らなくて済んでる化石のようなエンジニアの巣窟なの

**>>53** · 2014/05/12(月) 01:47:49.33

サーバー側で要求を受け付けて処理してHTMLを出力する方式は
wicketでもjsfでもセッション多用でレプリケーションの同期が多発
Playがセッション使わせたくないのもこの辺が原因でしょ

**デフォルトの名無しさん** · 2014/05/12(月) 02:04:03.42

>>445
一切使わないなんて言ってないんだけどな
>>442でも「なるべくサーバサイドでやる」とはそういう意味だ

>>446
業務アプリでJSが必須の機能少ないけどな
どういう機能か言ってみなよ

ユーザデータチェックのValidationではJS使うけど
業務アプリでJSでしか実現できない機能を求められることは少ない

**デフォルトの名無しさん** · 2014/05/12(月) 03:22:01.12

>>448
いやまあそれ言っちゃうとJSのほうだってなるべくHTMLは書くようになると思うよ。
JSが受け持つ範囲は多くなるけど。
全てのデザインをJSで組むっていうのはまずありえないかなと。HTMLで書くほうが早いし簡単だし。

あと>>446への返信に横入り。
「業務アプリ」で「最低限の機能」しか求められることが少ないって書いてあるけど、それって反論じゃなくて、
書いていることに対して認めているように見えるけど良いの？

**デフォルトの名無しさん** · 2014/05/12(月) 10:18:24.45

そもそも業務アプリなんかWebでやりたくねぇわ

**デフォルトの名無しさん** · 2014/05/12(月) 10:37:30.53

>>436

> JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
> 今後は、日本語で書かれた書籍も増えてくるかもしれないですね。
>
> ほんと、期待しています。

JSFが何年も前の1のころからJ2EE (いまで言うJavaEE)の標準になっていたが、結局流行らなかった。

流行るものは、結局標準化どうかではなく、そのプロダクトが使いやすいか(いいものか)どうかなんだよ。

**デフォルトの名無しさん** · 2014/05/12(月) 12:03:24.64

標準だとしてもOracleだぜ？
何だかんだ言ってもMSの方がマシだろ

**デフォルトの名無しさん** · 2014/05/12(月) 17:15:35.33

すれち

**デフォルトの名無しさん** · 2014/05/13(火) 22:10:38.32

酷い製造現場に入っちまったわ
少なくとも6年以上は前のフレームワークを使って色々やってるんだが
雛型作り上げるまでのプロセスがむちゃくちゃ

**デフォルトの名無しさん** · 2014/05/14(水) 02:03:31.02

6年前って2008年か… マシな方じゃね？
10年前のJ2EEで止まってる方が酷いと思うわ

**デフォルトの名無しさん** · 2014/05/17(土) 00:35:29.68

技術の蓄積が云々でStruts1

**デフォルトの名無しさん** · 2014/05/17(土) 02:08:09.45

Struts1内臓の自社製フレームワークだ

**デフォルトの名無しさん** · 2014/05/24(土) 10:45:14.85

http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/9/

**デフォルトの名無しさん** · 2014/05/24(土) 18:26:53.21

GWTとかVaadinって意外と使われているのね
Vaadinはそのうち開発頓挫しそうな空気だけど

**デフォルトの名無しさん** · 2014/05/25(日) 20:03:15.10

結論：Flexでおｋ

**デフォルトの名無しさん** · 2014/05/28(水) 00:27:43.53

GWTが流行るか、javascriptがdartに進化するべきだった
半端なJSフレームワーク乱立とか糞すぎる

**デフォルトの名無しさん** · 2014/05/28(水) 03:27:10.38

なんかもう

フロントコントローラ　：　Jersey + 好みのDIコンテナ
テンプレートエンジン　：　お好み（Thymeleafがよさげ）
DB　：　スクラッチ、ヘルパーライブラリ、ORMお好み
フロントエンド　：　軽量のMVCFWお好みで

こんな感じでいいような気がしてきた（想像）
上手く設計できれば結構いい感じにできそう（想像）

今はWebはPythonとかLL中心でアプリはAndroidやってるからJava資産活用できるしWebもJavaでやりたいって
上に言ってはいるけどなかなか通らない。

Java Web Application Framework総合 ver2

Java Web Application Framework総合　ver2