views:

622

answers:

9

With GWT, we can write code in Java and have it translated to JavaScript code. With Script#, we can write code in C# and have it translated to JavaScript code. It sounds GWT and Script# will save web developers from suffering javascript pains. Then, why these tools haven't been dominant? Why still people dedicated to write javascript code?

+4  A: 

For UI development, working in JavaScript is significantly less painful that Java. Would you use a framework which translated assembler to Java to write your Java apps?

Most of the 'pain' with JavaScript was due to browser incompatibilities, which has changed due to large JavaScript libraries (eg dojo), and improvements in the browsers themselves.

Pete Kirkham
++ "assembler to Java" - i like that... :-)
Shog9
True that. Using Java as a scripting language is a solution in search of a problem.
Chuck
+5  A: 

Multiple reasons, and which one is most important differs from developer to deverloper. Here are two:

  • Because JavaScript is a more nice/flexible/powerful/(insert adjective of choice here) language than Java/C#
  • People don't trust the output generated by GWT/Script#
Hank Gay
+3  A: 

Because of Leaky abstractions and because Javascript is a much more elegant and suitable language for ui than Java or C#.

troelskn
+2  A: 

because GWT ist not a one-size-fits-all solution.

GWT ist great and saves a lot of time for java developers who are writing rich internet applications. BUT!

for my unserstanding, it is quite hard to write a GWT site Seo-friendly. its impossible to have a non-javascript fallback. it is not truly optimized for loading speed.

Andreas Petersson
i agree with all comments except for the bit about GWT not being truly optimized for loading speed. GWT *is* truly optimized for loading speed with its indefinite caching of its compiled js, and also, its optimized RPC transfer protocol.
Chii
the number of round-trips in the network will be slightly higher, due to #anchor links. one-request-one-response is simply not possible.
Andreas Petersson
A: 

The problem with JavaScript isn't the language itself, which is quiet good in my opinion, it is, because JS is misunderstood and people don't take it seriously and don't learn it, but copy & paste crappy scripts without understanding the code. Secondly, InternetExplorer, JScript and the messed up DOM implementation ruined the image of the language.

But the main Problem is, you have to understand how the DOM and JavaScript works to write GWT code. It's the same as in JSF development, where you have to understand HTML and CSS. It is not like writing Java, where you don't have to understand the whole bytecode.

Tim Büthe
+3  A: 

For GWT, see "Why isn’t Google Web Toolkit more popular?" on SO

Thierry-Dimitri Roy
+1  A: 

One way to look at (x)HTML, CSS, and Javascript is as the worlds most flexible UI system. Systems like GWT trade some of that flexibility for stability (note: I'm not super familiar with GWT outside the basic premise). There are a lot of software and/or service oriented shops that use the flexibility that (x)HTML, CSS and Javascript provide to differentiate themselves in the marketplace.

Imaginary conversation.

Client: I like the UI you built, but can we make this 20 pixels wider, change the hue slightly, and have an additional floating prompt when you rollover this half of it.

GWT Shop: Yeah, unfortunately the GWT framework doesn't support anything like that without major hacking and/or a lot of extra work that you don't want to pay for.

(x)HTML/CSS/Javascript Shop: Yeah, we can do that without too much trouble, here's an estimate.

I'm not arguing pro/con here and it's certainly more complicated that the imaginary conversation implies, but there are shops who, if forced to adopt a GWT like approach, would loose a competitive business advantage, so they're not going to do it.

Alan Storm
+7  A: 

I can speak for only GWT, but here's the things that I think are holding it back:

  • compile time (GWT takes a long time to compile, javascript changes are instant)
  • learning new language (a lot of web developers don't know how to code java)
  • FUD over leaky abstractions and compiler. People fear a compiler making javascript for them and the leaky abstractions thing. Both are just FUD in my opinion, but that's doesn't make it any less of a reason.
  • people often don't understand where and how to use GWT and are put off by it because they try to wedge it into the wrong holes.
  • There's a perception that GWT was created to allow back end developers to code javascript, but it's not the case at all.
  • The whole idea of using VerticalPanels, HorizontalPanels, FlowPanels and FlexTables is foreign to people who have already learned how to lay things out in HTML.
  • Google is bad at marketing. No offence GWT guys, but if it was marketed/showed off a bit better it would have taken off like hotcakes
  • Lack of great widget libraries for GWT. The widgets that come with it by default are good, but we need a bit more. Libraries like GWT-ext aren't helping in my opinion, because they are just attempts to wrap javascript libraries in GWT, and don't take advantage of the power of coding in Java.
  • Steep learning curve for web developers, because it's framework is more Swing like than HTML like.

I still use it in my day to day coding, but I've long accepted that it's not about to take off.

rustyshelf
great answer - i myself feel the same way. I wished GWT was more popular. But the one bad thing about gwt is that it tends to produce poor html, and doesnt lend well to a public facing "website". Its great for GUI application that happens to be online (like a trade client for example).
Chii
A: 

If your a jave programmer and dont want to learn jave script or care about how IE version deal with Js then GWT is the way to go!

brant