On 23 sep, 16:54, lusus <[email protected]> wrote: > > 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.
In this case, just do the rendering in a <canvas>, as Bespin does (https://bespin.mozilla.org ) but then comes another problem: accessibility, because <canvas> is all and only about drawing. Let me summarize: what you want is... Java applets, Silverlight, Flash/ Flex, with a way to do "server push". Well, you already have all this: Silverlight can use sockets [1], as well as Flash/Flex [2] (I don't know for Java/JavaFX, but as far as I'm concerned java on the web is dead for a long time (except on the server side)). If you want some form of "standard protocol" to transport typed values, instead of plain old binary sockets, you can implement WebSockets (or any other protocol) on top of them. [1] http://weblogs.asp.net/mschwarz/archive/2008/03/07/silverlight-2-and-sockets.aspx [2] http://livedocs.adobe.com/flex/3/langref/flash/net/Socket.html > I think I can safely say that push is NOT evil. Not in itself. I must admit I agree (Yanick: how do you think GMail, (Wave), Facebook and the like do? oh, sure, that's not really "push", but is it really that different?) > 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). I don't get your point... why would the "app browser" have to open ports? what's the problem with opening a connection to the server and listening on it? that's what all jabber and IRC clients do, and it scales pretty well it seems... (if scaling was your concern) > 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. HTML5 (well, actually, many things have moved to their own specs now, but they're still globally referenced as HTML5, so...) adds a bunch of new things to browsers that allow you provide 2-grade access to your webapps; and all the users have to do is update their browser (that they believe is secure enough for them), not install something new (that they'd have to trust, i.e. you'd have to prove them that it's secure). Also, having everything in the same application (the browser) makes the user experience much better than having to switch between two (or more?) apps: one for the "old" web and one for the "new internet". > 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. Oh, I forgot to say: there's XUL and XPCOM too, and the runtime is available for (almost) all platforms. Is it what you're looking for? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
