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@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
On 06/14/2018 07:39 AM, Blake McBride wrote:
Old web architectures that made a lot of sense then aren't really applicable anymore.
They'll always be applicable; the wheel of smart client dumb client will never stop turning. Server based page rendering isn't outdated, it's not an either or situation, it's an and situation. React and Angular have not replaced server rendering and Ajax updates of fragments, they're merely additional options you now have. Perfectly fine and functional applications can and are still being done in what you call the old way and they always will be.
Give it a few years, the wheel will turn again and dumb clients will come back into fashion as they always do and have since the green screen mainframe days.
- Does Pharo support multiple OS/native threads?
No. What you do is run multiple processes on the backend and load balance between them via a proxy. Apache/haproxy, whatever.
- Can I run Seaside headless?
Of course.
- 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?
Frankly I wouldn't use Seaside if I were attempting RESTful services, I'd find another option. There's probably already a nice Smalltalk REST framework, but if not it wouldn't take much effort to hack up something like Sinatra in Smalltalk for doing it.
For Rest - there is a SeasideRest framework, but if its strictly a restful endpoint you want, maybe Teapot might be a better starring point (there are a few tutorials for it - but its pretty simple). https://github.com/zeroflag/Teapot https://github.com/zeroflag/Teapot
If you are really into Ajax stuff - Seaside is still pretty good, but there is also a new framework called Willow, that is pretty good for doing more UI Ajax’y stuff with single page applications. There are some good medium articles from the Willow team - e.g. https://github.com/ba-st/Willow https://github.com/ba-st/Willow . I have an example app that also shows how to deploy it to a DigitalOeean server which the guys here pointed me to - its well worth it for £5/m - https://gitlab.com/macta/WillowPagerDuty https://gitlab.com/macta/WillowPagerDuty
Tim
On 14 Jun 2018, at 17:19, Ramon Leon ramon.leon@allresnet.com wrote:
On 06/14/2018 07:39 AM, Blake McBride wrote:
Old web architectures that made a lot of sense then aren't really applicable anymore.
They'll always be applicable; the wheel of smart client dumb client will never stop turning. Server based page rendering isn't outdated, it's not an either or situation, it's an and situation. React and Angular have not replaced server rendering and Ajax updates of fragments, they're merely additional options you now have. Perfectly fine and functional applications can and are still being done in what you call the old way and they always will be.
Give it a few years, the wheel will turn again and dumb clients will come back into fashion as they always do and have since the green screen mainframe days.
- Does Pharo support multiple OS/native threads?
No. What you do is run multiple processes on the backend and load balance between them via a proxy. Apache/haproxy, whatever.
- Can I run Seaside headless?
Of course.
- 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?
Frankly I wouldn't use Seaside if I were attempting RESTful services, I'd find another option. There's probably already a nice Smalltalk REST framework, but if not it wouldn't take much effort to hack up something like Sinatra in Smalltalk for doing it.
-- Ramon Leon
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Thanks, Tim. Teapot looks very interesting!
On Thu, Jun 14, 2018 at 11:40 AM Tim Mackinnon tim@testit.works wrote:
For Rest - there is a SeasideRest framework, but if its strictly a restful endpoint you want, maybe Teapot might be a better starring point (there are a few tutorials for it - but its pretty simple). https://github.com/zeroflag/Teapot
If you are really into Ajax stuff - Seaside is still pretty good, but there is also a new framework called Willow, that is pretty good for doing more UI Ajax’y stuff with single page applications. There are some good medium articles from the Willow team - e.g. https://github.com/ba-st/Willow . I have an example app that also shows how to deploy it to a DigitalOeean server which the guys here pointed me to
- its well worth it for £5/m - https://gitlab.com/macta/WillowPagerDuty
Tim
On 14 Jun 2018, at 17:19, Ramon Leon ramon.leon@allresnet.com wrote:
On 06/14/2018 07:39 AM, Blake McBride wrote:
Old web architectures that made a lot of sense then aren't really applicable anymore.
They'll always be applicable; the wheel of smart client dumb client will never stop turning. Server based page rendering isn't outdated, it's not an either or situation, it's an and situation. React and Angular have not replaced server rendering and Ajax updates of fragments, they're merely additional options you now have. Perfectly fine and functional applications can and are still being done in what you call the old way and they always will be.
Give it a few years, the wheel will turn again and dumb clients will come back into fashion as they always do and have since the green screen mainframe days.
- Does Pharo support multiple OS/native threads?
No. What you do is run multiple processes on the backend and load balance between them via a proxy. Apache/haproxy, whatever.
- Can I run Seaside headless?
Of course.
- 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?
Frankly I wouldn't use Seaside if I were attempting RESTful services, I'd find another option. There's probably already a nice Smalltalk REST framework, but if not it wouldn't take much effort to hack up something like Sinatra in Smalltalk for doing it.
-- Ramon Leon
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Thu, Jun 14, 2018 at 11:19 AM Ramon Leon ramon.leon@allresnet.com wrote:
On 06/14/2018 07:39 AM, Blake McBride wrote:
Old web architectures that made a lot of sense then aren't really applicable anymore.
They'll always be applicable; the wheel of smart client dumb client will never stop turning. Server based page rendering isn't outdated, it's not an either or situation, it's an and situation. React and Angular have not replaced server rendering and Ajax updates of fragments, they're merely additional options you now have. Perfectly fine and functional applications can and are still being done in what you call the old way and they always will be.
Give it a few years, the wheel will turn again and dumb clients will come back into fashion as they always do and have since the green screen mainframe days.
With respect, having personally lived through all of it, there is no "wheel" of technology. Each change was motivated and a response to the available technology at that time. Having a central data store has always made sense. It just wasn't feasible if you were a small company and couldn't affort a $1M data center. A PC was better than nothing. Then, as technolog cought up and networks became available, we used that. Now we have cloud computing that is basically the same as mainframes. It isn't because of some "wheel" or a fickeled industry, it's about needs and feasability. The industry will never return to PC's!
- Does Pharo support multiple OS/native threads?
No. What you do is run multiple processes on the backend and load balance between them via a proxy. Apache/haproxy, whatever.
Given the limits of processors (and the speed of light), short of quantum computers (which are happening), the best scaling choice we have is multi-processing.
Although running multiple processes and a load balancer does work, the world is not moving in that direction. It is a short-term kludge around the problem. A multi-threaded aproach allows the OS to manage resources rather then me (or the Squeak VM) trying to do it on top of the OS. The OS has more global knowledge of what is happening on the machine.
- Can I run Seaside headless?
Of course.
Great!
- 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?
Frankly I wouldn't use Seaside if I were attempting RESTful services, I'd find another option. There's probably already a nice Smalltalk REST framework, but if not it wouldn't take much effort to hack up something like Sinatra in Smalltalk for doing it.
That's disappointing but probably accurate.
Thanks!
Blake McBride
-- Ramon Leon
On 14/06/2018 15:47, Blake McBride wrote:
On Thu, Jun 14, 2018 at 11:19 AM Ramon Leon <ramon.leon@allresnet.com mailto:ramon.leon@allresnet.com> wrote:
> 1. Does Pharo support multiple OS/native threads? No. What you do is run multiple processes on the backend and load balance between them via a proxy. Apache/haproxy, whatever.Given the limits of processors (and the speed of light), short of quantum computers (which are happening), the best scaling choice we have is multi-processing.
Although running multiple processes and a load balancer does work, the world is not moving in that direction. It is a short-term kludge around the problem. A multi-threaded aproach allows the OS to manage resources rather then me (or the Squeak VM) trying to do it on top of the OS. The OS has more global knowledge of what is happening on the machine.
One of the most popular (and hence hyped) platforms like node.js is single-threaded. And it achieves C10K by doing evented I/O, but if you run CPU intensive tasks, then no event will save you from that.
So not everything goes in the multi-threading realm, actually the only thing I see moving in that direction is heavy computation (and to GPU as well).
I agree there is no wheel, but up and downs instead, however these days if you take things to extremes the serverless/lambda approach seems to be the most single threaded thing you can think of.
Regards,
Node is incredibly efficient but it is not efficient because it is single threaded. It is efficient because of its asynchronous architecture - which is a real pain to code for. Since Smalltalk doesn't share this architecture, it also doesn't share in its efficiency (but it's much, much nicer to code for!).
On Thu, Jun 14, 2018 at 2:02 PM Esteban A. Maringolo emaringolo@gmail.com wrote:
On 14/06/2018 15:47, Blake McBride wrote:
On Thu, Jun 14, 2018 at 11:19 AM Ramon Leon <ramon.leon@allresnet.com mailto:ramon.leon@allresnet.com> wrote:
> 1. Does Pharo support multiple OS/native threads? No. What you do is run multiple processes on the backend and load balance between them via a proxy. Apache/haproxy, whatever.Given the limits of processors (and the speed of light), short of quantum computers (which are happening), the best scaling choice we have is multi-processing.
Although running multiple processes and a load balancer does work, the world is not moving in that direction. It is a short-term kludge around the problem. A multi-threaded aproach allows the OS to manage resources rather then me (or the Squeak VM) trying to do it on top of the OS. The OS has more global knowledge of what is happening on the machine.
One of the most popular (and hence hyped) platforms like node.js is single-threaded. And it achieves C10K by doing evented I/O, but if you run CPU intensive tasks, then no event will save you from that.
So not everything goes in the multi-threading realm, actually the only thing I see moving in that direction is heavy computation (and to GPU as well).
I agree there is no wheel, but up and downs instead, however these days if you take things to extremes the serverless/lambda approach seems to be the most single threaded thing you can think of.
Regards,
-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
One thing on-one has mentioned (and this isn’t a smalltalk specific forum) - there are other smalltalks that I think are multi-threaded (I might be wrong though - so other please jump in). While we love Squeak and Pharo for being open source and bit more champions of pushing in new ways - VW, VA and Gemstone are all very viable alternatives if you have a successful application that is hitting the kinds of limits you might be potentially talking about.
I’ve always felt that if successful, the tech can scale in many different ways, and the pleasure of developing in Smalltalk enables much more interesting solutions that avoids the drudgery of npm and webpack/bower or whatever else is the latest build thing.
Tim
On 14 Jun 2018, at 21:02, Blake McBride blake1024@gmail.com wrote:
Node is incredibly efficient but it is not efficient because it is single threaded. It is efficient because of its asynchronous architecture - which is a real pain to code for. Since Smalltalk doesn't share this architecture, it also doesn't share in its efficiency (but it's much, much nicer to code for!).
On Thu, Jun 14, 2018 at 2:02 PM Esteban A. Maringolo <emaringolo@gmail.com mailto:emaringolo@gmail.com> wrote: On 14/06/2018 15:47, Blake McBride wrote:
On Thu, Jun 14, 2018 at 11:19 AM Ramon Leon <ramon.leon@allresnet.com mailto:ramon.leon@allresnet.com <mailto:ramon.leon@allresnet.com mailto:ramon.leon@allresnet.com>> wrote:
> 1. Does Pharo support multiple OS/native threads? No. What you do is run multiple processes on the backend and load balance between them via a proxy. Apache/haproxy, whatever.Given the limits of processors (and the speed of light), short of quantum computers (which are happening), the best scaling choice we have is multi-processing.
Although running multiple processes and a load balancer does work, the world is not moving in that direction. It is a short-term kludge around the problem. A multi-threaded aproach allows the OS to manage resources rather then me (or the Squeak VM) trying to do it on top of the OS. The OS has more global knowledge of what is happening on the machine.
One of the most popular (and hence hyped) platforms like node.js is single-threaded. And it achieves C10K by doing evented I/O, but if you run CPU intensive tasks, then no event will save you from that.
So not everything goes in the multi-threading realm, actually the only thing I see moving in that direction is heavy computation (and to GPU as well).
I agree there is no wheel, but up and downs instead, however these days if you take things to extremes the serverless/lambda approach seems to be the most single threaded thing you can think of.
Regards,
-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org mailto:seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
With respect, having personally lived through all of it, there is no "wheel" of technology.
With respect, so have I, and we'll agree to disagree. :)
Given the limits of processors (and the speed of light), short of quantum computers (which are happening), the best scaling choice we have is multi-processing.
Agree.
Although running multiple processes and a load balancer does work, the world is not moving in that direction.
I was only answering what Pharo does, not making a statement about where it should go. I'd be great if the VM could access native threads, but it doesn't.
I currently run something like 224 Pharo images across 15 machines for my Seaside application. About twice what I need but that's for deployment reasons rather than load reasons.
That's disappointing but probably accurate.
Meh, other frameworks to choose from, Seaside is great for component based applications where you want to do everything in Smalltalk and avoid all the complexity the web can drown you in, but that's not what you want.
It's especially great for building an object oriented web applications where any screen in the app could be one of many specialized subclasses because unlike any other framework I'm aware of, I can factor my HTML and subclass my views to override very specific render methods for all the various "customizations" clients demand. I don't think I could do what I do in any of the modern client side frameworks.
That teapot framework reminds me a lot of Sinatra, looks perfect for a RESTful server framework.
At the end of the day, what's important to me is using Smalltalk, with whatever framework.
On Thu, Jun 14, 2018 at 4:17 PM Ramon Leon ramon.leon@allresnet.com wrote:
[...] I currently run something like 224 Pharo images across 15 machines for my Seaside application. About twice what I need but that's for deployment reasons rather than load reasons.
Does each particular connection spawn a cooperative thread? I presume each instance can handle multiple connections. Is that true?
So, the benefit to multiple processes is using multiple CPU's.
Is all that correct?
Thanks.
Blake
On 06/14/2018 04:44 PM, Blake McBride wrote:
Does each particular connection spawn a cooperative thread? I presume each instance can handle multiple connections. Is that true?
Yup.
So, the benefit to multiple processes is using multiple CPU's.
Yup.
Is all that correct?
Yup.
Thanks.
Blake
No prob.
seaside@lists.squeakfoundation.org
-
Blake McBride -
Esteban A. Maringolo -
Ramon Leon -
Tim Mackinnon