>>> Hm, I thought Tobias meant "run source.squeak.org's image with SS3
>>> code" rather than "move source.squeak.org's code to the SS3 servers". >> >> Porting SS3 from GemStone to Squeak would probably be harder than just >> upgrading the existing code. >> > > Have you actually looked at SS3? > I develop SS3 in Squeak (and pharo and gemstone) > and it always runs on Squeak (as long as Seaside does, for that matter). Ok, I didn't know that. I thought SS3 was targeted at GemStone. You're saying it'll run on Squeak as-is, right now? > Installer squeaksource > project: 'MetacelloRepository'; > install: 'ConfigurationOfSqueakSource'. > > ((Smalltalk classNamed: #'ConfigurationOfSqueakSource') project version: #bleedingEdge) load: 'All'. > " > Or without tests: > ((Smalltalk classNamed: #'ConfigurationOfSqueakSource') project version: #bleedingEdge) load: 'Full'. When I tried the above in trunk, it goes for a while before I get an error which says: " 'table is already defined in a subclass of nil'". Apparently while trying to load "WAEncoder" class... In Squeak 4.4, is an immediate error. > Have an image, see for yourself: > https://dl.dropboxusercontent.com/u/14917452/SS3.zip > http://localhost:8080/installSS > > You know, SS3 is one of the two only reasons I have made the > Squeak/Seaside all-in-one images. It is as if nobody cared about > seaside in the squeak world anymore. > It actually upsets me a little bit. Me too. I think people have given up because Seaside has not been reliably loadable on Squeak for a long time. That's why I think it would be good for us as a community to depend on a Squeak-based web-site so we will keep it maintained like the trunk. Squeak was a leader of web-dev tech in the early 2000's with Seaside. But the irony about trying to keep Seaside accessible on all platforms including Pharo is that it has became a huge, complex beast for all platforms, and inaccessible on its original platform entirely. You and I both have done work to try to keep Seaside 3.x loading and working in Squeak. Your script above doesn't work and now even my SqueakMap script for Seaside 3.0.3 no longer works because someone decided to delete all versions of Grease from SS3 without understanding or caring about the impacts to Squeak. (Sigh) So, in some respects it almost seems easier to just take charge of our own web-software destiny and fork our own Seaside, in our own repositories than to beg for cooperation from, ahem, other groups. And maybe that is why I thought there may be a case for the good ol'e days of SS2 on Seaside 2.x. Much smaller and easier to install and understand, just a few packages compared to 3.x. I don't care, I just think we need control because, if we don't, you can bet, in one week it won't work anymore. Maybe web guru's will speak up, I just think we need to do _something_ to wrest back control of our own software-destiny for web-development for Squeak. People want to build their OWN images from a base 4.4 / 4.5, not download a special all-in-one "Seaside" image.. |
> So, in some respects it almost seems easier to just take charge of > our own web-software destiny and fork our own Seaside, in our own > repositories than to beg for cooperation from, ahem, other groups. Yes. -C -- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014) |
In reply to this post by Chris Muller-3
> You and I both have done work to try to keep Seaside 3.x loading and
> working in Squeak. Your script above doesn't work and now even my > SqueakMap script for Seaside 3.0.3 no longer works because someone > decided to delete all versions of Grease from SS3 without > understanding or caring about the impacts to Squeak. Correction: It seems there was just a hiccup or something on SS3, the versions for Grease ARE there, but the registration changed from "Grease" to "grease". After fixing that in the SM script, I'm happy to report, Seaside 3.0.3 STILL loads into Squeak 4.4 and it even loads into trunk too. :) But that is not the Metacello version you did Tobias, which I guess loads Seaside 3.1.x, so it's still behind. |
In reply to this post by Chris Muller-3
I thought that its been loadable if you use the canonical ConfigurationOfSeaside3 (or ConfigurationOfSeaside30) that has been maintained by the Seaside community. Is that not the case? Using the canonical ConfigurationOfSeaside3 from here: MCHttpRepository location: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' user: '' password: '' and running: ConfigurationOfSeaside3 load. works in the 4.4 All in one. Just to be clear are you arguing that forking and maintaining a project, documentation, finding users and devs plus developing and integrating bugfixes, and creating improvements is easier or more desirable than fixing a build script every now and again? As I described above, loading Seaside into a 4.4 image is possible today. The ConfigurationOfSqueakSource is broken. I'm not sure why. But to say that Seaside doesn't load or is broken on Squeak is inaccurate |
In reply to this post by Chris Muller-3
On Tue, Jan 14, 2014 at 5:54 PM, Chris Muller <[hidden email]> wrote: Maybe web guru's will speak up, I just think we need to do _something_ Meh. Don't worry about it. Seaside is obsolete anyway. Colin |
On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: > Meh. Don't worry about it. Seaside is obsolete anyway. Really? I haven’t taken any interest in web development in ages; what’s the replacement for Seaside? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim I am the computer your mother warned you about. |
On Tue, Jan 14, 2014 at 8:29 PM, tim Rowledge <[hidden email]> wrote:
It's not that there's a replacement. It's more that the problem it solves isn't a problem anymore. Continuations were a brilliant way to manage apps that were basically dynamically generated web pages connected via links and forms. But Javascript runtimes have gotten way, way faster, more robust and more standardized in the last 10 years. Modern web apps are more of a client-server model: the UI rendering and interface logic is all done in Javascript running in the browser, and it communicates with the server by shuttling JSON back and forth over HTTP. In that sort of a system, continuations don't provide any benefit, and the drawbacks start to become significant.
Colin |
In reply to this post by Paul DeBruicker
On Tue, Jan 14, 2014 at 6:32 PM, Paul DeBruicker <[hidden email]> wrote:
> Chris Muller-3 wrote >> I think people have given up because Seaside has not been >> reliably loadable on Squeak for a long time. That's why I think it >> would be good for us as a community to depend on a Squeak-based >> web-site so we will keep it maintained like the trunk. > > I thought that its been loadable if you use the canonical > ConfigurationOfSeaside3 (or ConfigurationOfSeaside30) that has been > maintained by the Seaside community. Is that not the case? > > Using the canonical ConfigurationOfSeaside3 from here: > > MCHttpRepository > location: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' > user: '' > password: '' > > and running: > > ConfigurationOfSeaside3 load. That worked, thanks. Can you tell me the expression to load exactly version 3.1.0, even if stable is beyond that at some point in the future? > works in the 4.4 All in one. And in trunk, great! > Just to be clear are you arguing that forking and maintaining a project, > documentation, finding users and devs plus developing and integrating > bugfixes, and creating improvements is easier or more desirable than fixing > a build script every now and again? I had thought MC versions had been deleted from SS3 which were needed for Seaside in Squeak. I was wrong about that, but nothing was showing on the Versions tab for a time and in the meantime I stupidly expressed a not-very-well-thought-out knee-jerk response to secure a loadable configuration. My bad. >> People want to build their OWN images from a base 4.4 / >> 4.5, not download a special all-in-one "Seaside" image.. > > As I described above, loading Seaside into a 4.4 image is possible today. > The ConfigurationOfSqueakSource is broken. I'm not sure why. But to say > that Seaside doesn't load or is broken on Squeak is inaccurate Indeed, thanks for the clarification. |
In reply to this post by Colin Putney-3
>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>> > Meh. Don't worry about it. Seaside is obsolete anyway. >> >> Really? I haven’t taken any interest in web development in ages; what’s >> the replacement for Seaside? > > > It's not that there's a replacement. It's more that the problem it solves > isn't a problem anymore. Continuations were a brilliant way to manage apps > that were basically dynamically generated web pages connected via links and > forms. But Javascript runtimes have gotten way, way faster, more robust and > more standardized in the last 10 years. Modern web apps are more of a > client-server model: the UI rendering and interface logic is all done in > Javascript running in the browser, and it communicates with the server by > shuttling JSON back and forth over HTTP. In that sort of a system, > continuations don't provide any benefit, and the drawbacks start to become > significant. Continuations were never good for UI design anyway. Modal. What about HTML / DOM, is it still relevant in 2014? |
On Tue, Jan 14, 2014 at 10:10 PM, Chris Muller <[hidden email]> wrote: Continuations were never good for UI design anyway. Modal. The *web* wasn't good for UI design back then. But if you were going to do dynamic web sites, continuations were a great way to go about it!
What about HTML / DOM, is it still relevant in 2014? Yes, but smart phones are really important now, so "responsive design" is the in thing: one UI that scales down to 3" phone and up to 30" monitors.
|
In reply to this post by Chris Muller-3
On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote:
>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >>> > Meh. Don't worry about it. Seaside is obsolete anyway. >>> >>> Really? I haven’t taken any interest in web development in ages; what’s >>> the replacement for Seaside? >> >> >> It's not that there's a replacement. It's more that the problem it solves >> isn't a problem anymore. Continuations were a brilliant way to manage apps >> that were basically dynamically generated web pages connected via links and >> forms. But Javascript runtimes have gotten way, way faster, more robust and >> more standardized in the last 10 years. Modern web apps are more of a >> client-server model: the UI rendering and interface logic is all done in >> Javascript running in the browser, and it communicates with the server by >> shuttling JSON back and forth over HTTP. In that sort of a system, >> continuations don't provide any benefit, and the drawbacks start to become >> significant. > > Continuations were never good for UI design anyway. Modal. I don't understand - what does UI modal-ness got to do with with continuations? (Or: the whole of Squeak is fundamentally built on continuations (Process, ContextPart).) frank |
In reply to this post by Colin Putney-3
Hey!
On 01/15/2014 03:00 AM, Colin Putney wrote: > On Tue, Jan 14, 2014 at 8:29 PM, tim Rowledge <[hidden email] > <mailto:[hidden email]>> wrote: > > > On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email] > <mailto:[hidden email]>> wrote: > > Meh. Don't worry about it. Seaside is obsolete anyway. > > Really? I haven’t taken any interest in web development in ages; > what’s the replacement for Seaside? > > > It's not that there's a replacement. It's more that the problem it > solves isn't a problem anymore. Continuations were a brilliant way to > manage apps that were basically dynamically generated web pages > connected via links and forms. But Javascript runtimes have gotten way, > way faster, more robust and more standardized in the last 10 years. > Modern web apps are more of a client-server model: the UI rendering > and interface logic is all done in Javascript running in the browser, > and it communicates with the server by shuttling JSON back and forth > over HTTP. In that sort of a system, continuations don't provide any > benefit, and the drawbacks start to become significant. > > Colin And IMHO if you want the Seaside style of development (components, HTML DSL without templates etc) Amber is what you want - it is the "modern web" replacement for Seaside. smalltalkhub.com being the prime example of it. regards, Göran PS. But Seaside-REST is still quite slick and useful for createing RESTful backends. But that is probably easy to split out from the rest of Seaside. |
On Wed, Jan 15, 2014 at 8:51 AM, Göran Krampe <[hidden email]> wrote: And IMHO if you want the Seaside style of development (components, HTML DSL without templates etc) Amber is what you want - it is the "modern web" replacement for Seaside. Yes, exactly.
|
In reply to this post by Frank Shearar-3
Frank, by my limited knowledge, the call: / answer API of Seaside used
a Continuation to allow a modal component to be rendered on top of other components until #answer: is sent by one of the callbacks. That provides stateless web-apps the ability to do desktop-like modal "dialog" boxes that can return values to the calling component. On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote: > On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote: >>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >>>> > Meh. Don't worry about it. Seaside is obsolete anyway. >>>> >>>> Really? I haven’t taken any interest in web development in ages; what’s >>>> the replacement for Seaside? >>> >>> >>> It's not that there's a replacement. It's more that the problem it solves >>> isn't a problem anymore. Continuations were a brilliant way to manage apps >>> that were basically dynamically generated web pages connected via links and >>> forms. But Javascript runtimes have gotten way, way faster, more robust and >>> more standardized in the last 10 years. Modern web apps are more of a >>> client-server model: the UI rendering and interface logic is all done in >>> Javascript running in the browser, and it communicates with the server by >>> shuttling JSON back and forth over HTTP. In that sort of a system, >>> continuations don't provide any benefit, and the drawbacks start to become >>> significant. >> >> Continuations were never good for UI design anyway. Modal. > > I don't understand - what does UI modal-ness got to do with with > continuations? (Or: the whole of Squeak is fundamentally built on > continuations (Process, ContextPart).) > > frank > |
Yes, I know. But that just means that implementing a bad idea (modal
dialogs) with some random piece of tech (continuations) is a bad idea. I thought you meant that continuations _implied_ something negative about UI design by their very nature. But it sounds like that's not what you meant. Which is good :). frank On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote: > Frank, by my limited knowledge, the call: / answer API of Seaside used > a Continuation to allow a modal component to be rendered on top of > other components until #answer: is sent by one of the callbacks. That > provides stateless web-apps the ability to do desktop-like modal > "dialog" boxes that can return values to the calling component. > > On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote: >> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote: >>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >>>>> > Meh. Don't worry about it. Seaside is obsolete anyway. >>>>> >>>>> Really? I haven’t taken any interest in web development in ages; what’s >>>>> the replacement for Seaside? >>>> >>>> >>>> It's not that there's a replacement. It's more that the problem it solves >>>> isn't a problem anymore. Continuations were a brilliant way to manage apps >>>> that were basically dynamically generated web pages connected via links and >>>> forms. But Javascript runtimes have gotten way, way faster, more robust and >>>> more standardized in the last 10 years. Modern web apps are more of a >>>> client-server model: the UI rendering and interface logic is all done in >>>> Javascript running in the browser, and it communicates with the server by >>>> shuttling JSON back and forth over HTTP. In that sort of a system, >>>> continuations don't provide any benefit, and the drawbacks start to become >>>> significant. >>> >>> Continuations were never good for UI design anyway. Modal. >> >> I don't understand - what does UI modal-ness got to do with with >> continuations? (Or: the whole of Squeak is fundamentally built on >> continuations (Process, ContextPart).) >> >> frank >> > |
In reply to this post by Chris Muller-3
On 15.01.2014, at 03:42, Chris Muller <[hidden email]> wrote: > On Tue, Jan 14, 2014 at 6:32 PM, Paul DeBruicker <[hidden email]> wrote: >> Chris Muller-3 wrote >>> I think people have given up because Seaside has not been >>> reliably loadable on Squeak for a long time. That's why I think it >>> would be good for us as a community to depend on a Squeak-based >>> web-site so we will keep it maintained like the trunk. >> >> I thought that its been loadable if you use the canonical >> ConfigurationOfSeaside3 (or ConfigurationOfSeaside30) that has been >> maintained by the Seaside community. Is that not the case? >> >> Using the canonical ConfigurationOfSeaside3 from here: >> >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' >> user: '' >> password: '' >> >> and running: >> >> ConfigurationOfSeaside3 load. > > That worked, thanks. Can you tell me the expression to load exactly > version 3.1.0, even if stable is beyond that at some point in the > future? Best -Tobias signature.asc (1K) Download Attachment |
In reply to this post by Frank Shearar-3
Continuations are also bad because they leave Mutex's in their wait
state. That, alone, is a show-stopper for me for using continuations. On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <[hidden email]> wrote: > Yes, I know. But that just means that implementing a bad idea (modal > dialogs) with some random piece of tech (continuations) is a bad idea. > > I thought you meant that continuations _implied_ something negative > about UI design by their very nature. But it sounds like that's not > what you meant. Which is good :). > > frank > > On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote: >> Frank, by my limited knowledge, the call: / answer API of Seaside used >> a Continuation to allow a modal component to be rendered on top of >> other components until #answer: is sent by one of the callbacks. That >> provides stateless web-apps the ability to do desktop-like modal >> "dialog" boxes that can return values to the calling component. >> >> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote: >>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote: >>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway. >>>>>> >>>>>> Really? I haven’t taken any interest in web development in ages; what’s >>>>>> the replacement for Seaside? >>>>> >>>>> >>>>> It's not that there's a replacement. It's more that the problem it solves >>>>> isn't a problem anymore. Continuations were a brilliant way to manage apps >>>>> that were basically dynamically generated web pages connected via links and >>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and >>>>> more standardized in the last 10 years. Modern web apps are more of a >>>>> client-server model: the UI rendering and interface logic is all done in >>>>> Javascript running in the browser, and it communicates with the server by >>>>> shuttling JSON back and forth over HTTP. In that sort of a system, >>>>> continuations don't provide any benefit, and the drawbacks start to become >>>>> significant. >>>> >>>> Continuations were never good for UI design anyway. Modal. >>> >>> I don't understand - what does UI modal-ness got to do with with >>> continuations? (Or: the whole of Squeak is fundamentally built on >>> continuations (Process, ContextPart).) >>> >>> frank >>> >> |
On 15.01.2014, at 17:30, Chris Muller <[hidden email]> wrote: > Continuations are also bad because they leave Mutex's in their wait > state. That, alone, is a show-stopper for me for using continuations. They do what? Where? Can you enlighten me there… Best -Tobias signature.asc (1K) Download Attachment |
In reply to this post by Chris Muller-4
No they don't. Continuations have nothing to with mutexes at all. I'm
not sure that we're talking about the same thing when we say "continuation". When _I_ say "continuation" I mean, effectively, the call stack: it's the thing to which the result of the current activation record will return a result. You can thus consider a _delimited_ continuation as a chunk of stack. #on:do: delimits the stack using a primitive (19?). An _undelimited_ continuation is the entire call stack from the very beginning of a program. thisContext + all its senders is the closest we have to such a thing in Smalltalk: since all call stacks eventually hit nil, they're all delimited by _something_. And we use continuations _all the time_ in Smalltalk, or things that may be trivially expressed in delimited continuations: from a CS perspective delimited continuations and resumable exceptions are equivalent, in the sense that each may implement the other. frank On 15 January 2014 16:30, Chris Muller <[hidden email]> wrote: > Continuations are also bad because they leave Mutex's in their wait > state. That, alone, is a show-stopper for me for using continuations. > > On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <[hidden email]> wrote: >> Yes, I know. But that just means that implementing a bad idea (modal >> dialogs) with some random piece of tech (continuations) is a bad idea. >> >> I thought you meant that continuations _implied_ something negative >> about UI design by their very nature. But it sounds like that's not >> what you meant. Which is good :). >> >> frank >> >> On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote: >>> Frank, by my limited knowledge, the call: / answer API of Seaside used >>> a Continuation to allow a modal component to be rendered on top of >>> other components until #answer: is sent by one of the callbacks. That >>> provides stateless web-apps the ability to do desktop-like modal >>> "dialog" boxes that can return values to the calling component. >>> >>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote: >>>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote: >>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway. >>>>>>> >>>>>>> Really? I haven’t taken any interest in web development in ages; what’s >>>>>>> the replacement for Seaside? >>>>>> >>>>>> >>>>>> It's not that there's a replacement. It's more that the problem it solves >>>>>> isn't a problem anymore. Continuations were a brilliant way to manage apps >>>>>> that were basically dynamically generated web pages connected via links and >>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and >>>>>> more standardized in the last 10 years. Modern web apps are more of a >>>>>> client-server model: the UI rendering and interface logic is all done in >>>>>> Javascript running in the browser, and it communicates with the server by >>>>>> shuttling JSON back and forth over HTTP. In that sort of a system, >>>>>> continuations don't provide any benefit, and the drawbacks start to become >>>>>> significant. >>>>> >>>>> Continuations were never good for UI design anyway. Modal. >>>> >>>> I don't understand - what does UI modal-ness got to do with with >>>> continuations? (Or: the whole of Squeak is fundamentally built on >>>> continuations (Process, ContextPart).) >>>> >>>> frank >>>> >>> |
I was talking about class Continuation and how its used in the context
of Seaside. In that context, I have observed, for example, a critical block being entered prior to snipping a Continuation off the stack (to be resumed later), thus leaving Mutex's on the stack stuck in their wait state, and blocking subsequent requests. On Wed, Jan 15, 2014 at 11:23 AM, Frank Shearar <[hidden email]> wrote: > No they don't. Continuations have nothing to with mutexes at all. I'm > not sure that we're talking about the same thing when we say > "continuation". > > When _I_ say "continuation" I mean, effectively, the call stack: it's > the thing to which the result of the current activation record will > return a result. You can thus consider a _delimited_ continuation as a > chunk of stack. #on:do: delimits the stack using a primitive (19?). An > _undelimited_ continuation is the entire call stack from the very > beginning of a program. thisContext + all its senders is the closest > we have to such a thing in Smalltalk: since all call stacks eventually > hit nil, they're all delimited by _something_. > > And we use continuations _all the time_ in Smalltalk, or things that > may be trivially expressed in delimited continuations: from a CS > perspective delimited continuations and resumable exceptions are > equivalent, in the sense that each may implement the other. > > frank > > On 15 January 2014 16:30, Chris Muller <[hidden email]> wrote: >> Continuations are also bad because they leave Mutex's in their wait >> state. That, alone, is a show-stopper for me for using continuations. >> >> On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <[hidden email]> wrote: >>> Yes, I know. But that just means that implementing a bad idea (modal >>> dialogs) with some random piece of tech (continuations) is a bad idea. >>> >>> I thought you meant that continuations _implied_ something negative >>> about UI design by their very nature. But it sounds like that's not >>> what you meant. Which is good :). >>> >>> frank >>> >>> On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote: >>>> Frank, by my limited knowledge, the call: / answer API of Seaside used >>>> a Continuation to allow a modal component to be rendered on top of >>>> other components until #answer: is sent by one of the callbacks. That >>>> provides stateless web-apps the ability to do desktop-like modal >>>> "dialog" boxes that can return values to the calling component. >>>> >>>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote: >>>>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote: >>>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >>>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway. >>>>>>>> >>>>>>>> Really? I haven’t taken any interest in web development in ages; what’s >>>>>>>> the replacement for Seaside? >>>>>>> >>>>>>> >>>>>>> It's not that there's a replacement. It's more that the problem it solves >>>>>>> isn't a problem anymore. Continuations were a brilliant way to manage apps >>>>>>> that were basically dynamically generated web pages connected via links and >>>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and >>>>>>> more standardized in the last 10 years. Modern web apps are more of a >>>>>>> client-server model: the UI rendering and interface logic is all done in >>>>>>> Javascript running in the browser, and it communicates with the server by >>>>>>> shuttling JSON back and forth over HTTP. In that sort of a system, >>>>>>> continuations don't provide any benefit, and the drawbacks start to become >>>>>>> significant. >>>>>> >>>>>> Continuations were never good for UI design anyway. Modal. >>>>> >>>>> I don't understand - what does UI modal-ness got to do with with >>>>> continuations? (Or: the whole of Squeak is fundamentally built on >>>>> continuations (Process, ContextPart).) >>>>> >>>>> frank >>>>> >>>> > |
Free forum by Nabble | Edit this page |