海边仍然是一个有效的选择吗?

发布于 2024-09-08 06:18:09 字数 587 浏览 11 评论 0原文

Seaside 刚刚发布即将推出的 3.0 版本的候选版本,所以它又出现在我的雷达上。由于我目前正在考虑将来的项目使用哪种 Web 框架,我想知道是否值得考虑。唉,《Seaside》的大部分宣传都是从 07 年开始的,对于网络来说可能已经是一两代了。所以我希望这里的社区能够回答一些问题

  1. 当您的大部分工作流程主要采用 HTML 格式(例如表单提交)时,基于连续性的框架非常好。对于当今大量使用 JavaScript 的环境,这似乎不再值得了。

  2. Squeak 能够处理合理的工作负载吗?从这里和其他地方的其他问题来看,从长远来看,为了适当扩展另一个实现(Gemstone 等)可能会表现得更好,但我不知道那有多远。会话似乎相当昂贵。

  3. 我知道比较很困难,但是您在网上找到的大多数文章都将 Seaside 和 Rails 放在一起。像 Scala/Lift、Clojure/Compojure 或 Erlang/Nitrogen 这样的组合会如何做?

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. 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.

  2. 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.

  3. 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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

去了角落 2024-09-15 06:18:09

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

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

I have answers to question one and two:

  1. This is true. However since version 2.8 Seaside is not a strictly "continuation-based" framework anymore. Seaside uses continuations in the flow module only. Since Seaside 3.0 the flow module is even optional. Also note that Seaside has strong Javascript support since 2005, this is long before mainstream frameworks started to add Javascript functionality. Today Seaside comes with JQuery and JQueryUI support built-in.
  2. Of course that depends on what you store within your session objects, but typically sessions are small (less than 20 KiB). Use the memory profiler in your application to determine the exact memory consumption.
疾风者 2024-09-15 06:18:09

还有一本新的海边书:http://book.seaside.st/book

And there is a new seaside book: http://book.seaside.st/book

信愁 2024-09-15 06:18:09

我发现在具有良好抽象集的 Smalltalk IDE 中工作的生产力超过了工程主导项目中的所有其他问题。对于一家在单个服务器上拥有大约 100 个(同时但不是大量)用户(无需使用 SSD)的小公司来说,它可以作为企业系统运行良好。自 2007 年以来:

  • Seaside 已证明能够从 html 工作流程切换到 javascript 工作流程;
  • Seaside 已被移植到许多不同的 Smalltalks;
  • 见过Gemstone发布GLASS;

性能大幅提高的新“cog”虚拟机已于几周前发布,并显示出提高性能的巨大前景。

I find the productivity of working in a Smalltalk IDE with a good set of abstractions outweights all other issues in engineering dominated projects. It works well as an enterprise system for a small company with about 100 (simultaneous, but not heavy) users on a single server (without going to SSD). Since 2007:

  • Seaside has shown to be able to make the switch from html workflows to javascript ones;
  • Seaside has been ported to a lot of different Smalltalks;
  • Has seen Gemstone release GLASS;

The new 'cog' vm with much improved performance has been released a few weeks ago and shows great promise for improved performance.

草莓味的萝莉 2024-09-15 06:18:09

在 Smalltalk 中,我们现在需要考虑三个 Web 框架,除了 Seaside 之外,还有

两者后来都有效地解决了类似三的控制流,但不需要延续。两者都具有非常强大的 Ajax 集成,实际上您不再意识到您正在使用 Ajax。

两者在内存消耗方面也都能很好地扩展。 10.000 个会话在 Aida/Web 中花费 220MB,即每个会话大约 23KB,可以进一步优化至每个会话仅为 400B。这意味着您不仅可以从单个 Smalltalk 映像运行多个网站。当然,当您确实需要时,您可以随时升级到负载平衡解决方案。根据我的经验,这是很少需要的。

与 Ruby on Rails 相比,我的一位朋友抱怨说,他销售的每个网上商店网站最初都需要 50MB 内存。然后,他转向 Aida/Web 解决方案,其中图像需要大约相同的 MB,但每个额外的网上商店站点只需几 KB。

In Smalltalk we have now three web frameworks to consider, besides Seaside also

Both later effectively solve three-like control flow, but without needing continuations. Both also have a very strong Ajax integration, actually you don't realize anymore that you are working with Ajax.

Both also scale in memory consumption well. 10.000 sessions spend 220MB in Aida/Web, that is about 23KB per session, which can be further optimized down to mere 400B per session. This means, that you can run not only but many websites from the single Smalltalk image. Of course you can always upgrade to load balancing solution, when you really need. Which is from my experience very rarely needed.

Comparing to Ruby on Rails, a friend of mine complained that he needs 50MB of memory initially for every webshop site he is selling. He then turned to the Aida/Web solution where he needs about the same MB for the image, but then just few KB for every additional webshop site.

一曲爱恨情仇 2024-09-15 06:18:09

Seaside 的开发者 Avi Bryant 表示,AJAX 在几乎所有情况下都能胜任延续。尽管如此,您也可以使用 Seaside 和 AJAX 构建相当强大的应用程序。

Web 应用程序的应用程序部分可以使用 Ajax 在其他框架中很好地完成。

我认为目前缺少像 Cappuccino-for-Clamato 这样的 Seaside 集成 Smalltalk-to-Javascript 框架。我希望能够使用 Smalltalk 构建真正的 Javascript 应用程序。

Avi Bryant, the developer of Seaside, said that AJAX triumphs continuations in almost all situations. Nevertheless, you can build reasonably powerful applications with Seaside and AJAX, too.

The Application part of a Web-App can be done in other frameworks quite well using Ajax.

I think a Seaside integrated Smalltalk-to-Javascript Framework like Cappuccino-for-Clamato is missing, currently. I'd like to be able to build real Javascript-Apps using Smalltalk.

梦一生花开无言 2024-09-15 06:18:09
  1. Javascript 非常棒,但能够在服务器端以一种干净、廉价的方式处理复杂的工作流程(正如 Seaside 允许你做到的那样)可以防止它过时。经济性和实用性是能够在短期和长期内带来回报的东西。但抽象地讲述这一点毫无价值。您应该讨论一个精确的应用程序,并确定海边是否是您的一系列竞争优势的一部分,以形成一个令人震惊的方程式(并知道为什么)。
  2. 关于使用 Seaside 扩展工作负载,简短的答案是您可以像地狱一样扩展它(对于长答案,请在此处检查我的答案:
  3. 太无法回答了,伙计:) rty是你真正想问的问题的一个变体,

我认为你能做的最好的事情就是在周末制作出一些东西的原型。

如果你可以在两天内完成一个原型,并且你可以吸引一些注意力,并且你喜欢在海边做的开发经验,那么你将为你的下一件事情奠定基础。

它只花费您的时间(您可以在亚马逊服务器上发布)。

顺便说一句,本周我听说一家初创公司手工制作原型(一切都是静态的,他们手动处理东西)。非常惊人、疯狂而且便宜。当他们觉得自己的想法有足够的吸引力时(他们已经拥有了),他们就实现了该应用程序(无论使用什么技术,我确信对于海边开发人员来说这都不是什么挑战)

  1. Javascript is awesome but being capable of dealing with complicated workflow in a clean cheap way in the server side (as Seaside allows you to) is preventing it to become obsolete. Economy and utility are things that gives return in the short and long run. But telling this in the abstract has no value at all. You should be talking about a precise application and deciding if seaside is part of your bunch of competitive advantages to form an equation that rocks (and knowing why).
  2. About scaling workload with Seaside, the short answer is that you can scale it like hell yah (for the long answer check my answer here: Does Seaside scale?).
  3. too unanswerable man :) rty a variation of what you're really trying to ask

I think the best thing you can do is a prototype of something in a weekend.

If you can do a prototype in two days and you can capture some attention and you enjoyed the developing experience of doing it with seaside then you'll have the foundation of your next thing.

It costs only your time (you can publish in an amazon server).

BTW, this week I've heard about a startup that made its prototype by hand (was everything static and they processed stuff manually). Pretty amazing and crazy and cheap. When they felt that they had enough traction on the idea (which the had) they implemented the app (with whatever tech, I'm sure is no challenge for a seaside developer)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文