[Seaside] [vwnc] Web and Persistence Framework Recommendations?

Thu Jan 23 18:22:48 UTC 2020

Very good points, Esteban.

Referencing a static URL is always an option - it would be interesting if someone writes a blog post or something - how does it affect the Smalltalk wrapper compatibility? In a minor version it should be not an issue, but going from (e.g.) jQuery 1.11.3 to 3.4.1 - I think that can be a significant effort. Keeping the versions current and synchronized in your development / test/ production environments can also be a challenge. I have seen an ‘unexplainable’ differences in behaviour between a development environment (VW) and production (GemStone) until it became apparent that the jQuery versions were out of sync. But I digress.

I think if the Smalltalk wrappers are out of sync with a statically referenced library, and you have to drop down to writing JS by hand, the AppeX experience if better than Seaside because of the seamless IDE integration. Naturally, this will depend on the complexity of the app (SPA vs. the traditional ‘each click loads a page’), your familiarity with the tool, etc. As you say: there are always trade offs to consider.

As for publicly available security assessments - it’s something that has been on my mind for quite some time. I have done some work in that direction but nothing official yet. Just being busy. Hopefully a more concrete announcement can be made some time soon.

Jerry Kott, OSCP
Principal, Imageware Corporation <https://image-ware.com/>

Security. By choice and by design.

This message has been digitally signed.
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5

> On 23-01-2020, at 8:14 AM, Esteban Maringolo <emaringolo at gmail.com> wrote:
> 
> 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 at 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 at cincom.com]
>> Sent: Wednesday, 22 January 2020 9:14 a.m.
>> To: Stewart MacLean <stewart at xtra.co.nz>; vwnc at 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 at xtra.co.nz>
>> Sent: Tuesday, January 21, 2020 2:04 PM
>> To: vwnc at 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
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200123/af1152fb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200123/af1152fb/attachment-0001.sig>