Re: Teavm

[Emilio Bravo]

Source maps from byte code?


El martes, 1 de diciembre de 2015, 16:43:44 (UTC+1), Satguru Srivastava 
escribió:
>
> 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 ?
>
>
>
>
>
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Michael Joyner]

  
  
Wonderting if it is possible to convert
  a jar to js, then use it from GWT...
  
  
  On 12/04/2015 07:51 AM, Emilio Bravo wrote:


  Source maps from byte code?

  
  El martes, 1 de diciembre de 2015, 16:43:44 (UTC+1), Satguru
  Srivastava escribió:
  
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 ?
  
  
  
  
  
  
  
  
  
  
  

  

  
  -- 
  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-toolkit+unsubscr...@googlegroups.com.
  To post to this group, send email to google-web-toolkit@googlegroups.com.
  Visit this group at http://groups.google.com/group/google-web-toolkit.
  For more options, visit https://groups.google.com/d/optout.


  




-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Martin Trummer]

there is an old group post 
<https://groups.google.com/forum/#!msg/google-web-toolkit-contributors/7cQVHAFVZrc/AMF7UxahsS4J>
 
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 
<https://www.sencha.com/forum/showthread.php?306057-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 
   <https://news.ycombinator.com/item?id=8554339>)

On Wednesday, 2 December 2015 16:00:46 UTC+1, Thomas Broyer wrote:

>
>
> 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 
> <https://www.google.com/url?q=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMicrosoft_Live_Labs_Volta=D=1=AFQjCNEdBviOLnye1JafAOvLleqhldxSoQ>
>  
> 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
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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=PA67#v=onepage=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.

>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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?

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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.




On Thu, Dec 3, 2015 at 1:49 PM Martin Trummer 
wrote:

>
> 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?
>
>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Ü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. 


On Thursday, December 3, 2015 at 1:49:03 PM UTC+1, Martin Trummer wrote:
>
>
> 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?
>
>
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Satguru Srivastava]

Thanks for the link Compiling from source code vs. byte code 
<https://groups.google.com/forum/#!msg/google-web-toolkit-contributors/7cQVHAFVZrc/AMF7UxahsS4J>.
 
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 



On Thursday, December 3, 2015 at 5:24:38 AM UTC-6, Martin Trummer wrote:
>
> there is an old group post 
> <https://groups.google.com/forum/#!msg/google-web-toolkit-contributors/7cQVHAFVZrc/AMF7UxahsS4J>
>  
> 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 
> <https://www.sencha.com/forum/showthread.php?306057-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 
><https://news.ycombinator.com/item?id=8554339>)
>
> On Wednesday, 2 December 2015 16:00:46 UTC+1, Thomas Broyer wrote:
>
>>
>>
>> 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

Re: Teavm

[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

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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.

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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 <https://github.com/konsoletyper/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 <https://dukescript.com/> 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.

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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?

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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)

On Tuesday, December 1, 2015 at 9:45:20 PM UTC-5, Satguru Srivastava wrote:
>
> 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.
>
>
>
>
>
>
> On Tuesday, December 1, 2015 at 12:28:20 PM UTC-6, Adam M wrote:
>>
>> 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)
>>
>> On Tuesday, December 1, 2015 at 10:43:44 AM UTC-5, Satguru Srivastava 
>> wrote:
>>>
>>> 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 ?
>>>
>>>
>>>
>>>
>>>
>>>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Subhrajyoti Moitra]

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

Thanks,
Subhro.


On Wed, Dec 2, 2015 at 3:47 PM, Alexey Andreev <konsolety...@gmail.com>
wrote:

>  - 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?
>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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.

On Wednesday, December 2, 2015 at 7:51:12 AM UTC-5, Alexey Andreev wrote:
>
> 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 
> <https://github.com/konsoletyper/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 <https://dukescript.com/> 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.
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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.






On Tuesday, December 1, 2015 at 12:28:20 PM UTC-6, Adam M wrote:
>
> 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)
>
> On Tuesday, December 1, 2015 at 10:43:44 AM UTC-5, Satguru Srivastava 
> wrote:
>>
>> 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 ?
>>
>>
>>
>>
>>
>>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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)

On Tuesday, December 1, 2015 at 10:43:44 AM UTC-5, Satguru Srivastava wrote:
>
> 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 ?
>
>
>
>
>
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

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 ?





-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[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

On Tue, Dec 1, 2015 at 7:43 AM, Satguru Srivastava <ssatg...@gmail.com>
wrote:

> 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 ?
>
>
>
>
>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@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.

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.