パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

生き残るフレームワーク、どうすれば選択できる?」記事へのコメント

  • JavaFX2 なんてものがあるのか、まあ誰にも相手にされずに終わるだろう、ということを確認するためにググったとき読んだこの文章 [oracle.com]のグラフ [oracle.com]が、分かりやすく現状を示しているように思えます。HTML5 は素晴らしいが、どう作るかについては、いまだ試行錯誤のまっただ中。

    JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。LAMP Stack は書きづらいだけ。使う理由がなくなった。シングルページアプリケーションの利点がはっきりしてきた今となっては、たぶん

    • by Anonymous Coward

      > JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。

      それはないです。

      見た目重視のB2Cではなく、実用重視のB2Bや自社内業務アプリなどでは、
      JavaScriptに頼ったUI実装は無駄なコストやブラウザ変更時の負荷を非常に増大させるだけです。
      特に責任の分界があるようなシステムでは、可能な限り「自分の腹の中で」処理をし
      相手のブラウザにはなるべく仕事をさせない必要があります。
      これはビジネスの話ですので、実装の都合などより上のレイヤーです。

      • JavaScript に頼った実装で問題ない、というのがここ五年間の中で理解しなければならない重要な変化だと思います。ブラウザ変更で動きが大きく変わるというのは、過去の話。さすがにもう PHP は要らないと言わせてください(笑)

        • by Meth610 (31617) on 2013年10月27日 20時42分 (#2485153)

          JSのひとつの問題としてセキュリティがあります。
          つまりユーザー側でコードや変数の書き換えが好き勝手にできる。
          ゲームで言えばチートし放題。ChromeにはJSコンソールというチート機能が標準搭載。

          そこで質問ですが、JSオンリーで書かれたネットバンクサービスとか、使いたいですか?

          親コメント
          • by Anonymous Coward on 2013年10月27日 21時05分 (#2485165)

            JSだろうがHTMLだろうが、結局HTTPしゃべってるだけなんだから、
            そんなん自由にユーザ側で書き換えできることに大差ないだろ?
            別にユーザ側から好き勝手なHTTP送られても、サーバー側のValidationが機能要件を満たしていれば関係なくね?

            親コメント
            • by Anonymous Coward

              だから
              「(クライアントサイドの)JavaScriptやHTMLには重要なロジックを何も載せられない」
              「重要な処理は『全部』サーバー側でやるしかない」
              という話なのでは。

              極論すればJavaScriptを全部OFFにしても、全機能がそのまま稼働する。
              JavaScriptは完全に「オマケ」としてしか使われてない。
              バリデーションも全部サーバー側で実装するというのも、そういう話の一つでしょ。

              #世の中にはクライアントサイドJavaScriptによる入力チェックしかしてなくて、
              #脆弱性の塊でインターネットに接続できないWebアプリもあるのですよ。 orz

              • Re: (スコア:0, フレームのもと)

                by Anonymous Coward

                ちょっと何を言っているのかよくわからないですね

                だから
                「(クライアントサイドの)JavaScriptやHTMLには重要なロジックを何も載せられない」
                「重要な処理は『全部』サーバー側でやるしかない」
                という話なのでは。

                こんなのはWebアプリケーションであればどんな実装をしようが当然ですよね?
                徳丸本にもそう書いてありますよね
                何が言いたいのかまったくわからないんですが、つまり上の31617さんはWebアプリケーションとはどういうものか全く理解していない頭おかしい人ってことですか?

              • by Anonymous Coward

                >こんなのはWebアプリケーションであればどんな実装をしようが当然ですよね?
                うんにゃ。
                そうじゃない実装をする人はいるんだよ。

                あんたの経験が少なすぎるだけ。

              • by Anonymous Coward

                >こんなのはWebアプリケーションであればどんな実装をしようが当然ですよね?
                うんにゃ。
                そうじゃない実装をする人はいるんだよ。

                あんたの経験が少なすぎるだけ。

                そんな人はどんな技術を採用しても同じですよね。
                何が言いたいのかまったくわかりません。

            • by Anonymous Coward

              「アドレスバーで仕様が見えちゃうからGETでなくPOSTを使え」に通じるものがありますね。

              まあ実際に入力フォームのチェック処理が見えると攻撃対象の仕様を類推できることもありますし、
              ポケモンとかでよく聞く「個々の数値は範囲内だけど論理的にありえないチート」なんかは
              データこねくる部分を全部隠蔽できてないと排除が難しいですね。

          • by Anonymous Coward

            (銀行という特性上(勘定系まで含めちゃうと) Full JS ってのは無理だろうねぇ、とは思いますが、
             ここではWeb側システム、オンラインバンキング的な部分の話であると仮定します)

            そこで質問ですが、JSオンリーで書かれたネットバンクサービスとか、使いたいですか?

            「JSオンリー」というのがどこまでを表しているのかというのにもよりますね。
            クライアント側のJavascript(ブラウザで動く部分)なんかについては懸念は理解できますが、
            それに限らなければ、サーバ側は Node.js 使ってる、みたいなのがすでにあったり、今後出てきたりするんじゃないかとは思ってます。

ソースを見ろ -- ある4桁UID

処理中...