<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 20, 2014 at 6:55 PM, Germán Arduino <span dir="ltr"><<a href="mailto:garduino@gmail.com" target="_blank">garduino@gmail.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><div>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.</div>
</div></div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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."</div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Colin</div><div><br></div></div></div></div>