33

Seasideは次の3.0バージョンのリリース候補をリリースしたばかりなので、それは私のレーダーに再び現れました。現在、将来のプロジェクトでどのWebフレームワークを使用するかを考えているので、それを検討する必要があるのではないかと思います。残念ながら、Seasideの宣伝のほとんどは、2007年からのものです。これはおそらくWebの1世代または2世代です。だから私はここのコミュニティがいくつかの質問に答えることができることを望んでいます

  1. フォーム送信など、ワークフローのほとんどがHTMLである場合、継続ベースのフレームワークは非常に優れていました。今日のJavaScriptを多用する環境では、それはもはや価値がないように思われます。

  2. Squeakは妥当なワークロードを処理できますか？ここや他の場所での他の質問から、適切なスケーリングのために別の実装（Gemstoneなど）はおそらく長期的にはうまくいくようですが、それがどれだけ離れているかについては適切な考えがありません。セッションはかなり高価なようです。

  3. 比較が難しいことは知っていますが、ネット上で見つけた記事のほとんどは、SeasideとRailsを並べて設定しています。代わりに、Scala / Lift、Clojure / Compojure、Erlang / Nitrogenなどの組み合わせはどのように機能しますか？

4

6 に答える 6

19

質問1と2に対する回答があります。

  1. これは本当です。ただし、バージョン2.8以降、Seasideは厳密に「継続ベース」のフレームワークではなくなりました。Seasideは、フローモジュールでのみ継続を使用します。Seaside 3.0以降、フローモジュールはオプションですらあります。また、Seasideは2005年から強力なJavascriptをサポートしています。これは、主流のフレームワークがJavascript機能を追加し始めるずっと前のことです。現在、SeasideにはJQueryとJQueryUIのサポートが組み込まれています。
  2. もちろん、これはセッションオブジェクト内に何を格納するかによって異なりますが、通常、セッションは小さいです（20 KiB未満）。アプリケーションのメモリプロファイラーを使用して、正確なメモリ消費量を決定します。
于 2010-07-08T05:58:13.410 に答える
15

そして、新しい海辺の本があります：http: //book.seaside.st/book

于 2010-07-08T09:35:32.620 に答える
11

Smalltalkでは、Seasideの他に、考慮すべき3つのWebフレームワークがあります。

どちらも後で効果的に3つのような制御フローを解決しますが、継続する必要はありません。どちらも非常に強力なAjax統合を備えており、実際には、Ajaxを使用していることに気づきません。

どちらもメモリ消費量を適切にスケーリングします。10.000セッションはAida/Webで220MBを費やします。これは、セッションあたり約23KBであり、セッションあたりわずか400Bまでさらに最適化できます。これは、単一のSmalltalkイメージから多くのWebサイトを実行できるだけでなく実行できることを意味します。もちろん、本当に必要なときに、いつでも負荷分散ソリューションにアップグレードできます。これは私の経験から、めったに必要とされないものです。

Ruby on Railsと比較すると、私の友人は、販売しているすべてのWebショップサイトに最初は50MBのメモリが必要だと不満を漏らしていました。次に、彼はAida / Webソリューションに目を向けました。そこでは、画像にほぼ同じMBが必要ですが、追加のWebショップサイトごとにわずか数KBが必要です。

于 2010-07-08T05:55:28.503 に答える
11

優れた抽象化セットを備えたSmalltalkIDEで作業することの生産性は、エンジニアリングが支配的なプロジェクトにおける他のすべての問題よりも重要であることがわかりました。これは、（SSDに接続せずに）単一のサーバー上に約100人の（同時に、ただしヘビーではない）ユーザーがいる中小企業のエンタープライズシステムとしてうまく機能します。2007年以降：

  • Seasideは、htmlワークフローからjavascriptワークフローに切り替えることができることを示しています。
  • Seasideは多くの異なるSmalltalkに移植されています。
  • GemstoneがGLASSをリリースするのを見てきました。

パフォーマンスが大幅に向上した新しい「cog」vmが数週間前にリリースされ、パフォーマンスの向上に大きな期待が寄せられています。

于 2010-07-08T15:08:01.717 に答える
4

Seasideの開発者であるAviBryantは、AJAXはほとんどすべての状況で継続を勝ち取ると述べました。それでも、SeasideとAJAXを使用してかなり強力なアプリケーションを構築することもできます。

Webアプリのアプリケーション部分は、Ajaxを使用して他のフレームワークで非常にうまく実行できます。

現在、Cappuccino-for-ClamatoのようなSeaside統合のSmalltalk-to-Javascriptフレームワークが欠落していると思います。Smalltalkを使用して実際のJavascriptアプリを作成できるようにしたいと思います。

于 2010-07-09T14:43:53.763 に答える
4
  1. Javascriptは素晴らしいですが、サーバー側で（Seasideで許可されているように）クリーンで安価な方法で複雑なワークフローを処理できるため、Javascriptが廃止されるのを防いでいます。経済性と実用性は、短期的および長期的に利益をもたらすものです。しかし、これを要約で伝えることにはまったく価値がありません。正確なアプリケーションについて話し合い、海辺が競争上の優位性の一部であるかどうかを判断して、揺るぎない方程式を形成する必要があります（そしてその理由を知る必要があります）。
  2. Seasideを使用したワークロードのスケーリングについて、簡単な答えは、地獄のようにスケーリングできるということです（長い答えについては、ここで私の答えを確認してください：Seasideはスケーリングしますか？）。
  3. 答えられない男:)あなたが本当に尋ねようとしていることのバリエーション

週末に何かの試作品を作るのが一番いいと思います。

2日間でプロトタイプを作成でき、注目を集めることができ、海辺でプロトタイプを作成する開発経験を楽しんだ場合は、次のことの基礎ができます。

それはあなたの時間だけかかります（あなたはアマゾンサーバーで公開することができます）。

ところで、今週私はそのプロトタイプを手作業で作ったスタートアップについて聞いた（すべてが静的で、手動で処理した）。かなり素晴らしく、クレイジーで安い。彼らが（持っていた）アイデアに十分な牽引力があると感じたとき、彼らはアプリを実装しました（どんな技術でも、海辺の開発者にとっては挑戦ではないと確信しています）

于 2011-01-17T20:33:10.257 に答える