
Scala.js no longer experimental - densh
http://scala-lang.org/news/2015/02/05/scala-js-no-longer-experimental.html
======
noelwelsh
I was very sceptical of Scala.js, but decided to use it in a low risk project
([http://github.com/underscoreio/doodle](http://github.com/underscoreio/doodle))
to render to the HTML canvas and I am shocked at how well it works. The
community is moving very quickly as well, and many advanced Scala projects
have had the necessary tweaks applied to run in Scala.js.

Looking at broader trends, there is a clear movement towards static typing on
the Javascript VM, as in-browser programs become more complicated. Google is
developing SoundScript, there has been talk about gradual typing in ES7,
Facebook has their type checker etc. To some extent I think adding static
types to (the mess that is) Javascript is more work than may be worthwhile. I
see the most practical developments in the alternative JS languages, such as
Elm and Purescript, and now Scala.js, that start from a cleaner slate. The
Javascript committee have done a shockingly good job making Javascript a
compilation target with tail calls and so on in ES6.

~~~
desdiv
_Google is developing SoundScript_

Aren't they doing Dart as well? That has optional typing. Plus they have GWT,
which is Java to JS.

Don't get me wrong, I'm super grateful to receive their fruits of labor for
free, but this looks like a case of the left hand not knowing what the right
hand is doing.

~~~
fapjacks
You've hit the nail on the head with left-hand-right-handedness at Google.
Every interaction I've had with that company reveals behavior reflective of
this condition. You've gotta scratch the surface to find it, but lately it's
not very deep. When I interview places, and the interviewer gives me a single
question, I hit them with something almost no one expects ("If you could
change one thing without veto, what would it be?"). When I interviewed there
at Google some time ago (I turned down their offer because of the answers I
got to this question), six out of the seven interviewers I asked replied with
some variation on "All the low-hanging fruit has been picked, and most people
aren't in a position to solve the gnarly problems, so I wish I could do work
that challenges me." This immediately sent up red flags with me, along with
the weird sense of hivemind I got at the Googleplex. It wasn't exactly like
wandering around a Borg cube, but it was close. Then recently the company I
work for has had visitors from Google, and while I'm not involved in the
interactions personally, there's a huge sense of this left-hand-right-hand
problem even among teams working on the same product, just different groups.
This is probably the case with all large corporations after a certain critical
mass, but I'm personally experiencing a selection bias for Google in
particular.

~~~
ma2rten
_When I interview places, and the interviewer gives me a single question, I
hit them with something almost no one expects ( "If you could change one thing
without veto, what would it be?")_

I will remember this one. That's a great question for interviews.

~~~
wc-
Even from the POV of the interviewer it's a great question. I'd give my answer
then brainstorm with the interviewee about how they would propose solving that
problem.

Would you feel comfortable asking an interviewee the same question about their
last job? It could give a sense of how they think / why they are looking for a
new spot but might be a little invasive.

------
apo
Let's say I want to use Scala.js to build, not an application, but a
JavaScript library. The library exposes a JavaScript API that JavaScript code
can call. The library's objects can be used in full from JavaScript.

Can I do this with Scala.js? If so, how?

Very few, if no, *-to-JavaScript cross-compilers can do this. For example,
Dart might seem to be that language, but on closer inspection, it's not. Your
library is locked inside a JavaScript VM-like data structure.

Although you can get a JavaScript object out of Dart-to-JavaScript compiled
library, you need to manually hook up every function in its API yourself. In
other words, it's not practical to use Dart to build a JavaScript library that
exposes a sophisticated JavaScript API.

Is this possible in Scala.js?

~~~
densh
Yes, this is possible.

[http://www.scala-js.org/doc/export-to-javascript.html](http://www.scala-
js.org/doc/export-to-javascript.html)

~~~
apo
Exactly what I was looking for, thanks!

------
jsight
I understand why these types of compilers lack reflection support, but it
still bothers me (and general makes me want to avoid them). JavaScript is
naturally a very dynamic environment, and both Java and Scala have some pretty
strong dynamic capabilities of their own.

But somehow when they are combined (GWT or Scala.js) you end up with something
that is more static than Java or JavaScript. I know the reasons have to do
with the static compilation optimization, but I still think this is a huge
downside relative to languages that are designed for the browser from the
start.

~~~
adrusi
I don't understand why compilers can't simply emit global variables containing
structural descriptions of types. It seems like such a trivial thing to do. It
would increase the size of the binary, but it would be possible to disable in
projects that aren't using reflection, even automatically if the code never
imports the reflection package.

Maybe someone can explain this.

~~~
sjrd
Oh yes, compilers could do that. But because of the code explosion, everyone
would actively stay away from that feature. And we, compiler writers, don't
want to support a feature that's not used.

------
scorpwarp23
That's exciting. I have worked extensively with Scala during my Master's
project. What I'd really like to know is what this means in the context of the
current trend of JavaScript (both client and server-side).

I'm currently working exclusively on MeteorJS, Node.JS and Angular and fail to
see the relevance other than porting Scala applications to the web and making
Web App development easier for developers familiar with Scala. However,
without the kind of structure and inherent capabilities that a MeteorJS or
DerbyJS offers, what's the USP here?

~~~
brudgers
Scala.js, Clojure.js etc. treat JavaScript as assembly language and the
browser as a target architecture. It's not about porting applications. It is
about accessing the same data structures and abstractions on both ends of the
wire when writing code.

For languages like Scala this means things as obvious as keeping class based
inheritance with traits when writing client code for the browser. Those
classes can share the same hierarchy with the server side.

This means that the decisions about where to execute a feature becomes less
likely to be driven by differences between client and server language
features. The effort can be put into determining which execution environment
better solves the problem.

------
julius
This sounds great. I have not really used Scala before. 3 questions:

\- How good do IDEs understand Scala these days? Compared to C#/Java, where
IDEs instantly know a crazy lot about your code. I am looking at features like
IntelliSense, marking wrong code, marking typos, marking unused code, telling
me about unhandled Exceptions etc.

\- Is there any difference, on the IDE side, between Scala support and
Scala.JS support?

\- Is a development cycle possible, where I save and I can instantly reload
the page in my browser to see the differences?

\- (Bonus Question) How well does it integrate with React. If my memory is not
fooling me, Scala supports something like Inline-XML. Can I write React-Code,
like I write JSX code with it? Any examples?

~~~
the_af
Let me contradict the other answers with my personal experience: the two IDEs
for Scala I know, Scala-IDE (Eclipse based) and IntelliJ are relatively bad.

\- They are very slow.

\- They have poor refactoring support (Scala-IDE's support is still marked as
experimental; all but the simplest refactoring will often randomly break code,
either by not doing a full refactor, or by introducing gibberish).

\- Until the latest version of Scala-IDE, you couldn't inspect variable
contents while debugging. I can confirm the latest version does let you
inspect variables, but I'm not sure how stable this is.

\- This is the killer disadvantage for me: both Scala-IDE and IntelliJ give
spurious compilation errors pretty often, even for relatively trivial code. I
know there are valid technical reasons why this isn't solved yet, but to me
it's _unacceptable_ that an IDE for a _statically typed_ language gives
spurious compilation errors: after all, compile-time errors are the main tool
a statically typed language gives us. It's the one feature that absolutely
_must_ work correctly.

\- Even trivial autocomplete randomly stops working for Scala-IDE. This may be
related to the spurious compilation errors.

I've been told the unofficial recommendation from the Scala community is to
disable incremental compilation in the IDE and compile with SBT. Consider what
this says about the maturity of current IDEs.

~~~
lmm
My experience with Scala IDE:

\- Yes, it's very slow.

\- Refactoring is limited, will sometimes refuse to happen, and will sometimes
randomly move 1 character into the wrong place in the file. So yes it does
"break", but not in a way that's hard to fix.

\- Variable inspection when debugging has always worked fine for me.

\- Scala-IDE never gives a "full" spurious compilation error (one that shows
up in the problems tab and with a full icon on the left) - or rather, no more
than Eclipse in Java does (the kind where you have to refresh / clean the
project do sometimes happen). On some constructs it will show a spurious
"presentation" compiler error (red underline, simpler icon on the left), but
it's easy to visually tell the two apart. I never think code is broken when it
isn't.

\- Autocomplete never stops working. It does sometimes get slow (several
seconds)

\- I have automatic compilation on save (no incremental config),
manual/explicit saving. It's a workflow I'm happy with.

~~~
the_af
Thanks for the info. A couple of questions:

> _\- Variable inspection when debugging has always worked fine for me._

Are you using version 3 or 4? In version 3 this _definitely_ didn't work, as
stated in the changelog for version 4 ( [http://scala-
ide.org/docs/changelog.html](http://scala-ide.org/docs/changelog.html), look
for M3 "Show variable values in hovers when in suspended debug mode". It
should be noted that for me, in version 3 selecting and watching a variable
doesn't work either). This seems to be fixed in version 4, which was
officially released on 2014-12-16.

> _\- Scala-IDE never gives a "full" spurious compilation error_

True, this seems to be mostly a presentation issue, albeit a very distracting
one. However, in my experience occasionally one of these errors will prevent
the application from launching from Eclipse (for debugging, for example),
which seems very odd.

In my experience, autocomplete sometimes stops working completely. Or maybe
I'm really impatient :)

~~~
lmm
> Are you using version 3 or 4? In version 3 this definitely didn't work, as
> stated in the changelog for version 4 ( [http://scala-
> ide.org/docs/changelog.html](http://scala-ide.org/docs/changelog.html), look
> for M3 "Show variable values in hovers when in suspended debug mode"

Oh, I didn't realize you meant hovers; I never use that (even in Java), I
always use the pane with the variables in.

> In my experience, autocomplete sometimes stops working completely.

I sometimes get the "autocompletions took longer than 2 seconds to complete"
warning, but after I dismiss it they are there.

------
heathermiller
Or, said another way, Scala now officially runs on both the JVM and in the
browser.

~~~
tootie
Am I correct in my inference that Scala in the browser cannot import Java
classes? Meaning this isn't some backdoor to a Java-to-JavaScript compiler?

~~~
sjrd
You are correct. Scala.js compiles _Scala_ code to JS, not bytecode. A number
of core Java classes have been ported to Scala.js so they can be used anyway,
though. (see [http://lihaoyi.github.io/hands-on-scala-
js/#JavaAPIs](http://lihaoyi.github.io/hands-on-scala-js/#JavaAPIs) for a
mostly exhaustive list so far)

------
Taig
The "Hello World" example yields a 3500 LOC js file. I expected a high count
but that still managed to shock me. Well, I'm still pretty excited about this
announcement and looking forward to give it a try.

~~~
frowaway001
The important thing is that it doesn't grow proportionally.

Adding a second line to your "Hello World" doesn't give you 7000LOC, just like
using jQuery in two places instead of one doesn't automatically double
jQuery's library size.

------
kybernetikos
> It’s mostly about the strong typing for me. Nothing revolutionary about that
> idea, but it’s just as true on the client as on the server: having the
> compiler type-check your code makes it much quicker to get complex,
> sophisticated systems up and running.

I used to believe that this was obviously true. Then I went from doing a lot
of programming in JS where even with a large codebase, I could _see_ the code
fail in seconds to programming in Scala where type errors would not always
appear in the editor, but you'd have to do a compile step that takes ages to
actually see them.

Now I'm much less sure about the benefits of typing. What is actually useful
is fast failure and short iteration cycles. Seeing the errors as you write is
the fastest failure there is, but if I have to run a 30 second build to see a
type error, that is much worse than dynamic types but seeing the error in less
than a second.

Its true that carefully thought about types can catch errors you might not see
immediately, but you can fix this to some extent with putting effort into
making sure your code fails fast, and adding unit tests and while this doesn't
give you proof-level guarantees, for most practical work, with discipline,
it's good enough (even if emotionally unsatisfying).

Maybe one day I'll find a system that lets me encode constraints into the type
system _and have it actually tell me about violations quickly_ , and I'll
happily leave dynamic land behind (for most things), but I've come to the
conclusion that arguing about type systems misses the point, and the point is
that failing fast is better than failing late. Within a single environment,
failing at application startup is better than failing at an arbitrary point in
the future. Failing at compile time is better than failing at startup. Failing
at edit time is better than failing at compile time. But if your compile time
is slower than my runtime, you're losing.

~~~
frowaway001
Error highlighting is usually instantaneous.

~~~
kybernetikos
Not my experience in scala. I've had a lot of places where in the Scala plugin
for intellij, it incorrectly highlights errors, or doesn't discover the error
until a full build.

------
drapper
More and more languages have that now (F#, Ceylon, Haxe,...), I wonder how
well it works in practice, especially in terms of:

\- libraries availability

\- code size and speed

\- debugging capabilities

\- ...and interoperability with JS (I recall that F# uses TypeScript
definition files, that's a nice approach)

Anyone has more experience with it?

~~~
john2x
Link to F#-to-JS compiler?

~~~
quarterto
[http://funscript.info/](http://funscript.info/)

------
mercurial
I'm curious to know the size of a scala.js hello world program.

~~~
jducoeur
As mentioned upthread, hello world isn't really representative. A more useful
metric is probably what I'm doing -- a large, complex single-page business app
with lots of specialized gadgetry.

Including the standard Scala.js prelude (100-200k), that currently clocks in
at a bit under a megabyte. That's quite reasonable for a program of its
complexity, and loads pretty fast. And once that is loaded and in the browser
cache, the UI is _lightning_ fast afterwards...

~~~
Cyph0n
Thanks for the perspective. It seems like a viable option for the frontend of
my planned product, which I hope to write in Scala + Play.

------
aaronmck
I can't wait for nice bindings to a JS plotting library (something on top of
D3). One of the big missing parts of Scala for analysis...

~~~
qiemem
Here you go:
[https://github.com/quantifind/wisp](https://github.com/quantifind/wisp)

------
cmstoken
Looks like I'm gonna have to ditch React and IO now. I think those are getting
outdated. Will be rewriting all apps in Scala.js.

~~~
ignoramous
With the JVM of the near future [0] running JavaScript natively, that could
change again. Long before you know it, you'd be running java-scala-clojure-
javascript code inside of the same jvm on the server, and on the client...

[0]
[http://www.oracle.com/technetwork/articles/java/jf14-nashorn...](http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html)

~~~
Gurkenmaster
It's already out in Java 8 but the parser can choke on large js files. I tried
loading some Ceylon code compiled to js into the webview but it froze. I think
it will have the same problem with Scala.js

------
therockhead
How much of Scala and its APIs can be used? For example can you use Scala
Actors in Scala.js?

------
nowxue
This is awesome, thanks to the scala.js team and community for the hard work.

------
joajoa
I know it's a shameless plug, but if you want to convert any Java bytecode
with less semantic differences than scala.js and full reflection support you
might want to give [https://www.defrac.com/](https://www.defrac.com/) a try.

~~~
adrusi
Not really the same thing, scalajs is supposedly has full compatibility with
Scala, but it doesn't try to go beyond that. Its embracing JavaScript as a
platform.

100% code reuse across all platforms is unachievable. What a lot of do today
is complete horseshit relative to the state of the art, but different
platforms have different ui conventions and following their rules can't be
abstracted away into some library, obeying these conventions requires some
intuition about human psychology.

By embracing the JavaScript platform, the scalajs folks are leaving the
playing field open as to how to deal with multiple platforms. Maybe we can
hook up scalajs to react and react native, there seems to be a bit of hype
around that.

------
wampler
Is Scala.js recommended for small apps? Say something like Hello World?

~~~
sjrd
It's not unrecommended, but it's definitely not where it shines most. It's
difficult to get below the 100 KB not gzipped size. Although if you use jQuery
in your JS hello world, you also gather up 33 KB just for jQuery, so it's
still the same order of magnitude.

------
kashif
oh god! it was fine as an experiment but...

------
725686
Stop the programming language proliferation madness!

