海边仍然是有效的选择吗? [英] Is Seaside still a valid option?

问题描述

Seaside 刚刚发布即将推出的3.0版本，因此它再次出现在我的雷达上.当我目前正在考虑为将来的项目使用哪种Web框架时，我想知道是否需要考虑这一点. las，Seaside的大部分宣传活动始于'07，它可能是网络的一两个世代.所以我希望这里的社区能够回答一些问题

Seaside just released a release candidate for the upcoming 3.0 version, so it appeared on my radar again. As I'm currently pondering what web framework to use for a future project, I wonder whether it's something to consider. Alas, most of the publicity for Seaside is from '07, which is probably one or two generations for the web. So I'm hoping that the community here can answer some questions

1. 当大多数工作流大多使用HTML时(例如，表格提交.对于当今的JavaScript繁重的环境，这似乎不再值得了.

1. Continuation-based frameworks were pretty great when most of your workflow was mostly in HTML, e.g. form submits. For today's JavaScript-heavy environments, that hardly seems worthwhile anymore.

Squeak是否能够处理合理的工作量?从这里和其他地方的其他问题来看，从长远来看，似乎要适当扩展另一个实现(Gemstone等)可能会更好，但是我不知道这有多远.会议似乎很昂贵.

Is Squeak able to handle a reasonable workload? From other questions here and elsewhere, it seems that for proper scaling another implementation (Gemstone etc.) would probably fare better in the long run, but I don't have a proper idea how far away that is. Sessions seem to be rather expensive.

我知道比较很难，但是您在网上找到的大多数文章都是Seaside和Rails并排放置的.像Scala/Lift，Clojure/Compojure或Erlang/Nitrogen之类的组合又如何呢?

I know that comparisons are hard, but most of the articles you find on the net set Seaside and Rails side by side. How would combinations like Scala/Lift, Clojure/Compojure or Erlang/Nitrogen do instead?

推荐答案

我对第一个问题和第二个问题有答案:

I have answers to question one and two:

1. 这是真的.但是，从2.8版开始，Seaside不再是严格的基于延续"的框架. Seaside仅在流程模块中使用延续.从Seaside 3.0开始，流量模块甚至是可选的.另请注意，自2005年以来，Seaside就一直具有强大的Javascript支持，这比主流框架开始添加Javascript功能还早.今天，Seaside内置了JQuery和JQueryUI支持.
2. 当然这取决于您在会话对象中存储的内容，但是通常会话很小(小于20 KiB).在应用程序中使用内存探查器来确定确切的内存消耗.

这篇关于海边仍然是有效的选择吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！