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/03/16(日) 06:38:36.02

Oracle使った時SQLは全部ストアドに書くとかやったことあるわ
SELECTのReturnはXML
あれもある意味O/Rマッパーなんだろうか

**デフォルトの名無しさん** · 2014/03/16(日) 09:03:49.32

SQLをまったく意識しなくてよくなるようなまっぱができれば使いたいが

**デフォルトの名無しさん** · 2014/03/16(日) 09:17:10.22

O/Rマッパー黎明期から期待に胸を膨らませて追っかけてきたけど
保守段階までトータルで見ると、少なくとの日本の人月ベースで
コスト計算する業界では見合わないと思ってる。

初期HibernateのHQLなんかも設計思想はものすごく好きだった。
Torque、Castorなんかも試した。Torqueはクラス数が爆発しがちで
仕様がコロコロ変わる案件で地獄をみた。
Cayenneも良かったな。旧NeXT製のEOF(Enterprise Object Framework)
なんかの流れを彷彿とさせる設計は美しかったが、
日本ではマイナーで使える技術者が育たず広がらなかった。

とはいえ、素のJDBC使うのはめんどいし、もはやS2系は死んだ。
個人的に残された希望は枯れたMyBATISくらいかな。
SQLの透過性とシンプルにも使えるO/Rマッピングの融合がバランスいいよ。

**デフォルトの名無しさん** · 2014/03/16(日) 09:28:37.06

業務アプリなんかだと結局メイン部分はパフォーマンスや
堅牢性が大事になってきてSQLで書かないといけない。
まっぱが使えるのはマスタメンテくらいになる。
マスタメンテくらいのSQLなら別に複雑でもないからまっぱにする意味もない。
つまり使い道が無い。パフォーマンスや堅牢性も備えてはじめて使えるようになる。

**デフォルトの名無しさん** · 2014/03/16(日) 09:48:24.48

だよな。複雑なビジネスロジックをオブジェクト操作で
動的にSQL作るような仕組みだと、仕様変更とかバグ修正の場合に
マジックハンドでモノを掴むみたいな感じになるよ。
SQLならものの数分で終わるような対応が丸一日かかったり。

ただ、O/RマッピングとSQLの動的生成は違うものだから
ここは混同しちゃいかんな。
生JDBC使ったって最後はbeanにマッピングされるわけだし。

**デフォルトの名無しさん** · 2014/03/16(日) 10:12:47.25

JPAは再帰処理がないのが不満に思えたが
昨今の大規模環境ってJOIN禁止ルールとかあるみたいだし気にしなくていいのかな？

**デフォルトの名無しさん** · 2014/03/16(日) 17:26:09.65

JOIN禁止ってマジ話？
そんなプロジェクトに放り込まれたらプロマネ殴り倒す自信あるよ

**デフォルトの名無しさん** · 2014/03/16(日) 18:32:30.12

一部のコンシューマーサービスにおける設計の話を一般論扱いされても。
それにむしろ、そういうケースではMicro-ORMだろうし。

**デフォルトの名無しさん** · 2014/03/16(日) 18:53:19.88

指定数表以上の結合禁止、右外部結合禁止は見たことあるが、
結合そのものを禁止しているところは見たことないな。

**デフォルトの名無しさん** · 2014/03/16(日) 19:00:58.43

まあ将来的には結合なんてしなくてよくなるのが理想だよ。
だからまっぱは理想なんだけど今のハードではまだまっぱには無理がある

**デフォルトの名無しさん** · 2014/03/16(日) 19:36:35.66

逆だろ、将来的にはいくら結合しまくっても性能が劣化しないのが理想だよ

**デフォルトの名無しさん** · 2014/03/16(日) 19:41:36.95

結合時の性能劣化がなくなるよりも先にＲＤＢが廃れそうだなｗ

**デフォルトの名無しさん** · 2014/03/16(日) 19:44:29.10

え？結合なんかしたらSQLみたいじゃん

**デフォルトの名無しさん** · 2014/03/16(日) 19:53:56.08

抽象度が高くかつ表現力のあるマッピングAPIが、現状の言語仕様やHW的な限界で現実的ではないという話と、
リレーショナルモデルを相手にする以上、結合を考えないなんて意味がない話だし、本質的に性能劣化は発生する
みたいな話が混在してね？

**デフォルトの名無しさん** · 2014/03/16(日) 23:08:47.31

ソーシャルゲーム業界だと、たいがいJOIN禁止だな
詰めSQLやるようなチューニングはしない
大規模構成のMySQLをmemcachedとあわせてKVS的に使ったりって感じ
大規模にサーバまたいでデータ結合やったりするからJOINなんか使ってたら
保守できなくなる

**デフォルトの名無しさん** · 2014/03/17(月) 03:54:31.81

ORM使いにくいって感じる状況、ORMへの知識不足が原因じゃなけりゃ、
大元のDB設計とかがいまいちだったりする感じのこともけっこうありそうな

そもそも、言うほどパフォーマンスに問題が合ってSQL書かないと行けないような自体って起きるかなぁ
そういうのって、どっかうまいこと作れてないか、
体感できない性能差を突き詰めたいだけでチューニングを行なってる人かのどっちかってことも少なくない気がする

**デフォルトの名無しさん** · 2014/03/18(火) 02:18:31.77

ORMはEager fetch, Lazy fetchの問題を解決不可能なんだよ

**デフォルトの名無しさん** · 2014/03/18(火) 09:36:03.49

>>277
DB設計が大元ってｗ
ORMを理解してないのはお前だろ
ORMを使う動機はドメインモデルをRDBに永続化することなのに
なんでDB設計が先にくるんだよアホかｗｗｗｗ

ていうかみんなわかってなさすぎｗ
テーブルモジュールで設計していながらORM語ってんだろ？ｗｗ

**デフォルトの名無しさん** · 2014/03/18(火) 11:18:48.08

>>279
世の中の全てがモデルファーストでシステムを全て作れるわけではないし(そんなの本当に新規開発だけ)
パフォーマンスのために非正規化したりテーブル設計を崩すこともある

他システム連携があったりすると、そのDBにアクセスしてくるのはJavaだけとは限らない

もうちょっと世の中でいろんな経験をしてごらん。
見えなかったものが見えてくるよ

**デフォルトの名無しさん** · 2014/03/18(火) 16:21:01.00

次の仕事でPlay使うかもしれんとここ数日予習してるんだけどさ、
何か凄いstaticだらけで違和感覚えるんだが、
これはこういうものだと思って慣れるしかないの？
テストとかしずらくね？

工夫すれば一応DI使えるみたいだけど、entity注入するのはそれはそれで変な気もするし…

**デフォルトの名無しさん** · 2014/03/18(火) 19:40:51.38

常に新規開発でDBを好き勝手やれるならそもそもこんな話してないわ
システムリプレイスするけどDBはそのままとか
DB設計は他社とかそんなんばっか

>>281
Playはそういうもんだと諦めたまえ

**デフォルトの名無しさん** · 2014/03/18(火) 21:02:44.46

>>282
サンクス。気にはなるがやっぱフレームワークの流儀に従うべきか…。

**デフォルトの名無しさん** · 2014/03/23(日) 16:44:03.33

Javascriptに対してGAEができるなら
ORMにも似たようなのないの？

**デフォルトの名無しさん** · 2014/03/23(日) 16:44:45.76

間違えた！　GAEではなく、GWTです。

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

HSQLでfunctionつくるの楽しいわ

**デフォルトの名無しさん** · 2014/03/27(木) 10:11:37.22

プログラミング言語「Hack」登場 - 米Facebookが発表
http://news.mynavi.jp/news/2014/03/24/416/

動的な型付け言語がもたらす開発の手軽さと、静的な型付け
がもたらすエラーチェックの完全性の高さなどの双方の利点を
得ることを目指して開発されているという。

これはJavaより有望かもしれない

**デフォルトの名無しさん** · 2014/03/27(木) 13:18:35.80

ああほんと。電動歯ブラシぐらいのエロティシズムを感じるよ
Oculusなんて買収して、どんなイノベーションを見せるんだろうね

**デフォルトの名無しさん** · 2014/03/27(木) 22:05:13.54

所詮はペチパーだろ

**デフォルトの名無しさん** · 2014/03/28(金) 12:49:21.10

PHPのDartみたいなもんじゃん。糞杉ワロタ

**デフォルトの名無しさん** · 2014/03/29(土) 17:52:04.29

Javaのスレとしては、というかPHPのスレ以外もれなくだと思うが
まずPHPをベースにするのをやめろと言わざるを得ない

**デフォルトの名無しさん** · 2014/03/29(土) 19:25:52.45

facebookが内製用に使うぶんには有効なんだろうけど
こういうのって外部の開発者が採用しても
大抵の場合はメリット出ないよね

**デフォルトの名無しさん** · 2014/03/30(日) 17:09:49.38

CGIレンタルサーバーの都合(安さ)を考えて
Java, C#をベースとした言語から => PHP, Perlに変換するとか
そういう話ではないんだね

**デフォルトの名無しさん** · 2014/04/11(金) 23:22:52.67

Seasar2を使ってるところってもうないの？
新規案件ではSeasar2は選択肢にも入らないのでしょうか？

**デフォルトの名無しさん** · 2014/04/11(金) 23:35:33.19

そんなもん使うぐらいならStruts使えって言われる

**デフォルトの名無しさん** · 2014/04/11(金) 23:49:08.61

Seasarプロジェクト自体がもうオワコンだしねぇ。
今後を見据えたら、Java8でSpringでしょ。

**デフォルトの名無しさん** · 2014/04/12(土) 00:10:02.61

Playだ、Playを使うんだ

**デフォルトの名無しさん** · 2014/04/12(土) 00:14:19.11

Freemarkerもなかなかいいよ。

**デフォルトの名無しさん** · 2014/04/12(土) 01:02:21.33

出来が良い悪い以前に日本のプロダクトは長続きしないな

**デフォルトの名無しさん** · 2014/04/12(土) 01:18:14.99

支える人が少ないからな

**デフォルトの名無しさん** · 2014/04/12(土) 08:35:02.06

この記事最近のだけど今頃脱Strutsとか言っててちょっとポカーンなんだが
保守作業とかならわかるが新規プロジェクトでいまだにStruts1.x系選択するところとかあんの？
SAStrutsっていうならわかるけど書いてないし
ttp://gihyo.jp/news/report/2013/09/1901?page=1

Seasar2ってORMデフォルトでついてるからなんだかんだ言って開発しやすい

**デフォルトの名無しさん** · 2014/04/12(土) 10:07:33.97

新しいフレームワークは分からんとか言われて去年Struts1.3で作らされた

**デフォルトの名無しさん** · 2014/04/12(土) 11:05:52.31

脱Struts→HTML5

SIer的には物凄くハードル高いと思うよ。
HTML5と一口に言っても、その意味が内包している
要素技術って膨大だからな。

これからはHTML5だ！と鳴り物入りで一度は方針転換したのに
サーバーサイドでHTML生成するような実装してた開発者が
クライアントサイドでDOM生成する実装に馴染めず
結局モトサヤでStruts使い続けてる会社いくつも知ってる

バックエンド開発とフロントエンド開発で体制分けたのはいいけど
コミュニケーションロスやお互いの作業待ちでスタックしまくる
プロジェクトとかも。

プロジェクト管理や設計のやりかたが今までと同じで
それを変えられないってのがうまくいかない最大の要因な気がする。

**デフォルトの名無しさん** · 2014/04/12(土) 11:09:01.50

業務アプリごときJSF2で困ることがない

**デフォルトの名無しさん** · 2014/04/12(土) 11:58:38.19

まぁそれも１つあるよな。
業務アプリに見栄えのするUI/UXの必要性なんて
そもそもユーザーが求めてないわけだし。

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

ほんそれ
客にオナニーみせつけんなって話し

**デフォルトの名無しさん** · 2014/04/12(土) 19:48:03.14

JSF2とSpringMVCなら後者で

**デフォルトの名無しさん** · 2014/04/12(土) 20:35:30.10

用途によるよ。
業務アプリと一口にいっても、グリッドとフォームだらけのLOBアプリならJSFで良いし、
それとは別に情報ポータル/分析系みたいなものもあって。
後者については実際ソーシャル系みたいなニーズが求められるから。

っとSI屋で後者をメインにやっている人より。

つーか、前者みたなものをシコシコ作っていて、何が楽しいんだと思ったりはする個人的な意見ですが。

**デフォルトの名無しさん** · 2014/04/12(土) 21:16:25.65

前者みたいなの作ってて楽しくもなんともないけど仕事あるだけマシと思ってる

**デフォルトの名無しさん** · 2014/04/12(土) 21:20:03.72

俺も楽しいことは趣味でやってる

**デフォルトの名無しさん** · 2014/04/12(土) 22:27:17.38

仕事

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

JSFはブラックボックス

**デフォルトの名無しさん** · 2014/04/13(日) 12:09:15.45

動けばいいのよ
保守するのは自分じゃないし

**デフォルトの名無しさん** · 2014/04/13(日) 12:46:33.29

やっぱり今から勉強するならspringが無難だよね。

**デフォルトの名無しさん** · 2014/04/13(日) 17:12:24.83

>>313
お前、お前みたいな奴が、お前な、マジでお前
お前ーー！

**デフォルトの名無しさん** · 2014/04/13(日) 19:33:38.13

仕事だからとか、意外とみんな真面目なんだな。

**デフォルトの名無しさん** · 2014/04/13(日) 22:52:01.73

http://gihyo.jp/news/report/2013/09/1901?page=2

>>301の記事に２つの方法が書かれているけど
それぞれのメリット、デメリットはどういう感じなの？
「次世代型」はJavaScript有効化必須として
開発の生産性はどちらのが上？

「Oracleエバンジェリストの寺田氏は，Java標準によるWeb開発を，
次世代型と従来型の2種類に分類しました。

次世代型：クライアントとサーバ間をデータのみで通信し，画面の
生成から表示までをクライアントで行う方式。
従来型：サーバ側でデータを埋め込んだ画面を生成し，クライアント
では表示のみを行う方式。」

**デフォルトの名無しさん** · 2014/04/14(月) 00:44:17.72

>>317
次世代型って>>303みたいなの？
今の時点での生産性なら従来型じゃね
次世代型とか慣れるのに苦労しそう

**デフォルトの名無しさん** · 2014/04/14(月) 00:47:17.09

>次世代型：クライアントとサーバ間をデータのみで通信し，画面の
>生成から表示までをクライアントで行う方式。

Oracleの中の人ですら、まだこんなこと言ってんだもんな。
認識の周回遅れも甚だしい。
そりゃ日本のSIerが斜陽産業化するわけだわ。

**デフォルトの名無しさん** · 2014/04/14(月) 00:48:12.31

>>319
じゃあ本当の次世代型は？

**デフォルトの名無しさん** · 2014/04/14(月) 00:49:40.99

>>318
>>317のURLに書いてある「次世代型」。

生産性が低いなら海外で人気になったりしないと思う
なんで日本だけStruts使ってる化石企業ばかりなんだろう

両方とも経験ある人の意見が聞いてみたい。

**デフォルトの名無しさん** · 2014/04/14(月) 00:50:10.04

XML+XSLTで昔からできたのに全然普及しなかったな

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

>>320
Oracleの中の人の認識だと、まだajax使ったREST+JSON止まりなんだろう。
もうすでに、pjax+pushStateがメインで、今までのjsonベースの仕組みは
補助的に使う感じの動きになってきてる。

特にクライアントがモバイルの場合、SPA構成だとpjax+pushStateにしないと
いろいろ画面遷移周りの実装が複雑になりがちだし、
業務アプリ以外の外向けWebサービスなんかの場合は、サーバからJSONだけ
返してもらってクライアントでDOM生成する設計だと、SEO対策的にも高コスト。

とはいえ、イントラ系業務システム限定なら、REST+JSONでも何ら問題ないけど
だったらStruts1.x（）でもいいだろって話になる

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

pjaxも所詮RESTじゃん
JSFと違ってJAX-RSにVIEW実装なんて定義してないぞ

**デフォルトの名無しさん** · 2014/04/14(月) 02:26:03.09

次世代型って要はAjaxとJQueryでUI手書きかGWTってことでしょ。
旧来型には、javascriptを隠蔽するJSPタグライブラリとか
Wicketコンポーネントなんかがこちらに含まれるのかな。

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

>>323
元々PushState + Ajax = Pjaxじゃねーの？
そのPjaxにもう一回PushState加えるってどういうことだよ？w

**デフォルトの名無しさん** · 2014/04/14(月) 18:51:03.43

10年前からメンテしてるサイトは素のServlet/JSPで作ったが
流行に乗ってstrutsとか導入しなくてよかった。
長期開発・運用だと技術スタックは小さいほどいいね。
仕事だと「最新の開発手法」とやらの圧力が高くて抗えないけど・・

**デフォルトの名無しさん** · 2014/04/14(月) 19:02:38.25

Servlet使ってるところのソースは大抵糞コードだから読まされる立場だとうんざりするけどな

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

このスレっていつもループしてるよね・・・
適当に上の方へ戻っても話がつながって読める

**デフォルトの名無しさん** · 2014/04/14(月) 21:13:37.20

まったくなｗ

**デフォルトの名無しさん** · 2014/04/15(火) 00:54:06.51

>>325
jQuery手書きは旧世代だね。
AngularJSはjQuery使わないし、Backbone.jsでもテンプレートエンジンや
Marionettoとかのプラグイン使えばjQueryは隠蔽されるのが現世代。
AngularJSやBackbone.js使えば意識するまでもなくPushStateも使われるんだが、
>>323は何を次世代だと言ってるんだろうか？
ブラウザ側から見た新世代はWebComponents抜きには語れそうにない。
SEO含めた取り組みはRendrのやり方が新世代になりそう。

**デフォルトの名無しさん** · 2014/04/15(火) 01:04:58.06

Oracleの人は立場上、自社のJava EE7を推したいわけでしょうから
Java EE7標準を使った開発が、オラクルの言う「次世代型」でしょう

>>323
＞だったらStruts1.x（）でもいいだろって話になる
よくないでしょう
>>301の記事内でも指摘されているように
セキュリティ上の理由で、メンテナンス終了したStrutsはもう新規に使えない。

>>331
Javaはいろいろやり方があってわけがわからないよ
その辺の新しい開発方法をわかりやすくまとまめてあるサイトや本は
ありますか？

**デフォルトの名無しさん** · 2014/04/15(火) 01:16:41.62

phpだとcakephpが個人・学生から企業まで定番化してるっぽいけど
jsf2とかspringmvcがその地位には立てそうにないなー

**デフォルトの名無しさん** · 2014/04/15(火) 01:26:31.68

>>332
わけがわからないのはJavaじゃなくてJavaScriptのことだと思うけど、
とりあえず一つ追っかけるなら、今だとAngularJSがいいんじゃないかな。
読んでないけど日本語の本も一つ出てるし、来月にはオライリーの翻訳本も出る予定。

**デフォルトの名無しさん** · 2014/04/15(火) 01:56:57.27

JavaScriptは、後から後から話題になる要素技術がどんどん出てきて
トレンドが変わっていく
アメリカではそういうの自分たちでどんどん作って送り出すけど
日本じゃそれを表向きはドヤ顔で、内心ヒーヒー言いながら追いかけて
疲弊するだけ
不毛すぎる

**デフォルトの名無しさん** · 2014/04/15(火) 02:22:34.80

そろそろ表向きドヤ顔もできない感じになってきたわ
Webアプリやりたくねぇよ

**デフォルトの名無しさん** · 2014/04/15(火) 07:34:40.23

Web系はドヤってなんぼだろw
黙々と作業だけしてたら底辺臭が滞留してきちゃうからね

**デフォルトの名無しさん** · 2014/04/15(火) 08:14:59.36

去年辺りまではbackbone.jsがオススメされて
今年はAngularJSがはやってるよね
来年はまた別のものが流行して
再来年にはまた別のトレンドが来る
一貫してるのはなんだかんだでjQueryがデファクト

**デフォルトの名無しさん** · 2014/04/15(火) 15:28:26.34

ドヤ顔で講釈垂れてもな・・・
職場の人間は正直だと思うぞ

**デフォルトの名無しさん** · 2014/04/15(火) 20:31:58.52

最近の流行はJsViewsじゃないの？

**デフォルトの名無しさん** · 2014/04/16(水) 01:13:38.68

>>335,338
Javaも以前は同じだったじゃん
2000年にStruts 1.0とTapestry 1.0、2001年にWebWork 1.0、
2003年にJSF 1.0、2005年にWicket 1.0、2006年にClick 1.0…
ORMやDIコンテナも含めるとあの頃のJavaは今のJSよりもいそがしかった気がするけどな。

あとアメリカ人がみんな「自分たちで送り出す」なんて思ってないだろう。
ひがやすをがSeasar2を出したからって日本人がみんなそう思わないのと同じで。

**デフォルトの名無しさん** · 2014/04/16(水) 01:13:43.98

jQuery以外はdartでも触ってたほうが良さそう

**デフォルトの名無しさん** · 2014/04/16(水) 01:15:52.69

ひがやすを & やねうらをは兄弟らしい

**デフォルトの名無しさん** · 2014/04/19(土) 04:47:43.50

こういうの見ると、継続的なサポート力というのは重要だなあと。
5年後はすたれてそう・・みたいなフレームワークへの依存は避けたい・・

Apache Struts2 脆弱性に注意、IPA
http://news.mynavi.jp/news/2014/04/18/139/

**デフォルトの名無しさん** · 2014/04/19(土) 09:22:13.99

Struts2は後年にフレームワークの歴史における失敗作として語り継がれそう
やはり兄より優れた弟など存在しないんだ

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

Struts3ってどうなったんだ？

**デフォルトの名無しさん** · 2014/04/19(土) 12:31:51.21

正直もうJava EE一本化でいいんじゃないのか
標準だからStrutsやSeasarみたいに数年でオワコンにはならんし

**デフォルトの名無しさん** · 2014/04/19(土) 21:06:21.46

アクションベースのWeb FW、モダンなテンプレートエンジン、Micro-ORM
…を熟れるレベルまで標準化してくれるなら、そしたらEEでも良いよ、
っという意見は昔からあるけどな。

**デフォルトの名無しさん** · 2014/04/22(火) 20:51:03.30

NodejsやAngularJS使っている開発でyeoman入れている人いる?

**デフォルトの名無しさん** · 2014/04/23(水) 21:47:01.86

例えば、Strutsを避ける
http://www.scutum.jp/information/waf_tech_blog/2014/04/waf-blog-036.html

Struts2は根本的設計がまずかったり今のメンテナにとって
やる気のでないプロダクトだったりって状態なのかねえ
SIerが貢献することもなく使い続けて情報漏洩しまくらないといいが

>>349
JSの話題はここでは返事もらえないと思うよ

**デフォルトの名無しさん** · 2014/04/24(木) 01:22:07.08

node.js使ったサーバーサイド開発やってるのに
未だにJavaとJavaScriptの違いが解らないアホがいるってのが驚きだわ

**デフォルトの名無しさん** · 2014/04/24(木) 01:26:25.43

>>350
そのエントリ書いた人、StrutsとStruts2は全くの別物だってことと、
Struts2は少なくとも日本じゃポピュラーじゃないってことを知らなさそう

**デフォルトの名無しさん** · 2014/04/24(木) 22:11:08.66

今更?。Struts2は出た当初から致命的な脆弱性がある欠陥品だと言われていたでしょ。
MBSDで暫定的なものであるが、サーブレットフィルタのソースコードを公開したよ。
http://www.mbsd.jp/img/testFilter.java

**デフォルトの名無しさん** · 2014/04/24(木) 22:42:18.68

最近、JavaEEやspringMVCからJavascriptへ
トレンドが移行している印象を受けるね。

JavaSE8もあまり話題にならないけど、どうなの?

**デフォルトの名無しさん** · 2014/04/24(木) 23:17:35.98

【IT】サイト構築ソフト・ストラッツ1(Struts 1)に欠陥　パッチなく官公庁などサイバー攻撃の恐れ [4/24]
http://ai.2ch.net/test/read.cgi/newsplus/1398347971/

Struts 1.x使っていた時代遅れ企業終了

>>354
その印象を持ったのはどういう理由？
Java開発案件が減ってJSが増えてる？

**デフォルトの名無しさん** · 2014/04/25(金) 22:40:29.27

>>355
開発案件に影響は出ていないが、技術的な部分が日進月歩なので表面化しつつある。
WebがHTML5に向かう中で、Javaが担う機能を、どこまでJavascriptで
担えるかというところで微妙になってきた。
基幹業務システムをJavascriptで作る時代がきそうだと。

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

乱暴に言えば基幹システム＝DBアクセスだから、サーバサイド開発をゼロにするって無理だろ
JavaScriptから直接SQL叩くことを許可するのか？

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

>>357
クライアントではなくてサーバーサイドJavascriptの話をしているのだから
それ的外れな指摘だよ

>>356
Javascriptって、もともとDOM(xml/html)を操作して
画面UIを操作するためにあるような、それくらいしか能がない言語でしょ。
サーバーサイドには機能面で非力すぎるし、また独自仕様乱立とか始めるのがオチ。

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

>>356
＞基幹業務システムをJavascriptで作る時代がきそうだと

これは絶対に来ない
もし基幹業務をJSで作ったとしたら大バカ企業

動的言語は大規模開発だと開発生産性が落ちる。
このデメリットが大きいからFacebookなどもPHPを
静的言語に魔改造しようとしてきた。

JavaがゴミみたいなWebフレームワークしかないのに
大規模サイトで使われてきたのは、静的言語で、
ライセンスが比較的自由だからだろう

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

サーバーサイドJavaScriptといえばIBMがこういう記事出してるな。
http://www.ibm.com/developerworks/jp/java/library/j-nodejs/
それにIBMのBlueMixなんかは基幹系開発も用途に含むPaaS環境だけど
node.jsやRubyも対象にしてる。

まぁ日本のイントラ基幹系は業界的にも従事する人間の考え方的にも
頭が硬くて柔軟性に欠けるから、node.jsベースの開発なんて無理だろうけど
B2CとかのエンドユーザーがコンシューマーだったらサーバーサイドJavaScriptは
ぼちぼち盛り上がってるんじゃね。

JDK1.0が出た当時だって、動きのあるホームページ作るものでしょ的な
イメージばかりで将来まさかJavaがビジネス基幹系に使われるように
なるなんて誰も想像しなかったわけで。

静的型付けができないとか型推論とか言語仕様的にはJavaScriptそのものは
いろいろ欠点あるけど、CoffeeScript/TypeScript/HaxeとかのAltJSを使えば解決できる。

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

JavaScriptもこんな流行るとは思わんかったよ

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

現状ではpaypalの開発が代表的かな。
http://www.infoq.com/jp/news/2014/01/paypal-java-javascript

Java Web Application Framework総合 ver2

Java Web Application Framework総合　ver2