Differences between revisions 1 and 2
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
|
== 概念 == 現在のところの理解であるが、vaadinは簡単に言えば、ブラウザをダム端末として扱う仕組みである。 これは、VNCが単にリモートのコンピュータ上のデスクトップ上でのプログラム実行を表示する（あるいは、ユーザ入力をそこに送り込む）だけのダム端末であるのに似ている。 つまり、vaadinで作成されたアプリケーションは、基本的にはブラウザ上では実行されず、サーバ上で実行されるものである。ブラウザ側は単にその結果を表示し、ユーザからの入力をサーバに送り込む役割しか持たないと思われる。 それがゆえに、vaadinによるアプリは、ブラウザとサーバ間のトラフィックがGWTに比較すれば大きなものになることが容易に想像される。アプリを操作すれば、ほぼ常にサーバとのトラフィックが発生すると考えてよい。これは、できることはブラウザ上で行い必要になった時点でサーバとのやりとりを行う、ということを制御可能なGWTに比較すれば非常に大きなアーキテクチャ上の違いであると言える。 上記に示した参考リンクでは最も重要なこの点を完全に無視しているので注意が必要である。 vaadinの開発は１０年にのぼるというが、１０年前のjavascriptの状況を見れば、このアイデアが素晴らしいものだったことは想像に難くない。しかしいまやhtml5という高機能標準がブラウザに搭載される状況になり、このようなアーキテクチャが存続できるかどうかには疑問が残るし、わざわざこのようなことをするのであれば、ブラウザ用のVNCプラグインでも作成した方がよほど効率がよいだろう。 |
vaadin
参考
概念
現在のところの理解であるが、vaadinは簡単に言えば、ブラウザをダム端末として扱う仕組みである。 これは、VNCが単にリモートのコンピュータ上のデスクトップ上でのプログラム実行を表示する（あるいは、ユーザ入力をそこに送り込む）だけのダム端末であるのに似ている。
つまり、vaadinで作成されたアプリケーションは、基本的にはブラウザ上では実行されず、サーバ上で実行されるものである。ブラウザ側は単にその結果を表示し、ユーザからの入力をサーバに送り込む役割しか持たないと思われる。
それがゆえに、vaadinによるアプリは、ブラウザとサーバ間のトラフィックがGWTに比較すれば大きなものになることが容易に想像される。アプリを操作すれば、ほぼ常にサーバとのトラフィックが発生すると考えてよい。これは、できることはブラウザ上で行い必要になった時点でサーバとのやりとりを行う、ということを制御可能なGWTに比較すれば非常に大きなアーキテクチャ上の違いであると言える。
上記に示した参考リンクでは最も重要なこの点を完全に無視しているので注意が必要である。
vaadinの開発は１０年にのぼるというが、１０年前のjavascriptの状況を見れば、このアイデアが素晴らしいものだったことは想像に難くない。しかしいまやhtml5という高機能標準がブラウザに搭載される状況になり、このようなアーキテクチャが存続できるかどうかには疑問が残るし、わざわざこのようなことをするのであれば、ブラウザ用のVNCプラグインでも作成した方がよほど効率がよいだろう。