Nice write-up, flj. Kyle Simpson started a promising series of articles about UI architecture in JSMag, entitled 'The Rise of the "Middle-End"', where he advocates deployment of JS on the server for some of Kenny's arguments.
T. On 05/28/2010 05:53 AM, [email protected] wrote: > Hi. > >> So qooxdoo truly is just the view layer, including handling GUI events >> of course, but not the application layer, including not even the >> widget linkage. Here's an example from the demo app: I wanted to >> disable the Search button if the text input for the search string was >> blank. So I had various editing events piped back to the server, which >> returned JS code to enable/disable the search button as needed. That >> may seem like a long way to go to do what could easily be done on the >> client, but as long as performance keeps up I like just sitting in my >> application (in whatever language it might be) and forgetting the >> client is on the other side of http. If performance is a problem, I >> will look at using the qooxdoo databinding mechanism to achieve the >> same end, but strive to do so by programming qooxdoo from the >> server/Lisp application. ie, I will try not to have to subclass or end >> up with application-specific code in the static JS. >> >> I have done this sort of thing with Tcl/Tk, by the way, which someone >> ported to GTk. It has gone well in the past, tho now I am going across >> HTTP instead of a C interface so I'll have my eye open for performance >> issues, but I suspect they will all roll over for me with sufficient >> clever hacking. The big win is just sitting in a big language with >> ready access to server data and almost forgetting HTTP and even >> qooxdoo exists. >> >> About that last: no, we are still programming qooxdoo, and qooxdoo >> documentation will be qooxlisp documentation, but the design goal is >> to minimize what the application developer must specify by having >> qooxlisp intelligently fill in the needed boilerplate to make things >> work. > > Idunno. I like Javascript. It may not be the richest language in the world, > but it is built in such a way that you can easily do anything to it in > javascript code, except enriching its syntax. Besides, you only have to drive > the UI from it. > > I suppose qooxlisp has to replicate the entire UI state on the server to be > able to properly react to events in the UI. Right? Alternatively you can go > the ASP.Net way and pass the state along with each request and response. But > somehow state has to be available on the server in order the server to be > able to react properly to UI requests/events. > > Therefore, I can't really see the benefit of it. Indeed, you do keep > application-specific logic, including UI-related logic, in your preferred > language, but IMO there are two significant disadvantages to it, both related > to the fat state information corresponding to rich UIs. First, in the case > of large number of users, resource consumption grows much faster than in case > of an architecture which requires no state or only slim session state on the > server, which also doesn't change very often. Second, in case of fat and > dynamic session state which is maintained on the server, clustering becomes > complicated (due to complicated replication of the state info across cluster > members). Alternatively, if instead of maintaining the fat state on the > server it is sent along with each request and response (the ASP.Net way), > computational effort to serialize/deserialize it becomes significant, > especially for a chatty web app, where ever ything is handled on the server. > > All of these are most likely no issues in case of small numbers of users on > an intranet. But each of them easily becomes a bad pain if your application > is used concurrently by just a few tens of thousands of users, and it's even > worse if your app is accessed over the internet, in which case you have no > control over delays, lags, routing speed etc. > > A different approach, which IMO allows for faster, less resource hungry > applications, is to have the entire UI logic in Javascript code, and define a > set of JSON-based requests and responses upon which the UI application has to > rely. There are several advantages to such an architecture. > > First, you only have to keep very slim session info on the server. Small > session info which almost never changes during a session (a user name, an > authentication token, only things like this) allows for much higher > scalability. > > Second, a natural separation of concerns arises between layers. It's very > well defined what the server has to do, in fact, each request/response can be > handled in isolation. Similarly, the various UI parts can each be handled in > isolation, as they each rely on specific data being retrieved/sent, less on > data provided by other UI components. This allows for many programmers > working in parallel on the various parts, without needing too much > synchronization among them. > > Third, the well-defined set of JSON requests/responses constitute a natural > interface for third-party apps which need to interact with your app - one > which doesn't expose app internals, and thus protects your app from having > its data damaged by external code - such as would be the risk when doing > integration at the database level. > > Fourth, the nice isolation between layers and between components inside a > layer allows for improved testability. You can unit test each component in > context, without wrapping it in tons of mocks. > > Essentially, my point is that now th at we have qooxdoo, to use it with state > and UI logic managed server-side would be to some extent a pervertion of its > purpose. For years before qooxdoo apps were written this way, and web app > development was a pain in the ass. I for one don't want to go back to that > type of apps, even if this would allow me to code everything in my language > of choice. > > br, > > flj > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
