オフィススイートよりも多機能なIDEよりも、ウェブブラウズの方が重いのおかしいし、おかしいと気づけない上にそれがどう問題なのかも理解できない人が大半なのが絶望的感＞＜
@[email protected] ウェブブラウズでなくブラウザが基本ソフトの一つになっていると考えればそれだけリソースを持っていかれたとしても文句は言えないことが分かるはず
@tacumi いえ、全く＞＜
20年ほど前は今の1/10以下のメモリの環境で現在の平均的な環境よりも高速にウェブブラウズできましたよ？＞＜
それがソフトウェアとウェブの誇大化です＞＜
@[email protected] ウェブ経由でオフィスソフトを利用する人間もいるのでそれに対応するためにブラウザのエンジン部分もメモリを要求しはじめたのでは?
@tacumi メモリだけでいってもが、たとえばかつてのSunのシンクライアントが積んでたメモリと、現在のウェブブラウザがウェブ越しにオフィススイートを実行するために要求するメモリ、どちらが大きいでしょう？＞＜
@[email protected] それを言うなら今のオフィスソフトが実現しなきゃいけない機能にどれだけのメモリが必要かまで考えて言ってるんだね?
当時はそれを行うことができないから機能を制限せざるを得なかったという背景まで考えて.
@tacumi どう必要な機能が増えてるんでしょう？＞＜
たとえばDEC Alphaがまだ元気だった時代に既にスペルチェックに秒単位の時間がかかる時代は通り過ぎてるんですよ？＞＜
@[email protected] 複数人が同じドキュメントを操作する機能は今はブラウザ上では必要でしょう?そのためにはリアルタイムでクライアント側の操作を同期させるための処理が走るはずで,そのために必要なメモリが増加することは避けられないと思うのですが
@tacumi たぶん＞＜
シンクライアントを例に出した通り、サーバー側にリソースを押し付けられるだろうにより多く消費しているということは、実装に問題があり、ひとつのドキュメントを複数人で操作する機能ごときでクライアントの要求メモリが大きく上昇するのは、サーバーに処理を任せるモデルではなおさら実装が間違ってると言えるかも＞＜
あるいは、そもそもウェブブラウザ越しというモデルが正しくなかったかのどちらかかも＞＜
@[email protected] 複数人が同時に同じドキュメントを操作することがかなり難しいのでそれを無理矢理実現するならそうなるなと思います
@tacumi なぜせっかく鯖があるモデルで実装してるのに、全体の調停と合成に関する処理をクライアントに押し付ける必要があるのか？＞＜ そうやって考えていけば純粋にそれにより追加されるヒューマンインタフェース(鯖側とに調停含む(もっともそれはこの機能がなくても必要))が必要とするリソース以上のリソースを消費したら実装がおかしいと気づけるかも＞＜
@[email protected]
もっかい議論の始めまでもどりましょっか
なんかズレてる気がしはじめた.
あなたは「ウェブブラウザがIDEよりオフィスソフトよりメモリを食うのが問題だと思う」と言ってましたね
それに対して自分は「オフィスソフトがウェブブラウザ経由で利用される現在ならそれはそうだろう」という意味の返答を返したんですが,ここまでで理解の相違はありますか