
Overview of Scala.js from a GWT developer perspective - based2
http://www.g-widgets.com/2017/06/26/overview-of-scala-js-from-an-gwt-developer-perspective/
======
audi100quattro
Li Haoyi (scala.js author) explains why he worked on scala.js pretty well:
[http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...](http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScalajs.html)

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.

~~~
lihaoyi
Small correction: I'm not the author of Scala.js, that honor falls to
Sebastien who did all the hard compiler work to make Scala.js happen.

I just used Scala.js and built libraries on top of it

~~~
audi100quattro
Thanks Li, seems like [http://udash.io/](http://udash.io/) would be a more
direct comparison to GWT.

------
joshhart
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.

~~~
candiodari
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.

~~~
rpeden
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.

------
jpitz
I'm a little bit doubtful about a Scala.js overview from someone who thinks
that Scala's big advantage over Java is dynamic type inferencing.

~~~
freddex
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.

~~~
jpitz
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.

FWIW, I didn't call it dynamic, TFA did.

------
HackerDre
Why would someone use this instead of ClojureScript? Unless they're a Scala
expert

~~~
fwefwwfe
Why would someone use ClojureScript instead of this? Unless they're a Clojure
expert.

------
mbell
How does Scala.js deal with inconsistent browser APIs and type safety? Does it
just include all of core-js and hope for the best?

~~~
fwefwwfe
It lets you define types for more safely interacting with other Javascript
code. It doesn't magically make browsers have consistent behavior.

~~~
mbell
What I'm getting at is how it handles type safety at the browser API boundary.
e.g. how does it handle a situation like:

`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?

~~~
sjrd
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.

[1] [https://github.com/scala-js/scala-js-dom](https://github.com/scala-
js/scala-js-dom)

