3

私のアプリケーションは、読み込み時にクライアント側で DOM の大規模な書き換えを行います。特別なマークアップ (Markdown と考えてください) やその他のパタ​​ーンをスキャンしてページを走査し、それらを ( などの DOM 呼び出しを使用してcreateElement) かなり複雑な DOM 構造に置き換えて、テキストのスタイルを設定するだけでなく、図やグラフィックも作成します。

ビルドや前処理の手順を避けるために、このアーキテクチャを採用しました。デスクトップ ブラウザでは正常に動作しますが、モバイル デバイスでは著しく遅くなります (絶え間なく最適化した後でも数秒かかります)。そこで、システムを再設計して、ページを事前にスキャンし、DOM を事前に構築したいと考えています。私はこれを行う方法を考え出すために少し精神的なブロックを抱えています. もちろん、他のサーバー側言語ですべての Javascript を書き直すことは避けたいと思います。また、同じコードを共有する基本的な書き換えロジックを使用して、現在のようにロード時にビルドを行うオプションを保持したいと思います。

私はノードの初心者ですが、最も可能性の高いオプションは、これをノード アプリとしてビルドすることです。jsdom を使用して、入力の解析と DOM の変更の両方を行います。または、私は XSLT のファンであり、Saxon-CE に興味を持っているので、たとえすべてを書き直すことになるとしても、XSLT でスキャン/書き換えロジックを実装することも検討しました。ケース - 人々はノードからサクソンを使用しますか?) またはブラウザー (ロード時のビルドの場合)。

誰かがこのアプローチについてコメントしたり、別のアイデアを捨てたりできますか?

4

2 に答える 2

3

大規模なDOMの書き換えに取り組んでいる特定のユースケースがわからない、またはスループット要件が何であるかもわかりません. そうは言っても、node/jsdom ルートへの代替アプローチの 1 つは、ヘッドレス Webkit ブラウザーのファームを実行し、そのライブ レンダリング コンテキストで現在の JavaScript をそのまま実行することです。これにより、それらのポーキーなモバイル CPU から任意にスケーラブルなクラウド リソースに処理をオフロードすることができ (これがプロジェクト/ビジネスにとって手頃な価格であると仮定して)、現在の動作中のコードを書き直したり微調整したりする必要がまったくなくなります。

于 2012-10-02T04:12:53.200 に答える
0

ノードが必要なようですね。JavaScript の知識があれば、簡単に習得できます。

次のようなチュートリアルをお勧めします: http://www.nodebeginner.org/

完了するのに 1 時間ほどかかりますが、作成者と一緒に小さいながらも機能的なアプリを構築することで、Node.js の概要をしっかりと理解できます。

于 2012-10-02T03:16:46.157 に答える