@Kenneth Tilton: Don't get me wrong, I didn't mean to be offensive in any way. Only, as far as my experience goes, there is a generic problem with applications or frameworks trying to move much or all of the logic to the server. It's not qooxdlisp I'm not convinced about, it's all frameworks which execute application logic exclusively or mainly server-side.
I can see a benefit of having the possibility to create web applications from your (and your team's) language of choice. But this doesn't eliminate the problems of having all logic executed server-side and having huge state information stored on the server. In general, the more complex the user interface, the more logic has to be built into it, and the more state information has to be maintained. If you execute all of this logic server-side, no matter what language you use, you will have a chatty web application which has to manage huge sessions. Which is heavy on the server even when used concurrently by a smaller number of users. It's not a matter of qooxdlisp. There are tons of Java frameworks which execute logic and keep state server-side, and just drive the UI. And they are widely used. I just can't see the advantages of such an approach, as long as there is a reasonable alternative. About data mining and algebra: of all the web applications you know of (and I'm not talking social networks), how many are similar to these two? Other than that, I don't really know enough about these two apps to judge whether there could have more logic been moved to the browser. We have just started a much less complex but quite large application than the two you mention, which I think is quite typical for web development: an application where tens of thousands or hundreds of thousands of users have to be trained online. They get courses, exams and the like online. The editors and the tutors do their activity also online. Users communicate with trainers online, via the application. The application is meant for intranets of large companies, whow have to be able to prove in court, if necessary, that they have provided adequate training to their employees. I wouldn't say this app has a trivial user interface, neither that its logic is trivial. Just a few years ago, such an application was the typical rich client application. A few less years ago, you would have done it using a framework which _does_ execute all logic on the server and which _does_ store huge server-side state. However, I can't see a single reason today to place much of the logic on the server. Essentially, the server is only responsible for adapting the relational database to the object-oriented user interface and enforcing access restrictions. And doesn't keep anything in the session info besides the user identity associated with the session. Of course, there will be some maintenance jobs running on the server in the end, written entirely for the server, but there's no way we will have logic on the server deciding what control to enable and or what value to put in what field. We will abstract such operations in higher-level operations, and call the server to obtain data the javascript application needs. Time and again we have found this to be faster and providing better scalablility. If we had to maintain the user interface state on the server, while twenty thousand users would access the application, we'd need to run the application off a server having maybe 10 TB memory, serving up several thousands of requests each second, most of which would need to access a database - or else memory consumption would go up, due to caching requirements. Having all the logic related to the user interface on the client, memory requirements are of only a few GB, and a lot less than a thousand requests a second - although more complex ones - only the ones related to access to the database or to the file system. Even if the qooxdoo application will need to keep several megabytes of state and code in the browser, this doesn't seem to be a problem. Most workstations nowadays have huge unused quantities of memory and processor cycles. Before that, we have worked on a somewhat similar application, although the backend was ASP.Net. We used exactly the same architectural ideas, and the outcome was quite nice. We did test frameworks doing the logic almost entirely server-side some time ago. Our conclusion was that there's no way you can build an UI as smart and responsive using server-side logic as you can when you move much of the logic to the browser. Besides, working with such frameworks is a lot less pleasant than using qooxdoo for the most of the application, not just for the user interface. One more final note: you keep nagging that clear separation of layers in an application is not always possible. It is indeed a bad idea for some applications. However, many programmers who have worked on many different projects have found that this separation is useful in many cases. Either you are constantly doing very special applications, in which case you are a lucky person, but which's experience isn't really relevant to the most of us, programmers who toil away at database interfaces, workflow applications, or other more or less typical business applications, or there must be something wrong in how you use (or think you should use) a layered architecture for your applications. best regards, flj ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
