Amber v. Dojo v. Seaside

>
> 2011/10/5 Göran Krampe <[hidden email]>
>         Hi!
>        
>         Sorry for top posting (my phone) but IMO:
>         - Amber offers Smalltalk lang and IDE running in the browser.
>         - Amber offers Seaside-ish component/canvas style programming.
>         Now, if that was "all" then it would be a hard sell, but the
>         killer feature is very good mixability with js code and
>         libraries so we can stand on the huge shoulder of the js
>         community.
>        
>         This means you can use jQuery or Dojo from Amber right now -
>         no "binding" or glue needed.
>        
>         regards, Göran
>        
>        
>         -- Sent from my Palm Pre 2, wohoo!
>        
>        
>         ______________________________________________________________
>        
>         On Oct 5, 2011 17:01, Jimmie Houchin <[hidden email]>
>         wrote:
>        
>        
>        
>         Hello,
>        
>         I am considering writing a web application. I am trying to
>         understand my
>         options as best I can. I do not know JS and haven't built any
>         web app
>         before.
>        
>         I do know Smalltalk and love Pharo/Squeak. I know a few other
>         languages,
>         Python, Lua, etc. and am willing and able to acquire JS as
>         necessary.
>        
>         I read that Amber is for developing client-side heavy web
>         applications
>         in Smalltalk. Disregarding the Smalltalk part. What does Amber
>         do for me
>         that I can't find in say Dojo?
>        
>         Or how would development compare to Seaside and the
>         respective
>         performance between similar Seaside and Amber apps?
>        
>         I am just trying to understand where Amber fits in the
>         available choices
>         in web development. I believe having a good answer to
>         questions like
>         these would also help Amber be able to position itself in the
>         web app
>         marketplace. I mention these particular technologies not
>         necessarily
>         because they are the only or the best. But they are the ones I
>         am
>         currently exploring for learning this style of web app
>         development.
>        
>         Any insight is greatly appreciated.
>        
>         Thanks.
>        
>         Jimmie
>        
>
>
>
>
> --
> Charles A. Monteiro
> www.monteirosfusion.com
> sent from the road

> Hi,
>
> On Wed, 2011-10-05 at 12:10 -0400, Charles Monteiro wrote:
>>  a good to have just in case but then again one of the reasons why I
>> like Seaside is because it "wraps" JQuery with what I think is a
>> cleaner API. Also you can effectively call js from Seaside so how is
>> Amber different ?
>
> Seaside is a server-side web framework. Amber is a Smalltalk that runs
> on top of JavaScript (client-side).
>
> As such, Amber is able to use any JS library in Smalltalk without
> writing any glue code. Seaside can't do that of course, as it's a
> server-side Smalltalk web framework.
>
> Amber and Seaside are very different by nature and I don't think they
> compete.
>
> Cheers,
> Nico
>>
>> 2011/10/5 Göran Krampe <[hidden email]>
>>         Hi!
>>        
>>         Sorry for top posting (my phone) but IMO:
>>         - Amber offers Smalltalk lang and IDE running in the browser.
>>         - Amber offers Seaside-ish component/canvas style programming.
>>         Now, if that was "all" then it would be a hard sell, but the
>>         killer feature is very good mixability with js code and
>>         libraries so we can stand on the huge shoulder of the js
>>         community.
>>        
>>         This means you can use jQuery or Dojo from Amber right now -
>>         no "binding" or glue needed.
>>        
>>         regards, Göran
>>        
>>        
>>         -- Sent from my Palm Pre 2, wohoo!
>>        
>>        
>>         ______________________________________________________________
>>        
>>         On Oct 5, 2011 17:01, Jimmie Houchin <[hidden email]>
>>         wrote:
>>        
>>        
>>        
>>         Hello,
>>        
>>         I am considering writing a web application. I am trying to
>>         understand my
>>         options as best I can. I do not know JS and haven't built any
>>         web app
>>         before.
>>        
>>         I do know Smalltalk and love Pharo/Squeak. I know a few other
>>         languages,
>>         Python, Lua, etc. and am willing and able to acquire JS as
>>         necessary.
>>        
>>         I read that Amber is for developing client-side heavy web
>>         applications
>>         in Smalltalk. Disregarding the Smalltalk part. What does Amber
>>         do for me
>>         that I can't find in say Dojo?
>>        
>>         Or how would development compare to Seaside and the
>>         respective
>>         performance between similar Seaside and Amber apps?
>>        
>>         I am just trying to understand where Amber fits in the
>>         available choices
>>         in web development. I believe having a good answer to
>>         questions like
>>         these would also help Amber be able to position itself in the
>>         web app
>>         marketplace. I mention these particular technologies not
>>         necessarily
>>         because they are the only or the best. But they are the ones I
>>         am
>>         currently exploring for learning this style of web app
>>         development.
>>        
>>         Any insight is greatly appreciated.
>>        
>>         Thanks.
>>        
>>         Jimmie
>>        
>>
>>
>>
>>
>> --
>> Charles A. Monteiro
>> www.monteirosfusion.com
>> sent from the road
>
>
>

> Hi guys,
>
> I think server-side and client-side web frameworks have a future when
> combined together. At least that is Aida/Web plan with Amber.
>
> There are apps which are best to be fully client-side, and there are
> those best completely on server side. But majority of them will be on
> both sides. Specially in the era of always on-line connection to the cloud.
>
> So, Aida will slowly integrate Amber more and more in its "ecosphere",
> with an end goal to build web apps the same way for both client and
> server side. Where to run an app at the end is a decision to be
> postponed as late in runtime phase as possible. That way you can decide
> on the fly, where to run. If you go mobile and offline, you can "load"
> and app to your tablet and when you came back online, synchronize back
> to Aida server and continue to run server-side.
>
> Or "hybrid-side", that is: part on client, part on server. To be able to
> partition your app to best suit your current needs. In runtime.
> Something like that.
>
> Nota also Amber usage on server side, to work with all 1000nds JS apps
> around node.js ecosphere, for instance. Same idea, Aida should choose at
> runtime at which VM to run, a Smalltalk one or Amber/V8 one...
>
> And there is Amber IDE, just perfect to develop Aida apps on the server
> just from your web browser, wherever you are :)
>
> Best regards
> Janko
>
> S, Nicolas Petton piše:
>> Hi,
>>
>> On Wed, 2011-10-05 at 12:10 -0400, Charles Monteiro wrote:
>>>  a good to have just in case but then again one of the reasons why I
>>> like Seaside is because it "wraps" JQuery with what I think is a
>>> cleaner API. Also you can effectively call js from Seaside so how is
>>> Amber different ?
>>
>> Seaside is a server-side web framework. Amber is a Smalltalk that runs
>> on top of JavaScript (client-side).
>>
>> As such, Amber is able to use any JS library in Smalltalk without
>> writing any glue code. Seaside can't do that of course, as it's a
>> server-side Smalltalk web framework.
>>
>> Amber and Seaside are very different by nature and I don't think they
>> compete.
>>
>> Cheers,
>> Nico
>>>
>>> 2011/10/5 Göran Krampe <[hidden email]>
>>>         Hi!
>>>
>>>         Sorry for top posting (my phone) but IMO:
>>>         - Amber offers Smalltalk lang and IDE running in the browser.
>>>         - Amber offers Seaside-ish component/canvas style programming.
>>>         Now, if that was "all" then it would be a hard sell, but the
>>>         killer feature is very good mixability with js code and
>>>         libraries so we can stand on the huge shoulder of the js
>>>         community.
>>>
>>>         This means you can use jQuery or Dojo from Amber right now -
>>>         no "binding" or glue needed.
>>>
>>>         regards, Göran
>>>
>>>
>>>         -- Sent from my Palm Pre 2, wohoo!
>>>
>>>
>>>         ______________________________________________________________
>>>
>>>         On Oct 5, 2011 17:01, Jimmie Houchin <[hidden email]>
>>>         wrote:
>>>
>>>
>>>
>>>         Hello,
>>>
>>>         I am considering writing a web application. I am trying to
>>>         understand my
>>>         options as best I can. I do not know JS and haven't built any
>>>         web app
>>>         before.
>>>
>>>         I do know Smalltalk and love Pharo/Squeak. I know a few other
>>>         languages,
>>>         Python, Lua, etc. and am willing and able to acquire JS as
>>>         necessary.
>>>
>>>         I read that Amber is for developing client-side heavy web
>>>         applications
>>>         in Smalltalk. Disregarding the Smalltalk part. What does Amber
>>>         do for me
>>>         that I can't find in say Dojo?
>>>
>>>         Or how would development compare to Seaside and the
>>>         respective
>>>         performance between similar Seaside and Amber apps?
>>>
>>>         I am just trying to understand where Amber fits in the
>>>         available choices
>>>         in web development. I believe having a good answer to
>>>         questions like
>>>         these would also help Amber be able to position itself in the
>>>         web app
>>>         marketplace. I mention these particular technologies not
>>>         necessarily
>>>         because they are the only or the best. But they are the ones I
>>>         am
>>>         currently exploring for learning this style of web app
>>>         development.
>>>
>>>         Any insight is greatly appreciated.
>>>
>>>         Thanks.
>>>
>>>         Jimmie
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Charles A. Monteiro
>>> www.monteirosfusion.com
>>> sent from the road
>>
>>
>>
>
> --
> Janko Mivšek
> Svetovalec za informatiko
> Eranova d.o.o.
> Ljubljana, Slovenija
> www.eranova.si
> tel:  01 514 22 55
> faks: 01 514 22 56
> gsm: 031 674 565
>

> Larry,
>
> I am taking a crack at the "unified development environment" you describe ... I am working on getting tODE[1] running using Amber for the client-side and Seaside for the server-side, so I am experiencing first hand the issues that I hope to solve .... Still very early on though
>
> Dale
>
> [1] http://code.google.com/p/tode/
> ----- Original Message -----
> | From: "Larry White" <[hidden email]>
> | To: [hidden email]
> | Sent: Wednesday, October 5, 2011 5:15:00 PM
> | Subject: Re: [amber-lang] Amber v. Dojo v. Seaside
> |
> | To add/comment on Janko's post:
> |
> | I think Amber is a client-side solution for people who love, or will
> | love, Smalltalk development, rather than for random
> | php/javascript/ruby guys. For the most part, Smalltalkers will want
> | to
> | write both the client and server in Smalltalk. What I've found
> | missing
> | in my limited experience with Amber, is a total solution perspective,
> | like you see with GWT for example.  In GWT, you work in one IDE: You
> | put your client code here, and your server code there, and your
> | shared
> | code over there. and you can fairly easily wrap your brain around the
> | end-to-end experience of building a client-heavy web application.  A
> | similar approach would be more powerful in Smalltalk.
> |
> | For me, I would love most to be able to do my Amber development in a
> | modified version of Pharo.  I'm interested in the whole Amber on Node
> | thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
> | in developer experience and libraries (compare the stream libraries
> | for example).  It doesn't seem to me to be so hard to imagine a
> | "Client side" browser within Pharo that let you do Amber work along
> | side the standard browser, combined with a standard approach to
> | persisting your Amber code so that it was available on the next page
> | load from Seaside.
> |
> | Anyway, when I think of getting to the full promise of web
> | development
> | in Smalltalk, that's my vision. YMMV :).
> |
> | Larry
> |
> |
> |
> | 2011/10/5 Janko Mivšek <[hidden email]>:
> | > Hi guys,
> | >
> | > I think server-side and client-side web frameworks have a future
> | > when
> | > combined together. At least that is Aida/Web plan with Amber.
> | >
> | > There are apps which are best to be fully client-side, and there
> | > are
> | > those best completely on server side. But majority of them will be
> | > on
> | > both sides. Specially in the era of always on-line connection to
> | > the cloud.
> | >
> | > So, Aida will slowly integrate Amber more and more in its
> | > "ecosphere",
> | > with an end goal to build web apps the same way for both client and
> | > server side. Where to run an app at the end is a decision to be
> | > postponed as late in runtime phase as possible. That way you can
> | > decide
> | > on the fly, where to run. If you go mobile and offline, you can
> | > "load"
> | > and app to your tablet and when you came back online, synchronize
> | > back
> | > to Aida server and continue to run server-side.
> | >
> | > Or "hybrid-side", that is: part on client, part on server. To be
> | > able to
> | > partition your app to best suit your current needs. In runtime.
> | > Something like that.
> | >
> | > Nota also Amber usage on server side, to work with all 1000nds JS
> | > apps
> | > around node.js ecosphere, for instance. Same idea, Aida should
> | > choose at
> | > runtime at which VM to run, a Smalltalk one or Amber/V8 one...
> | >
> | > And there is Amber IDE, just perfect to develop Aida apps on the
> | > server
> | > just from your web browser, wherever you are :)
> | >
> | > Best regards
> | > Janko
> | >
> | > S, Nicolas Petton piše:
> | >> Hi,
> | >>
> | >> On Wed, 2011-10-05 at 12:10 -0400, Charles Monteiro wrote:
> | >>>  a good to have just in case but then again one of the reasons
> | >>>  why I
> | >>> like Seaside is because it "wraps" JQuery with what I think is a
> | >>> cleaner API. Also you can effectively call js from Seaside so how
> | >>> is
> | >>> Amber different ?
> | >>
> | >> Seaside is a server-side web framework. Amber is a Smalltalk that
> | >> runs
> | >> on top of JavaScript (client-side).
> | >>
> | >> As such, Amber is able to use any JS library in Smalltalk without
> | >> writing any glue code. Seaside can't do that of course, as it's a
> | >> server-side Smalltalk web framework.
> | >>
> | >> Amber and Seaside are very different by nature and I don't think
> | >> they
> | >> compete.
> | >>
> | >> Cheers,
> | >> Nico
> | >>>
> | >>> 2011/10/5 Göran Krampe <[hidden email]>
> | >>>         Hi!
> | >>>
> | >>>         Sorry for top posting (my phone) but IMO:
> | >>>         - Amber offers Smalltalk lang and IDE running in the
> | >>>         browser.
> | >>>         - Amber offers Seaside-ish component/canvas style
> | >>>         programming.
> | >>>         Now, if that was "all" then it would be a hard sell, but
> | >>>         the
> | >>>         killer feature is very good mixability with js code and
> | >>>         libraries so we can stand on the huge shoulder of the js
> | >>>         community.
> | >>>
> | >>>         This means you can use jQuery or Dojo from Amber right
> | >>>         now -
> | >>>         no "binding" or glue needed.
> | >>>
> | >>>         regards, Göran
> | >>>
> | >>>
> | >>>         -- Sent from my Palm Pre 2, wohoo!
> | >>>
> | >>>
> | >>>         ______________________________________________________________
> | >>>
> | >>>         On Oct 5, 2011 17:01, Jimmie Houchin
> | >>>         <[hidden email]>
> | >>>         wrote:
> | >>>
> | >>>
> | >>>
> | >>>         Hello,
> | >>>
> | >>>         I am considering writing a web application. I am trying
> | >>>         to
> | >>>         understand my
> | >>>         options as best I can. I do not know JS and haven't built
> | >>>         any
> | >>>         web app
> | >>>         before.
> | >>>
> | >>>         I do know Smalltalk and love Pharo/Squeak. I know a few
> | >>>         other
> | >>>         languages,
> | >>>         Python, Lua, etc. and am willing and able to acquire JS
> | >>>         as
> | >>>         necessary.
> | >>>
> | >>>         I read that Amber is for developing client-side heavy web
> | >>>         applications
> | >>>         in Smalltalk. Disregarding the Smalltalk part. What does
> | >>>         Amber
> | >>>         do for me
> | >>>         that I can't find in say Dojo?
> | >>>
> | >>>         Or how would development compare to Seaside and the
> | >>>         respective
> | >>>         performance between similar Seaside and Amber apps?
> | >>>
> | >>>         I am just trying to understand where Amber fits in the
> | >>>         available choices
> | >>>         in web development. I believe having a good answer to
> | >>>         questions like
> | >>>         these would also help Amber be able to position itself in
> | >>>         the
> | >>>         web app
> | >>>         marketplace. I mention these particular technologies not
> | >>>         necessarily
> | >>>         because they are the only or the best. But they are the
> | >>>         ones I
> | >>>         am
> | >>>         currently exploring for learning this style of web app
> | >>>         development.
> | >>>
> | >>>         Any insight is greatly appreciated.
> | >>>
> | >>>         Thanks.
> | >>>
> | >>>         Jimmie
> | >>>
> | >>>
> | >>>
> | >>>
> | >>>
> | >>> --
> | >>> Charles A. Monteiro
> | >>> www.monteirosfusion.com
> | >>> sent from the road
> | >>
> | >>
> | >>
> | >
> | > --
> | > Janko Mivšek
> | > Svetovalec za informatiko
> | > Eranova d.o.o.
> | > Ljubljana, Slovenija
> | > www.eranova.si
> | > tel:  01 514 22 55
> | > faks: 01 514 22 56
> | > gsm: 031 674 565
> | >
> |

> Hello,
>
> I am considering writing a web application. I am trying to understand
> my options as best I can. I do not know JS and haven't built any web
> app before.
>
> I do know Smalltalk and love Pharo/Squeak. I know a few other
> languages, Python, Lua, etc. and am willing and able to acquire JS as
> necessary.
>
> I read that Amber is for developing client-side heavy web applications
> in Smalltalk. Disregarding the Smalltalk part. What does Amber do for
> me that I can't find in say Dojo?
>
> Or how would development compare to Seaside and the respective
> performance between similar Seaside and Amber apps?
>
> I am just trying to understand where Amber fits in the available
> choices in web development. I believe having a good answer to
> questions like these would also help Amber be able to position itself
> in the web app marketplace. I mention these particular technologies
> not necessarily because they are the only or the best. But they are
> the ones I am currently exploring for learning this style of web app
> development.
>
> Any insight is greatly appreciated.
>
> Thanks.
>
> Jimmie

> Hi guys,
>
> I think server-side and client-side web frameworks have a future when
> combined together. At least that is Aida/Web plan with Amber.
>
> There are apps which are best to be fully client-side, and there are
> those best completely on server side. But majority of them will be on
> both sides. Specially in the era of always on-line connection to the cloud.
>
> So, Aida will slowly integrate Amber more and more in its "ecosphere",
> with an end goal to build web apps the same way for both client and
> server side. Where to run an app at the end is a decision to be
> postponed as late in runtime phase as possible. That way you can decide
> on the fly, where to run. If you go mobile and offline, you can "load"
> and app to your tablet and when you came back online, synchronize back
> to Aida server and continue to run server-side.
>
> Or "hybrid-side", that is: part on client, part on server. To be able to
> partition your app to best suit your current needs. In runtime.
> Something like that.
>
> Nota also Amber usage on server side, to work with all 1000nds JS apps
> around node.js ecosphere, for instance. Same idea, Aida should choose at
> runtime at which VM to run, a Smalltalk one or Amber/V8 one...
>
> And there is Amber IDE, just perfect to develop Aida apps on the server
> just from your web browser, wherever you are :)
>
> Best regards
> Janko

> To add/comment on Janko's post:
>
> I think Amber is a client-side solution for people who love, or will
> love, Smalltalk development, rather than for random
> php/javascript/ruby guys. For the most part, Smalltalkers will want to
> write both the client and server in Smalltalk. What I've found missing
> in my limited experience with Amber, is a total solution perspective,
> like you see with GWT for example.  In GWT, you work in one IDE: You
> put your client code here, and your server code there, and your shared
> code over there. and you can fairly easily wrap your brain around the
> end-to-end experience of building a client-heavy web application.  A
> similar approach would be more powerful in Smalltalk.
>
> For me, I would love most to be able to do my Amber development in a
> modified version of Pharo.  I'm interested in the whole Amber on Node
> thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
> in developer experience and libraries (compare the stream libraries
> for example).  It doesn't seem to me to be so hard to imagine a
> "Client side" browser within Pharo that let you do Amber work along
> side the standard browser, combined with a standard approach to
> persisting your Amber code so that it was available on the next page
> load from Seaside.
>
> Anyway, when I think of getting to the full promise of web development
> in Smalltalk, that's my vision. YMMV :).
>
> Larry
>

> Hello Larry, thanks for the reply.
>
> I agree. I too would love to see a reasonably complete Smalltalk stack here. We drop down into JavaScript when necessary, but develop like Smalltalkers, in Smalltalk with Smalltalk tools. Developing for Seaside, AIDA/Web, Iliad, ... and developing/deploying to Amber for client.
>
> Even if you had to develop Amber in the Web Browser, it would be nice if persistency and version control was handled in Pharo. So at most you have your Pharo server image up for developing that side of things. You had the web browser up for its side. But instead of node.js/webdav the calls were made to the Pharo image. This might be a reasonable mid-step between the present and doing all development in Pharo and deploying its requisite js to the appropriate files.
>
> For those of us who already doing the Pharo/favorite framework server side. We already have that toolset and app running. It would be nice to not have the node.js setup even if they did a nice job for a JS tool. Smalltalk web developers are already using their favorite Smalltalk, framework and a web browser. It would be nice to keep it there.
>
> Just some thoughts.
>
> Thanks.
>
> Jimmie
>
>
>
> On 10/5/2011 7:15 PM, Larry White wrote:
> > To add/comment on Janko's post:
> >
> > I think Amber is a client-side solution for people who love, or will
> > love, Smalltalk development, rather than for random
> > php/javascript/ruby guys. For the most part, Smalltalkers will want to
> > write both the client and server in Smalltalk. What I've found missing
> > in my limited experience with Amber, is a total solution perspective,
> > like you see with GWT for example.  In GWT, you work in one IDE: You
> > put your client code here, and your server code there, and your shared
> > code over there. and you can fairly easily wrap your brain around the
> > end-to-end experience of building a client-heavy web application.  A
> > similar approach would be more powerful in Smalltalk.
> >
> > For me, I would love most to be able to do my Amber development in a
> > modified version of Pharo.  I'm interested in the whole Amber on Node
> > thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
> > in developer experience and libraries (compare the stream libraries
> > for example).  It doesn't seem to me to be so hard to imagine a
> > "Client side" browser within Pharo that let you do Amber work along
> > side the standard browser, combined with a standard approach to
> > persisting your Amber code so that it was available on the next page
> > load from Seaside.
> >
> > Anyway, when I think of getting to the full promise of web development
> > in Smalltalk, that's my vision. YMMV :).
> >
> > Larry
> >

>
> ----- Original Message -----
> | From: "Jimmie Houchin"<[hidden email]>
> | To: [hidden email]
> | Sent: Thursday, October 6, 2011 1:51:36 PM
> | Subject: Re: [amber-lang] Amber v. Dojo v. Seaside
> |
> | Hello Larry, thanks for the reply.
> |
> | I agree. I too would love to see a reasonably complete Smalltalk
> | stack here. We drop down into JavaScript when necessary, but develop
> | like Smalltalkers, in Smalltalk with Smalltalk tools. Developing for
> | Seaside, AIDA/Web, Iliad, ... and developing/deploying to Amber for
> | client.
> |
> | Even if you had to develop Amber in the Web Browser, it would be nice
> | if persistency and version control was handled in Pharo. So at most
> | you have your Pharo server image up for developing that side of
> | things. You had the web browser up for its side. But instead of
> | node.js/webdav the calls were made to the Pharo image. This might be
> | a reasonable mid-step between the present and doing all development
> | in Pharo and deploying its requisite js to the appropriate files.
>
> Jimmie,
>
> I have a project called Kaliningrad[1] that runs in Pharo and uses Seaside as the server-side webDav  ... amber is loaded from a WAFileLibrary (http://localhost:4000/tools/amber-browser will load bring up a Seaside app that runs the Amber Browser) and when you commit packages from the Amber Browser, they are stored in a WAFileLibrary....You can also upload smalltalk classes defined in your pharo image into Amber ...
>
> The name of the package that you use in Amber is the name of the package that is used in Pharo, so you can manage your project's amber source with Monticello ...
>
> I have a rough draft of a blog post describing Kaliningrad in more detail, but I haven't had the time to polish it up ...
>
> I am using Kaliningrad for my tODE development ... I am also toying with the idea of creating classes on the Pharo side when you commit a package from the Amber Browser...but there are probably a couple of sticky wickets to be encountered if you go that way:)
>
> Feel free to take it for a whirl ... if you do decide to use Kaliningrad, let me know so that I can take care not to break it (like snap off a new version)
>
> Dale
>
> [1] http://ss3.gemstone.com/ss/Kaliningrad.html

> Hey guys,
>
> If we look at nowadays web apps, it's clear that JavaScript is now an
> important part of the web stack. Much more than before. We're not
> talking about cool effects, or some XMLHttpRequest anymore, but about
> building better user experiences and more responsive applications with
> some important part of them being in the client side. Take a look at
> Gmail or twitter :)
>
> That's when Amber goes in. Wheither we like it or not, we have to deal
> with javascript-heavy apps. Amber wants to offer a better way to develop
> this part of web applications. As Smalltalkers we all know what that
> means.
>
> Does that mean that apps written with Amber won't need server-side code?
> Certainly not for 99% of them. We need server-side web frameworks, being
> Aida/Seaside/Iliad/Rails/...
>
> Cheers,
> Nico
>
> On Thu, 2011-10-06 at 15:51 -0500, Jimmie Houchin wrote:
>> Hello Larry, thanks for the reply.
>>
>> I agree. I too would love to see a reasonably complete Smalltalk stack here. We drop down into JavaScript when necessary, but develop like Smalltalkers, in Smalltalk with Smalltalk tools. Developing for Seaside, AIDA/Web, Iliad, ... and developing/deploying to Amber for client.
>>
>> Even if you had to develop Amber in the Web Browser, it would be nice if persistency and version control was handled in Pharo. So at most you have your Pharo server image up for developing that side of things. You had the web browser up for its side. But instead of node.js/webdav the calls were made to the Pharo image. This might be a reasonable mid-step between the present and doing all development in Pharo and deploying its requisite js to the appropriate files.
>>
>> For those of us who already doing the Pharo/favorite framework server side. We already have that toolset and app running. It would be nice to not have the node.js setup even if they did a nice job for a JS tool. Smalltalk web developers are already using their favorite Smalltalk, framework and a web browser. It would be nice to keep it there.
>>
>> Just some thoughts.
>>
>> Thanks.
>>
>> Jimmie
>>
>>
>>
>> On 10/5/2011 7:15 PM, Larry White wrote:
>>> To add/comment on Janko's post:
>>>
>>> I think Amber is a client-side solution for people who love, or will
>>> love, Smalltalk development, rather than for random
>>> php/javascript/ruby guys. For the most part, Smalltalkers will want to
>>> write both the client and server in Smalltalk. What I've found missing
>>> in my limited experience with Amber, is a total solution perspective,
>>> like you see with GWT for example.  In GWT, you work in one IDE: You
>>> put your client code here, and your server code there, and your shared
>>> code over there. and you can fairly easily wrap your brain around the
>>> end-to-end experience of building a client-heavy web application.  A
>>> similar approach would be more powerful in Smalltalk.
>>>
>>> For me, I would love most to be able to do my Amber development in a
>>> modified version of Pharo.  I'm interested in the whole Amber on Node
>>> thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
>>> in developer experience and libraries (compare the stream libraries
>>> for example).  It doesn't seem to me to be so hard to imagine a
>>> "Client side" browser within Pharo that let you do Amber work along
>>> side the standard browser, combined with a standard approach to
>>> persisting your Amber code so that it was available on the next page
>>> load from Seaside.
>>>
>>> Anyway, when I think of getting to the full promise of web development
>>> in Smalltalk, that's my vision. YMMV :).
>>>
>>> Larry
>>>
>

> Hey Nicolas,
>
> I absolutely agree with what you say.
> I absolutely want a better way to write rich client apps.
> I want to write a mash-up which will store nominal stuff on the client
> and collect content from other peoples servers. I would not be running a
> server at all. I think Amber would be great for this.
>
> Some of what I was referring to is the somewhat
> recommend/required/desired use of node.js/webdav instead of Pharo et al.
> server side tools.
>
> Now, I speak totally out of ignorance regarding node.js/webdav. It might
> be wonderful and simple. I haven't used it yet. But it isn't a part of
> the client-side javascript heavy apps you are referring to. It is server
> side. For those of use accustomed to Smalltalk development. I really
> like having method versioning on commits/saves. I like being able to
> easily undo a method commit, that just broke what previously worked. I
> really like Monticello. I like the Smalltalk way of development.
>
> If we can reach than kind of development from within the web browser
> writing Amber code, then I am totally cool with that. I am happy to use
> a web UI and Pharo as server. But I would like tools which begin to
> approach what I currently use. If not, then the Smalltalker who uses
> Amber is always going to have that gentle tug.
>
> Now, I haven't yet dug in and used Amber yet. If Amber already does per
> method commits/saves/versioning, then woohoo. If I lose the Smalltalk
> live objects, development model and toolchain, then once again my
> question would be, why am I not just simply writing a Dojo app? I am not
> one who wants to write Smalltalk in Emacs. :)  (or any other plain dead
> text editor)
>
> And if thats the case, I don't have a problem learning JavaScript, Dojo,
> etc...    ( or Dart,  wink, wink.  ;)
>
> Like you, I really believe I can do much of what I want to do totally on
> the client. Especially with indexedDb, localStorage or whatever.
>
> This is why I started this discussion so that I could learn, what
> exactly does Amber buy me, as opposed to going straight to
> JS/Dojo/node.js, etc.
>
>
> Jimmie
>
> On 10/6/2011 4:19 PM, Nicolas Petton wrote:
> > Hey guys,
> >
> > If we look at nowadays web apps, it's clear that JavaScript is now an
> > important part of the web stack. Much more than before. We're not
> > talking about cool effects, or some XMLHttpRequest anymore, but about
> > building better user experiences and more responsive applications with
> > some important part of them being in the client side. Take a look at
> > Gmail or twitter :)
> >
> > That's when Amber goes in. Wheither we like it or not, we have to deal
> > with javascript-heavy apps. Amber wants to offer a better way to develop
> > this part of web applications. As Smalltalkers we all know what that
> > means.
> >
> > Does that mean that apps written with Amber won't need server-side code?
> > Certainly not for 99% of them. We need server-side web frameworks, being
> > Aida/Seaside/Iliad/Rails/...
> >
> > Cheers,
> > Nico
> >
> > On Thu, 2011-10-06 at 15:51 -0500, Jimmie Houchin wrote:
> >> Hello Larry, thanks for the reply.
> >>
> >> I agree. I too would love to see a reasonably complete Smalltalk stack here. We drop down into JavaScript when necessary, but develop like Smalltalkers, in Smalltalk with Smalltalk tools. Developing for Seaside, AIDA/Web, Iliad, ... and developing/deploying to Amber for client.
> >>
> >> Even if you had to develop Amber in the Web Browser, it would be nice if persistency and version control was handled in Pharo. So at most you have your Pharo server image up for developing that side of things. You had the web browser up for its side. But instead of node.js/webdav the calls were made to the Pharo image. This might be a reasonable mid-step between the present and doing all development in Pharo and deploying its requisite js to the appropriate files.
> >>
> >> For those of us who already doing the Pharo/favorite framework server side. We already have that toolset and app running. It would be nice to not have the node.js setup even if they did a nice job for a JS tool. Smalltalk web developers are already using their favorite Smalltalk, framework and a web browser. It would be nice to keep it there.
> >>
> >> Just some thoughts.
> >>
> >> Thanks.
> >>
> >> Jimmie
> >>
> >>
> >>
> >> On 10/5/2011 7:15 PM, Larry White wrote:
> >>> To add/comment on Janko's post:
> >>>
> >>> I think Amber is a client-side solution for people who love, or will
> >>> love, Smalltalk development, rather than for random
> >>> php/javascript/ruby guys. For the most part, Smalltalkers will want to
> >>> write both the client and server in Smalltalk. What I've found missing
> >>> in my limited experience with Amber, is a total solution perspective,
> >>> like you see with GWT for example.  In GWT, you work in one IDE: You
> >>> put your client code here, and your server code there, and your shared
> >>> code over there. and you can fairly easily wrap your brain around the
> >>> end-to-end experience of building a client-heavy web application.  A
> >>> similar approach would be more powerful in Smalltalk.
> >>>
> >>> For me, I would love most to be able to do my Amber development in a
> >>> modified version of Pharo.  I'm interested in the whole Amber on Node
> >>> thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
> >>> in developer experience and libraries (compare the stream libraries
> >>> for example).  It doesn't seem to me to be so hard to imagine a
> >>> "Client side" browser within Pharo that let you do Amber work along
> >>> side the standard browser, combined with a standard approach to
> >>> persisting your Amber code so that it was available on the next page
> >>> load from Seaside.
> >>>
> >>> Anyway, when I think of getting to the full promise of web development
> >>> in Smalltalk, that's my vision. YMMV :).
> >>>
> >>> Larry
> >>>
> >
>

> Dale already has something with Seaside, and I have something similar
> with Iliad. I know Janko plans to integrate Amber in Aida. Oh, and
> there's a Rails package :)
>
>
> Cheers,
> Nico
>
> On Thu, 2011-10-06 at 17:39 -0500, Jimmie Houchin wrote:
>> Hey Nicolas,
>>
>> I absolutely agree with what you say.
>> I absolutely want a better way to write rich client apps.
>> I want to write a mash-up which will store nominal stuff on the client
>> and collect content from other peoples servers. I would not be running a
>> server at all. I think Amber would be great for this.
>>
>> Some of what I was referring to is the somewhat
>> recommend/required/desired use of node.js/webdav instead of Pharo et al.
>> server side tools.
>>
>> Now, I speak totally out of ignorance regarding node.js/webdav. It might
>> be wonderful and simple. I haven't used it yet. But it isn't a part of
>> the client-side javascript heavy apps you are referring to. It is server
>> side. For those of use accustomed to Smalltalk development. I really
>> like having method versioning on commits/saves. I like being able to
>> easily undo a method commit, that just broke what previously worked. I
>> really like Monticello. I like the Smalltalk way of development.
>>
>> If we can reach than kind of development from within the web browser
>> writing Amber code, then I am totally cool with that. I am happy to use
>> a web UI and Pharo as server. But I would like tools which begin to
>> approach what I currently use. If not, then the Smalltalker who uses
>> Amber is always going to have that gentle tug.
>>
>> Now, I haven't yet dug in and used Amber yet. If Amber already does per
>> method commits/saves/versioning, then woohoo. If I lose the Smalltalk
>> live objects, development model and toolchain, then once again my
>> question would be, why am I not just simply writing a Dojo app? I am not
>> one who wants to write Smalltalk in Emacs. :)  (or any other plain dead
>> text editor)
>>
>> And if thats the case, I don't have a problem learning JavaScript, Dojo,
>> etc...    ( or Dart,  wink, wink.  ;)
>>
>> Like you, I really believe I can do much of what I want to do totally on
>> the client. Especially with indexedDb, localStorage or whatever.
>>
>> This is why I started this discussion so that I could learn, what
>> exactly does Amber buy me, as opposed to going straight to
>> JS/Dojo/node.js, etc.
>>
>>
>> Jimmie
>>
>> On 10/6/2011 4:19 PM, Nicolas Petton wrote:
>>> Hey guys,
>>>
>>> If we look at nowadays web apps, it's clear that JavaScript is now an
>>> important part of the web stack. Much more than before. We're not
>>> talking about cool effects, or some XMLHttpRequest anymore, but about
>>> building better user experiences and more responsive applications with
>>> some important part of them being in the client side. Take a look at
>>> Gmail or twitter :)
>>>
>>> That's when Amber goes in. Wheither we like it or not, we have to deal
>>> with javascript-heavy apps. Amber wants to offer a better way to develop
>>> this part of web applications. As Smalltalkers we all know what that
>>> means.
>>>
>>> Does that mean that apps written with Amber won't need server-side code?
>>> Certainly not for 99% of them. We need server-side web frameworks, being
>>> Aida/Seaside/Iliad/Rails/...
>>>
>>> Cheers,
>>> Nico
>>>
>>> On Thu, 2011-10-06 at 15:51 -0500, Jimmie Houchin wrote:
>>>> Hello Larry, thanks for the reply.
>>>>
>>>> I agree. I too would love to see a reasonably complete Smalltalk stack here. We drop down into JavaScript when necessary, but develop like Smalltalkers, in Smalltalk with Smalltalk tools. Developing for Seaside, AIDA/Web, Iliad, ... and developing/deploying to Amber for client.
>>>>
>>>> Even if you had to develop Amber in the Web Browser, it would be nice if persistency and version control was handled in Pharo. So at most you have your Pharo server image up for developing that side of things. You had the web browser up for its side. But instead of node.js/webdav the calls were made to the Pharo image. This might be a reasonable mid-step between the present and doing all development in Pharo and deploying its requisite js to the appropriate files.
>>>>
>>>> For those of us who already doing the Pharo/favorite framework server side. We already have that toolset and app running. It would be nice to not have the node.js setup even if they did a nice job for a JS tool. Smalltalk web developers are already using their favorite Smalltalk, framework and a web browser. It would be nice to keep it there.
>>>>
>>>> Just some thoughts.
>>>>
>>>> Thanks.
>>>>
>>>> Jimmie
>>>>
>>>>
>>>>
>>>> On 10/5/2011 7:15 PM, Larry White wrote:
>>>>> To add/comment on Janko's post:
>>>>>
>>>>> I think Amber is a client-side solution for people who love, or will
>>>>> love, Smalltalk development, rather than for random
>>>>> php/javascript/ruby guys. For the most part, Smalltalkers will want to
>>>>> write both the client and server in Smalltalk. What I've found missing
>>>>> in my limited experience with Amber, is a total solution perspective,
>>>>> like you see with GWT for example.  In GWT, you work in one IDE: You
>>>>> put your client code here, and your server code there, and your shared
>>>>> code over there. and you can fairly easily wrap your brain around the
>>>>> end-to-end experience of building a client-heavy web application.  A
>>>>> similar approach would be more powerful in Smalltalk.
>>>>>
>>>>> For me, I would love most to be able to do my Amber development in a
>>>>> modified version of Pharo.  I'm interested in the whole Amber on Node
>>>>> thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
>>>>> in developer experience and libraries (compare the stream libraries
>>>>> for example).  It doesn't seem to me to be so hard to imagine a
>>>>> "Client side" browser within Pharo that let you do Amber work along
>>>>> side the standard browser, combined with a standard approach to
>>>>> persisting your Amber code so that it was available on the next page
>>>>> load from Seaside.
>>>>>
>>>>> Anyway, when I think of getting to the full promise of web development
>>>>> in Smalltalk, that's my vision. YMMV :).
>>>>>
>>>>> Larry
>>>>>
>

> Hello,
>
> Thanks for the reply.
>
> On 10/7/2011 3:51 AM, Nicolas Petton wrote:
> > Hi,
> >
> > Amber doesn't do method versioning yet. st files are versioned through
> > git, but it doesn't mean you have to write Smalltalk code inside Emacs,
> > you can use the web-based IDE. That's what I do. Even for Node.js code.
> > As an example, I wrote the file server (in bin/server) in the IDE. Sure,
> > I missed the debugger, but as Avi said, it would be great to edit both
> > client-side and server-side (ie on top of node.js) code from the IDE.
> Nothing I posted about were deal breakers. My main goal was/is to try to
> dive in and try to separate Amber from the others. To distinguish why
> and when to choose Amber.
>
> I don't need Amber to do JQuery, Dojo, or any other JS library or
> framework. What is Amber really buying me?
>
> Amber buys a Smalltalker like me a lot. But if the only reason Amber
> buys me what it does is because I am not a JavaScript guy, then I could
> use CoffeeScript.
>
> If Amber is a Smalltalk, then I expect similar things to my other
> Smalltalk experiences.
>
> Which is where my failed Emacs comment comes in. My apologies, it did
> not come across as intended. What I meant was that not specifically
> Emacs, but rather a dead text editor, rather than a live object editing
> environment. We have certain expectations of our browsers beyond what a
> text editor does. That is what I meant. I hope I am being more clear
> here. I don't want Notepad in a browser to edit my Smalltalk language.
>
> I am not trying to be adversarial. But I am trying to get us to come up
> with our story. Our story is why some one would choose us. Our story
> must be more than we can do what they can do with the tools they developed.
>
> For me as a Smalltalker, Amber a Smalltalk in the browser is a natural
> sale provided it actually delivers Smalltalk not just the Smalltalk
> language.
>
> Why would I as a JQuery or Dojo user and JavaScript expert choose
> Amber?  We need a good story here. Otherwise we are limiting our
> audience to people who favor Smalltalk.
>
> > I know Göran plans to port Delta to Amber, maybe this will improve
> > versioning. As for myself, I don't want to lose GIT, because I think
> > it's currently the best VCS. And it's not just GIT, with Amber you can
> > actually choose your tools, if you like svn, use svn.
> > About Pharo vs node vs you-name-it, there's nothing in Amber that makes
> > the choice for you. Amber is only a Smalltalk that runs on top of JS.
> > Use it however you like. I would love to see Seaside/Iliad/Aida
> > integration, node.js backend, callback/JSON based communication from the
> > server, etc.
> Amber is only a Smalltalk that runs on top of the JS.
> But what defines a Smalltalk?
> I am a Smalltalker. I like my language, my environment, my tools. For me
> (and I think many others) that is what Smalltalk is.
>
> I have no problem with GIT.
> I want Amber to use GIT or whatever VCS Amber chooses as its tool
> without me explicitly knowing. It should be an implementation detail
> that I don't have to know in order to do normal method or package commit
> and it do what a Smalltalker would expect. I do not know or care about
> the implementation of Monticello. I know it is integrated into my
> toolchain and it is easy and intuitive to use. I only see its interface
> to me.
>
> When I read the archives and I see stuff like requires, Apache, node.js,
> etc...
> All in order to get what I expect from a Smalltalk environment, just to
> simply be able to commit.
> We have left the world I like and entered a world where I find it harder
> to distinguish the advantages of Amber.
>
> Now if in Amber, I select install webdav server package. It then
> downloads, installs and starts up node.js/webdav, then were talking. The
> toolchain is working, and I am doing it from my environment.
>
> Now I know Amber currently cannot do something like that. And I don't if
> that would ever be in the capability.
>
> I actually like node.js.  I think it is pretty cool technology. And with
> a nice Windows executable. It was actually easier to install than I
> expected.
>
> I personally would have no problem with embracing node.js and making it
> a part of the Amber development toolchain. Let it be the interface to
> os, apps, and storage side of things. For development purposes, we would
> have the ability to reach outside the browser. It would provide avenues
> to make Amber as about a complete Smalltalk as any other. Of course I am
> reading into this the ability that node.js has on the os to do things.
> Regardless, node.js or some other languages webdav, and commandline
> toolset. This would also provide Amber with the ability to create
> Desktop apps for the browser. Of course this should only be done in the
> context of full disclosure and knowledge to the user.
>
> I like opinionated software. :)
>
> I want to know what is the Vision for Amber.
> What is the roadmap to achieve that vision.
> Where are we on the roadmap.
>
> Smalltalkers like the full end user development experience.
>
> This is open source software.  (and thank you for creating it)
>
> Anybody with the resources can do whatever they want with it.
>
> But what is your Vision or the communities Vision for Amber.
> And when I say community, in this context I mean more of a meritocracy.
> I have no say in the vision as I have contributed nothing but a bunch of
> hot air. :)
>
> Even if you do not have the resources in and of your own self to
> complete the Vision. If you help the community to have a vision. Then we
> can fill out Göran's roadmap to 1.0. And the community can come on board
> and help reach it.
>
> I do not have the knowledge to pick the best JS libraries to interface,
> the best VCS to version our code, the best...
>
> Could one port Iliad to run on Amber on node.js?  Just an interesting
> thought?
> Could we have Amber as such on client and server side JS?
>
> The world is open. Where do we want to go?
>
> Thanks, and my apologies for being as adversarial as I am. I really want
> Amber to do well. But I think we have to know who we are and what our
> story is. Both to Smalltalkers and to JS or other web dev people.
>
> Jimmie
>
> > Dale already has something with Seaside, and I have something similar
> > with Iliad. I know Janko plans to integrate Amber in Aida. Oh, and
> > there's a Rails package :)
> >
> >
> > Cheers,
> > Nico
> >
> > On Thu, 2011-10-06 at 17:39 -0500, Jimmie Houchin wrote:
> >> Hey Nicolas,
> >>
> >> I absolutely agree with what you say.
> >> I absolutely want a better way to write rich client apps.
> >> I want to write a mash-up which will store nominal stuff on the client
> >> and collect content from other peoples servers. I would not be running a
> >> server at all. I think Amber would be great for this.
> >>
> >> Some of what I was referring to is the somewhat
> >> recommend/required/desired use of node.js/webdav instead of Pharo et al.
> >> server side tools.
> >>
> >> Now, I speak totally out of ignorance regarding node.js/webdav. It might
> >> be wonderful and simple. I haven't used it yet. But it isn't a part of
> >> the client-side javascript heavy apps you are referring to. It is server
> >> side. For those of use accustomed to Smalltalk development. I really
> >> like having method versioning on commits/saves. I like being able to
> >> easily undo a method commit, that just broke what previously worked. I
> >> really like Monticello. I like the Smalltalk way of development.
> >>
> >> If we can reach than kind of development from within the web browser
> >> writing Amber code, then I am totally cool with that. I am happy to use
> >> a web UI and Pharo as server. But I would like tools which begin to
> >> approach what I currently use. If not, then the Smalltalker who uses
> >> Amber is always going to have that gentle tug.
> >>
> >> Now, I haven't yet dug in and used Amber yet. If Amber already does per
> >> method commits/saves/versioning, then woohoo. If I lose the Smalltalk
> >> live objects, development model and toolchain, then once again my
> >> question would be, why am I not just simply writing a Dojo app? I am not
> >> one who wants to write Smalltalk in Emacs. :)  (or any other plain dead
> >> text editor)
> >>
> >> And if thats the case, I don't have a problem learning JavaScript, Dojo,
> >> etc...    ( or Dart,  wink, wink.  ;)
> >>
> >> Like you, I really believe I can do much of what I want to do totally on
> >> the client. Especially with indexedDb, localStorage or whatever.
> >>
> >> This is why I started this discussion so that I could learn, what
> >> exactly does Amber buy me, as opposed to going straight to
> >> JS/Dojo/node.js, etc.
> >>
> >>
> >> Jimmie
> >>
> >> On 10/6/2011 4:19 PM, Nicolas Petton wrote:
> >>> Hey guys,
> >>>
> >>> If we look at nowadays web apps, it's clear that JavaScript is now an
> >>> important part of the web stack. Much more than before. We're not
> >>> talking about cool effects, or some XMLHttpRequest anymore, but about
> >>> building better user experiences and more responsive applications with
> >>> some important part of them being in the client side. Take a look at
> >>> Gmail or twitter :)
> >>>
> >>> That's when Amber goes in. Wheither we like it or not, we have to deal
> >>> with javascript-heavy apps. Amber wants to offer a better way to develop
> >>> this part of web applications. As Smalltalkers we all know what that
> >>> means.
> >>>
> >>> Does that mean that apps written with Amber won't need server-side code?
> >>> Certainly not for 99% of them. We need server-side web frameworks, being
> >>> Aida/Seaside/Iliad/Rails/...
> >>>
> >>> Cheers,
> >>> Nico
> >>>
> >>> On Thu, 2011-10-06 at 15:51 -0500, Jimmie Houchin wrote:
> >>>> Hello Larry, thanks for the reply.
> >>>>
> >>>> I agree. I too would love to see a reasonably complete Smalltalk stack here. We drop down into JavaScript when necessary, but develop like Smalltalkers, in Smalltalk with Smalltalk tools. Developing for Seaside, AIDA/Web, Iliad, ... and developing/deploying to Amber for client.
> >>>>
> >>>> Even if you had to develop Amber in the Web Browser, it would be nice if persistency and version control was handled in Pharo. So at most you have your Pharo server image up for developing that side of things. You had the web browser up for its side. But instead of node.js/webdav the calls were made to the Pharo image. This might be a reasonable mid-step between the present and doing all development in Pharo and deploying its requisite js to the appropriate files.
> >>>>
> >>>> For those of us who already doing the Pharo/favorite framework server side. We already have that toolset and app running. It would be nice to not have the node.js setup even if they did a nice job for a JS tool. Smalltalk web developers are already using their favorite Smalltalk, framework and a web browser. It would be nice to keep it there.
> >>>>
> >>>> Just some thoughts.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> Jimmie
> >>>>
> >>>>
> >>>>
> >>>> On 10/5/2011 7:15 PM, Larry White wrote:
> >>>>> To add/comment on Janko's post:
> >>>>>
> >>>>> I think Amber is a client-side solution for people who love, or will
> >>>>> love, Smalltalk development, rather than for random
> >>>>> php/javascript/ruby guys. For the most part, Smalltalkers will want to
> >>>>> write both the client and server in Smalltalk. What I've found missing
> >>>>> in my limited experience with Amber, is a total solution perspective,
> >>>>> like you see with GWT for example.  In GWT, you work in one IDE: You
> >>>>> put your client code here, and your server code there, and your shared
> >>>>> code over there. and you can fairly easily wrap your brain around the
> >>>>> end-to-end experience of building a client-heavy web application.  A
> >>>>> similar approach would be more powerful in Smalltalk.
> >>>>>
> >>>>> For me, I would love most to be able to do my Amber development in a
> >>>>> modified version of Pharo.  I'm interested in the whole Amber on Node
> >>>>> thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
> >>>>> in developer experience and libraries (compare the stream libraries
> >>>>> for example).  It doesn't seem to me to be so hard to imagine a
> >>>>> "Client side" browser within Pharo that let you do Amber work along
> >>>>> side the standard browser, combined with a standard approach to
> >>>>> persisting your Amber code so that it was available on the next page
> >>>>> load from Seaside.
> >>>>>
> >>>>> Anyway, when I think of getting to the full promise of web development
> >>>>> in Smalltalk, that's my vision. YMMV :).
> >>>>>
> >>>>> Larry
> >>>>>
> >
>

> Hello,
>
> Thanks for the reply.
>
> On 10/7/2011 3:51 AM, Nicolas Petton wrote:
>> Hi,
>>
>> Amber doesn't do method versioning yet. st files are versioned through
>> git, but it doesn't mean you have to write Smalltalk code inside Emacs,
>> you can use the web-based IDE. That's what I do. Even for Node.js code.
>> As an example, I wrote the file server (in bin/server) in the IDE. Sure,
>> I missed the debugger, but as Avi said, it would be great to edit both
>> client-side and server-side (ie on top of node.js) code from the IDE.
> Nothing I posted about were deal breakers. My main goal was/is to try to dive in and try to separate Amber from the others. To distinguish why and when to choose Amber.
>
> I don't need Amber to do JQuery, Dojo, or any other JS library or framework. What is Amber really buying me?
>
> Amber buys a Smalltalker like me a lot. But if the only reason Amber buys me what it does is because I am not a JavaScript guy, then I could use CoffeeScript.
>
> If Amber is a Smalltalk, then I expect similar things to my other Smalltalk experiences.
>
> Which is where my failed Emacs comment comes in. My apologies, it did not come across as intended. What I meant was that not specifically Emacs, but rather a dead text editor, rather than a live object editing environment. We have certain expectations of our browsers beyond what a text editor does. That is what I meant. I hope I am being more clear here. I don't want Notepad in a browser to edit my Smalltalk language.
>
> I am not trying to be adversarial. But I am trying to get us to come up with our story. Our story is why some one would choose us. Our story must be more than we can do what they can do with the tools they developed.
>
> For me as a Smalltalker, Amber a Smalltalk in the browser is a natural sale provided it actually delivers Smalltalk not just the Smalltalk language.
>
> Why would I as a JQuery or Dojo user and JavaScript expert choose Amber?  We need a good story here. Otherwise we are limiting our audience to people who favor Smalltalk.
>
>> I know Göran plans to port Delta to Amber, maybe this will improve
>> versioning. As for myself, I don't want to lose GIT, because I think
>> it's currently the best VCS. And it's not just GIT, with Amber you can
>> actually choose your tools, if you like svn, use svn.
>> About Pharo vs node vs you-name-it, there's nothing in Amber that makes
>> the choice for you. Amber is only a Smalltalk that runs on top of JS.
>> Use it however you like. I would love to see Seaside/Iliad/Aida
>> integration, node.js backend, callback/JSON based communication from the
>> server, etc.
> Amber is only a Smalltalk that runs on top of the JS.
> But what defines a Smalltalk?
> I am a Smalltalker. I like my language, my environment, my tools. For me (and I think many others) that is what Smalltalk is.
>
> I have no problem with GIT.
> I want Amber to use GIT or whatever VCS Amber chooses as its tool without me explicitly knowing. It should be an implementation detail that I don't have to know in order to do normal method or package commit and it do what a Smalltalker would expect. I do not know or care about the implementation of Monticello. I know it is integrated into my toolchain and it is easy and intuitive to use. I only see its interface to me.
>
> When I read the archives and I see stuff like requires, Apache, node.js, etc...
> All in order to get what I expect from a Smalltalk environment, just to simply be able to commit.
> We have left the world I like and entered a world where I find it harder to distinguish the advantages of Amber.
>
> Now if in Amber, I select install webdav server package. It then downloads, installs and starts up node.js/webdav, then were talking. The toolchain is working, and I am doing it from my environment.
>
> Now I know Amber currently cannot do something like that. And I don't if that would ever be in the capability.
>
> I actually like node.js.  I think it is pretty cool technology. And with a nice Windows executable. It was actually easier to install than I expected.
>
> I personally would have no problem with embracing node.js and making it a part of the Amber development toolchain. Let it be the interface to os, apps, and storage side of things. For development purposes, we would have the ability to reach outside the browser. It would provide avenues to make Amber as about a complete Smalltalk as any other. Of course I am reading into this the ability that node.js has on the os to do things. Regardless, node.js or some other languages webdav, and commandline toolset. This would also provide Amber with the ability to create Desktop apps for the browser. Of course this should only be done in the context of full disclosure and knowledge to the user.
>
> I like opinionated software. :)
>
> I want to know what is the Vision for Amber.
> What is the roadmap to achieve that vision.
> Where are we on the roadmap.
>
> Smalltalkers like the full end user development experience.
>
> This is open source software.  (and thank you for creating it)
>
> Anybody with the resources can do whatever they want with it.
>
> But what is your Vision or the communities Vision for Amber.
> And when I say community, in this context I mean more of a meritocracy.
> I have no say in the vision as I have contributed nothing but a bunch of hot air. :)
>
> Even if you do not have the resources in and of your own self to complete the Vision. If you help the community to have a vision. Then we can fill out Göran's roadmap to 1.0. And the community can come on board and help reach it.
>
> I do not have the knowledge to pick the best JS libraries to interface, the best VCS to version our code, the best...
>
> Could one port Iliad to run on Amber on node.js?  Just an interesting thought?
> Could we have Amber as such on client and server side JS?
>
> The world is open. Where do we want to go?
>
> Thanks, and my apologies for being as adversarial as I am. I really want Amber to do well. But I think we have to know who we are and what our story is. Both to Smalltalkers and to JS or other web dev people.
>
> Jimmie
>
>> Dale already has something with Seaside, and I have something similar
>> with Iliad. I know Janko plans to integrate Amber in Aida. Oh, and
>> there's a Rails package :)
>>
>>
>> Cheers,
>> Nico
>>
>> On Thu, 2011-10-06 at 17:39 -0500, Jimmie Houchin wrote:
>>> Hey Nicolas,
>>>
>>> I absolutely agree with what you say.
>>> I absolutely want a better way to write rich client apps.
>>> I want to write a mash-up which will store nominal stuff on the client
>>> and collect content from other peoples servers. I would not be running a
>>> server at all. I think Amber would be great for this.
>>>
>>> Some of what I was referring to is the somewhat
>>> recommend/required/desired use of node.js/webdav instead of Pharo et al.
>>> server side tools.
>>>
>>> Now, I speak totally out of ignorance regarding node.js/webdav. It might
>>> be wonderful and simple. I haven't used it yet. But it isn't a part of
>>> the client-side javascript heavy apps you are referring to. It is server
>>> side. For those of use accustomed to Smalltalk development. I really
>>> like having method versioning on commits/saves. I like being able to
>>> easily undo a method commit, that just broke what previously worked. I
>>> really like Monticello. I like the Smalltalk way of development.
>>>
>>> If we can reach than kind of development from within the web browser
>>> writing Amber code, then I am totally cool with that. I am happy to use
>>> a web UI and Pharo as server. But I would like tools which begin to
>>> approach what I currently use. If not, then the Smalltalker who uses
>>> Amber is always going to have that gentle tug.
>>>
>>> Now, I haven't yet dug in and used Amber yet. If Amber already does per
>>> method commits/saves/versioning, then woohoo. If I lose the Smalltalk
>>> live objects, development model and toolchain, then once again my
>>> question would be, why am I not just simply writing a Dojo app? I am not
>>> one who wants to write Smalltalk in Emacs. :)  (or any other plain dead
>>> text editor)
>>>
>>> And if thats the case, I don't have a problem learning JavaScript, Dojo,
>>> etc...    ( or Dart,  wink, wink.  ;)
>>>
>>> Like you, I really believe I can do much of what I want to do totally on
>>> the client. Especially with indexedDb, localStorage or whatever.
>>>
>>> This is why I started this discussion so that I could learn, what
>>> exactly does Amber buy me, as opposed to going straight to
>>> JS/Dojo/node.js, etc.
>>>
>>>
>>> Jimmie
>>>
>>> On 10/6/2011 4:19 PM, Nicolas Petton wrote:
>>>> Hey guys,
>>>>
>>>> If we look at nowadays web apps, it's clear that JavaScript is now an
>>>> important part of the web stack. Much more than before. We're not
>>>> talking about cool effects, or some XMLHttpRequest anymore, but about
>>>> building better user experiences and more responsive applications with
>>>> some important part of them being in the client side. Take a look at
>>>> Gmail or twitter :)
>>>>
>>>> That's when Amber goes in. Wheither we like it or not, we have to deal
>>>> with javascript-heavy apps. Amber wants to offer a better way to develop
>>>> this part of web applications. As Smalltalkers we all know what that
>>>> means.
>>>>
>>>> Does that mean that apps written with Amber won't need server-side code?
>>>> Certainly not for 99% of them. We need server-side web frameworks, being
>>>> Aida/Seaside/Iliad/Rails/...
>>>>
>>>> Cheers,
>>>> Nico
>>>>
>>>> On Thu, 2011-10-06 at 15:51 -0500, Jimmie Houchin wrote:
>>>>> Hello Larry, thanks for the reply.
>>>>>
>>>>> I agree. I too would love to see a reasonably complete Smalltalk stack here. We drop down into JavaScript when necessary, but develop like Smalltalkers, in Smalltalk with Smalltalk tools. Developing for Seaside, AIDA/Web, Iliad, ... and developing/deploying to Amber for client.
>>>>>
>>>>> Even if you had to develop Amber in the Web Browser, it would be nice if persistency and version control was handled in Pharo. So at most you have your Pharo server image up for developing that side of things. You had the web browser up for its side. But instead of node.js/webdav the calls were made to the Pharo image. This might be a reasonable mid-step between the present and doing all development in Pharo and deploying its requisite js to the appropriate files.
>>>>>
>>>>> For those of us who already doing the Pharo/favorite framework server side. We already have that toolset and app running. It would be nice to not have the node.js setup even if they did a nice job for a JS tool. Smalltalk web developers are already using their favorite Smalltalk, framework and a web browser. It would be nice to keep it there.
>>>>>
>>>>> Just some thoughts.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Jimmie
>>>>>
>>>>>
>>>>>
>>>>> On 10/5/2011 7:15 PM, Larry White wrote:
>>>>>> To add/comment on Janko's post:
>>>>>>
>>>>>> I think Amber is a client-side solution for people who love, or will
>>>>>> love, Smalltalk development, rather than for random
>>>>>> php/javascript/ruby guys. For the most part, Smalltalkers will want to
>>>>>> write both the client and server in Smalltalk. What I've found missing
>>>>>> in my limited experience with Amber, is a total solution perspective,
>>>>>> like you see with GWT for example.  In GWT, you work in one IDE: You
>>>>>> put your client code here, and your server code there, and your shared
>>>>>> code over there. and you can fairly easily wrap your brain around the
>>>>>> end-to-end experience of building a client-heavy web application.  A
>>>>>> similar approach would be more powerful in Smalltalk.
>>>>>>
>>>>>> For me, I would love most to be able to do my Amber development in a
>>>>>> modified version of Pharo.  I'm interested in the whole Amber on Node
>>>>>> thing, but Pharo (using Aida or Seaside or Illiad) is still far ahead
>>>>>> in developer experience and libraries (compare the stream libraries
>>>>>> for example).  It doesn't seem to me to be so hard to imagine a
>>>>>> "Client side" browser within Pharo that let you do Amber work along
>>>>>> side the standard browser, combined with a standard approach to
>>>>>> persisting your Amber code so that it was available on the next page
>>>>>> load from Seaside.
>>>>>>
>>>>>> Anyway, when I think of getting to the full promise of web development
>>>>>> in Smalltalk, that's my vision. YMMV :).
>>>>>>
>>>>>> Larry
>>>>>>
>>
>