What are the differences between the three Smalltalk web application frameworks?
Some starting points:
I'm just trying to decide which framework is appropriate for each kind of application.
I can only answer for Seaside:
Target: Seaside targets complex web applications with focus on reusability and development productivity. There is automatic session state management and back-button support. The two free online books Dynamic Web Development with Seaside and Seaside Tutorial provide documentation.
Weakness: For RESTful URLs you have to do some extra work.
Clean URLs: For RESTful URLs you have to do some extra work, but it can be worth it (e.g. Pier).
AJAX: There are plenty of AJAX libraries integrated in Seaside (jQuery, jQueryUI, Prototype, script.aculo.us, ...). The integrations give you full access to these libraries from within Smalltalk. New libraries can be easily integrated, e.g. JQueryWidgetBox.
Persistency: Seaside is a web application framework, not a persistency framework. You can use whatever persistency solution fits you the best, e.g. GemStone, GOODS, GLORP, ...
Also see these other questions/discussions on StackOverflow:
I can say something on the Iliad side:
Sweet spot(s): It handles AJAX painlessly. For me, that was the turning point that made me switch to Iliad. Also, it's so small and non-bloated that you can read the whole code in a day and have a grasp on how it works.
Weaknesses: The community is also very small. This results in a lack of documentation, additional modules or pre-made widgets. OTOH, small communities tend to be willing to help each other more eagerly, so pretty much all your doubts can be solved by asking at the mailing list.
URLs: Well, since all calls in Iliad are AJAX by default, the URL stays clean the whole time.
Ajax: Yep. For free and by default. You just #markDirty a widget and it'll update automatically. Dependencies are as easy to define as sending #addDependantWidget: to a widget, so that when the first is marked dirty, both will be updated. Also, if the client doesn't have a javascript capable browser, all calls will fall back to regular HTTP requests automatically.
Persistence: No preference. Since the model is separated from the framework (I think this applies for the three frameworks) you can still follow the same guidelines you would for Aida or Seaside.
And for Aida/Web:
Sweet spots: Realtime web support out of the box, for both content websites and complex web apps, HTML5 and mobile support, web server included so it works immediately after installation, you can serve many virtual websites from the same image.
Weaknesses: lack of documentation, small community
URLs: clean REST-like URLs all the time, because Aida follows from the start the moto: every domain object can have its URL (also by Alan Kay) and domain object can even choose its URL by itself.
Ajax: Seamlessly integrated, you don't see it anymore, all is just there. To refresh some element on webpage you simply call e update. No need to know any jQuery or some other JavaScript. Same goes for realtime web apps as well. WebSocket protocol is default communication channel on supported browsers to exchange JSON messages between browser and Aida based server.
Persistence: Image based persistence with automatic snapshot every hour is turned on by default. Gemstone/GLASS support provided for the next step. Relational/other DB is a duty of domain level, if needed.
For more:
For some persistency solutions for Seaside, there is a page. Most of the solutions there are independent of Seaside.
© 2022 - 2024 — McMap. All rights reserved.
