[Seaside] Seaside done?

[Esteban Maringolo]

Hi Jerry,

You pointed to several things in your email, and not to start a
discussion on each of them, but I'd like to add my remarks.

On Thu, Apr 9, 2020 at 6:40 PM Jerry Kott <jkott at image-ware.com> wrote:
>
> I concur. Seaside is a great framework, and those who build and maintain it deserve our thanks.

> Seaside security is fairly poor. It doesn’t offer any protection against CSRF attacks or session hijacking.

It currently does not, but could be added pretty easily, about session
hijacking it depends on how you implement the session tracking.

> The built-in basic authentication only supports MD5-hashed password which has not been considered secure since 2004. Using other authentication mechanisms is non-trivial and can lead to deploying catastrophically insecure application (don’t ask me how I know).

How do you know? :)
I'm still waiting for the summary of your Smalltalk security survey
(more than a year ago, AFAIR).

> Seaside use of third-party JS libraries gives you two options: use a Seaside library that wraps the original JS, or use JS directly.
> The first option emits JS code that is several years behind (current Seaside jQuery is from 2017?),
>  in most cases with known vulnerablities that are fairly easily exploitable.
> The second option robs the developer of all the nice application state integration capabilities.
> Both options lead to incredibly ugly JS code on the client side. Now - some people think that’s not a problem.
> I disagree - in a modern web application you need to be able to develop and debug at least partially in the web browser,
> and your JS readability will directly affect both your productivity and the quality of your code.

This is simply not true. Or not fair. :)
I've been working with several JS libraries, for some years, some as
part of WAFileLibrary (it is, embedded in Smalltalk code) and others
externally, and for performance I concat and minify some of the
external JS.
The generated JS by some library wrappers is not unreadable, on the
contrary, it is generated consistently the same, and it also depends
on how you architecture your app.
If you ever try to read the JS output of webpack or any "modern"
application it will be far more unreadable.

> Last but not least, handling of volume has been issue.
> I don’t have experience with a deployed Seaside app on Pharo,
> but I know that on VW you quickly reach a point where your app performance
> suffers even with a couple hundred users.

Here I kind of agree, even "a couple hundred" seems like a lot in my experience.
Of course it depends on the kind of application, but for a typical
backoffice kind of app, database bound, my threshold in Pharo was
always around ~20 users... per VM. My solution was to have several
worker VMs for this, and other worker VMs for REST APIs.

> With GS, you need a multitude of Gems to handle even relatively modest load.
> I think this would be probably the worst weakness - today’s web apps are built for tens of thousands of concurrent users,
> and even with the use of a load balancer, this would be a limiting factor for anyone
> considering the deployment of a globally reachable web app.

I don't know if there is anything built with Seaside that handles tens
of thousands concurrent users (it is C10K), but I don't think this has
to do with Seaside itself. It's a matter than maybe no Seaside
application was that successful. Going from 100, to 1K to 10K is not
just technical. Maybe Allstocker is the most recent large-scale
success, and you can read how they managed to do it [1].


> Would I consider Seaside for a low-volume, tightly controlled internal web app?
> Absolutely. I would even use it for a publicly accessible web app in a geographically limited market and no sensitive data.
> But despite my admiration for the work that has been done, I would advise anyone against using it for anything ’serious’ on the open internet.

> In that sense, I think Seaside is ‘done’ and not going anywhere.
> It can be maintained and incrementally improved for sure,
> but I don’t expect any new features that would make it feasible
> for a large scale app delivered to the masses.

I think the scalability comes from both the technology and the
architecture, I haven't seen a SSR app written fully in Go, and in my
circle I yet have to see a large, corporate-scale, React/Vue/Angular
application like the ones I've seen written in Seaside, Java or even
ASP (In all verisons).

The Seaside is not going nowhere, it's the tide that comes and goes :-)

Regards!

[1] https://pharoweekly.wordpress.com/2016/10/17/allstocker-internals/


Esteban A. Maringolo