nextime wrote: > On Fri, Jun 04, 2010 at 06:27:26AM +0200, [email protected] wrote: >> 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. > > Another cons in this approach is that the communication between > the server and the ui when the logic is managed by the server > has to be very intensive, and, possibily, this introduce > more bandwidth used and also bad resposivity of the ui.
"has to be very intensive"? /Has to be?/ Is this anything like the flj's repeated incantation of "huge client state"? Prithee, precisely how huge is the hugeness of /my/ application's client state? And how intense is its client-server interaction? You don't know? Precisely. This is a qooxdoo list, not a Theory of Web 2.0 list, so I will end by pointing out you both fail to consider that applications vary. And neither of you seem to understand that we are free with qooxlisp and I presume other such frameworks to move logic to the client (by coding JS) whenever that would help. btw, that there are other such frameworks suggests your insistence that this approach is prima facie wrong is, um, de facto wrong. Love that Latin. The meta-answer is precisely not to have rules such as "X will never work" and "Y is the only way". We are never writing all applications, we are only ever writing /this/ application. It might call for X, Y, or a mix of X and Y. Sarte said we are not free to be not free, Kenny says we are not free not to engineer our applications in all their specificity. btw, JS is neat but not a heavy-duty language so your side needs to stop pretending that programming applications in JS is as easy as merely deciding to do so. Clearly your model of an application is one in which the logic is trivial and the data interesting. That's not always how it goes. kt ------------------------------------------------------------------------------ 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
