Overview of Scala.js from a GWT developer perspective | Hacker News Reader

Overview of Scala.js from a GWT developer perspective

g-widgets.com

27 pointsbased222 comments

Li Haoyi (scala.js author) explains why he worked on scala.js pretty well: http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...

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.

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

Thanks Li, seems like http://udash.io/ would be a more direct comparison to GWT.

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

Two dead techs in one peice, so bizarre.

You're asking me to believe the ranking that has assembly or basic in the top 10 over github's rankings. No thanks.

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

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

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.

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

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

I'm thinking that static typing is a big one.

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

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?

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.

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

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

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

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

> It lets you define types for more safely interacting with other Javascript code

You define types for everything.

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.

Reply on news.ycombinator.com