Hi lusus, I'm not a a guru in all web technologies, but I think knowing enough to comment on this.
On Sep 23, 12:24 am, lusus <[email protected]> wrote: > First I would like to point out a few important facts: > 1) I think that GWT is a fantastic idea, and that the developers > deserve awards and ice cream and funny hats and should be carried > through the streets. > 2) I am just throwing this out as a discussion point. > 3) I am not a classically trained programmer, and some of my > terminology may be technically errant. Try to go with the overarching > idea, and not just write me off because I thought REST meant nap > time. > > Now with that said, here's my question/thought. > > Isn't it time that we finally quit trying to warp the WWW into what we > really want it to be, and come up with a new protocol all together? > More specifically, isn't it time we made a "browser" that simply > interprets the major programming languages - not riding on the WWW, > but with it's own network protocols? > What do you mean by "major programming languages"? Javascript is a major programming language. (more on this below) I understand, however, that HTTP was originally created to display content (documents) in standardized way, as BBS were insufficient, and there was a need to, well, "please" the user and make it more attractive and user friendly. Hypertext markup language (HTML) was born to satisfy the problem, and it is still a proof of concept design even today with web applications. XSLT tried to change that and allow custom markups, and all, but my opinion is, why changing something that works and is general enough to support nearly any kind of data representation? On the same thought, I believe that the language is not faulty, but the renderers that interprets it... > It could exist like a stub on an individual client computer, run over > it's own public port, and allow push AND pull communication. > Programmers would need only to learn the proper communication methods, > and could then write unbridled applications that are served directly > to the clients, bypassing the rube-goldberg system of manipulation > required to make it understandable by the CURRENT browsers. > > What if you could write a JAVA program where main() was served to the > client "browser" and that's that. As cool as GWT is, when you step > back and think about the actual structure, it's conjures (at least for > me) images of popsicle sticks and duct tape. First you write the JAVA > code, and add CSS styles. Those are combined and interpreted to > Javascript which is optimized to several (currently used) browsers, > which is in turn interpreted to HTML and displayed in the browser, > which is based on a protocol that does not REALLY allow push > communication. *** Again, nothing against the GWT developers. They did > a fine job of contorting the existing structures to bring us closer to > the goal. *** > Push communication is evil as it allows servers to send data to the client, and I certainly don't want to end up on a web page having data uploaded to me without my consent, or knowing about it. "What about push techniques?" you might say, well, at least we see a "Loading..." message while the page "push" is being made. Furthermore, the amount of work to simply allow this, supposing it's really implemented, and to keep track of all users connected to the web page is too great for the trouble. I mean, we're not talking about enterprise applications only here, but world wide web applications. How could a busy web server keep track of all the thousands users, if not millions, connected to it's content and knowing when it's no longer necessary to send data? The overall process would simply slow the server down. Except keeping track of session data between calls and have a garbage collection system to cleanup all this on inactive data is quit enough trouble already. On the other hand, you can actually use third party software (ie. Java) to do this; Applets may keep a socket open in TCP to the origin and receive push from it, if you really need to. GWT actually solves a big issue for many big project; a standardized way to communicate to the server(s) throughout the whole application. And even re-use the system in all projects. I personally consider text/ XML/JSON responses as "legacy", and RPC as the new way of communicating with the server side part of the application. There are still improvements to be made, about protocol and especially on the software layer design patterns, but the general idea is there, and it works. There are actually existing projects being developped to allow GWT and PHP to communicate through RPC, and the idea is sound and looks promissing. This means that it won't matter what language your servers can support; your GWT application will be able to communicate using RPCs with PHP, Java, etc. in a seamless fashion. > I realize that, as far as cloud computing is concerned, the GWT > outcome is (almost) the same as what I'm talking about. You write JAVA > code, and it gets displayed in the browsers. Who cares what torture it > has to go through to get there. right? > > Looking back, it was oh so simple to get virtually everyone using the > WWW. Would it be that hard to get the general public to accept a new > internet that involves application browsers? > > And finally, the "browsers" could be made to understand multiple > programming languages. It could basically be an omni- (and slightly > upgraded for communication purposes) Virtual Machine. Many optimizations have been made on the engines that runs Javascripts. The language itself has evolved and tends to have a more rebust structure (http://en.wikipedia.org/wiki/JavaScript. see versions table). The problem is that there is not a general consensus on this and browsers may implement the specification they want. It will take time, a very long time, but I believe that eventually we'll get to a point where Javascript will be as fast as Java. (Same with CSS.) I personally do not like the idea of a browser natively supporting many languages, as it is hard enough for all browsers to all support one single up-to-date language. Javascript is a great language for client side programming. There is this idea laying around for many years now, that a server and client might execute and communicate both sides with Javascript only, but not very praised by all. The point is that the more language a browser will support, the slower it will run and more incompatibilities it will have. And I agree with that. Right now, the technologies are general enough to carry nearly any kind of tasks. The problem is not the technologies themselves, but the browsers that runs them. If it's so hard to simply support the latest HTML/Javascript/CSS specifications in all browsers, how would it be with other languages and specifications? GWT actually answers that problem--at a best effort basis--, and very nicely, by abstracting all these differences and compensating for incompatibilities. And all it's left to do is to write in a more strict, but yet powerful language that is Java. The code produced is not only compatible in all major browsers, but also minified, obfuscated, and optimized. If, ever, Javascript, or HTTP, etc. are replaced by some other things, you can be assured that the GWT compiler will be adjusted by someone. In conclusion, web security has been the concern of millions of individuals since the www was popularized in the '90's and I believe that it is close to be as perfect as it can be. So why change it now? The current technologies not only support nearly any kind of data manipulation and representation but nearly if not all kind of platforms. All is left to do is to choose the technology that best fit the problematic and build on top of HTTP and all. There has been a long way made since the past 20 years in web technologies and I believe GWT does not try to replace it, but simply to unify the client part of it, as you may have a GWT client communicate with whatever backend you have. As for the communication part, like it has been said in this thread already, it cannot get as secure as it is right now (not significantly anyway). But this simply what I see of it. Anyone is entitle to disagree and prove me wrong :) > > Here is my list of key points: > 1) Cut out the middle man. No more Rube-Goldberg. > 2) Allow Push communication. > 3) No worries about upgraded or new browsers, and cross-browser > compatibility. (The App-Browsers would just keep up with the current > programming language upgrades.) > 4) Use the layout tools that belong the the program language you are > using. > 5) Wouldn't it possibly even be more secure? (maybe not) > 6) Let the kids play in the WWW kiddy pool. Let the real programmers > swim in the deep end, away from the yellow water. > > That's all. I don't work for the W3C, and I've never once even spoken > to Al Gore. I have no idea how to make something like this happen. I'm > just interested in thoughts on the matter. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
