I use Jerry's comment to "extend" his reply by adding my opinion about
some of the topics mentioned.
On Wed, Jan 22, 2020 at 11:04 PM Jerry Kott <[hidden email]> wrote:
> I love Seaside for its HTML semantics and ease of HTML generation. Almost everything else about it is dated and a PITA. The JS frameworks and libraries are too many and are moving too fast for the Smalltalk/Pharo/Seaside community to keep up with. As a result, even the most popular ones are way outdated.
> Take jQuery as an example: the jQuery library included with Seaside 3.2 in VW 8.3.1 is version 1.11.3 (from 2015). Even the most recent Seaside 3.3 loaded in Pharo 8.0 by default, has jQuery 3.3.1 which is approximately two years old. The current version is 3.4.1. It’s similar with every single JS library I know of, if it even has a Seaside wrapper. Many of the JS libraries release new versions to address security vulnerabilities. Thus, no matter which JS library/framework Seaside uses, it’s either outdated or insecure. We just don’t have enough developers in the community to keep up. This makes the development of secure web applications with Seaside difficult if not impossible.
I've been working with Seaside for the last 6 years, and worked with
it before too (since v 1.0), and IMO Seaside is is still the best
option in Smalltalk for complex interfaces given you do Server-Side
For the last 3 years I've been also using VW version of Seaside, which
is outdated, so I upgraded jQuery, Bootstrap 3, FontAwesome and a
whole set of libraries that work perfectly today. Plus a lot of other
libraries that we either use as a WAFileLibrary or link to the static
files using a file responder. One thing is to ship with a version with
a minor version change (as the 3.4.x vs 3.3.x) versus being one or two
major releases behind (as the case of the version shipped with VW).
Which in any case, except for Smalltalk wrappers for some of the
abstractions, could be solved by referencing a static url instead of
using the FileLibraries provided by Seaside.
But today you can build large scale applications developed with
Seaside, most of the scaling goes to middleware, cointainers and/or
reverse proxies architectures, instead of a single VM serving all the
requests serially (which only work in very small scales).
Seaside in VW seems outdated (albeit still useful) and no longer
maintained by Cincom (by whatever reason), and that would be the only
reason to advice against it if you don't know how to keep it up to
Which is a pity, since I find VisualWorks's very robust to work with
Seaside, with the best management of breakpoints within clousures,
continuations and stack management compared with other dialects.
> When AppeX was first designed, our goal was to avoid the pitfalls of web framework integration cost that Seaside has. This was expressed by the motto “Play well with others”.
> In contrast, AppeX allows loading of any JS framework without the need for Smalltalk / AppeX wrappers, and as you pointed out, its integrated JS code management capabilities allow developers to keep the JS code for their applications as soon as a new version of a library is out. I think this is the single most important advantage of AppeX over Seaside.
This I don't understand, you can use any library you want from
Seaside, but it only has costs if you want to build Smalltalk classes
around them, jQuery being the canonical example.
But in my experience, we always ship static js along applications, and
our Seaside app uses these JS or the JS uses other third party
libraries without issues.
> The other aspect is that the JS code one can (but doesn’t have to) write the JS application code using the OO paradigm Smalltalkes know and love. Most of the JS ecosystem is not object oriented, or is a bastardized version of OO. AppeX allows you to design JS classes in hierarchies, using inheritance and polymorphism just like we do in Smalltalk. Even though one must use the JS syntax (supported by the tools as you mentioned), staying within the OO mental model and the VW IDE to write a JS app for the client browser more than makes up for that shortcoming ;).
AppeX, as mentioned, takes a different, and interesting "polyglot"
approach, aimed at Single Page Application (aka SPA's), but IMO lost
its edge for today SPA/PWA's frameworks such as React, Vue.js or
Angular (just to mention to most prominent), because they have a
different development pipeline and deployment, since there is no
"backend ready" tool for a React.js front end. So you also have to
develop your own too. Try using Grunt, Webpack or a similar tool with
I admit that while I read the documentation about AppeX I never used
it for any "toy project" (as I did with other frameworks, Smalltalk or
> However, if one needs an internal web app not exposed to the Internet without all the JS mumbo/jumbo, the productivity of Seaside is hard to beat.
Seaside is highly productive, but there is no silver bullet and it has
its pitfalls too, like the heretic use of HTTP for non-idempotent
requests, the lack of a "convention" to easily structure an
application and get nice URLs by default, and being 100%
server-session dependant. So everything comes with a tradeoff.
As I see it today, there are two "most efficient" (or less
inefficient) ways of doing Smalltak web development today:
SSR) Server Side Rendering, either by using Seaside or any other HTTP
framework with static URLs with some templating (if the workflow is
limited or fixed)
API) REST Server in Smalltalk, frontend in JS (React/Vue/Angular).
There are hybrids there (e.g. Seaside using React/Vue components), but
are very specific use cases.
As for persistance, if you go for RDBMS, VisualWorks's Glorp is still
the canonical version, and works pretty well, either the SSR model of
Seaside (one Glorp session per Seaside session) or by pooling sessions
in a REST API server.
I leave the security part aside, since there is not much public
assessment of any of these, I have my experience and good practices
about it, but since Jerry is OSCP I'd love to know his insight about
security in Smalltalk web applications in general.
Esteban A. Maringolo
> From: Degen, Vladimir [mailto:[hidden email]]
> Sent: Wednesday, 22 January 2020 9:14 a.m.
> To: Stewart MacLean <[hidden email]>; [hidden email]
> Subject: RE: [vwnc] Web and Persistence Framework Recommendations?
> Hi Stewart,
> AppeX is VW's ES6/HTML5 web application framework for single page web application building.
> In AppeX-Examples you'll find "mobile device friendly content" examples and persistence examples (e.g. the Genealogy example).
> There is a wizard for quickly creating a web application with persistence (Tools...Web Development...Create a Web application).
> Also, you can take a look in the WeAppDevGuide.pdf under the topic "Create an Application" in the chapter entitled "Scaffolding".
> Vlad Degen, Cincom
> p.s. Feel free to ask further AppeX/Scaffolding questions!
> From: Stewart MacLean <[hidden email]>
> Sent: Tuesday, January 21, 2020 2:04 PM
> To: [hidden email]
> Subject: [vwnc] Web and Persistence Framework Recommendations?
> Hi All,
> I’m about to embark on developing a web based system to implement a publish/subscribe business model.
> It has been some time since I’ve updated to the latest version of VisualWorks so I am interested in any recommendations/observations on which framework to use for
> 1) the web UI front end
> 2) the data persistence back end
> I don’t envisage a high transaction load, but the data model will potentially be complex. I have experience with SQL/Relational Databases, but would prefer to stay in ObjectLand if feasible. Another consideration is that I may want to use a mobile App to interface to the server as well.
> Thoughts/suggestions much appreciated.
seaside mailing list
On Thu, Jan 23, 2020 at 3:40 PM Degen, Vladimir <[hidden email]> wrote:
> Hi Esteban,
> First, you'll be happy to hear that we just recently updated VW Seaside to version 3.3.4.
Great! Any ETA of its availability?
(I have no rush to migrate the current code, just to know.)
> We are of course glad to hear that you consider VW "very robust to work with Seaside, with the best management of breakpoints within closures, continuations and stack management " :).
I find it surprisingly stable. To the point sometimes I forget the
save the image during a whole workday (moral hazard? :-) ).
> On to AppeX.
> Here are a few of the new/improved features of AppeX:
> 1. automatic synchronization between internal JS code and external files so that, for instance, a developer can change their code in a chrome debugger and have those changes propagate to the JS refactoring browser in Smalltalk
How would this work? If you change something in the debugger you're
working on a read-only version of the served resource (from a HTTP
> 4. AppeX's build and deployment workflow has also been undergoing improvement; e.g. one can set on automatic JS code minification, and bundling together of JS files to serve as a single file during deployment.
Doesn't loading all the JS resources into the image make the image
grow, and so the publishing/versioning of the packages containing it?
I found that accidentally selecting the "content" selectors in some of
Seaside File Libraries would block the UI for a while until the whole
content was parsed.
Another remarkable point is that SiouX supports HTTP/2, which is
useful if you serve directly from the VW VM.
Is there a way to make the request/response multithreaded at the VM level?
Esteban A. Maringolo
seaside mailing list
|Free forum by Nabble||Edit this page|