とりあえず "Professional JavaScript for Web Developers"を眺めてみると良いと思う。 http://www.amazon.co.jp/dp/B006PW2URI/ [amazon.co.jp] ここまで違うとJavaとC#、N-BASICとF-BASICのような意味で別言語だ。
そもそも、アプリケーションの動作環境として複数のOSが存在していて、それらすべての環境に個別の専用クライアントを開発するコストが負担できないから、代替案として、ほぼ共通の動作環境としてwebブラウザを理容してたんじゃなかったかな? 単一環境で避ければ、例えば Windows 用の専用アプリを1つ作ればそれで問題なかったはずなんだよね。 なので、逆にwebブラウザすべてをサポートしようとすることで、コストが上がるのであれば本末転倒じゃないだろうか?
わからない (スコア:3, 興味深い)
JavaFX2 なんてものがあるのか、まあ誰にも相手にされずに終わるだろう、ということを確認するためにググったとき読んだこの文章 [oracle.com]のグラフ [oracle.com]が、分かりやすく現状を示しているように思えます。HTML5 は素晴らしいが、どう作るかについては、いまだ試行錯誤のまっただ中。
JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。LAMP Stack は書きづらいだけ。使う理由がなくなった。シングルページアプリケーションの利点がはっきりしてきた今となっては、たぶん MEAN Stack [youtube.com] が最高に近い形に見えます、が、Dart だの、Type Script、オフラインアプリケーション、いろんな方向から新しいコンセプトが次々出てくるときになにが最善かわかりようがない。
(その点、iOS や Android は簡単でいいですね。OSが提供する API を使う以外に選択肢がない。はっきりしていていい)
Re: (スコア:0)
> JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。
それはないです。
見た目重視のB2Cではなく、実用重視のB2Bや自社内業務アプリなどでは、
JavaScriptに頼ったUI実装は無駄なコストやブラウザ変更時の負荷を非常に増大させるだけです。
特に責任の分界があるようなシステムでは、可能な限り「自分の腹の中で」処理をし
相手のブラウザにはなるべく仕事をさせない必要があります。
これはビジネスの話ですので、実装の都合などより上のレイヤーです。
Re:わからない (スコア:2)
JavaScript に頼った実装で問題ない、というのがここ五年間の中で理解しなければならない重要な変化だと思います。ブラウザ変更で動きが大きく変わるというのは、過去の話。さすがにもう PHP は要らないと言わせてください(笑)
Re:わからない (スコア:2)
JSのひとつの問題としてセキュリティがあります。
つまりユーザー側でコードや変数の書き換えが好き勝手にできる。
ゲームで言えばチートし放題。ChromeにはJSコンソールというチート機能が標準搭載。
そこで質問ですが、JSオンリーで書かれたネットバンクサービスとか、使いたいですか?
Re:わからない (スコア:1)
JSだろうがHTMLだろうが、結局HTTPしゃべってるだけなんだから、
そんなん自由にユーザ側で書き換えできることに大差ないだろ?
別にユーザ側から好き勝手なHTTP送られても、サーバー側のValidationが機能要件を満たしていれば関係なくね?
Re: (スコア:0)
だから
「(クライアントサイドの)JavaScriptやHTMLには重要なロジックを何も載せられない」
「重要な処理は『全部』サーバー側でやるしかない」
という話なのでは。
極論すればJavaScriptを全部OFFにしても、全機能がそのまま稼働する。
JavaScriptは完全に「オマケ」としてしか使われてない。
バリデーションも全部サーバー側で実装するというのも、そういう話の一つでしょ。
#世の中にはクライアントサイドJavaScriptによる入力チェックしかしてなくて、
#脆弱性の塊でインターネットに接続できないWebアプリもあるのですよ。 orz
Re: (スコア:0, フレームのもと)
ちょっと何を言っているのかよくわからないですね
こんなのはWebアプリケーションであればどんな実装をしようが当然ですよね?
徳丸本にもそう書いてありますよね
何が言いたいのかまったくわからないんですが、つまり上の31617さんはWebアプリケーションとはどういうものか全く理解していない頭おかしい人ってことですか?
Re: (スコア:0)
>こんなのはWebアプリケーションであればどんな実装をしようが当然ですよね?
うんにゃ。
そうじゃない実装をする人はいるんだよ。
あんたの経験が少なすぎるだけ。
Re: (スコア:0)
>こんなのはWebアプリケーションであればどんな実装をしようが当然ですよね?
うんにゃ。
そうじゃない実装をする人はいるんだよ。
あんたの経験が少なすぎるだけ。
そんな人はどんな技術を採用しても同じですよね。
何が言いたいのかまったくわかりません。
Re: (スコア:0)
「アドレスバーで仕様が見えちゃうからGETでなくPOSTを使え」に通じるものがありますね。
まあ実際に入力フォームのチェック処理が見えると攻撃対象の仕様を類推できることもありますし、
ポケモンとかでよく聞く「個々の数値は範囲内だけど論理的にありえないチート」なんかは
データこねくる部分を全部隠蔽できてないと排除が難しいですね。
Re: (スコア:0)
(銀行という特性上(勘定系まで含めちゃうと) Full JS ってのは無理だろうねぇ、とは思いますが、
ここではWeb側システム、オンラインバンキング的な部分の話であると仮定します)
「JSオンリー」というのがどこまでを表しているのかというのにもよりますね。
クライアント側のJavascript(ブラウザで動く部分)なんかについては懸念は理解できますが、
それに限らなければ、サーバ側は Node.js 使ってる、みたいなのがすでにあったり、今後出てきたりするんじゃないかとは思ってます。
Re:わからない (スコア:1)
ないわー。
jQueryを使おうが、JavaScriptを使う限りブラウザ間の互換性・挙動の違いに振り回される。
ましてやPHPが要らないとか、本気で業務アプリ作ってるのと言いたくなります。
時代の変化はありますが、それが全てを解決した訳でもないし、エンドユーザーに対して「このブラウザ以外は動作しません。ご了承ください。」と
動作環境を押し付けられる訳でもない。
個人で趣味で作るようなものならともかく、対顧客ありきのシステム構築で「JavaScriptに頼ったUIが最適」とか意味わかりません。
Re: (スコア:0)
> jQueryを使おうが、JavaScriptを使う限りブラウザ間の互換性・挙動の違いに振り回される。
それいったらHTMLだって同じじゃん
業務アプリケーション程度ならJavascriptの挙動の違いよりHTMLでの見え方の違いの方が困ることの方が多いけど
もしかして生PHPで業務アプリを作ってるレガシーさんかな?
Re: (スコア:0)
そうですよ。HTMLですらブラウザ間の互換性・挙動の違いに振り回されてる現状なのです。
あなたのいう「業務アプリケーション」がどの規模なのかは知りませんが、規模がデカくなればなるほど、使うユーザーが
多くなればなるほど、JavaScriptの細かな挙動での不具合報告・エンドユーザーからの質問が飛び交うのです。
運用・サポートコストを軽視できる問題ではありません。
生PHPと言うのが、フレームワークを使わないフルスクラッチを指しているのなら、見当違いです。
顧客の要求する動作環境で出来るだけ問題が起きないようにするなら、JavaScriptに頼った実装を「現時点で」選択するのは
リスクがありすぎます。
それとも、何か画期的なフレームワーク・ソリューションがあるのでしょうか。
あるのでしたら、是非お教えください。直ぐにでも検証・検討しますので。
Re: (スコア:0)
上の人とは別ACなんで、別にそんな完全にJavascriptに頼った実装を推してるわけじゃないよ
ただ、問題が多発するのは結局View/UI層が原因なんだから、別にそれはJavascriptが全面的に悪いわけじゃないよね
そこは「ここまでJavascriptでやると大変そうだな」って分界点を決めて実装すればいいだけで
御社の書き込みをみていると、どうもそのあたり分かってなさそうな雰囲気がプンプンするのでツッコミを入れただけ
そんなん無いでしょ。Javascript MVCフレームワークの鉄板すらまだ決まってないんだから
ただ、PHPで業務アプリを作るならCakePHPを使うのが鉄板だろうね
Re: (スコア:0)
選択する人が多いので私も使うことは多いのですが「・・・ぶっちゃけCake糞じゃね?」と思うことも多々
Re: (スコア:0)
HTMLで発生する問題と、
JavaScriptで発生する問題では、
問題の次元が異なると思う。
とりあえず "Professional JavaScript for Web Developers"を眺めてみると良いと思う。
http://www.amazon.co.jp/dp/B006PW2URI/ [amazon.co.jp]
ここまで違うとJavaとC#、N-BASICとF-BASICのような意味で別言語だ。
JavaScriptで書くってことは、
IE6,
IE7,8,9,10,
その他ブラウザ、
に分けてコードを書くようなものなんだなと。
それとIE6が消えて本当に良かった。
Re:わからない (スコア:1)
IE9/10とその他のブラウザは一緒でいいだろ
発想の転換 (スコア:0)
アプリケーション動作環境として特定のブラウザをインストールしてもらえばよいのでは?
そもそも、アプリケーションの動作環境として複数のOSが存在していて、それらすべての環境に個別の専用クライアントを開発するコストが負担できないから、代替案として、ほぼ共通の動作環境としてwebブラウザを理容してたんじゃなかったかな?
単一環境で避ければ、例えば Windows 用の専用アプリを1つ作ればそれで問題なかったはずなんだよね。
なので、逆にwebブラウザすべてをサポートしようとすることで、コストが上がるのであれば本末転倒じゃないだろうか?
原点に立ち返って考えれば、複数の環境(OS)をサポートした共通の実行環境さえ用意出来れば問題は解決すると思うんだよね。
Re: (スコア:0)
突然JavaVMが立ち上がり、仲間になりたそうにこちらを見ている。仲間にしますか?
Re: (スコア:0)
「PHP」はいらないという気分は分かる。というか、そこでなぜPHP限定になるのかはわからない。
#個人的にPostBackは滅んでしまえ(というかそんなもん採用してんじゃねえよ)と今、目の前にして思う
Re:わからない (スコア:1)
これには反対1票
組み込み系で、複数のブラウザ+独自機器をサポートしています。
JavaScriptに頼った場合、貧弱なマシン、独自機器での表示パフォーマンスが
極端に落ちるのが現状です。
あと、特定のブラウザでの不具合回収時の、再確認も、
サーバサイド側での対応のほうがやりやすいです。
表示がリッチになればリッチになるほど、サーバサイド側で、
必要な情報を出力するほうがよいというのが、
昨年まで作っていたシステムでの結論です。
コソコソAC
Re: (スコア:0)
まぁ、今の時代、サーバサイドもjavascriptってのも珍しくないんじゃないかしら? とも思いますが。
今回のストーリーとはずれた話ではありますけど。
Re:わからない (スコア:1)
さすがにサーバーサイド開発に、JavaScriptを使いたいとは思わないな。
型安全性さえ満足にナインだぞ。
Effective JavaScriptを読んで、ますますそう思ったわ。
Re: (スコア:0)
JavaScriptはすごく酷い方の言語ではないけど、いい(書き易い)言語とも思わないから、
JavaScriptをブラウザの外にまで普及させようとする勢力って正直敵認識してるわw。
Re: (スコア:0)
い、intramart......
#個人的経験から滅んでしまえと思っているのでAC
人によるでしょ (スコア:0)
そういう人ばかりなら Node.js は流行らないよ
Re: (スコア:0)
だから、ぜんぜん流行ってないじゃん。
Re: (スコア:0)
「ネ申Excel」
最近、JavaScript でコテコテのページが増えて、嫌気が差してきてます。時々、Web 1・0 なページがあると、ホっとしたりして。…。
それもそうと、スクリプトで動的に作られたコンテンツは、検索したり保存して処理したりできないので、先日の「ネ申Excel」に近い存在ですけどねっ。
Re: (スコア:0)
今作ってる某社の社内システムがまさにクライアントサイドJavaScriptバリバリで、サーバはJSONを返すだけという変態システムなんだが。
# 超AC
Re:わからない (スコア:1)
8年くらい前になるか、某プロバイダのWebメール新版を作るとき、Outlookを目指してAjax/JSONバリバリでやったなぁ。
Ajaxの技術書も限られてて、結構難産だったけど、動作の組み立てよりも軽量化に腐心した記憶ばかり蘇る。
それでも「重い」「使いづらい」と不評だったけど。
クライアント側はその頃からさらに代替わりしてるけど、鯖側は我々が作ったものを引き継いだと聞いた。
「ここ五年間の」ということは、やはりちょっと早かったのかな…。
Re: (スコア:0)
実用重視なら、余計にJSは使うと思うんだけど、#2485073の人は、装飾用途でのJSしか知らないのかしら。
HTMLページを一Pづつ開くより、Ajaxで必要な部分だけ書き替えたほうがずっと負荷が少ない。
Re: (スコア:0)
サーバー側は、JSONベースのAPIさえ定義できれば、比較的、UI側の人と分業がしやすいので従来よりは開発が楽になったと思っています。
いざとなれば、JSONを喋るリッチクライアントも作れますし、
セキュリティやユーザーサイドを信用できるかどうかといった議論さえしっかりできれば非常によい傾向だと思っています。
Re: (スコア:0, 興味深い)
今、とあるWebシステム(100画面はある。顧客、オペレータ両方使う)のリプレース版を作ってるんだけど…JavaScriptなんてほとんどないよ…。
選択による活性非活性の切り替えとか、領域の表示非表示とか、それくらい。
周りを見回してもJavaScriptの技術持ってる人間なんて全然いなくて、だいたい回って来るし。
いや、そもそもJSP使ったことある人間が少ないかも。
鯖側は一応のフレームワークがあるけど業務は画面からのコマンドごとのベタで、ほとんど同じコンポーネントが5つも6つもあったり。
利用者や開発者の目線はなく、進捗管理の目線だけっぽい。
継承禁止、privateメソッド禁止、三項演算子禁止、==null禁止(共通クラス使用)、+で文字列連結禁止、
単体試験も専用ツール利用(死ぬほど重くて使いづらい)、etc.、etc.で頭が痛い日々。
まあ、H系なんですが。いい加減抜けさせてくれ。
Re:わからない (スコア:1)
>+で文字列連結禁止
何年前のコンパイラ使っているの?
>継承禁止、privateメソッド禁止
え~と、JSPって出てきているからjavaだよね?
無駄に工数増やしているような……
# 関わりたくない、本気で。
notice : I ignore an anonymous contribution.
Re: (スコア:0)
privateメソッド禁止って凄いな。
Re:わからない (スコア:1)
凄いなの意味が良い意味なら同意。
悪い意味なら今どきのOODを再入門すると良い。
かつてOODの黎明期にオブジェクトの説明で真っ先にカプセル化を教えたもんだから
今でもカプセル化に拘る人がいるけど、もう今はUnitTestあたりまえ時代なので
privateにされると試験しにくいデメリットの方が大きくなりすぎてカプセル化のメリットを上回っている。
正直カプセル化って、カプセルした中身の信頼度が低いと開かずのトイレで爆弾抱えてるようなもの。
今どきはオープンにして、代わりにコードカバレッジ100%にしたり規約チェック入れたり別の手段で全体の信頼度を高めるのが正しいOOD。
Re:わからない (スコア:2, すばらしい洞察)
privateだからテストしにくいという時点で設計を間違えている
Re:わからない (スコア:1)
おもしろおかしいをつけたいけど、
まあ、卵か鶏かの話になるのかな。「カプセルした中身の信頼度が低い」「カプセルした中身の信頼度が低い事でテストしづらい」という事実が
先行するか、「テストしづらい設計(粒度が低い)にする方が悪い」とするかの問題だと思うが。そこで「privateにすんな」という結論は頭が悪いと思う。
#TDDの話で、「テストしやすい設計にしろ」という話はあまり聞かないけど、言うほどの事もない常識という事かな
Re: (スコア:0)
#2485137から追記。
いわゆるCOBOL風Javaで、処理がダラダラベタ書き。
処理を親にまとめたくても継承禁止。
仕方なくサブルーチン化を考えてもprivate禁止。
そんな感じ。
大半はオフショアがこの縛りで作ったんだけど、一番デカいクラスは9600行くらい。
当然不具合てんこ盛りで、修正は国内。
数万ファイルの詳細設計書もいい加減見たくない。
え!? (スコア:0)
Java と JavaScript 混同してない?この人?
Re: (スコア:0)
> まあ、H系なんですが。いい加減抜けさせてくれ。
抜ける前にそこらへん全部改善して行ってよ。
改善できるのは関係者以外に居ないんだから。
Re: (スコア:0)
#金にも権限にも縁のない人間ほどそう言う。というか、本当に金や権限を持つ人はうっかりそんな言質はとらせないんだよね。
というわけで、そんな金も権限ももらってないし、契約も義理もねえ。
ムセキニンダーと言いたいかもしれんが、そういう契約で召喚されたのは確か。
純粋に心情的な面だけ考えても、一通り改善しまくった結果、さよならだけが人生だというのは虚しいじゃないか。
Re: (スコア:0)
私も最近作ってるWEBアプリのほとんどにおいて、サーバ側は認証を含むリクエストの妥当性の検証と、それが通った場合はリクエストに沿ったデータをせっせとJSONで返す、というだけのI/Fを最低限守る実装しかしてないかも。
フレームワークは古くはPHPでCodeIgniterで作ってたり、最近はnode.jsのExpressだったり様々。
それを受け取るクライアントもJSONをもとに画面書き換えするブラウザアプリであったり、はたまた別のサーバ側アプリだったりと様々。
Re: (スコア:0)
ロジック以外は全部シンプルなRPCコールにしろという話でしょう。
現実に動いているシステムならともかくフレームワーク心配するぐらいなら
単純なロジックのコール部分だけ作れと言いたいのだろうと。
そうなればフレームワークなんていりません。どうせ決定版のフレームワークも無いしね。
Re: (スコア:0)
RPCコールって何ですか?
Re: (スコア:0)
JavaFX2はつなぎかなぁぐらいにしか思っておらず。
# Javaも1.8に興味あったんですけどLambdaの実装が残念に思えて興味なくなってしまいました。
Re: (スコア:0)
【Apach Pivot】 Windows でちょっとしたユーティリティを作るのに HTA がとても便利で、その Linux 版は?と探してみたら、Apach Pivot というJava ベースのフレームワークがあり、とて重宝してます。正確には Java + JavaScript + XML で、HTA でやるようなことは、ほぼ JavaScript でできます。もちろん Java で重たい処理をゴリゴリ書くこともできます。
Linux の HTA として使ってますが、Java なので、Windows でも、そのまま動きますしね ( ̄▽ ̄;)
Re: (スコア:0)
もちろん、システムの設定とか、Com オブジェクトの操作とかはできないですけど、Java でできることは何でもできます。Java のウィンドウ・フレームワークだから当たり前ですけどねっ。 ( ̄▽ ̄;)
Re: (スコア:0)
Tcl/Tk に比べると遥かにモダンで強力とみた。。。