Re: Are you happy with GWT?

[Paul Robinson]

In a word: yes.

You also need to decide whether to use a third party library like Sencha's GXT and SmartClient's SmartGWT. Personally, I chose vanilla GWT and have never once regretted choosing GWT or choosing not to use an external widget library.

Paul

On 05/10/12 16:53, Charlie Youakim wrote:
> I'm deciding on whether to switch my team to GWT. I think the biggest thing for me as the tech lead for the company is "Are you happy with your choice to use GWT?"
>
> My reasons for thinking to switch:
>
> -Javascript is a fast and free language, sometimes too fast and free for a large team. Coding standards can vary from developer to developer, and maintaining architectures can be difficult
> -Javascript mistakes are only caught in runtime. The fact that GWT(Java) would catch 90+% of our simple mistakes makes me more confident that our clients won't.
> -Javascript allows for rapid development, but not so rapid bug fixing.
> -Strict Java coding + a strong architecture at the outset creates a great foundation to build from. I've even seen this in my firm's Android apps. They are very stable.
>
> But for me, I'd really like to hear from developers active in the community. Are you happy? Or do you wish you went a different route? My goal is to have my dev team work more on new projects rather than fixing old projects. I am hoping that GWT can help with that. thoughts?
>
> -Charlie
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/7HVAiaphHqwJ.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Roger Studner]

So, let me give my take on GWT (and add, I'm' happy).

I use GWT, UIBinder, and JavascriptOverlayObjects to handle my tempting, i8n and client side business logic code (event bus, writing happy things like if (account.isOpen()) etc)

I use 100% ajax calls to JSON endpoints.. I don't use gwt-rpc.

I use GWTQuery or JSNI =-> jquery for 99% of my actual DOM manipulation & event handling.

GWT/Java people can read it.

The web designer / html / css / jquery people can read it.

Best,

Roger

[Brian Slesinsky]

As a team member I'm admittedly biased, but here are a few other points:

- You can share Java code between Android and the web. This doesn't make sense for UI code, but it does for business logic and maybe RPC calls (but you have to design for this).

- It's not either-or. You can call JavaScript easily through JSNI and have full access to HTML5 API's and high-quality JavaScript libraries.

- You don't have to use the standard libraries. Some of them fall under "it seemed like a good idea at the time" and there are better alternatives.

[Charlie Youakim]

Thanks for the early replies.  I also wanted to point out we use PHP on the server side, and I'm happy with that.  I feel like our struggles are mostly with JS on the client side, which is why I'm looking at GWT.

[Charlie Youakim]

Thanks Roger!  Yes we would be building to JSON endpoints as well.  Great to hear your feedback.

To unsubscribe from this group, send email to google-web-toolkit+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To post to this group, send email to google-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-toolkit+unsub...@googlegroups.com.

[Roger Studner]

So i'd read up on having your PHP services produce JSON, and GWT's use of RequestBuilder + JavascriptOverlayObjects.  I've put plenty of GWT ui's on front of rails, grails, php back ends etc.

TO note: I love javascript.. use it all the time for personal projects.. I just happen to like the blend these days to separate concerns a bit.

Best,

Roger

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/uZ_XLWOVNgsJ.

To post to this group, send email to google-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Dennis Haupt]

YES!

if i had to mess (and i mean mess) around with jsp files, webflows,
generated javascript in tags, embedded javascript in jsp files... i
wouldn't keep that job. javascript is nice for almost logic-less things
like the whole jquery stuff, but as soon as you have to run logic in the
browser, javascript (or rather its lack of mandatory documentation aka
static typing - or worse: it expects a special context that is
dynamically generated on in random files that are mentioned nowhere)
will come back and bite you.
of course the GWT isn't the only way to avoid melee fights with
javascript, but it's one of the good ways that works for us in
production since more than 2 years. we never had a bug where some
developer would say: "yeah of course it's the GWT again".

Am 05.10.2012 17:53, schrieb Charlie Youakim:
> I'm deciding on whether to switch my team to GWT. I think the biggest
> thing for me as the tech lead for the company is "Are you happy with
> your choice to use GWT?"
>
> My reasons for thinking to switch:
>
> -Javascript is a fast and free language, sometimes too fast and free for
> a large team. Coding standards can vary from developer to developer,
> and maintaining architectures can be difficult
> -Javascript mistakes are only caught in runtime. The fact that
> GWT(Java) would catch 90+% of our simple mistakes makes me more
> confident that our clients won't.
> -Javascript allows for rapid development, but not so rapid bug fixing.
> -Strict Java coding + a strong architecture at the outset creates a
> great foundation to build from. I've even seen this in my firm's
> Android apps. They are very stable.
>
> But for me, I'd really like to hear from developers active in the
> community. Are you happy? Or do you wish you went a different route?
> My goal is to have my dev team work more on new projects rather than
> fixing old projects. I am hoping that GWT can help with that. thoughts?
>
> -Charlie
>
> --
> You received this message because you are subscribed to the Google
> Groups "Google Web Toolkit" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/google-web-toolkit/-/7HVAiaphHqwJ.

> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-tool...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.

--

[Charlie Youakim]

Thank you Roger.  And thank you for pointing out you love JS.  I think that's an important thing to point out.  The team has many Javascript fans and this kind of thing is important for me to know.

To unsubscribe from this group, send email to google-web-toolkit+unsub...@googlegroups.com.

[Charlie Youakim]

Hamster, yes, this was the kind of thing I was worried about seeing in a year:

"yeah of course it's the GWT again" 

Ha.  Thanks for sharing.  Good stuff.

> google-web-toolkit+unsub...@googlegroups.com.

[Roger Studner]

I tend to just always start with an index.html, a reset.css & main.css, and a kitchensink.js hah.. and at some point.. that grows.. and then, at some point, I migrate it to a GWT structure when I feel all the application logic, event bus handling etc warrants it.

I really like java package structures for my widgets.. it helps my old brain out when things get giant.

Sure, I love backbone, and handlebars, and mustache… angular.js is awesome.. but I find, most often, that there is "me" and then 15 java people who like Spring MVC in the room.. and so I have to migrate to a middle ground for the long term productivity of the people.

Best,

Roger

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/1uI21fbAQHEJ.

To post to this group, send email to google-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Alain Ekambi]

YES.

We have  had some crazy requirements that would nt be possible  to implement without GWT.

Think of  " If it s desktop and Flash is installed we want a Flex UI otherwise fall back to HTML5. We also need a Sencha Touch mobile UI and add PhoneGap support  for device access"

Without GWT we would end up with a nightmare of MXML, ActionScript, Granite DS, HTML, JS, etc.

With GWT one code base one language.

Customer happy, devs happy :)

@Bryan.

GWT can also be used for native Android and iOS development.

We wrapped the Titanium API to make it available from GWT.

http://www.emitrom.com/titanium4j

GWT for the win :)

Cheers,

Alain

2012/10/5 Roger Studner <rstu...@gmail.com>

[jones34]

Yes.

I think it's the best available tool for building enterprise web apps.

[Jens]

I am also happy with GWT, working with it for about 2 years now. I like the fact that I get all the benefits of a strongly typed language like Java (strong IDE support, Java debugging features thanks to DevMode, static code analysis) and you get some nice build-in features through GWT like I18n, UiBinder, compile time code generators, deferred binding for optimal code per browser, drop to native JS if needed.

I am not sure if I ever want to write a large enterprise app directly in JS, I think this can easily become a nightmare. JS can be cool for web apps but for enterprise apps you need to get it right with the right tooling and thats where GWT makes your life a lot easier.

Of course GWT has issues, but in general it is pretty stable and there are quite some people using GWT trunk instead of the official releases (even Google itself).

I would always choose it again.

-- J.

[dhoffer]

Yes.  We chose to use GXT 3.x with GWT because GWT has limited widgets, the combination works well.

-Dave

[Sebastián Gurin]

yes I'm happy, and besides the other people reasons, I would like to share my experience from the point of view of reusing existing javascript toolkits and frameworks.

GWT let you define a Java API for any existing JavaScript toolkit or library.  The mechanism of translating an existing JavaScript API to a GWT Java API using GWT JSNI and JavaScriptObject (overlay types) is very mechanical, and can be boosted using a good api tool like eclipse editor's Java code Templates. Besides using overlaytypes gives a Java API with zero-overhead : your java calls will be literally translated to native javascript. No wrappers !

So in other words, GWT provides with good tools for easy and safe JavaScript toolkit definition and reuse in java. (at this time however is rare not to find a GWT version of a cool existing JavaScript toolkit).

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm quite happy with GWT. I prefer it for the type-safety, good
tooling, and language features that support programming-in-the-large
(whatever that means) that are all absent when working in Javascript.
Being able to debug code running in a browser with an IDE is fantastic!

With GWT, we devs spend much less mental energy juggling the
interactions of several templating systems and dynamic, typo-prone
browser APIs, plus our designer can work with what we do via UIBinder
quite naturally. (We actually take his mockups and turn the HTML
directly into UIBindered widgets.)

The only downside of GWT is Java. We do all our server-side work in
Scala, and having to go back to Java's verbosity and (comparatively)
anemic collections API now that we're used to a higher-level language
is a drag. (My coworker calls it "coding through mud".)

It's worth dealing with Java though. I couldn't imagine writing
dynamic, single-page webapps any other way. I've written several in
pure JS, and I would never go back to that.

On 10/05/2012 11:53 AM, Charlie Youakim wrote:
> I'm deciding on whether to switch my team to GWT. I think the
> biggest thing for me as the tech lead for the company is "Are you
> happy with your choice to use GWT?"
>
> My reasons for thinking to switch:
>
> -Javascript is a fast and free language, sometimes too fast and
> free for a large team. Coding standards can vary from developer to
> developer, and maintaining architectures can be difficult
> -Javascript mistakes are only caught in runtime. The fact that
> GWT(Java) would catch 90+% of our simple mistakes makes me more
> confident that our clients won't. -Javascript allows for rapid
> development, but not so rapid bug fixing. -Strict Java coding + a
> strong architecture at the outset creates a great foundation to
> build from. I've even seen this in my firm's Android apps. They
> are very stable.
>
> But for me, I'd really like to hear from developers active in the
> community. Are you happy? Or do you wish you went a different
> route? My goal is to have my dev team work more on new projects
> rather than fixing old projects. I am hoping that GWT can help
> with that. thoughts?
>
> -Charlie
>

> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit

> https://groups.google.com/d/msg/google-web-toolkit/-/7HVAiaphHqwJ.

> To post to this group, send email to
> google-we...@googlegroups.com. To unsubscribe from this
> group, send email to
> google-web-tool...@googlegroups.com. For more options,
> visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBvWP0ACgkQ5IyIbnMUeTs1oQCgqa/bveNbhKxskyK1rBLRSBqI
otQAmgKXwQriwtalaxi/B/03hpX5GYta
=YPUg
-----END PGP SIGNATURE-----

[Charlie Youakim]

Thank you to all the replies.  You covered the concerns I had and more.

[David]

GWT. You had me at "Hello World".    I can't GWT you. :)

[Yarden Shem Tov]

Yes very much.

Although now I would try also TypeScript (from microsoft) if your problems are just runtime bugs and all the dynamic nature of JS.

But again, GWT is great for my opinion.

[Lothar Kimmeringer]

Am 05.10.2012 17:53, schrieb Charlie Youakim:

> I'm deciding on whether to switch my team to GWT. I think the biggest
> thing for me as the tech lead for the company is "Are you happy with
> your choice to use GWT?"

I haven't regretted it. One of the aspects that haven't been
mentioned, yet, is the ability to use JUnit for testing your GUI.
In short that was one of the main reasons I switched to GWT.
There are many GUI-frameworks out there that for example allow
to create native GUIs for mobile devices from one source-base.
But none of them have something like JUnit that can be as easily
integrated into your production process as it can be done with
GWT (at least if your server side als is Java based or you use
Ant or Maven as deployment tool).

The creation of a GUI working in a browser as well as in a mobile
device might take you a bit longer with GWT but the cost of testing
and debugging with JUnit is way lower in the long run.


Regards, Lothar

[Martones]

Yes we are very happy too :)

We have a business application which is basicly aimed to become our home-made ERP. It grows nicely since 2 years (~50 users). We like to have an object oriented, structured long-run model. We have a PHP backend and we use request builder. We use JSONObject that we parse to create the business objects, rather then wrappers.

I'm also bulding some secondary projects with a similar ambition as this one, for other companies.

Our only concern is the GWT future and we are wishing it a long healthy life ;)

Le vendredi 5 octobre 2012 17:53:17 UTC+2, Charlie Youakim a écrit :

I'm deciding on whether to switch my team to GWT.  I think the biggest thing for me as the tech lead for the company is "Are you happy with your choice to use GWT?"

[Milan Cvejic]

Definitely YES! We are using vanilla GWT, and it is great, just documentation is not that helpful. If you want to create some more advance things, you will need to dive
into GWT source.

On Friday, October 5, 2012 5:53:17 PM UTC+2, Charlie Youakim wrote:

[Richard]

A couple warnings.

I'd suggest starting off slowly, rather than dumping the whole team onto GWT on day 1. There are a ton of gotchas or WTF's that the good GWT devs likely don't remember. Adding an intermediate layer can frustrate you if you're used to bare-metal web dev, so you'll definitely get some pushback at some point.

Also, since Java's now considered a bit of an older language compared to the dynamic stuff the cool kids are using, that can affect resourcing. Are the cool kids happy to write Java for their front-end work? Are they happy that it'll have a positive effect on their career and not paint them into a corner?

Personally, I love it. It can drive me nuts at times, but it gives me too many benefits to ignore. Once you learn the intricacies, it's very powerful.

[Dennis Haupt]

there are a few wtfs, yes - but they only come once. once you know them,
they are no problem.

Am 09.10.2012 12:05, schrieb Richard:
> A couple warnings.
>
> I
> <http://www.thehubsa.co.za/forum/index.php?app=hubmarket&do=view_item&item_id=40056>'d

> --
> You received this message because you are subscribed to the Google
> Groups "Google Web Toolkit" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/google-web-toolkit/-/R436N4yJOKQJ.

[David Levy]

Some examples of pushback when trying to introduce GWT into a legacy j2ee application

1) "We don't have time for a re-write"

2) "this is a website not an application"

3) "servlet template engines are sufficient for most UX and the rest can be done in javascript"

4) SEO requirements

5) I18n stuff needs to be in our familiar message.properties

6) UI designers don't want to live in hosted mode

It's my observation that most J2EE developers who fight against GWT change their minds when they are asked to write jquery or native javascript.    You'll however have to provide them with a easy way to inject gwt components into their servlet templates.  Some things to consider:

1) consider consuming a smaller portion of a servlet template rather than the whole page

1a) design your MVP end to support a servlet template containing multiple sections earmarked for gwt (as independent widgets or working in unison) 

2) add comments to the serlvet template file to reveal the entry point or presenter that will be boostrapped when the page loads

3) use http page requests instead of Place management when jumping around to new locations ( a single entry point with MVP and code splitting works very well with this model)

4) Use UIB templates!!!

5) demonstrate the ability to Junit test presenter logic  ( mockito , jukito ..)  - in contrast to the 10s of thousands of lines of .js code that go  unwatched

David

   

--

[Chris Lercher]

That's a very interesting situation. Actually, this is a decision between "full-ajax site" and "js-enhanced site", and for that question it doesn't even really matter which JS framework is used.

Server-side templating has always been a somewhat crazy idea (a hack, if you want - but then again, AJAX is a hack, too). It's surprising, that GWT can handle even this scenario well, and although it can't show its full set of advantages then, it's still a great choice.

It's possible with GWT to eliminate server-side templating, if you want, because GWT makes it so easy to move the UI logic to the client. There are simply things that should live on the server side and things that should live on the client side. With traditional web development techniques, this decision was biased - now you can make a balanced decision.

[David Levy]

When servlet engines first came on the scene , developers were writing stringified content directly to the HttpResponse.  There were also some popular widget frameworks at the time.   Server side templating was introduced to let web designers into the fray.  I wouldn't consider it a hack.  Eliminating them completely has always been a tough sell.  Luckily GWT does not require this . 

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Jz9n8x8JjQwJ.

[Chris Lercher]

On Tuesday, October 9, 2012 4:38:47 PM UTC+2, David wrote:

When servlet engines first came on the scene , developers were writing stringified content directly to the HttpResponse. 

Absolutely, from that point of view (and I remember cgi scripts), template engines are a big enhancement to what existed before!

But imagine telling developers from a different field, who have never looked into web development before, that there's 

- one approach that is based on sending the complete same "<html><head>...</head><body><div>...</div></body>" over and over again, after using a template to replace just a small part of it.

- and there's a second approach that just gets the necessary data from the server, and then updates the view (making use of the specific client's features)

Which one would they choose? I believe it might be a hard time arguing in favor of the first approach.

 

Eliminating them completely has always been a tough sell.

The only significant technical argument against full-ajax is probably the SEO argument. Then again, it's not hard to make it work with Google Search. And other search engines, while maybe not treating it perfectly yet, will eventually have to improve their strategy, too. (Note: In Germany, this is not much of an issue, as Google Search has a market share of >95% here)

 

Eliminating them completely has always been a tough sell.  Luckily GWT does not require this .  

 

I agree. The decision is separate from GWT/other JS framework. And GWT doesn't restrict what you can do in web development.

[Oliver Krylow]

Wow, I am impressed how much attention such a simple and non-technical question got.

But then again, I am about to give my own opinion so why am I surprised :)

Of course I am not happy with gwt itself, that would mean I am content with it the way it is, whereas there are so many improvements I can imagine ;)

( by the way, if you haven't already done so, please take time to participate in the gwt survey  http://bit.ly/GWT2012)

Having said that, I really do believe that choosing gwt was smart, because it has the potential to redefine what we believe a web application to be. I am pretty sure soon no one will be able to distinguish between web, mobile ,application and website. And Google will once again, just like for the web in the good ol' times, have a helping hand in this;)

Realistically speaking, developing a gwt app RIGHT NOW is just about as messy as tinkering with js/HTML/CSS directly, where you trade having to deal with browser-specific bs for having to deal with gwt-specific quirks. This is of course my own opinion ,but it might be noteworthy, that I came as a Java Application developer to gwt and most of CSS /js issues still feel like black magic to me.

But those are rather issues with my lack of knowledge ( scattered ,incomplete, outdated,contradictory or simply wrong documentation seems to be norm in web dev) than with gwt itself.

Thanks for asking this question, if it isn't already it should be part of gwt survey ;)

Oliver

[Joseph Lust]

Praise

I think it is best to assert that GWT is to Javascript what Scala is to Java. GWT is a higher level web framework. Sure, your devs can learn every browser quirk and go bare metal, writing verbose code. But they can also just focus on the higher level of logic, interactions and reusability.

Put simply, the GWT framework allows you to carry out nearly every best practice in web application design, and do so in a robust, automated manner. Sure, you can sprite your images, minify and obfuscate your CSS, combine your JS files, then minimize them, then run them through the Closure compiler, then gzip them, and repeat for each language you plan to i18n for. Or you can just hit compile in GWT. And you can unit test that process as well. Awesome!

Coming from being a script kiddie in 1997, having done PHP frameworks, C# & ASP.Net, and raw JS with ExtJs, there is no better way to create RIA’s than GWT. I used to hate my life when I fought with debuggers in FF and raw HTML code to get a blasted form to come up right. Now I just put a few UiBinder XML tags in with something like gwt-bootstrap and it is done and pretty. Life saver. Why would you do it any other way?

And, to note what you can do with this. My employer, a large financial institution, uses GWT as their standard inhouse technology for enterprise web applications. One team just finished a 400 screen application and I’m currently working on a bleeding edge, HTML5/canvas based flagship product which is 200kLOC strong. GWT makes these applications, their rapid turnaround, and very high level of quality possible.

Terms and Conditions

This is not for script kiddies. You should have a good grasp of OO, Java, and JS. GWT itself is a bit dogmatic. This means it requires competent developers.  Once they read all the docs on the Google Dev pages, they’ll be in good shape. Still, becoming a serious GWTer is not a weekend effort. Thus, if you want to create a simple blog, stick with PHP and WP, but if you want a highly optimized, complex web application, go with GWT. 

Sincerely,

Joseph

[Charlie Youakim]

Great posts.  I am truly gracious of all the responses to this question I posted.  I feel like we have made the right move going in this direction.

[Shaun Tarves]

There is no doubt that what GWT does, it's really good at. However, some things that I've found GWT really isn't good at:

1) Producing clean HTML

The structure of GWT "page views," especially with GWT widgets, is really poor. The DOM gets bloated with lots of extra elements that are used for focus and positioning. There are ways around this, but I feel like I'm constantly fighting with GWT to generate HTML structure on my terms.

For example, some of the most lauded constructs in GWT are the Cell-based widgets (CellTable, and CellList, specifically). With CellLists, you are stuck with divs. There's no way around it. So that means if you want to make a good data model-backed list and render it as a UL with LIs, you're SOL.

2) The history mechanism is really powerful, but it's important to get your URL structure correct from the start. The built-in history token parser is a little too rigid in that it forces the first part of your URLs to be of the form xxxx:yyy and then anything you want after that. When you dive deeper into GWT, you'll understand the limitations of the PlaceHistoryMapper and why you might want to avoid the tokenizers and write your own parser.

3) The GWT CSS compiler doesn't understand any CSS3 attributes. Also, browser-specific attributes (such as the * hack for IE) throw warnings on compiling. It's not really GWT's fault (it's a Java compiler issue), but be aware nonetheless.

Just a few things to keep in mind.

[Thomas Broyer]

On Wednesday, October 10, 2012 10:13:36 PM UTC+2, Shaun Tarves wrote:

There is no doubt that what GWT does, it's really good at. However, some things that I've found GWT really isn't good at:

1) Producing clean HTML

The structure of GWT "page views," especially with GWT widgets, is really poor. The DOM gets bloated with lots of extra elements that are used for focus and positioning. There are ways around this, but I feel like I'm constantly fighting with GWT to generate HTML structure on my terms.

For example, some of the most lauded constructs in GWT are the Cell-based widgets (CellTable, and CellList, specifically). With CellLists, you are stuck with divs. There's no way around it. So that means if you want to make a good data model-backed list and render it as a UL with LIs, you're SOL.

It's a false problem. GWT widgets are generally good as far as accessibility is concerned, and let's put it clearly the only reason on having a "semantic" DOM tree is for a11y.

2) The history mechanism is really powerful, but it's important to get your URL structure correct from the start. The built-in history token parser is a little too rigid in that it forces the first part of your URLs to be of the form xxxx:yyy and then anything you want after that. When you dive deeper into GWT, you'll understand the limitations of the PlaceHistoryMapper and why you might want to avoid the tokenizers and write your own parser.

On the plus side: it's pluggable. (it wasn't at first, you had to re-implement the whole PlaceHistoryHander+PlaceHistoryMapper)

 

3) The GWT CSS compiler doesn't understand any CSS3 attributes. Also, browser-specific attributes (such as the * hack for IE) throw warnings on compiling. It's not really GWT's fault (it's a Java compiler issue), but be aware nonetheless.

You don't need browser-specific hacks, simply use "@if user.agent ie6 ie8". The real issue is with selectors. FYI, gradients can now be used without literal() in 2.5.0-rc2: http://code.google.com/p/google-web-toolkit/issues/detail?id=5771

[Roger Studner]

There is no such thing as "producing clean vs not clean" html unless you rely on other peoples widgets.

100% of my widgets are a UIBTemplate.. of my creation… I use GWTQuery (or jquery) to add/remove elements from my widgets.  Thus, the HTML is exactly as clean as any HTML that any non-gwt application would use/produce.

Roger

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/A-GepWmKMf0J.

[Brian Slesinsky]

The original goal of writing clean HTML was for static, document-centric websites where you could do things like run a filesystem search or a web spider to create an index of all your documents, use an HTML editor, or perhaps do a search and replace. And of course it helps with SEO. But how relevant is it to a web application where "view source" won't show you much and you'll only see the DOM in the debugger?

To unsubscribe from this group, send email to google-web-toolkit+unsub...@googlegroups.com.

[Roger Studner]

It helps the most when highly talented html5/css3/jquery people produce mockups etc.. as then translating them to GWT to get i8n, code splitting and a handy way to do an event bus + business logic all in java, is pretty darn easy

Roger

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/WgLQsqv2dBoJ.

To post to this group, send email to google-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

1) Has largely been a non-issue for us in practice, since we use
UIBinder. We devs take a mockup from our designer, extract chunks of
HTML from it, and parameterize them into UIBinder widgets.

We end up with an app whose DOM structure is 99% the same as the
designer's mockup, which means we can use the mockup's CSS without any
modifications. For devs like us that would prefer to stay as removed
from CSS as possible to concentrate on other things, this is a huge win.

That said, if styling isn't important - and it isn't for a good chunk
of internal CRUD-oriented apps - it's not that big a deal if 'view
source' shows "ugly" nested tables or not.

> *Praise*
>
> I think it is best to assert that /GWT is to Javascript what Scala
> is to Java/. GWT is a higher level web framework. Sure, your devs

> can learn every browser quirk and go bare metal, writing verbose
> code. But they can also just focus on the higher level of logic,
> interactions and reusability.
>
> Put simply, the GWT framework allows you to carry out nearly every
> best practice in web application design, and do so in a robust,
> automated manner. Sure, you can sprite your images, minify and
> obfuscate your CSS, combine your JS files, then minimize them, then
> run them through the Closure compiler, then gzip them, and repeat
> for each language you plan to i18n for. Or you can just hit compile
> in GWT. And you can unit test that process as well. Awesome!
>
> Coming from being a script kiddie in 1997, having done PHP
> frameworks, C# & ASP.Net, and raw JS with ExtJs, there is no better

> way to create RIA�s than GWT. I used to hate my life when I fought

> with debuggers in FF and raw HTML code to get a blasted form to
> come up right. Now I just put a few UiBinder XML tags in with
> something like gwt-bootstrap and it is done and pretty. Life saver.
> Why would you do it any other way?
>
> And, to note what you can do with this. My employer, a large
> financial institution, uses GWT as their standard inhouse
> technology for enterprise web applications. One team just finished

> a 400 screen application and I�m currently working on a bleeding

> edge, HTML5/canvas based flagship product which is 200kLOC strong.
> GWT makes these applications, their rapid turnaround, and very high
> level of quality possible.
>

> *Terms and Conditions*

>
> This is not for script kiddies. You should have a good grasp of
> OO, Java, and JS. GWT itself is a bit dogmatic. This means it
> requires competent developers. Once they read all the docs on the

> Google Dev pages, they�ll be in good shape. Still, becoming a

> serious GWTer is not a weekend effort. Thus, if you want to create
> a simple blog, stick with PHP and WP, but if you want a highly
> optimized, complex web application, go with GWT.
>
> Sincerely,
>
> Joseph
>

> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit

> https://groups.google.com/d/msg/google-web-toolkit/-/Wysu0gYQN3MJ.

> To post to this group, send email to
> google-we...@googlegroups.com. To unsubscribe from this
> group, send email to
> google-web-tool...@googlegroups.com. For more options,
> visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQdfrQAAoJEMPs4oOavcuslTYH/1yjJw7zpsyipi1Yxw97pm5X
cfav6naCJdT6aveb+U6HIlHe65GPlMApHAURTOlAIztFxqfTLdJDdS+c14WWP6eN
uKz3FVknvtQP/rJ9dT6wXdy3GQx0IfWF/afU/Exxf6yZrp0tzFF+V+U/PJzTPZG3
uSA6+PETVBwcgDzFK0Avn5W+DnCFAIyOuxnF9dQsbC3LOxgFDpQcSJgmd6zSbbYS
zjg9pHykIXRimwECiiceNO72HDaeJpMOoUvnXrNzoYcxwfv3+IZym2DQJeSHalXS
sDtap9GKHPM5OXG6z+dtgYj1KljWrQAa2bnJ+NSF5OO24H9wF2+1sDaI7LNEmxA=
=2fiv
-----END PGP SIGNATURE-----

[Joseph Lust]

I've got to add my two cents here since the "pretty" argument and "CSS designer" bit has irked me over the years.

There is a clear impedance mismatch between what a CSS/HTML designer can kick out from a graphical suite, and what is a truly robust, reusable component.

1. You must protect the CSS namespaces. Just because Mockup A looks good, does not mean it will work well together with Mockup B on Page C.
   
2. The CSS in mockups can be quite fragile and verbose, not being well suited to componentization (i.e. depending on x:nth-child(4), x:last-child) when you now have N entries and M instance of the widget on the page.
   
3. Various transitions and UI changes in the mockup should be triggered by changing a single class, not manually applying myriad style changes like "right:33px" and "opacity:0.34". Otherwise the devs need to rework the CSS themselves.

Frankly "mockups" can be misleading and make a product look functionally complete, even though as coded they cannot be robustly implemented. Such things however are not a flaw in GWT, but a need to design for reuse and extensiblilty at the mockup stage. So be sure to set some requirements for your designers to be GWT friendly and the code should be easy to implement.

Sincerely,

Joseph

[Ümit Seren]

I am really happy with GWT.
I must say that I had some issues with the relatively slow dev-mode debug cycle (I was using Chrome and I know that Chrome is slower than Firefox) but since I switched to SuperDevMode debugging has been a bliss
I can now change something in the code, recompile it almost instantly and then see the live effects right away. Futhermore debugging with Chrome Developer Tools works really well and given that Google is putting a lot of effort in improving the Chrome Developer Tools it can only become better and better ( I really recommend to try out SuperDevMode). 

The second aspect which I really like is that there are a lot of great 3rd party libraries (gwt-bootstrap, gwt-chosen, piriti, gwtquery, gwtp, many more) for additional functionality and it is really easy and straight forward to create your own library and use it in your projects. For example I created several visualizations using processingjs and created a GWT wrapper around it and I am using it in different projects. If you apply MVP to these wrappers/libraries they can also be easily tested and other people can re-use them. 

Of course some aspect of GWT (Editor, RequestFactory) can have a steeper learning curve.

[Shawn Brown]

> ( I really recommend to try out SuperDevMode).

Sounds great but for anyone using AppEngine and RPC calls, won't
really work without tons of hassle (as far as I can find).

http://code.google.com/p/google-web-toolkit/issues/detail?id=7522

[Ümit Seren]

True, RPC is an issue with SuperDevMode.
However fortunately I always used either RequestFactory or Restfull services/RequestBuilder. 

[salk31]

YES! 

To add an analogy: I'm an old geek and going from JSP/JS/Servlet/MVC etc to GWT feels like going from assembly to C/C++...  I sort of knew at the time that the compiler should be doing lots of things for me but now I've switched to GWT (last few years) it is even more obvious that I'm using a mature approach rather than wild west of previous web development.

More gushing: It is not just that they got the general approach right but the quality of design and implementation is exceptional. These people obviously knew what they were/are doing.