6 ms·

Seaside – Developing Sophisticated Web Applications in Smalltalk

91 points by nikolay 11y ago

remontoire 11y ago
This approach to webdev (continuations) could be so cool. I just wish there was a framework on the level of django/rails so that I could feel comfortable using it for a large product.
- tbje 11y ago
  The Lift web framework in Scala is somehow similar in that aspect. It has been used on multiple bigger sites like foursquare. I really like the approach compared to MVC.
  - eggy 11y ago
    Racket does stateful and stateless servers, and the continuations are either stored on the server or the client per which type you choose to implement [1]. [1] https://docs.racket-lang.org/web-server/
- long 11y ago
  The FAQ doesn't mention anything about this -- can you explain how Seaside uses continuations?
  - doublec 11y ago
    It uses continuations to hide the asynchronous nature of web requests and allows the flow between pages of a web app to be written in an imperative style. "Inverting back the inversion of control" describes the idea (in Scheme) https://pages.lip6.fr/Christian.Queinnec/PDF/www.pdf https://pages.lip6.fr/Christian.Queinnec/PDF/www.pdf Paul Graham used the idea in ViaWeb - and apparently got a patent on some aspect of it https://web.archive.org/web/20060323211251/http://paulgraham.infogami.com/blog/morepatents https://web.archive.org/web/20060323211251/http://paulgraham...
    - agumonkey 11y ago
      IIUC HN uses them too.
    - mbrock 11y ago
      There are a couple of continuation-based web frameworks for Ruby (Borges, Wee), but they're old and abandoned as far as I know. I suspect it didn't catch on because (1) people are afraid of continuations, and (2) web apps are typically designed in at least a pseudo-REST-like style, so the paradigm of "asking" the user (like "await" in ES6) isn't needed very often. But it's a cool thing to be able to do, especially for funnel-type flows, and other types of more complex session-based interactions. I wonder if there are any JavaScript inversion of control things for client side code. I've been working for the past week on a signup funnel with React and Flux, and it's just a big explicit state machine... which kind of works, but is also kind of tedious.
      - doublec 11y ago
        I think 'Ajax' killed continuation based web servers. See Avi Bryant's thoughts in this area from back then: https://web.archive.org/web/20060610180033/http://smallthought.com/avi/?p=14 https://web.archive.org/web/20060610180033/http://smallthoug... There were client side JavaScript continuation like things. Back in the mid-2000's there was Narrative JavaScript. I used it to implement threads and Alice ML style futures/promises on the client side: https://bluishcoder.co.nz/2006/06/05/more-concurrency-in-narrative.html https://bluishcoder.co.nz/2006/06/05/more-concurrency-in-nar...
      - klibertp 11y ago
        There's also Nagare in Python: http://www.nagare.org/trac/wiki/NagareTutorial http://www.nagare.org/trac/wiki/NagareTutorial IIRC it uses Stackless Python, not the standard interpreter, and I don't know how active its development is.
- sriku 11y ago
  Paul Graham's startup (way back) did this and he claims it was a competitive advantage. These days it doesn't feel like this approach offers enough.
  - derefr 11y ago
    Not just way back; HN uses continuations. (Not in many user-visible places any more, but every link on the front page used to be one—expired "next page" continuation links were a frequent source of grumbling.) Note that you don't have to expire continuations, necessarily—you could actually persist them statelessly (i.e. without server-side state), by shipping their encoded representations to the client embedded into HMAC-signed links. You're basically giving the server a raw bytecode-eval endpoint, and then making sure that it only accepts code you yourself wrote. Kind of a crazy strategy compared to the standard predeclared REST API, but interestingly flexible.
    - dang 11y ago
      > their encoded representations What's an example of such a representation?
      - derefr 11y ago
        Now that you mention it, I can't think of very many languages that define a language-standard persistent encoding of a continuation on a closure. One that I can think of is Erlang. Here's the relevant section of the Erlang "External Term Format encoding" spec: http://erlang.org/doc/apps/erts/erl_ext_dist.html#id95269 http://erlang.org/doc/apps/erts/erl_ext_dist.html#id95269 Said spec is nominally "about" the wire protocol Erlang nodes use to communicate with one another in a distributed system. But the ETF format defined there is much more general, and is used all over the place (e.g. when persisting values in Erlang's DETS tables to disk.) It's what you get when you call Erlang's global term_to_binary/1 function. Erlang's ETF could probably be most closely compared to Python's "pickle" format. (Though, sadly, you can't pickle a lexical closure in Python.)
        11y ago
- rakoo 11y ago
  Never used it but Tir (https://github.com/mongrel2/Tir https://github.com/mongrel2/Tir), which runs on top of mongrel2, allows you to use continuation style if you wish to do so.
  - aidenn0 11y ago
    Tir is currently without a maintainer and won't even install from the rocks file in the repository.
polotics 11y ago
Seems to me that the Nagare framework is the closest match in Python.
- klibertp 11y ago
  Yes, it's explicitly said in the docs that it's based/inspired by Seaside[1]. But note that - last time I checked - Nagare requires Stackless Python and not the standard interpreter. That's because Stackless lets you serialize tasklets and stack frames, which is impossible in normal Python without a custom C extension. It also lacked many useful features, like any kind of authentication handling (but, being WSGI compliant, you probably can plug some middleware to handle this). [1] http://www.nagare.org/trac/wiki/NagareFeatures http://www.nagare.org/trac/wiki/NagareFeatures
fahrradflucht 11y ago
Not responsive :(
- Jack5500 11y ago
  Well, it's as responsive as design it to be. The framework only gives you the building blocks(tags), you can still use bootstrap or your own responsive design with it
  - astares 11y ago
    Smalltalk is the most lively environment you can have. Pure OO with direct feedback. Not the usual dead code in files with long cycles as in more mainstream technologies There is a bootstrap package for Seaside, check out the demo page at: http://pharo.pharocloud.com http://pharo.pharocloud.com It is true that meanwhile single page applications have hit the client web space - but you can address them easily with the Seaside-REST package (for instance sending JSON to clients side AngularJS). If you need a framework with less footprint check out "Teapot" which you can easily run on Pharo (http://www.pharo.org http://www.pharo.org).
Jack5500 11y ago
I wrote a Monopoly Clone in Seaside for University. The framework was really intuitive, but the documentation could use some work.
mostafaberg 11y ago
Irrelevant funny comment, but everytime I read Smalltalk I imagine this scenario: Jim: Yo bob!, how's it going man? Bob: Not so much, what's going on your side? Jim: Nah, not so much, how's your family? Bob: They're fine, how's your wife? Jim: All is good man, all is good... Bob: .... Jim:..... Bob: Hey we should make a webapp together! Jim: That would be totally rad !.. Jim: .. I've even heard there's a sophisticated webapp framework for people having a smalltalk like us! Bob: Whoa that's cool !, let's get on it man! Jim: Smashing!!, But what kind of app should we work on?! Bob: I don't know let's just download it and make something simple Jim: Darn, it's only made for sophisticated webapps, says so on their website:( Bob: Naaah, life sucks man, lets wait till they support simple stuff in the future Jim: Sure thing, let's take it in our next smalltalk, gotta run now I have a scrum! Bob: Ok, I'll get my coffee and leave before no one notices I don't even work here! Jim: K man, cya!
mariodiana 11y ago
Can I ask: assuming that Smalltalk and Seaside are the bee's knees, who are your customers? Who do you sell Seaside solutions to? I'm not a Smalltalk developer; I ask this as someone who finds himself missing Objective-C's dynamism when programming C# or Java, so I'm sympathetic to the advantages of Smalltalk. But customers know .NET and Java. That's not a hard sell.
- igrekel 11y ago
  Personally I still have a seaside application, I sell the service so clients get a user account on the web application that I host myself. I wouldn't attempt selling the application as something a client would continue developing on.
muraiki 11y ago
Developing webapps in Seaside is a lot of fun. The ability that Smalltalk gives to you in terms of having a live coding environment, coupled with being able to debug and modify Seaside code in the browser while in development mode, is really powerful. When I first started learning how to program, learning Pharo and Seaside was of tremendous help in understanding how things work. After having used components to build webapps in Seaside, I was simultaneously amused and saddened when I saw it hailed as the next big thing years after Seaside had already done it (disclaimer: I've probably now opened myself up to someone telling me that it was done before Seaside did it!) The free "Dynamic Web Development with Seaside" book guides you through creating an ajax webapp, but the last time I checked the chapters on persistence were kind of weak. That being said, for toy webapps it's sufficient to just save the state of the Seaside image, with a singleton as your "database".
- igrekel 11y ago
  Indeed, the big plus is really that when an error happens, you can save the state and open a debugger right where the problem happened resume execution. This was a big help when I'd get home at night, I would check if there were errors during the day and would fix them right in the debugger.
cousin_it 11y ago
Ooh, this brings back memories. Continuation-based web frameworks were my original gateway drug to "exotic" programming techniques. Dabble DB was the poster child of Seaside, but didn't get much traction and was acqui-hired by Twitter, whereupon Avi Bryant moved on to other pastures. The other high profile examples of continuation-based web development were Paul Graham's Viaweb (which was acquired by Yahoo and rewritten with more traditional techniques) and Hacker News (which had usability problems due to continuations and mostly phased them out). The verdict of history is clear: continuation-based web development is a sexy but ultimately misguided idea.
- deleted 11y ago
  [deleted]
- dang 11y ago
  Great comment, but I don't think I agree with your conclusion. HN still has closure-style handlers [1] all through the code—60 or so as of the latest commit. We phased out the ones that were being invoked millions of times, but I'd emphasize that our reason for doing this was implementation-driven, i.e. accidental rather than essential. (This, by the way, is true of many alleged "verdicts of history" in programming. Those who care about good ideas should treat such arguments as guilty until proven innocent, lest we all get sucked completely into popular practice.) Writing the code to phase out those handlers was a deep lesson for me, because the new code came out more verbose and harder to follow. One rarely gets to do an apples-to-apples comparison of programming techniques on a production system, and somewhat to my surprise the experience convinced me (I was agnostic to begin with) that the closure approach is superior. There are at least four reasons: (1) the closure has immediate access to all the state that existed when the request was previously processed; (2) the closure is nested inside the code that creates it, so everything you need to understand a full request cycle is in one place; (3) much boilerplate is eliminated, making the code easier to read and write—it can be explicitly at the problem level; (4) security is less of a worry when the client only has to pass back a token instead of all the original parameters to the request, the latter being safely packed away in the closure. That last advantage, i.e. reduced attack surface, was particularly surprising. Learning this the hard way, by dismantling those advantages and replacing them with manual code in selected cases, taught me something else about this design: it's more than just a clever device. It's really a triumph of two of the greatest programming ideas: first-class functions—more specifically, what used to be called upward funargs [2] back when people were arguing about whether they were a good idea—and lexical scoping. The combination of those two abstractions is what allows this model to shuffle off most of the gruntwork instead of making you, in pg's memorable phrase, a human compiler. The fact that the design eventually hit scalability problems at millions of users is also a vindication of it, in the sense that it enabled pg to write HN more quickly and safely in the first place. We could selectively deal with the scalability problems later, and have done so. That has worked fine as an engineering tradeoff, but IMO a better solution will come from new implementation ideas that allow another couple orders of magnitude of closures to be kept without slowing down the rest of the system. If we get there, I will take pleasure in rolling all that manual code back into the original design. 1. They're closures, not continuations, which for HN is fine. 2. Meaning the ability to return a function from a function, and thus keep it around indefinitely, as opposed to passing a function to another function as a parameter (downward funargs).

91 points by nikolay 11y ago

This approach to webdev (continuations) could be so cool. I just wish there was a framework on the level of django/rails so that I could feel comfortable using it for a large product.

tbje 11y ago
The Lift web framework in Scala is somehow similar in that aspect. It has been used on multiple bigger sites like foursquare. I really like the approach compared to MVC.
- eggy 11y ago
  Racket does stateful and stateless servers, and the continuations are either stored on the server or the client per which type you choose to implement [1]. [1] https://docs.racket-lang.org/web-server/
long 11y ago
The FAQ doesn't mention anything about this -- can you explain how Seaside uses continuations?
- doublec 11y ago
  It uses continuations to hide the asynchronous nature of web requests and allows the flow between pages of a web app to be written in an imperative style. "Inverting back the inversion of control" describes the idea (in Scheme) https://pages.lip6.fr/Christian.Queinnec/PDF/www.pdf https://pages.lip6.fr/Christian.Queinnec/PDF/www.pdf Paul Graham used the idea in ViaWeb - and apparently got a patent on some aspect of it https://web.archive.org/web/20060323211251/http://paulgraham.infogami.com/blog/morepatents https://web.archive.org/web/20060323211251/http://paulgraham...
  - agumonkey 11y ago
    IIUC HN uses them too.
  - mbrock 11y ago
    There are a couple of continuation-based web frameworks for Ruby (Borges, Wee), but they're old and abandoned as far as I know. I suspect it didn't catch on because (1) people are afraid of continuations, and (2) web apps are typically designed in at least a pseudo-REST-like style, so the paradigm of "asking" the user (like "await" in ES6) isn't needed very often. But it's a cool thing to be able to do, especially for funnel-type flows, and other types of more complex session-based interactions. I wonder if there are any JavaScript inversion of control things for client side code. I've been working for the past week on a signup funnel with React and Flux, and it's just a big explicit state machine... which kind of works, but is also kind of tedious.
    - doublec 11y ago
      I think 'Ajax' killed continuation based web servers. See Avi Bryant's thoughts in this area from back then: https://web.archive.org/web/20060610180033/http://smallthought.com/avi/?p=14 https://web.archive.org/web/20060610180033/http://smallthoug... There were client side JavaScript continuation like things. Back in the mid-2000's there was Narrative JavaScript. I used it to implement threads and Alice ML style futures/promises on the client side: https://bluishcoder.co.nz/2006/06/05/more-concurrency-in-narrative.html https://bluishcoder.co.nz/2006/06/05/more-concurrency-in-nar...
    - klibertp 11y ago
      There's also Nagare in Python: http://www.nagare.org/trac/wiki/NagareTutorial http://www.nagare.org/trac/wiki/NagareTutorial IIRC it uses Stackless Python, not the standard interpreter, and I don't know how active its development is.
sriku 11y ago
Paul Graham's startup (way back) did this and he claims it was a competitive advantage. These days it doesn't feel like this approach offers enough.
- derefr 11y ago
  Not just way back; HN uses continuations. (Not in many user-visible places any more, but every link on the front page used to be one—expired "next page" continuation links were a frequent source of grumbling.) Note that you don't have to expire continuations, necessarily—you could actually persist them statelessly (i.e. without server-side state), by shipping their encoded representations to the client embedded into HMAC-signed links. You're basically giving the server a raw bytecode-eval endpoint, and then making sure that it only accepts code you yourself wrote. Kind of a crazy strategy compared to the standard predeclared REST API, but interestingly flexible.
  - dang 11y ago
    > their encoded representations What's an example of such a representation?
    - derefr 11y ago
      Now that you mention it, I can't think of very many languages that define a language-standard persistent encoding of a continuation on a closure. One that I can think of is Erlang. Here's the relevant section of the Erlang "External Term Format encoding" spec: http://erlang.org/doc/apps/erts/erl_ext_dist.html#id95269 http://erlang.org/doc/apps/erts/erl_ext_dist.html#id95269 Said spec is nominally "about" the wire protocol Erlang nodes use to communicate with one another in a distributed system. But the ETF format defined there is much more general, and is used all over the place (e.g. when persisting values in Erlang's DETS tables to disk.) It's what you get when you call Erlang's global term_to_binary/1 function. Erlang's ETF could probably be most closely compared to Python's "pickle" format. (Though, sadly, you can't pickle a lexical closure in Python.)
      - 11y ago
rakoo 11y ago
Never used it but Tir (https://github.com/mongrel2/Tir https://github.com/mongrel2/Tir), which runs on top of mongrel2, allows you to use continuation style if you wish to do so.
- aidenn0 11y ago
  Tir is currently without a maintainer and won't even install from the rocks file in the repository.

polotics 11y ago

Seems to me that the Nagare framework is the closest match in Python.

klibertp 11y ago
Yes, it's explicitly said in the docs that it's based/inspired by Seaside[1]. But note that - last time I checked - Nagare requires Stackless Python and not the standard interpreter. That's because Stackless lets you serialize tasklets and stack frames, which is impossible in normal Python without a custom C extension. It also lacked many useful features, like any kind of authentication handling (but, being WSGI compliant, you probably can plug some middleware to handle this). [1] http://www.nagare.org/trac/wiki/NagareFeatures http://www.nagare.org/trac/wiki/NagareFeatures

fahrradflucht 11y ago

Not responsive :(

Jack5500 11y ago
Well, it's as responsive as design it to be. The framework only gives you the building blocks(tags), you can still use bootstrap or your own responsive design with it
- astares 11y ago
  Smalltalk is the most lively environment you can have. Pure OO with direct feedback. Not the usual dead code in files with long cycles as in more mainstream technologies There is a bootstrap package for Seaside, check out the demo page at: http://pharo.pharocloud.com http://pharo.pharocloud.com It is true that meanwhile single page applications have hit the client web space - but you can address them easily with the Seaside-REST package (for instance sending JSON to clients side AngularJS). If you need a framework with less footprint check out "Teapot" which you can easily run on Pharo (http://www.pharo.org http://www.pharo.org).

Jack5500 11y ago

I wrote a Monopoly Clone in Seaside for University. The framework was really intuitive, but the documentation could use some work.

mostafaberg 11y ago

Irrelevant funny comment, but everytime I read Smalltalk I imagine this scenario: Jim: Yo bob!, how's it going man? Bob: Not so much, what's going on your side? Jim: Nah, not so much, how's your family? Bob: They're fine, how's your wife? Jim: All is good man, all is good... Bob: .... Jim:..... Bob: Hey we should make a webapp together! Jim: That would be totally rad !.. Jim: .. I've even heard there's a sophisticated webapp framework for people having a smalltalk like us! Bob: Whoa that's cool !, let's get on it man! Jim: Smashing!!, But what kind of app should we work on?! Bob: I don't know let's just download it and make something simple Jim: Darn, it's only made for sophisticated webapps, says so on their website:( Bob: Naaah, life sucks man, lets wait till they support simple stuff in the future Jim: Sure thing, let's take it in our next smalltalk, gotta run now I have a scrum! Bob: Ok, I'll get my coffee and leave before no one notices I don't even work here! Jim: K man, cya!

mariodiana 11y ago

Can I ask: assuming that Smalltalk and Seaside are the bee's knees, who are your customers? Who do you sell Seaside solutions to? I'm not a Smalltalk developer; I ask this as someone who finds himself missing Objective-C's dynamism when programming C# or Java, so I'm sympathetic to the advantages of Smalltalk. But customers know .NET and Java. That's not a hard sell.

igrekel 11y ago
Personally I still have a seaside application, I sell the service so clients get a user account on the web application that I host myself. I wouldn't attempt selling the application as something a client would continue developing on.

muraiki 11y ago

Developing webapps in Seaside is a lot of fun. The ability that Smalltalk gives to you in terms of having a live coding environment, coupled with being able to debug and modify Seaside code in the browser while in development mode, is really powerful. When I first started learning how to program, learning Pharo and Seaside was of tremendous help in understanding how things work. After having used components to build webapps in Seaside, I was simultaneously amused and saddened when I saw it hailed as the next big thing years after Seaside had already done it (disclaimer: I've probably now opened myself up to someone telling me that it was done before Seaside did it!) The free "Dynamic Web Development with Seaside" book guides you through creating an ajax webapp, but the last time I checked the chapters on persistence were kind of weak. That being said, for toy webapps it's sufficient to just save the state of the Seaside image, with a singleton as your "database".

igrekel 11y ago
Indeed, the big plus is really that when an error happens, you can save the state and open a debugger right where the problem happened resume execution. This was a big help when I'd get home at night, I would check if there were errors during the day and would fix them right in the debugger.

cousin_it 11y ago

Ooh, this brings back memories. Continuation-based web frameworks were my original gateway drug to "exotic" programming techniques. Dabble DB was the poster child of Seaside, but didn't get much traction and was acqui-hired by Twitter, whereupon Avi Bryant moved on to other pastures. The other high profile examples of continuation-based web development were Paul Graham's Viaweb (which was acquired by Yahoo and rewritten with more traditional techniques) and Hacker News (which had usability problems due to continuations and mostly phased them out). The verdict of history is clear: continuation-based web development is a sexy but ultimately misguided idea.

deleted 11y ago
[deleted]
dang 11y ago
Great comment, but I don't think I agree with your conclusion. HN still has closure-style handlers [1] all through the code—60 or so as of the latest commit. We phased out the ones that were being invoked millions of times, but I'd emphasize that our reason for doing this was implementation-driven, i.e. accidental rather than essential. (This, by the way, is true of many alleged "verdicts of history" in programming. Those who care about good ideas should treat such arguments as guilty until proven innocent, lest we all get sucked completely into popular practice.) Writing the code to phase out those handlers was a deep lesson for me, because the new code came out more verbose and harder to follow. One rarely gets to do an apples-to-apples comparison of programming techniques on a production system, and somewhat to my surprise the experience convinced me (I was agnostic to begin with) that the closure approach is superior. There are at least four reasons: (1) the closure has immediate access to all the state that existed when the request was previously processed; (2) the closure is nested inside the code that creates it, so everything you need to understand a full request cycle is in one place; (3) much boilerplate is eliminated, making the code easier to read and write—it can be explicitly at the problem level; (4) security is less of a worry when the client only has to pass back a token instead of all the original parameters to the request, the latter being safely packed away in the closure. That last advantage, i.e. reduced attack surface, was particularly surprising. Learning this the hard way, by dismantling those advantages and replacing them with manual code in selected cases, taught me something else about this design: it's more than just a clever device. It's really a triumph of two of the greatest programming ideas: first-class functions—more specifically, what used to be called upward funargs [2] back when people were arguing about whether they were a good idea—and lexical scoping. The combination of those two abstractions is what allows this model to shuffle off most of the gruntwork instead of making you, in pg's memorable phrase, a human compiler. The fact that the design eventually hit scalability problems at millions of users is also a vindication of it, in the sense that it enabled pg to write HN more quickly and safely in the first place. We could selectively deal with the scalability problems later, and have done so. That has worked fine as an engineering tradeoff, but IMO a better solution will come from new implementation ideas that allow another couple orders of magnitude of closures to be kept without slowing down the rest of the system. If we get there, I will take pleasure in rolling all that manual code back into the original design. 1. They're closures, not continuations, which for HN is fine. 2. Meaning the ability to return a function from a function, and thus keep it around indefinitely, as opposed to passing a function to another function as a parameter (downward funargs).