What is it preventing you from doing in its current state (the language, not DHTML standardization issues)? I understand that it could benefit from a better architecture and achieve higher performance, but remember, we're talking about client apps.
Alexey ________________________________ From: Carl Jokl <[email protected]> To: The Java Posse <[email protected]> Sent: Fri, November 5, 2010 11:14:13 AM Subject: [The Java Posse] Re: Evolution from web to desktop? With all due respect JavaScript is Source Code and not byte code. Describing JavaScript as bytecode is nonsense. 1) It is not a binary format. 2) It is not close to machine code. Yes the different browsers are putting in features like JIT for JavaScript, the problem is that each JavaScript engine is doing things in its own way. JavaScript was intended as s glue language just like Visual Basic. Both have ended up being used to try and solve problems for which they were not well suited. I for one and I think other developers also would be happier if they could target the browser scripting engine using a more powerful language than JavaScript. At the moment there is no way to write to the scripting engine directly bypassing the JavaScript language. That is where a 'real' bytecode system would come in. On Nov 5, 2:59 pm, Alexey Zinger <[email protected]> wrote: > JavaScript already is running in a JIT-enabled VM with the same bells and > whistles managed code developers are used to. What it doesn't have is type > safety, so you can effectively think of JavaScript as your medium of > distribution -- bytecode. It just happens to be human readable, so a lot of > people write it by hand. But you can just as easily have a tool that >"compiles" > your strongly typed language into JavaScript, package it for distribution with > some limited compile-time optimizations and rely on the client-side VM to do >the > rest. This is exactly what GWT does. > > Alexey > > ________________________________ > From: Carl Jokl <[email protected]> > To: The Java Posse <[email protected]> > Sent: Fri, November 5, 2010 6:16:13 AM > Subject: [The Java Posse] Re: Evolution from web to desktop? > > I hope it may be a good sign that others are thinking on the same > lines as I have been thinking too for some time. Albeit I am not sure > if it will happen. > > Considering Flash, Java and .Net amongst others all have some kind of > Virtual Machine. It would be good it the "JavaScript" engine were a > virtual machine too supporting some kind of bytecode. This means that > it could be targeted by any compiler which could compile to that > bytecode. > > In terms of supporting all the languages. Support for the languages > may not be so much of the issue. It is really a matter of the API's. > Saying that something cannot be called Java because it doesn't support > the whole JavaSE API set may not be a fair statement. We already have > had JavaME which is branded as "Java" but only supports a much more > limited set of APIs which are suited to that platform. > > In that case would it not be reasonable then to have a JavaWE (Web > Edition) or JavaBE (Browser Edition), such that the APIs are limited > to just those which are supported currently by JavaScript. > > Needless to say JavaScript doesn't support anything like the rich > functionality that Java or .Net do but surely you have to start > somewhere. If broad support for the browser VM came into place then > expanding the functionality could be done bit by bit via the W3C. In > the case of things like Flash, JavaFX and Silverlight it may be that > the functionality needed for those could be provided by loading > additional libraries beyond the core "Browser JM Libraries" to provide > that functionality. > > The aspect that could make it interesting is the prospect of > seamlessly pass objects from server to client back to server the way > thick clients have been able to such as with RMI, RPC, CORBA etc. > > -- > You received this message because you are subscribed to the Google Groups "The > Java Posse" 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 >athttp://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en.
