Thanks for you reply Colin!


2014/1/20 Colin Putney <colin at wiresong.com>

>
>
>
> On Mon, Jan 20, 2014 at 6:55 PM, Germán Arduino <garduino at gmail.com>wrote:
>
>
>> Can you elaborate a bit more what do you mean with "modern web*
>> replacement for Seaside? I really have not found yet the utility of a tool
>> as Amber, and I'm very interested in learn about what new ways of
>> development Amber make more easy.
>>
>
> Well, a typical Seaside application is largely components. They render
> bits of HTML and handle callbacks triggered by the user's actions. They're
> UI; Seaside doesn't concern its self with model objects or persistence.
>
> Amber does the same sort of thing. You have a tree of components that
> render HTML programatically, and react to user gestures. But instead of
> handling HTTP requests and producing responses, an Amber app runs in the
> browser. It updates the DOM directly and handles DOM events without a
> round-trip to the server. That allows the app to be much more responsive
> and eliminates the need for modal interfaces that Chris complained about.
> In that sense it's "modern."
>
>
Ah ok! I agree.



> On the other hand, I don't use Amber, personally. I don't mind writing
> Javascript directly, and I like to be able to use the really amazing
> Javascript frameworks that are out there—e.g. Angular or React. Also,
> performance matters on the web, and it's particularly difficult to get good
> frame rates on mobile browsers, so I find the layer of indirection that
> compile-to-Javascript introduces just gets in my way when it comes time to
> debug and optimize.
>
> So I'd say that Amber is useful if you'd rather write Smalltalk than
> Javascript, or if you want to stick with the Seaside UI paradigm of
> components rendering and callbacks (although see React.js for a really neat
> take on that.) By moving the UI to the client-side it can produce better,
> more responsive interfaces, and compiling to Javascript is a common
> strategy these days. (See Dart, CoffeeScript, Emscripten, ClojureScript,
> Elm, GWT,  etc). So it's not "obsolete" like Seaside. On the other hand, it
> doesn't feel "cutting edge" to me in the way that Seaside did when it was
> new and shiny. It's more about making web development comfortable for
> Smalltalkers.
>
>
Yes, it's clear enough now, I agree with this vision.

Anyway, moving all these stuff to the client is the new way to make the
things, I know, but we still need to solve other important things, as
persistence for example, and develop a complete system, involving different
products (as SmalltalkHub for example that use Pharo, Mongo in the backend)
sound a bit complicated to my work preferences.

Cheers.
Germán.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140121/165bc3f2/attachment.htm