[Seaside] Questions about seaside and pharo

Blake McBride blake1024 at gmail.com
Thu Jun 14 14:39:16 UTC 2018


Greetings,

In my arena, I have found that there is only interest in web applications
these days, so my focus is there.

I have been highly attracted to Smalltalk since Smalltalk-80 came out.
Unfortunately, I couldn't afford the system in the early days and I was
caught up in other technology in later days.  I've kept an eye on Smalltalk
over the years.  The number one thing that's kept me from Smalltalk was
portable widgets such as textbox, radio buttons, checkboxes, dropdowns,
etc.  But noseaside at lists.squeakfoundation.orgw, as I said, the world has
moved on to web-apps so all those widgets aren't important anymore.  Java
was designed as a front-end solution but found success on the back-end.
Perhaps the same will be true of Smalltalk...

The browser world has evolved very significantly these last several years.
Old web architectures that made a lot of sense then aren't really
applicable anymore.  For example, early on browsers were slow and had a lot
of differences.  It made sense to generate the HTML on the back-end and
send it to the browser.  This is no longer the case!  Javascript is very
fast now, and HTML has become substantially powerful and standardized.
Granted that there is a lot more work to be done, but it has reached a
practical level.

Today's model is different.  Push all the display logic to the browser via
tools like React, Angular, etc.  This means less load on the back-end and a
clean separation between the logic and the display.  So, today's model
looks like this:

1.  All graphical rendering and processing are done at the front-end (the
browser).

2.  The back-end serves up only two things:

a.  Static HTML, JavaScrip, and CSS (images, PDF, etc.) files.

b.  The front-end and back-end communicate with *stateless* REST services.

This minimizes the back-end load and allows companies to anticipate
industry changes since the front-end can be changed independently of the
back-end, i.e. their investment in the back-end is saved.

My impression is that Seaside was designed for the era when the back-end
produced the front-end HTML.  Although, I am also under the impression that
this aspect of Seaside need not be utilized, and that Seaside can serve
static files and provide REST services.  So, perhaps Seaside is a
potentially useful solution for today's needs.

I have the following question (which I understand are really more
Squeak/Pharo questions but I think this community would know the answers):

1.  Does Pharo support multiple OS/native threads?  (I know the difference
between native threads, cooperative threads, and single threading.)  I
believe Pharo is of the cooperative thread sort.  Node has a lot of design
features that make it run in a single thread very efficiently.  If Pharo
doesn't have native threads, does it have design features that make it
especially efficient with a single OS thread (like node)?

2.  Can I run Seaside headless?

3.  The Seaside book at
http://book.seaside.st/book/advanced/restful/nutshell talks about REST
services in two models but seems to only give an example for the case I am
not interested in.  Is there a tutorial for the REST centric core model?

I've wanted to use Smalltalk for over 30 years to do real work that I
need.  Perhaps I can.

Thanks!

Blake McBride
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20180614/b129ae79/attachment.html>


More information about the seaside mailing list