there is an old group post that already discusses the byte-code vs. source code issue - maybe it is still helpful
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)
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 http://jscriptsuite.com/ http://jsil.org/ http://jsc.sourceforge.net/ https://github.com/Reactive- https://Extensions/IL2JS 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+unsubscribe@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.
No comments:
Post a Comment