Hi Stewart,
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 <jkott(a)image-ware.com> 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
Rendering.
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
date.
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
AppeX.
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
not).
> 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.
Regards,
Esteban A. Maringolo
>
> Stewart
>
> From: Degen, Vladimir [mailto:VDegen@cincom.com]
> Sent: Wednesday, 22 January 2020 9:14 a.m.
> To: Stewart MacLean <stewart(a)xtra.co.nz>; vwnc(a)cs.uiuc.edu
> 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 <stewart(a)xtra.co.nz>
> Sent: Tuesday, January 21, 2020 2:04 PM
> To: vwnc(a)cs.uiuc.edu
> 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.
>
> Cheers,
>
> Stewart
>
>
