Good article. It is important to point out that GWT comes with more than just a Java -> Javascript compiler. It is also a set of tools and components to make web development feel more native. Over time, emphasis on these has lessened but it's possible to write web apps in GWT in a very similar manner to building Swing apps. I think 10 years ago this was really important for easing the transition for those coming from a desktop app world.
In my experience it's still a far superior method for producing larger single page apps. Static typing, great components (e.g. data table, including custom-components-data-table, ...), incredible tooling, ridiculous amounts of libraries, incredible RPC, ...
Where it comes to "produce exactly this HTML/CSS/..." that's where it sucks. This seems to matter a lot to react/angular guys.
Getting very far in functionality I would certainly use GWT over a "modern" stack though.
GWT definitely deserves a better reputation than it has.
I use and enjoy tools like React, Webpack, and friends. They make for a pleasant development experience. I do find it mildly amusing when people get excited about things like code splitting and dead code elimination in Webpack, though. Those things were pretty cool to see in GWT....in 2009. :) I remember it being pretty decent for plain HTML and CSS, too. I worked on a fairly big app and we didn't really use any of the build in widgets - mostly just HTML and CSS with UiBinder templates.
GWT is definitely showing its age in some ways now, but for those of us who had to make single page apps in 2009/2010, it wasn't a bad way to get things done. I've seen some GWT apps whose codebases were disorganized horror shows. The main GWT app I worked on was quite nice - small, self contained components, all communicating asynchronously via an event bus that was passed in via dependency injection. It actually felt really, really similar to the way an Angular 2/4+ app does now.
Overall, though, I try not to grump about the fact that mainstream front end development is rediscovering some of the good things GWT pioneered in this space. The more accessible front end development tools are, the better off we all are.
I don't know, but I would be surprised if Scala.js does anything in that regard. It's a Scala-to-JS compiler, its job is to translate Scala code to JS code.
Scala.js lets you require any npm modules, so you can `require()` any JS polyfills you want just like you would do if writing JS code by yourself.
Does it just allow 'Any' for the type of the third param and thus somewhat punt on type safety at the browser API boundary or is there some attempt at defining an algebraic type for that param?
Or as another example, how would it handle the object passed to `fn` above, presumably some sort of event type, having different properties in different browsers?
In the standard types for the DOM [1], only types for standardized browser APIs are made available. Browser inconsistencies wrt. standards are dealt with polyfills, either written in JS because they already exist, or you can write them in Scala.js too if you prefer.
But Scala.js doesn't force the standard typings on you. If you prefer another strategy, you can write your own types for the browser. You could use overloads in your example above.
That wouldn't prevent you from using the wrong overload on the wrong browser at the type system level, though, obviously. Doing so might be possible if you're willing to go very far with Scala's path-dependent types, but I won't go into details here. Scala.js users tend to prefer the earlier solutions.
About as well as jquery-ui or bootstrap would deal with browser inconsistencies if that's what you use for pre-made widgets/forms/layouts/themes/etc.. as other have said, you can use any js library.
What do you mean by dynamic here, exactly? From what I understand, in Scala, types are statically inferred (at compile time, not at runtime). I'd call this a very nice feature to reduce boilerplate.
Compile time type inference is nice, but it doesn't make me excited about the language. Personally, I find more value in things like pattern matching and case classes.
Using scala.js with jquery-ui or any other js library using facades works well. If you wanted pre-made ui widgets, your choices are going to limit you in one way or another (compared with writing html/css), so arguably learning jetty+scala.js+jqueryui, is equivalent to using GWT, and has surpassed GWT in terms of js/scala/jvm compatibility in every way. It might never compete with webassembly in terms of raw performance, but then GWT isn't about to do that either if you're writing code for the browser.
Also, Scala+GWT seems to be dead, probably because of scala.js. You can use gradle/maven with Scala just fine. I use gradle for all of my Scala projects.
GWT was dead a long time ago, maybe two years after it came out, it's a dead tech. So is Scala, after the scala hype train left a few years ago, almost no one is using it (see tiobe).
There's a lot of embedded systems in this world that are still written in straight assembly, and there's a lot of business systems written in VB. I cringe at both thoughts, but...
22 comments
[ 2.9 ms ] story [ 56.8 ms ] threadWhere it comes to "produce exactly this HTML/CSS/..." that's where it sucks. This seems to matter a lot to react/angular guys.
Getting very far in functionality I would certainly use GWT over a "modern" stack though.
I use and enjoy tools like React, Webpack, and friends. They make for a pleasant development experience. I do find it mildly amusing when people get excited about things like code splitting and dead code elimination in Webpack, though. Those things were pretty cool to see in GWT....in 2009. :) I remember it being pretty decent for plain HTML and CSS, too. I worked on a fairly big app and we didn't really use any of the build in widgets - mostly just HTML and CSS with UiBinder templates.
GWT is definitely showing its age in some ways now, but for those of us who had to make single page apps in 2009/2010, it wasn't a bad way to get things done. I've seen some GWT apps whose codebases were disorganized horror shows. The main GWT app I worked on was quite nice - small, self contained components, all communicating asynchronously via an event bus that was passed in via dependency injection. It actually felt really, really similar to the way an Angular 2/4+ app does now.
Overall, though, I try not to grump about the fact that mainstream front end development is rediscovering some of the good things GWT pioneered in this space. The more accessible front end development tools are, the better off we all are.
Scala.js lets you require any npm modules, so you can `require()` any JS polyfills you want just like you would do if writing JS code by yourself.
`eventTgt.addEventListener('whatever', fn, true)`
vs
`eventTgt.addEventListener('whatever', fn, { passive: true })`
Does it just allow 'Any' for the type of the third param and thus somewhat punt on type safety at the browser API boundary or is there some attempt at defining an algebraic type for that param?
Or as another example, how would it handle the object passed to `fn` above, presumably some sort of event type, having different properties in different browsers?
But Scala.js doesn't force the standard typings on you. If you prefer another strategy, you can write your own types for the browser. You could use overloads in your example above.
That wouldn't prevent you from using the wrong overload on the wrong browser at the type system level, though, obviously. Doing so might be possible if you're willing to go very far with Scala's path-dependent types, but I won't go into details here. Scala.js users tend to prefer the earlier solutions.
[1] https://github.com/scala-js/scala-js-dom
You define types for everything.
FWIW, I didn't call it dynamic, TFA did.
Using scala.js with jquery-ui or any other js library using facades works well. If you wanted pre-made ui widgets, your choices are going to limit you in one way or another (compared with writing html/css), so arguably learning jetty+scala.js+jqueryui, is equivalent to using GWT, and has surpassed GWT in terms of js/scala/jvm compatibility in every way. It might never compete with webassembly in terms of raw performance, but then GWT isn't about to do that either if you're writing code for the browser.
Also, Scala+GWT seems to be dead, probably because of scala.js. You can use gradle/maven with Scala just fine. I use gradle for all of my Scala projects.
I just used Scala.js and built libraries on top of it
Two dead techs in one peice, so bizarre.