YUI、JQuery、Prototype などの JavaScript フレームワークと Firebug などのデバッグ ツールの能力が向上したため、完全にブラウザー サイド JavaScript でアプリケーションを実行することは、パズル ゲームや特殊な電卓などの単純なアプリケーションを作成するための優れた方法のように見えます。
ソースコードを公開する以外に、これにマイナス面はありますか? この種のプログラムのデータ ストレージをどのように処理する必要がありますか?
編集: はい、Gears と Cookie をローカル ストレージに使用できますが、ユーザーが既に持っているファイルやその他のオブジェクトに簡単にアクセスすることはできません。また、PDF への印刷やページをファイルとして保存するなどのブラウザー機能を呼び出さなければ、ユーザーのデータをファイルに保存することもできません。
スプレッドシートを含むいくつかのアプリケーションを JS で作成しました。
利点:
欠点:
結論：頑張ってください。やった。
アプリケーションやゲームなどの単純なデスクトップを JavaScript で開発するためのもう 1 つのオプションは、Adobe AIRです。HTML + JavaScript で、または Flash/Flex を使用して、あるいはその両方を組み合わせて、アプリ コードを作成できます。クロスプラットフォームであるという利点があります (実際にはクロスプラットフォーム、Linux、OS X、および Windows。Windows と OS X だけではありません)。
開発者としてのキャリアの中で、Web ページを作成して 1 つのブラウザーのみをターゲットにできるのは、このときだけかもしれません。
SproutCoreは、完全に JavaScript でホストされるアプリケーション フレームワークであり、特に Cocoa (KVO など) や Ruby on Rails (モデル、ビュー、コントローラーに CLI ジェネレーターを使用するなど) から概念を取り入れています。プロトタイプが含まれていますが、その上に洗練されたコントロールなどの多くのものを構築します。その写真デモは間違いなく印象的です (特に Safari 3.1 では)。
Greg はすでに Gears を紹介しています。さらに、HTML 5 にはローカル ストレージの標準化された手段が付属しています。Safari 3.1 には、ユーザーが最大サイズを設定できるサイトごとの SQLite データベースと、SQL クエリ機能を備えた組み込みのデータベース ブラウザが実装されています。残念ながら、幅広いブラウザのサポートが期待できるようになるまでには、長い時間がかかります。それまでは、Gears が確かに代替手段となります (ただし、Safari の場合は… <a href="http://code.google.com/p/gears/wiki/BuildingGearsForSafari" rel="noreferrer">まだ!)。保存を簡単にするために、もちろん常に Cookie があります。
スタンドアロンのJavaScriptアプリケーションを作成する場合は、XULrunnerを参照してください。これはFirefoxが構築されているものですが、アプリケーションランタイムとして配布できるようにも構築されています。インターフェイスの一部をJavaScriptで記述し、コードにJavaScriptを使用します。
これの欠点は、js が有効になっている彼らに翻弄されることです。これが今大したことかどうかはわかりません。ほとんどすべてのブラウザが js をサポートしており、デフォルトで有効になっています。
もちろん、他の欠点はパフォーマンスです。あなたは再び、すべての集中的な作業を処理するクライアントに翻弄されます. これも大したことではないかもしれませんが、構築しているアプリの種類によって異なります。
Gears を使ったことはありませんが、試してみる価値はありそうです。バックアップ計画は、データをどこかにダンプする ajax を介してサーバー側のスクリプトを実行することです。
完全にクライアント側ではありませんが、まあまあです。
クライアントの Javascript インタープリターに完全に翻弄されている場合、パフォーマンスの問題が発生する可能性があります。Gears はデータ ストレージの優れた方法ですが、市場にそれほど浸透しているとは思いません。そのようなことにこだわらなければ、Cookie を使用することもできます。
GWT のスタンドアロン ゲーム:
私は ScottKoon と一緒です。Adobe AIR は素晴らしいです。これまでに本当に素晴らしい (imho) ウィジェットを 1 つしか作成していませんが、jQuery と Prototype.js を使用して作成しました。これは、まったく新しいイベント モデルを学習する必要がなかったため、非常に素晴らしい方法で床を整えました。Adobe AIR は非常に優れており、メモリ フット プリントはそれほど悪くありません。新しいバージョンへのアップグレードは AIR に組み込まれているため、ほとんど自動で行われます。何よりクロスプラットフォームです。Linux 用のアルファ版もあります。 、しかし、それはすでに私のEeeでかなりうまく機能しています。
JavaScript アプリケーションからのファイルの保存に関して:
クライアント側アプリケーションの可能性にとても興奮しています。Flash 10 では、ブラウザで直接保存するファイルを作成する機能が導入されました。とてもクールだと思ったので、保存機能をラップする javascript+flash コンポーネントを作成しました。現在、テキストベースのファイル (vcard、ical、xml、html、css など) の作成にのみ機能します。
テキスト以外のファイルのサポートをすぐに追加したいと考えていますが、これは始まりです。
私の RSS フィードは役に立ちました。JavaScript がローグライクであることがわかりました。
アシロスの墓と呼ばれています。
いずれにせよ何らかのサーバー コードを作成することを考えると、多数のドメイン (アドレス帳、ポーカー スコア、GUI 構成など) のストレージをサーバーに保持することは理にかなっています。 'Webkit または Gears で入手できます。おそらく、サーバー上に保持することもできます。
サーバー上に保持する利点は 2 つあります。
これを処理するためのサーバー コードも、特にこのタスクを念頭に置いて記述されている場合は、かなり単純なものになる可能性があるため、大きな認知的負担にはなりません。
qooxdoo で行きます。彼らは最近 1.0 をリリースしましたが、ほとんどのユーザーは少なくとも 2 バージョン前には 1.0 の機が熟していたと言っています。
qooxdoo を YUI および ext と比較しましたが、qooxdoo はプログラマー向けの方法だと思います。プログラマーの観点から見ると、YUI は qooxdoo ほど洗練されておらず、ext のライセンス モデルはあまり友好的ではありません。
qooxdoo の (私にとっての) 長所のいくつかは次のとおりです。
また、単体テスト用のテスト ランナー、API doc ジェネレーターとリーダー、ログ機能、およびデバッグ用のいくつかの便利な機能も備えており、Inspector と呼ばれるものの下にグループ化されています。
唯一の欠点は、qooxdoo 用の既製のテーマ (スキンのようなもの) がないことです。しかし、独自のテーマを作成するのは非常に簡単です。