It's possible to use GWT in a Jruby app?
No, it is not possible to use GWT in any other programming language.
The key thing to understand is that "GWT" translates to "convert Java code to JavaScript"; in other words, it is fundamentally a compiler technology. While GWT offers other benefits, such as a rich collection of widgets, it's main purposes is running Java code as JavaScript.
However, between GWT and Google App Engine I am sure there are many ways to solve your problem. Can you share any more details about what you are trying to do?
Related
I know that Scala has Swing (exclusively) as stand alone UI.
Is there any better UI (like JavaFX in Java) in Scala.For a better look and feel.
Please help.
The quick answer is no. Scala does not include a UI framework on its own. You can either use any java UI framework (swing, javaFX and others) via java interop (which is trivial) or find a scala wrapper for one of them (as the comment above).
I mainly post this since your question is else likely to go unanswered, which is kind of a burden on the site.
I am looking for a Technology that I can compare with GWT.
I was thinking about comparing GWT vs Ruby on Rail. But I am not sure if it is the best compare to pick.
If any one can give me some hints, I really appreciate it
It's hard to compare GWT to anything else.
The main idea behind GWT was to leverage existing tooling: debuggers, IDEs (refactoring, etc.), static analysis tools (findbugs, checkstyle, PMD), etc. The goal is not to provide a true emulation of Java in JavaScript; being able to use any existing Java library with GWT is a non-goal.
So, what is GWT?
GWT is a transpiler to JavaScript, much like CoffeeScript, TypeScript, Script#, Emscripten, Haxe and many more.
Unlike many others though, GWT development runs Java in a JVM rather than compiling to JS (Dart with its Dartium and dart2js works similarly), which allows you to use a Java debugger, and tools like JRebel for hot code replacement.
The compilation process is also pluggable with code/resource generators (deferred binding). This, combined with the static typing of Java, makes it possible to use dependency-injection tools such as GIN (Guice for GWT)
GWT is also an extensive library:
client-server communication protocols: GWT-RPC and RequestFactory (RequestFactory can also be used from a Java client, such as an Android application; RequestFactory can also be used to consume JSON-RPC services)
JSON marshalling through AutoBeans
widgets, which makes people sometimes compare GWT to Swing in the way to build UIs (though if you build GWT UIs like you do Swing UIs, you're doomed)
UiBinder is similar to Flex's MXML, .NET's XAML, or Gnome's Glade; but can also be used to output HTML rather than build widgets, which makes it more like… AngularJS maybe?
SafeHtmlTemplates can be seen as similar to Mustache.js
CssResources are similar to Closure Stylesheet, or Sass or Less, though with fewer features
Editors are somehow comparable to AngularJS bindings (see discussion at https://plus.google.com/114156500057804356924/posts/LSNj2zTZo78)
Depending on the facet you're looking at, you can compare GWT with many other tools; but most of all, GWT is a client-side tool, so one thing you can't compare it with is Rails.
GWT:
GWT architecture needs deep understanding to be used completely. It is built for advanced users.
Rails:
Rails is simple and aimed at writing less code. Suitable for beginners in web development.
Here is a complete PDF about comparison .
Simple JavaScript MV* frameworks are numerous and easy to compare. However, at the enterprise scale - there are far fewer frameworks and each are very different. A few others:
ExtJS - A complex and enterprise scale JavaScript framework
TypeScript - A new language developed by Microsoft that is strongly typed and compiles to JavaScipt
Closure - A Google technology for type-checking JavaScript
As you can see, none of these are quite the same as GWT, yet all are targeted at enterprise scale JavaScript development.
I am hoping that someone might be able to tell me how I could use GWT to create a javascript library which I can easily distribute for use in other plain old javascript applications.
The reasoning for this is that we have a very very complex web application, and are looking to eventually move it to GWT to help manage the complexity and reduce the learning curve for new developers. However, I would like to be able to replace the application from the bottom up, that is, start moving some of our core libraries into native GWT, and worry about the UI last. So I need to have our existing applications be able to reference and use the compiled GWT that replaces the existing code.
I realize that this might not be possible given how GWT compiles, but if it is, that would be amazing. It would also help in the future when we need to expose a javascript API to our GWT application.
Thanks,
Casey
Because of the way GWT declares its namespaces in Javascript you can't just use straight GWT in normal Javascript or at least it's not that easy.
However you can check out the gwt-exporter project which might be of some use.
I am about to start a new webapp that will be running on P/GAE and reagarding the front end we would like to use one of the mentioned frameworks (GWT, SC, Cap).
Which one do you think is the most developer friendly? It seems that Cappuccino looks stunning but you have to learn Obj-J. Sproutcore seems nicer (since there is only JS) but I could not say I am impressed with the docs plus some of the demos are broken.
GWT on the other hand is very mature but I have the feeling that using Java may slow you down as you cannot use some of the JS quirks on the other hand there is vibrant ecosystem around it.
I think the answer depends on what type of developer are you?
For me, I'm comfortable with Javascript and like the ability to manipulate the browser DOM so that I can implement features that may not be in the framework. That's why I prefer Sproutcore.
Checkout http://www.infoq.com/news/2009/09/sproutcore-1-0.
I have to agree with you that documentation is limited. However, I've found wiki useful and the community really helpful.
GWT is a very nice choice if you're using GAE-Java because then you can develop server-side and client-side in the same language. If you're using Python on the server-side, you won't be able to use GWT's simple RPC calls to serialize objects to/from the browser. It's still a nice framework though.
GWT does allow you to write JS-native code if needed, so you can "use some of the JS quirks" if you need to.
One warning: GWT apps are totally AJAX, so they can't really be seen by search engines (a general problem with AJAX, not with GWT specifically)
I'm starting work on a smartGWT project in a few days and I'd like to know what kind of experiences you had. To avoid making this a bashing of smartGWT or GWT or a freestyle discussion, I'm going to provide some pointers for the discussion:
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Have you encountered any problems when designing your application that were caused by the framework?
Is the datasource integration as usefull as the smartClient team claims?
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Feel free to add anything you feel is worth pointing out.
I guess you already have your answers, but I would like to add a few more comments that may affect your decision:
Pros:
SmartGWT is the most compreensive LGPL GWT-based widgetery library you can find. So if you care for GPL pain, this is your thing
Comprehensive Showcase.
Really good performance (just check the Showcase).
Very active community in the forums.
SmartGWT extensions is another important project. For example, it has support for GWT-RPC based communication, which is not possible only with SmartGWT (unless you implement your own integration).
Rapid pace of development from the SmartGWT guys. Just count the number of releases since the SmartGWT project appeared.
Cons:
Besides the Showcase, I sometimes feel the only way to figure out how something works is by asking in the forums. This leads to a spread knowledge base. A community based wiki would be preferable.
Large amount of static files you have to use with your application (the famous 'sc' directory) which might lead to problems if your back-end is in GAE (because of the 1000 files limit).
We used SmartGWT in our last project (duration: 6 months). The following is my personal opinion:
The widgets are really great! The documentation and API is verbose. We would use client-side again.
The server-side integration works, but did not save any development time. Instead we had a lot of problems where we had to find workarounds. Also, because of the new API, no other developer can maintain the project within investing a lot of time to learn the SmartGWT API.
Some Cons:
You have to learn a totally new API instead of using Hibernate and GWT-RPC or REST.
The data integration is done automatically, that is true. But if you need some (also little) changes, you have to write XML mapping files as with Hibernate or JDO. So the benefit is gone.
The forum support is bad: You get an answer to almost every posted question. But that answer often does not help. They ask you things such as “why do you want to do that”. Or they say: “use our tool and do XYZ with it” three times, although again and again I told them this suggestion does not work. After a few answers to a question the final answer is: “you need training, buy our support”.
The commercial support is way to expensive (costs approximately as much as the SmartGWT license).
We will probably not use the server-side integration of SmartGWT again.
You can read all my "lessons learned" with Pros and Cons at my blog:
http://www.kai-waehner.de/blog/2010/12/11/lessons-learned-smartgwt-2-3-component-library-for-google-web-toolkit-gwt/
Best regards,
Kai Wähner
Do you feel that the provided widgets
are integrated well? Is there any
widget you miss in particular?
You could create any missed widgets, there is no single framework that can provide everything you want. The widgets are pretty extendable.
Is the datasource integration as usefull as the smartClient team claims?
The data (JSON/XML) can be provided by servlet services, and they are understood by the
widgets.
What methods do you use to make your smartGWT application persistent? e.g. How well do
Hibernate and smartGWT play with each other?
In the backend servlet services of GWT, you can persist your data in the store by using any persistent layer in Java. Hibernate can be just used as same as normal java app.
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Yes. The widgets have a consistent API and work well together.
Is the datasource integration as usefull as the smartClient team claims?
This IMO is one of their strongest feature. Once you start using their Datasource API you realize how little code is required to get a fully functional CRUD screen
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Hibernate works out of the box with the SmartGWT EE version. With the LGPL version using Glead works wells
I think SmartGWT has a ton of great widgets, but but but there is a HUGE price.
Create a simple SmartGWT based project and watch how many files get loaded by your page.
That, I think, is totally against the ideals of something like GWT. While SmartGWT may be a pretty good option for people on a deadline, if you want raw performance, stay away from it.
The number of HTTP requests will simply kill your application.
Have you encountered any problems when designing your application that were caused by the framework?
Yes. When I combined Google Eclipse plugin, SmartGWT, GWT 1.6.4, and Wicket the gwt compiler would emit bad javascript. By bad javascript, I mean javascrip that would not work in webkit, or firefox. I was not able to get good javascript until I removed it completely from the Eclipse project and restarted Eclipse. So, this combination would not work and I ended up building the SmartGWT piece separately in another project. The other issue is that the Smart client seems to want control of the whole page in a css sense. So, the integrated SmartGWT module was all messed up, because styles were not isolated properly. Your mileage may vary.
Personally if you use SmartGWT only and for everything then all will most likely be fine, but if you try and mix it, well my results were disastrous. So, I no longer use it.
Just as a counterpoint to the poster above who mentioned troubles with Wicket, the SmartClient forums (forums.smartclient.com) have reports of success integrating SmartGWT with a wide variety of other technologies. This poster's problems sound like 1) a GWT bug causing bad JavaScript and 2) CSS naming conflicts between SmartGWT and Wicket, probably neither framework's fault. All of SmartGWT's style names can be renamed via the skinning system to resolve any such conflict.