Microsoft GWT clone

[Juan]

Hi,

One of the good things about Microsoft Volta is that it uses the
bytecode, not the source code. This allows them to use any language. I
wonder why the GWT didn't follow this approach. Can you imagine
programming the front end using JRuby ? Sweeeeeet :)

Best regards,
Juan

[Issac Trotts]

I don't see how using byte code would be any better than using source
code, since the source code has just as much information. Maybe
compiles could be made a little bit faster, but that's not a serious
issue since reloads are so fast in hosted mode.

GWT probably couldn't generate fast JavaScript if it used Ruby instead
of Java, because it wouldn't have the type information it needs for
optimization.

Issac

--
http://svwebbuilder.com

[masterGaurav]

I don't think bytecode can be used at all... JSNI will fail to work.
JSNI code -- for Java compiler is pure comment, and would be lost in
bytecode.


--
Cheers,
Gaurav Vaish
http://dwt.sf.net
http://www.mastergaurav.com
---------------------------------

On Aug 24, 10:01 am, "Issac Trotts" <issac.tro...@gmail.com> wrote:
> I don't see how using byte code would be any better than using source
> code, since the source code has just as much information.  Maybe
> compiles could be made a little bit faster, but that's not a serious
> issue since reloads are so fast in hosted mode.
>
> GWT probably couldn't generate fast JavaScript if it used Ruby instead
> of Java, because it wouldn't have the type information it needs for
> optimization.
>
> Issac
>

[Juan]

> I don't see how using byte code would be any better than using source
> code, since the source code has just as much information.

It's not about having more information, it's about the possibility of
using other JVM supported languages. Language lock-in seems like a
severe limitation for a platform like the JVM -that it's clearly
evolving into a multi-language platform-

> GWT probably couldn't generate fast JavaScript if it used Ruby instead
> of Java, because it wouldn't have the type information it needs for
> optimization.

I assume this is only your guess. Anyway MS seems to be following this
way so soon we will see how fast it's (anyway I don't see why it
should be slower than Ruby -as they are both dynamically typed
languages-)

Anyway I was just wondering if anyone did know some solid reason as
why they didn't use bytecode interpretation.

Juan

[Ian Bambury]

As I see it:

 

Bytecode is intended for a JVM. As such you would either have to emulate a JVM in JavaScript or at least partially reverse engineer the bytecode to a point where you could optimise it. The compiler out put would be pretty much unreadable (no -pretty available) so developing the compiler would be n times more difficult. Never mind less optimised and more stages to the compile.

 

There would also be no way to stop people trying to compile any old byte code they produced whereas now if it ain't emulated, you can't use it.

 

I'm sure there are people who would prefer to write in Fortran or Visual Turing, but Google will have a budget for GWT and can get more features in GWT faster this way.

 

You're hungry, someone offers you a free lunch, and you start moaning that you can't pick the restaurant. :-)

 

Ian

2008/8/24 Juan <juan...@gmail.com>

Stuff the environment - Print this email
_______________________________________

[Tim]

last I heard MS' Volta was buggy and slow and unacceptable for any
serious development. Have things changed?

from MS' own description, Volta hasn't undergone yet any performance
optimizations yet http://livelabs.com/volta/docs/issues/. I wonder how
many underwater road blocks they'll face with that, since MSIL was
designed before the MSIL to javascript compilation process was
conceived.

On Aug 24, 7:59 am, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> As I see it:
>
> Bytecode is intended for a JVM. As such you would either have to emulate a
> JVM in JavaScript or at least partially reverse engineer the bytecode to a
> point where you could optimise it. The compiler out put would be pretty much
> unreadable (no -pretty available) so developing the compiler would be n
> times more difficult. Never mind less optimised and more stages to the
> compile.
>
> There would also be no way to stop people trying to compile any old byte
> code they produced whereas now if it ain't emulated, you can't use it.
>
> I'm sure there are people who would prefer to write in Fortran or Visual
> Turing, but Google will have a budget for GWT and can get more features in
> GWT faster this way.
>
> You're hungry, someone offers you a free lunch, and you start moaning that
> you can't pick the restaurant. :-)
>
> Ian
>

> 2008/8/24 Juan <juanme...@gmail.com>

>
>
>
>
>
> > > I don't see how using byte code would be any better than using source
> > > code, since the source code has just as much information.
>
> > It's not about having more information, it's about the possibility of
> > using other JVM supported languages. Language lock-in seems like a
> > severe limitation for a platform like the JVM -that it's clearly
> > evolving into a multi-language platform-
>
> > > GWT probably couldn't generate fast JavaScript if it used Ruby instead
> > > of Java, because it wouldn't have the type information it needs for
> > > optimization.
>
> > I assume this is only your guess. Anyway MS seems to be following this
> > way so soon we will see how fast it's (anyway I don't see why it
> > should be slower than Ruby -as they are both dynamically typed
> > languages-)
>
> > Anyway I was just wondering if anyone did know some solid reason as
> > why they didn't use bytecode interpretation.
>
> > Juan
>

> --
> Ianhttp://examples.roughian.com
> _______________________________________

[Fred Sauer]

You can read up on a few past discussions on bytecode vs. source, and even find Volta references on the contributor's list
  http://groups.google.com/group/Google-Web-Toolkit-Contributors

Fred Sauer
fr...@allen-sauer.com

[Maxim]

On Aug 24, 4:59 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> As I see it:
>
> Bytecode is intended for a JVM. As such you would either have to emulate a
> JVM in JavaScript or at least partially reverse engineer the bytecode to a
> point where you could optimise it.

I do not think that recompiling is a big problem - thare are tools
which recompile Java byte code into Javba source, and results are
quite similar to original.

Regards,
Maxim

[Juan]

Thanks for the link. Sounds like that's just what I was looking
for.

On Aug 24, 5:29 pm, "Fred Sauer" <f...@allen-sauer.com> wrote:
> You can read up on a few past discussions on bytecode vs. source, and even
> find Volta references on the contributor's list
>  http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> Fred Sauer

> f...@allen-sauer.com

>
> On Sun, Aug 24, 2008 at 8:55 AM, Tim <ttara...@gmail.com> wrote:
>
> > last I heard MS' Volta was buggy and slow and unacceptable for any
> > serious development. Have things changed?
>
> > from MS' own description, Volta hasn't undergone yet any performance

> > optimizations yethttp://livelabs.com/volta/docs/issues/. I wonder how

[Arthur Kalmenson]

There is a very good reason why GWT couldn't produce the tight JS it
does if it was using a dynamic language like Ruby. If you watch Bruce
Johnson's (co-creator of GWT) Google I/O presentation, Faster-than-
Possible Code: Deferred Binding with GWT (http://sites.google.com/site/
io/faster-than-possible-code-deferred-binding-with-gwt), you'll see
why the GWT compiler can only be as optimized as it is when it
compiles statically typed languages. A lot of the GWT optimizations
rely on types being known at compile time and the removal of
Reflections, these two properties are fundamental in most dynamic
languages and would thus make it impossible to optimize code the
resulting JS the way the GWT compiler does.

Regards,
Arthur Kalmenson

[Maxim]

On Aug 25, 7:46 am, Arthur Kalmenson <arthur.k...@gmail.com> wrote:
> compiles statically typed languages. A lot of the GWT optimizations
> rely on types being known at compile time and the removal of
> Reflections, these two properties are fundamental in most dynamic
> languages and would thus make it impossible to optimize code the
> resulting JS the way the GWT compiler does.

As I understand from:

http://livelabs.com/volta/docs/issues/
"At run time a Volta application downloads many files from the server,
one for each class that is used. The classes are loaded lazily, i.e.
not downloaded until they are needed..."

they do not need "by size" optimization - they load only those classes
which are really used.

From other side, loading class-by-class can seriously affect
perfomance ...

[Magno Machado]

Depending on the level of the performance penalty, loading class on demand is much better than downloading all the application on start up, as GWT does.
----
Another advantage of generate JS from compiled code is that one can write a lib and don't have to make the sources available for users.

[Dean S. Jones]

how so???

I have a LARGE application, 2Meg of JS, but compresses to just over 8K
on the wire... downloads in 580~ms. Many smaller requests are going to
suffer from TCP connection set-up time. ( as compared to ONE file )

[Dean S. Jones]

Sorry, that was 800K

[Jason Morris]

Quite frankly, my point of view on this subject is: reverse engineering Java
byte-code is a black-art.

Different Java compilers produce different byte-code structures, often confusing
these tools. The tools themselves are constantly trying to patch strange little
behaviours as the compilers change and the byte-code changes. Decompilers are
nasty beasts on the inside, and often break while trying to decompile certain
structures.

One of the advantages of using byte-code for GWT would be multi-language
support? I think not! It would be hard enough just trying to maintain a Sun
JavaC decompiler, let alone trying to get other language compilers (and their
supporting API's) running in JavaScript.

Go take a look at the JRE emulation code in GWT for String. Then think about how
well this would fly. A bit like a herd of drunk elephants.

Magno Machado wrote:
> Depending on the level of the performance penalty, loading class on
> demand is much better than downloading all the application on start up,
> as GWT does.
> ----
> Another advantage of generate JS from compiled code is that one can
> write a lib and don't have to make the sources available for users.
>

> 2008/8/25 Maxim <maxim.ge <http://maxim.ge>@gmail.com <http://gmail.com>>

>
>
> On Aug 25, 7:46 am, Arthur Kalmenson <arthur.k...@gmail.com

[Magno Machado]

Just to clarify, I am NOT defending JS from bytecode. I just think both strategies have pros and cons.
Let's give MS some time to mature it's product and see what's the best approach.

2008/8/25 Jason Morris <lem...@gmail.com>

[Tim]

GWT also seems to be heading into the direction of lazy loading - take
a look at the runAsync branch in GWT svn - it's pretty sweet. I really
don't think that MS's approach of one js file per class is wise.
Afterall current browsers have a limit of 2 connections per domain,
which really limits the number of concurrent connections and
ultimately the speed of downloads. I like more GWT's upcoming approach
to lazy loading - let the developer control what gets loaded lazily vs
eagerly.

Tim
http://gwtnow.com

[Yegor]

I don't know what Volta looks like today, but last December it was
simply horrible. Check out this post:

http://pavelgj.blogspot.com/2007/12/ms-volta-is-doomed-i-tell-you-doooooo-o.html

I have big doubts about Volta. They will probably end up doing the
same thing as GWT, that is implement a C# to JS compiler. Overall, I
fail to see a reason why microsoft could be interested in creating a
good cross-platform web-technology unless they are sure they can
control it (that includes the developers and the users). They are
dragging their feet with IE, letting FF and WebKit kick their butt,
just to make web-apps looks slower and uglier than their desktop apps.
Also Volta directly competes with Silverlight. Guess which one will
eventually get more attention? And I am sure their engineers will have
nothing to do with this.

No, no, no, you will have to convince me how Volta can have a bright
future before I even start considering it, nevermind their multi-
lingual support. Today there are two kinds of languages that prove to
be best suitable to write applications: statically typed VM languages
(Java, C#, etc), dynamic VM languages (JavaScript, Python, Ruby, etc).
Use JavaScript if you like dynamic, use Java/GWT if you like static.

Yegor

[Reinier Zwitserloot]

Wow. I need to clear up some misconceptions.

Volta utterly sucks. It's a project I could have written in a weekend
by myself, and it completely ignores the realities of javascript. It
fundamentally will never work right unless someone actually spends
serious time and effort making it better. Let me repeat that: It's -
unusable-.

You can't use JRuby to write GWT because GWT uses a unique 'closed-
world, statically analysed code coverage' concept to take a batch of
java code and turn *ONLY* those parts that will actually be called
into javascript. To the commenter that thought volta had no size issue
because it lazy loads: Well, one, Hello World downloads over a meg of
cruft in volta, in a gazillion files, and two, GWT also only loads the
used bits, just does it one go.

To accomplish this, GWT will begin at the entry point(s) and apply a
process somewhat similar to garbage collection, except that it
analyses the source itself instead of the runtime state. Basically,
any code not somehow invoked by the entry point itself or by anything
the entry point invokes, is not included because its never used. And
in order to get this right, GWT *MUST* disallow e.g. usage of
reflection. After all, if you can do this:

Class c = Class.forName(classBox.getText());
Method m = c.getMethod(methodBox.getText());
m.invoke(c.newInstance());

legally, in GWT, then - that one block of code would cause the GWT
compiler to include -every- single last method that is inside the
project set. There's no way to know what that will end up calling at
runtime, hence the need to do that. In one fell swoop GWT has to
include every emulated class, every widget, every library you linked
in (e.g. all of ext-gwt even if you're only using a fraction of it),
and you'll end up with a 5 MB disaster.

JRuby uses reflection extensively to make it work. After all, this is
legal (Python source, but JRuby, javascript, and Python have the exact
same typing system, so in that sense they are equal in the eyes of
potential GWT languages):

someObject[methodBox.getText()]();


And, as you can see, same issue. In order for GWT to allow Python,
Ruby, and JS as source languages, it would need to add lots of
limitations, such as never doing a named lookup on object members.
However, because those languages aren't statically typed, even that
won't help much. Besides, the whole point of those languages is that
you CAN do that stuff - they were designed with that in mind. If you
start taking the language apart and only allowing half the feature
set, you'll soon find you can't reasonably program anything in it
without tearing your hair out by the roots. It would be a stupid
exercise in futility.


Now, there are some languages where you may fare better. Scala, for
example. Or, here's a fun twist: .NET could be compiled quite easily
to javascript using the GWT engine, where 'quite easily' is a relative
term (it would still take a month or two of good hacking to get there,
but at least you know where to start and where to go).