Re: [vwnc] Web and Persistence Framework Recommendations?

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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.
> The most simple thing to do in AppeX is naturally to use HTML5 and vanilla JavaScript to build an application.
> However AppeX, as a JavaScript IDE and web application hosting environment, attempts to remain agnostic as to whatever JavaScript libraries the developer wishes to incorporate in their application.  There are examples of using external libraries scattered throughout the examples, e.g. in the Genealogy and mobile examples.


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

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

Regards,

--
Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside