> 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... > The semantics about which programs are Major is for a different discussion. That was me be purposely general. And yes, the renderers are most of the problem. What I am proposing is (partially) a new rendering model. JAVA (and other languages) have the ability to render graphics themselves. Why do we need to then convert that code to javascript, and then to html to then be interpreted by any number of different browsers. It's a long walk to get a short distance. >
> > 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. > I think I can safely say that push is NOT evil. Not in itself. Perhaps there are evil things that can be done with it, but push is actually very useful for number of purposes. It is absolutely possible/ plausible. We are talking about rich applications not just banner ads. And yes, sockets can be used, but that brings up my point about ports. (see my other responses). > 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. > Again, and I can't say it enough, I think that GWT is great, and a huge step in the right direction. I think that GWT points directly to what we have been slowly moving toward since the beginning of the WWW - the idea of serving real and robust applications. I think that, instead of continuing to contort the web, and stack new technologies on top of it, perhaps we should look at the idea of a new internet that takes into account the technologies and discovered needs that didn't exist when the web was originally created. > 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 :) > Well, thanks for your input. The new "browser" I speak of would only need to understand the language at hand (*** important: Only languages that have built graphics capabilities and do not rely on manipulating css and html ***). Then allow the language to control the display of the application (as well as all the other functioning). That's a great leap from how current browser interpret (in their own specific and cute way) javascript, css, html, etc. There would be no ( hehe o.k. - or at least far less) incompatibility. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
