<div dir="ltr">Greetings,<div dir="ltr"></div><div><br></div><div>In my arena, I have found that there is only interest in web applications these days, so my focus is there.</div><div><br></div><div>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@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...</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1.  All graphical rendering and processing are done at the front-end (the browser).</div><div><br></div><div>2.  The back-end serves up only two things:</div><div><br></div><div>a.  Static HTML, JavaScrip, and CSS (images, PDF, etc.) files.</div><div><br></div><div>b.  The front-end and back-end communicate with <i>stateless</i> REST services.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I have the following question (which I understand are really more Squeak/Pharo questions but I think this community would know the answers):</div><div><br></div><div>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)?</div><div><br></div><div>2.  Can I run Seaside headless?</div><div><br></div><div>3.  The Seaside book at <a href="http://book.seaside.st/book/advanced/restful/nutshell">http://book.seaside.st/book/advanced/restful/nutshell</a> 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?</div><div><br></div><div>I've wanted to use Smalltalk for over 30 years to do real work that I need.  Perhaps I can.</div><div><br></div><div>Thanks!</div><div><br></div><div>Blake McBride</div><div><br></div><div><br></div><div><br></div><div><br></div></div>