Teavm

[Satguru Srivastava]

So, I recently came across TeaVM (http://teavm.org/)

Similar to GWT but unlike GWT, which compiles Java Source Code to JavaScript, TeaVM compiles Java Byte Code to JavaScript.

It is an interesting approach.

The big advantage to this approach is that you do not have to create and maintain your own compiler.

You ride on the back of the JavaC compiler and can take advantage of the optimizations, latest changes and updates made to the compiler.

So while GWT is working on supporting Java 8 , TeaVM already provides support for that.

What do you guys think?

What are the pros/cons of this approach ?

[Steve Hannah]

We are using TeaVM for the javascript port of Codename One and have been very happy with the results.  One thing that TeaVM offers that nobody else in the Java->Javascript realm is thread support.  Performance is also very good, and the creator (Alexey) is quite responsive to support requests.

Steve

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Web Lite Solutions Corp.

[Adam M]

TeavVM seams be very interesting project however for me it looks like it serves different needs that GWT. It has tons of very interesting stuff and using Java Byte Code for compilation to JavaScript makes it almost 100% language agnostic as source code input (in theory - you can compile it to byte code and run it on JVM - you can run it with TeaVM - of course with some reasonable restrictions because of JavaScript nature).

However for me there are two major show stoppers for broad adoption in production:

 - project is still in early growing phase 

 - virtually this is one pony show - except Alexey there are no major contributors (nothing against Alexey of course he is brilliant guy)

[Satguru Srivastava]

Not sure if TeaVM serves different need than GWT. Seems like both want to provide a better alternative to JavaScript.

Now TeaVM does not have anything equivalent to GWT widgets but then  it seems, after watching the GWT Create session videos, the recommendation, for newer apps, is not to use the GWT widgets anyway.

Instead of GWT widgets the direction seems to be to use more HTML5 based components like web components polymer etc which technology like the newer GWT JSInterop could make it easier to consume.

Like GWT JSInterop , TeaVM has something called JSO which also propose to make consuming java script libraries easier.

I haven't used JSInterop or JSO so can't compare the two.

Anyway, what is interesting is the Java Source Code to Javascript vs Java Byte Code to JavaScript issue.

Wonder if GWT creators ever debated this issue when they started work on GWT.

[Alexey Andreev]

 - virtually this is one pony show - except Alexey there are no major contributors (nothing against Alexey of course he is brilliant guy)

Yes, this is the worst problem of TeaVM. I wonder how do projects become popular? If a project is maintaned by a big and rich company, this company likely has enough resources and reputation to make project popular. What if a project is made by enthusiasts? I can see two general ways:

• the project becomes popular enough to draw money;
• some big and rich company is interested in the project and starts to support it.

As for the first one. TeaVM does not have a big community, since people don't trust a project maintained by one developer, so I get into vicious circle. As for the second one. I believe, most major companies have heard of TeaVM. So why don't they communicate me and try to support my project? Do they feel that a project like TeaVM has no future, that cominuty needs things like Dart and TypeScript?

[Alexey Andreev]

Not sure if TeaVM serves different need than GWT. Seems like both want to provide a better alternative to JavaScript.

Now TeaVM does not have anything equivalent to GWT widgets but then  it seems, after watching the GWT Create session videos, the recommendation, for newer apps, is not to use the GWT widgets anyway.

Instead of GWT widgets the direction seems to be to use more HTML5 based components like web components polymer etc which technology like the newer GWT JSInterop could make it easier to consume.

Like GWT JSInterop , TeaVM has something called JSO which also propose to make consuming java script libraries easier.

I haven't used JSInterop or JSO so can't compare the two.

Besides JSO wich provides interop with JS libraries, there is forthcoming project called TeaVM Flavour. It's a framework similar to Angular, but written entirely in Java. I have a lot of disappointing experience with GWT widgets (but still use it, as it's still 10 times better than maintaining megabytes of JS code), since it's virtually impossible to create good widget-based abstraction over HTML technoligies. A better approach is a thin layer of abstraction, wich allows easy interaction with underlying nature of HTML.

I could take experience of dukescript guys (BTW, TeaVM can be used as dukescript backend) and wrap existing libraries like Angular and Knockout. However, I don't think it is a good approach, since I ask myself: what makes me use Java on front-end? My answer is: it's static typing. When I refactor code, I get errors displayed immediately in Eclipse and have a chance to fix them before I even run application. Consider I wrap angular and pass Java method name to ng-click directive. If later I refactor my Java code and this method got renamed, I won't get any feedback from IDE. And so on. I took many cases and figured out that pure Java-based approach is far superior than JavaScript wrappers, except for complexity.

[Adam M]

Call me old school but for me direction in which GWT 3.0 is going is strange - if I'm forced to use HTML5/JavaScript libraries instead GWT widgets why I should do anything in Java in the first place - just grab Angular or Ember and be done - GWT doesn't help me too much with server side code anyway. The whole purpose of using GWT/GWTP was to avoid to deal with JavaScript, at least in my case.

For me TeaVM has completely different approach to the problem than GWT - it allows language agnostic web application development (I never liked GWT no prisoners taken approach - Java or nothing - but as you know there was nothing better in "dark ages" of web application development)  - even that end result is very similar - JavaScript code running in the browser.

I wonder if something similar like Java Byte Code to JavaScript could be done with Microsoft CLI to JavScript (just wild shot - I'm not too familiar with the whole .Net infrastructure - different programming environment)

[Subhrajyoti Moitra]

Hello Alexey,

Since the end result is JS, can i use cordova to cook up a mobile app using TeaVM?

Thanks,

Subhro.

--

[Adam M]

I feel your pain - too bad that everybody are so hell bend to develop "better mouse trap" in JavaScript so they are lost sight of different ways of doing things. I'm planning to start working on TeaVM in the next 6 months - maybe approach every little bit helps will move TeaVM from corner closer to center stage.

[Thomas Broyer]

On Wednesday, December 2, 2015 at 2:06:24 PM UTC+1, Adam M wrote:

Call me old school but for me direction in which GWT 3.0 is going is strange - if I'm forced to use HTML5/JavaScript libraries instead GWT widgets why I should do anything in Java in the first place - just grab Angular or Ember and be done - GWT doesn't help me too much with server side code anyway. The whole purpose of using GWT/GWTP was to avoid to deal with JavaScript, at least in my case.

You fooled yourself (but you're not alone). The whole purpose of GWT has always been about tooling: http://www.gwtproject.org/makinggwtbetter.html

Now that tooling is quite good in the JS world, GWT is turning to… tooling, still (because tooling for a statically-typed language is different from / can go farther than for a dynamically-typed one), and sharing code.

 

For me TeaVM has completely different approach to the problem than GWT - it allows language agnostic web application development (I never liked GWT no prisoners taken approach - Java or nothing - but as you know there was nothing better in "dark ages" of web application development)  - even that end result is very similar - JavaScript code running in the browser.

I wonder if something similar like Java Byte Code to JavaScript could be done with Microsoft CLI to JavScript (just wild shot - I'm not too familiar with the whole .Net infrastructure - different programming environment)

Not only can it be done, but has been done, many times, including by Microsoft themselves: https://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta http://jscriptsuite.com/ http://jsil.org/ http://jsc.sourceforge.net/ https://github.com/Reactive-Extensions/IL2JS https://github.com/mtenpow/xaeios

BTW, there are / has been also many source-to-source compilers using C# as input: http://bridge.net/ http://duoco.de/ http://sharpkit.net/ and the pioneer of them all and now apparently defunct: https://github.com/nikhilk/scriptsharp

[Alexey Andreev]

Since the end result is JS, can i use cordova to cook up a mobile app using TeaVM?

You can try to. I'm not sure I've cleaned up any browser-specific APIs from TeaVM runtime. Please, report me if you have some success with cordova. However, I don't think it's a good idea. There is Android which supports subset of Java natively, iOS with RoboVM. I'd look for Java frameworks that support both. There is CodenameOne with its own implementation of Java for different platforms and experimental JavaScript target that uses TeaVM. There is dukescript wich supports Android, RoboVM and TeaVM, though I don't really like the idea of wrapping Java around Knockout or similar framework. Choose which one fits you needs better.

[Martin Trummer]

there is an old group post that already discusses the byte-code vs. source code issue - maybe it is still helpful 

I think the http://www.gwtproject.org/makinggwtbetter.html page should be updated for GWT 3.0.

As I understood all the talks, info etc. about GWT 3.x (e.g. GWT-3.0-Sencha-GXT-and-the-future-of-the-widget-eco-system) we will lose some of the GWT 2.x benefits - please anybody correct my when I got things wrong

• "Key facilities out of the box: history, RPC, localization, and unit testing": History, RPC and localization will only be available as 3rd party add-ons
  
• "Discourage unoptimizable patterns": 
  
• the GWT compiler cannot optimize js-GUIs (Webcomponents, Polymer, ..) per browser: so we must always send all the css-prefix bloat and js for feature-detection, browser quirks etc. to the client (no matter which browser it is)
• code-splitting worked great for GWT-widgets - I don't see how this could work for js-widgets

I've always seen the biggest benefits of GWT like this:

• you can build fast, big, reliable, rock-solid web-apps
• you can get perfectly optimized js code - so that you can also build a great mobile-experience, where smallest code size (and minimal initial download size) is of most importance
  
• you can use the the same statically typed language (Java, or compile-to-Java languages, e.g. xtend) on the client/server (now even for Web/Android/iOS like Google Inbox)

[Thomas Broyer]

On Thursday, December 3, 2015 at 12:24:38 PM UTC+1, Martin Trummer wrote:

there is an old group post that already discusses the byte-code vs. source code issue - maybe it is still helpful 

I think the http://www.gwtproject.org/makinggwtbetter.html page should be updated for GWT 3.0.

As I understood all the talks, info etc. about GWT 3.x (e.g. GWT-3.0-Sencha-GXT-and-the-future-of-the-widget-eco-system) we will lose some of the GWT 2.x benefits - please anybody correct my when I got things wrong

• "Key facilities out of the box: history, RPC, localization, and unit testing": History, RPC and localization will only be available as 3rd party add-ons
  
• "Discourage unoptimizable patterns": 
  
• the GWT compiler cannot optimize js-GUIs (Webcomponents, Polymer, ..) per browser: so we must always send all the css-prefix bloat and js for feature-detection, browser quirks etc. to the client (no matter which browser it is)
• code-splitting worked great for GWT-widgets - I don't see how this could work for js-widgets

We don't know yet what GWT 3.0 will exactly look like, and remember that GWT 3.0 != J2CL.

It's (apparently) true that J2CL won't have "permutations" in the sense we know it with GWT, but will allow you to build for a specific browser (or whatever) by setting a "system property" to some value. One could thus create a class similar to Closure Library's goog.userAgent's namespace that by default detects the user agent at runtime but could force a specific user-agent at compile-time with a "system property"; you could then create permutations "manually" and select among them either on server-side (I believe this is what Google does most of the time) or client-side (equivalent of the selection script, i.e. *.nocache.js, generated by GWT). And similarly for I18N: https://books.google.fr/books?id=p7uyWPcVGZsC&pg=PA67#v=onepage&q&f=false

GWT 3.0 will likely use J2CL, but that doesn't mean it will stop doing permutations (particularly for I18N). That doesn't mean it will continue to support them either, we just don't know yet.

That said, browser-specific permutations has IMO reached a dead-end: Microsoft will stop support IE<11 in 40 days or so (except IE9 on Vista), which means that we'll have (hopefully) almost everyone using a "modern browser" where discrepancies aren't that many and can be dealt with at runtime without too much overhead.

[Martin Trummer]

That said, browser-specific permutations has IMO reached a dead-end: Microsoft will stop support IE<11 in 40 days or so (except IE9 on Vista), which means that we'll have (hopefully) almost everyone using a "modern browser" where discrepancies aren't that many and can be dealt with at runtime without too much overhead.

Why should browser specific permutations ever reach a dead-end? 

just take a look at any of the items at http://caniuse.com/? 

whenever a new feature is being introduced, we have the same problems.

i.e. WebComponents: in Chrome they work, for Firefox HTML import does not work, for Safari only the Templates work, ...

--> this looks like a perfect match for browser specific permutations, doesn't it?

[Alberto Mancini]

I do not know if permutations have reached a dead-end but i find that 

'static' (in the sense related to the browser user agent) detection is going to be hard to maintain.

Each new version of a browser (and the update is largely automatic) may change the support so 

compiling for a specific user agent does not give the ability to use new features as soon as they are available

(this post more or less explains the two approaches ,'user agent' vs 'feature' detection, http://www.html5rocks.com/en/tutorials/detection/).

One approach may be to have an improved concept of permutation based on features and not on the matching of 

the user agent(*) but this would probably result in an huge number of permutations and i do now know if the gain in term of download size 

would justify the effort.

A. 

(*) this is actually already possible in current GWT with the use of a property provider.

[Ümit Seren]

I don't see how you can easily support and maintain something like web-components (where different Browsers implement different parts of the spec) using browser specific permutations. 

With Edge almost all browsers vendor follow a relatively fast release cycle (ok Safari is the new IE in this regard) and Polyfills (Polymer) seem to be the way to smooth over most of the missing native implementations. 

[Satguru Srivastava]

Thanks for the link Compiling from source code vs. byte code. That was an interesting read. 

That discussion tool place one year into the implementation of GWT. 

Two factors seemed to have played a major part into the team staying the course of source code compilation

a) the source code compiler was already in place and 

b) JSNI implementation 

JSNI implementation requires code in comments and that obviously is lost by the time you reach class files.

Now going forward JSNI will be replaced by  JSInterops and from the little  bit I have read/heard about it, that does not involve code in comments. 

Further in the last ten years JVM has improved quite a bit, has lot more features  and better support for other languages,

Makes you wonder what the byte code approach would have gotten us, .

TeaVM. I guess, is a way to find that out .

Add benefits of byte-code compilation and TeaVM becomes whole lot more interesting 

[Emilio Bravo]

Source maps from byte code?

[Michael Joyner]

Wonderting if it is possible to convert a jar to js, then use it from GWT...