12 ms·

From first principles: Why I bet on Scala.js

106 points by lihaoyi 10y ago

grok2 10y ago
The author explains his reasoning for using Scala.js well and what he says makes me tempted to learn Scala as the "language-to-rule-them-all"!
lihaoyi 10y ago
I wrote this; ask me anything
- atemerev 10y ago
  Scala.js is magic under magic sauce with magical cherry on top of it. Thank you and everyone else involved! Compiling _entire Scala_ to JavaScript? Without runtime?! To the point of compatibility that Scalaz can be compiled, with all its horrors?!! Wow.
- bcherny 10y ago
  What do you think of using Dotty's effect system for frontend code?
  - lihaoyi 10y ago
    No clue, as far as I know (as an outsider) the effect system is still in the brainstorming phase with not much pinned down or concrete yet. On the other hand Dotty has a lot of very, very concrete benefits I would like. 2x faster compile times for my Scala code sure would be nice...
    - bcherny 10y ago
      That's fair. Personally, I'm excited to have another way to manage side effects on a platform that has so many of them.
- edko 10y ago
  Would you bet as much on Scala Native?
  - lihaoyi 10y ago
    I can't say, really. I have written a lot of Javascript/Coffee/Java/Scala/C#/F#/Python/PHP, and made a bunch of crappy websites, but I have never written any code in a language that compiles to assembly (500 lines of C in 20-50 line snippets for various classes probably doesn't count). While I consider myself "pretty experienced" at doing web-stuff, and thus knowing the pain-points and constraints and prior work, I have no clue at all what the world of C/C++ is like. Scala-Native is in that world, so someone who has a Scala + C/C++ background would have much better instincts than I would
- labrador 10y ago
  What do you think of Dart? I need to know this for reasons I can't go into.
  - lihaoyi 10y ago
    Never used it but it seems like a plausible project; it has Google's infinite $$$ backing it and smart people like Gilad Bracha on the team. They've built up quite a lot (language, tools, package-manager, IDE, ...) from scratch which is pretty impressive. As a language, it seems pleasant: somewhere around C#, a mix of JS and Java, less "powerful" (or less "crazy" depending on how you look at it) than Scala. I think I personally prefer Scala, but wouldn't complain too loudly if I had to use Dart/Dart instead of Javascript/PHP. On the other hand, even with Google's backing they seem to not have managed to aggregate as much of an ecosystem in the 4 years they've been available. In particular, server-side-Dart hasn't really taken off, and client-side dart doesn't seem to be that popular compared to say Coffeescript or Typescript or even Clojurescript. I think the advantage of Scala.js over dart is that we only need to build the JS side of things: there's already a pretty large server-side Scala ecosystem. There's already all the tooling and IDEs set up. There's already the community of people who already know Scala, and do not need to re-learn anything. Thus even though the Dart-JS ecosystem is probably not that much smaller than the Scala-JS ecosystem, I think Scala-JS is a lot more viable and sustainable (since it can piggy-back on all the Scala-JVM stuff) while Dart-JS and many other new-language communities have a tough struggle to gain enough critical-mass to be self-sustaining
    - labrador 10y ago
      I was full in for Dart but Scala.js has been one of those alternatives that seemed more viable. Thanks!
- apo 10y ago
  Amazing work - thanks for putting it out there. In your live coding presentation, you mentioned that the output from compiling scala to js is several files. I'm interested in generating one file that exposed JavaScript functions that can be easily called from a js runtime. In other words, I'd like to write a JavaScript library in Scala - not a full-blown application. What are some good resources showing how to do this?
  - lihaoyi 10y ago
    The live coding presentation is two years out of date; Scala.js now compiles to a single JS blob Everything function marked with @JSExport will be exposed to Javascript. There's no concrete difference between an application with one `@JSExport def main` method that you call to initialize it, and a library with multiple `@JSExport`ed methods. It all works the same way: the `@JSExport`ed functions are exposed, and people can call them. This repo shows how to make a NPM library using Scala.js - https://github.com/rockymadden/scala-node/ https://github.com/rockymadden/scala-node/ If you want to learn how to use `@JSExport` properly, the [core documentation](http://www.scala-js.org/tutorial/basic/ http://www.scala-js.org/tutorial/basic/) and [Hands-on Scala.js](http://www.lihaoyi.com/hands-on-scala-js/ http://www.lihaoyi.com/hands-on-scala-js/) are great.
- saosebastiao 10y ago
  No questions, just praise. I love your scala work, and would love to take my company far enough to be able to approach you to work full time writing scala.
  - difftest 10y ago
    Sincere praise!
- nilknarf 10y ago
  Great post! Just curious, why didn't you include emscripten (C/C++) in your comparisons?
- curious2learn 10y ago
  Which resources (books/tutorials) do you recommend for learning Scala.js for someone who does not know Scala or Java or any JVM language, but knows a decent amount of Python, Julia, Go, Javascript, Dart etc. I should add that I am not interested in JVM (at least, now). I want to know what are good resources if one intends to use Scala only for the JS side of things.
  - merb 10y ago
    Actually you should start out with https://www.amazon.de/Programming-Scala-Martin-Odersky/dp/0981531687 https://www.amazon.de/Programming-Scala-Martin-Odersky/dp/09... Even when it's targeted at the JVM. Scala.JS usage isn't that hard after you read half of the book.
- oever 10y ago
  Closure Compiler uses type annotations on variables and functions that give information on null and undefined. These annotations look like {?Object|undefined} (Object may be null or undefined) and {!Object} (object is guaranteed to not be null). In Java, NullPointerExceptions is huge problem. IDEs have plugins to check for this error, but there is no standard solution. Does Scala help in avoiding NullPointerExceptions? Do function signatures specify if a value may be null?
  - gmartres 10y ago
    Scala does not have non-nullable types currently (but that might happen in the future), in practice this is not a problem simply because using null is seen as a code smell and basically no Scala library API expects parameters to be null or return null, optional values are usually represented with the standard library class Option: http://www.scala-lang.org/api/2.11.8/#scala.Option http://www.scala-lang.org/api/2.11.8/#scala.Option
    - oever 10y ago
      One of the main points of the blog is that Scala.js integrates well with the JavaScript apis and those apis are full of null. A typical loop in the DOM looks like this: var node = element.firstChild; while (node) { // do something node = node.nextSibling; } Perhaps those interfaces use the Option class?
      - oever 10y ago
        I wrote a small test function. It appears that Scala.js has no default protections against null values from the browser DOM. def printNodes(targetNode: dom.Node): Unit = { var c = targetNode.firstChild while (c != null) { if (c.nodeValue != null) { println(c.nodeValue) } c = c.nextSibling } } The return value from firstChild and nextSibling can be null.
    - deleted 10y ago
      [deleted]
k__ 10y ago
3 things I don't like about Scala: 1. It's based on the Java platform. 2. It's excessive use of operator overloading. 3. Mad implicit conversions all over the place. (yes, I exaggrated a bit ;))
- atemerev 10y ago
  1. Java platform is excellent. Also, Scala.js is now Scala for JS platform, and scala-native is coming soon. 2. Have you seen languages like APL or J? Now that's operator overloading. '+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention. 3. In modern Scala, implicit _conversions_ are discouraged unless you know what are you doing. Besides, Scala IDEs are excellent in showing applied implicits anywhere in the code (you do use an IDE, right?)
  - stcredzero 10y ago
    '+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention. As always: cost/benefit! There is a price for the "context switch" out of one set of conventions into another. Sometimes, the benefit far outweighs the cost. For example, there are certain environments where you can jump out of the programming language and simply write a method in SQL. Not embed SQL in code in a string, you can simply write prepared statements as a method. For certain applications, this can be beneficial. The problem I have with operator overloading, is that it allows the average programmer to switch conventions using some of the the most commonly used conventions with barely a sign that something special is going on. It's too easy to use. It's too easy to miss. It's too easy to get a moment of confusion from it when debugging. (What, I'm in a method? Oh, operator overloading!) And it doesn't produce a great benefit all that often. Yet it has a "nifty" factor that encourages in experienced programmers to make use of it -- precisely the people who probably shouldn't be making that decision.
  - k__ 10y ago
    Thanks for the reply :) 1. Java platform is overengineered, everytime I had to set up stuff like Maven, I missed the easy JS days. 2. True story, I can infer what a '+' between two strings means, but what about all the non-intuitive operators? (List concats etc. pp.) 3. Not a big fan of IDEs. More of an editor dev, but good to know ICs are now discuraged. I got myself "Programming in Scala" back in the days and it seemed to me, that the Scala makers thought of IC as Scalas killer feature :D
s_m 10y ago
Great article. I'm not a particularly sophisticated Scala user but I love using Scala.js for all the reasons described in this piece. Thanks for all your work on it!
weego 10y ago
I've backed the current iteration of my career on Scala and like the idea and some of the practicalities of Scalajs but it is destined to be limited to fun projects. The unavoidable problem is by committing to Scalajs you are accepting that you can no longer go out and get one of any number of JavaScript contractors or staffers to come on board and develop / maintain you client code and have to always have a Scala developer for that job as well which is a magnitude of time and expense different. The underlying notion of Scala to X ie Scala Native has lots of potential but Scalajs is more of a segue.
- JohnnyConatus 10y ago
  Seconded. I love Scala but when I hire for Scala devs there are so few that I just hire the smartest developer I can find with FP experience and their first task is learning Scala. If I was starting something now I'd be tempted to use TypeScript if I wanted one language on the front-end and the back-end.
harveywi 10y ago
Scala-js is fantastic for all of the reasons mentioned in the article. It is one of those tools that has become indispensable when I write web applications. Here is a web app that I built using scala-js: http://experimental.worldcat.org/vandrmapping http://experimental.worldcat.org/vandrmapping
virtualwhys 10y ago
Article is a total tour de force. The OP has contributed so much to the Scala community; somehow he's a Python + Coffeescript developer by day, and an absurdly prolific Scala library author in the evenings. As for Scala.js, representing browser interactions in types is such a relief, and to have the entire Scala language available is almost too good to be true: client-server interop is seamless. Really the only negative for me is the Scala collections library. Of the @100KB Hello World[1] generated blob half of that is Scala collections. There's a small initial "tax" to pay basically, and thereafter size increase is on par with normal javascript. [1] not totally true, vanilla Hello World is more like 40KB, but once you define a Scala collection then generated blob doubles in size.
eggy 10y ago
Very nice article. I am itching to play around with Scala.js because of it. I had chosen Purescript over Elm, since I have read about Elm being constricting once you move outside of most of the examples use cases.
hongboz 10y ago
For people who want to do typed functional programming on JS platform, there is another candidate: BuckleScript for OCaml: https://bloomberg.github.io/bucklescript/js-demo/ https://bloomberg.github.io/bucklescript/js-demo/ The compiler is compiled into JS and native code. It generates highly readable JS code and easier FFI. It compiles super fast (generally 10~100 faster than Scala) and generates optimized code.
- querulous 10y ago
  there's also elm and purescript, both of which are haskell likes
  - nv-vn 10y ago
    As well as GHC JS (not that I'd recommend it over Purescript)
    - premium-concern 10y ago
      The huge difference is that Scala.js is production-ready, the other ones mentioned aren't.
      - tel 10y ago
        Purescript is pretty production ready. It's in use in production in a number of places.
      - willtim 10y ago
        By what measure is Scala.js more production ready than ghcjs?
        tel 10y ago
        I feel like you've not seriously used each of them. Ghcjs is very interesting, but also very, very early. The ecosystem is tiny, the compiler produces huge and slow builds, the interop is tricky, the semantics imperfect. It may be a very long time before any of those are resolved, too! Compiling a lazy language to Javascript is no simple trick. Luite deserves all the praise in the world for getting it this far... but there's just a long way to go. So, in the terms of this article, Ghcjs might be around the same place Scala.js was 2 years ago. In the mean time, Scala.js has taken off in a lot of ways. It's yet to be seen what will happen with Ghcjs.
asciihacker 10y ago
The livecoding with ScalaJS was especially impressive: http://www.lihaoyi.com/post/TalksIveGiven.html#live-coding-scalajs http://www.lihaoyi.com/post/TalksIveGiven.html#live-coding-s...
CuriouslyC 10y ago
Scala is a cool language, but I can't help feeling that Javascript has a very strong culture around it that pretty much dooms adoption of things that don't feel "Javascript-y". I think the strong commitment to being a Javascript superset is the reason Typescript is blowing up the way it is.
- smrtinsert 10y ago
  absolutely agree. they nailed it by repurposing any js dev as a potential ts user. part of the reason ill be pushing ts soon at my current position.
kevindeasis 10y ago
What's a good way to learn how to use other languages in the browser asides from javascript?
- raquo 10y ago
  For Scala.js there are a lot of resources, e.g. http://www.lihaoyi.com/hands-on-scala-js/ http://www.lihaoyi.com/hands-on-scala-js/ is a good start.
  - kevindeasis 10y ago
    How does scala get embedded in the browser? I can't seem to find it on that document? I know you can use asm.js but it looks like they're not using asm.js
    - whateveracct 10y ago
      What do you mean? It gets compiled to vanilla JS. You can use sourcemaps to link to your original source file for debugging as well.
      - kevindeasis 10y ago
        I was looking for this: >It gets compiled to vanilla JS thanks
saskurambo 10y ago
Also haxe have nice features like scala.js bu have a c like syntax conservative and is more practical. Big interaction with externs js with external types definition, dynamics and untyped blocks. And can interact with npm, webpack, closure and browserify. Js code generated is really small
stijlist 10y ago
It's a little strange that ClojureScript is omitted from the sections where it compares favorably to Scala.js, e.g.: > If you look at other compile-to-JS languages like: > - Google Web Toolkit which lets you compile Java to Javascript, > - The Opal Ruby Compiler for Ruby > - Brython, PyJS, Skulpt, Transcrypt or RapydScript for Python > - Various flavors of C#-to-Javascript (Salterelle, Bridge.Net, JSIL) > - Or Haskell-to-Javascript compilers (Haste, Faye) > You'll notice one thing in common: none of them have a standard way of writing code that runs on both their "original" runtime (JVM, MRI, CPython, CLI, ...) and on Javascript. And the reason why is straightforward: none of them are compatible enough, complete enough to really let you write "full" Java/Ruby/Python/C#/etc.. ClojureScript is mentioned in the article, but only for this specious comparison: > Clunky Interop > Many other languages are not as fortunate. For example, here's how you create an element in ClojureScript, compared with Javascript (let [paragraph (.createElement js/document "p")] (set! (. paragraph -innerHTML) "Bold!")) var paragraph = document.createElement("p") paragraph.innerHTML = "It works!" > Now, the conversion between these two snippets is mechanical, so it's not something you need a PhD to perform. Nevertheless, it is clear that using Javascript APIs in ClojureScript, while looking like ClojureScript, looks almost nothing like the Javascript it represents. > This mapping is something that everyone who wishes to learn Clojurescript will have to internalize. This seems misinformed at best - both Clojure and ClojureScript have interop as a first-class concern, and interop forms are exactly the same between them. I appreciate the work that Li's done, but I'm disappointed by what seems like a rather disingenuous omission of the only other language which fulfills Li's criteria. Interop, IDE support (IntelliJ), parent language compatibility, static optimization (judging by the payload size numbers, ClojureScript utilizes dead-code elimination more effectively than Scala.js), performance (ClojureScript immutable vectors are faster to build than JavaScript arrays, far from the 1-2x Scala.js slowdown cited in the article!) - there is (and has been - since 2011) a compile-to-JavaScript language that is in the same league as Scala.js, and arguably eclipses it on many dimensions. A language-agnostic comparison can't reasonably leave out ClojureScript.
- tel 10y ago
 Except for: types. That's a big deal about what the author liked about Scala.js.
lihaoyi 10y ago
For all the people asking "Why didn't I talk about X"... The real reason is that this 24-page heavily-researched blog post is already too damn long lol
dk8996 10y ago
This is such a cool tool, being a Scala developer and not really loving writing JavaScript. The only thing is that creating binding for JavaScript lib sounds like a bit of a pain.
cromwellian 10y ago
The comments on jsinterop with respect to GWT are stale, GWT has a rich non-JSNI based JsInterop system now, as well as a generator that can read Closure and Typescript files and produce typed Java interfaces and classes for calling external JS. It even converts Java8 lambdas directly into JS functions and the reverse. Also, the design restrictions to ban runtime reflection in GWT are a codesize decision. Allowing reflective calls basically inhibits optimization and forces the retention of tons of metadata. The Deferred Binding mechanism is essentially dependency injection before DI and annotation processing existed, because GWT hails from 2007. We now recommend using Dagger2 for DI, and Annotation Processors for code generators, so that the system of compile time reflective calls is all part of the standard tool chain. In the era of mobile browsers, I think 100k is a bridge too far for a hello world, especially in the developing world, so restrictions to the JRE runtime which allow much greater code pruning are a necessary evil. It hasn't really prevented an enormous amount of code sharing. For example, Google Inbox shares 70% of its Java code between Web, Android, and iOS (via J2Objc)

106 points by lihaoyi 10y ago

grok2 10y ago

The author explains his reasoning for using Scala.js well and what he says makes me tempted to learn Scala as the "language-to-rule-them-all"!

lihaoyi 10y ago

I wrote this; ask me anything

atemerev 10y ago
Scala.js is magic under magic sauce with magical cherry on top of it. Thank you and everyone else involved! Compiling _entire Scala_ to JavaScript? Without runtime?! To the point of compatibility that Scalaz can be compiled, with all its horrors?!! Wow.
bcherny 10y ago
What do you think of using Dotty's effect system for frontend code?
- lihaoyi 10y ago
  No clue, as far as I know (as an outsider) the effect system is still in the brainstorming phase with not much pinned down or concrete yet. On the other hand Dotty has a lot of very, very concrete benefits I would like. 2x faster compile times for my Scala code sure would be nice...
  - bcherny 10y ago
    That's fair. Personally, I'm excited to have another way to manage side effects on a platform that has so many of them.
edko 10y ago
Would you bet as much on Scala Native?
- lihaoyi 10y ago
  I can't say, really. I have written a lot of Javascript/Coffee/Java/Scala/C#/F#/Python/PHP, and made a bunch of crappy websites, but I have never written any code in a language that compiles to assembly (500 lines of C in 20-50 line snippets for various classes probably doesn't count). While I consider myself "pretty experienced" at doing web-stuff, and thus knowing the pain-points and constraints and prior work, I have no clue at all what the world of C/C++ is like. Scala-Native is in that world, so someone who has a Scala + C/C++ background would have much better instincts than I would
labrador 10y ago
What do you think of Dart? I need to know this for reasons I can't go into.
- lihaoyi 10y ago
  Never used it but it seems like a plausible project; it has Google's infinite $$$ backing it and smart people like Gilad Bracha on the team. They've built up quite a lot (language, tools, package-manager, IDE, ...) from scratch which is pretty impressive. As a language, it seems pleasant: somewhere around C#, a mix of JS and Java, less "powerful" (or less "crazy" depending on how you look at it) than Scala. I think I personally prefer Scala, but wouldn't complain too loudly if I had to use Dart/Dart instead of Javascript/PHP. On the other hand, even with Google's backing they seem to not have managed to aggregate as much of an ecosystem in the 4 years they've been available. In particular, server-side-Dart hasn't really taken off, and client-side dart doesn't seem to be that popular compared to say Coffeescript or Typescript or even Clojurescript. I think the advantage of Scala.js over dart is that we only need to build the JS side of things: there's already a pretty large server-side Scala ecosystem. There's already all the tooling and IDEs set up. There's already the community of people who already know Scala, and do not need to re-learn anything. Thus even though the Dart-JS ecosystem is probably not that much smaller than the Scala-JS ecosystem, I think Scala-JS is a lot more viable and sustainable (since it can piggy-back on all the Scala-JVM stuff) while Dart-JS and many other new-language communities have a tough struggle to gain enough critical-mass to be self-sustaining
  - labrador 10y ago
    I was full in for Dart but Scala.js has been one of those alternatives that seemed more viable. Thanks!
apo 10y ago
Amazing work - thanks for putting it out there. In your live coding presentation, you mentioned that the output from compiling scala to js is several files. I'm interested in generating one file that exposed JavaScript functions that can be easily called from a js runtime. In other words, I'd like to write a JavaScript library in Scala - not a full-blown application. What are some good resources showing how to do this?
- lihaoyi 10y ago
  The live coding presentation is two years out of date; Scala.js now compiles to a single JS blob Everything function marked with @JSExport will be exposed to Javascript. There's no concrete difference between an application with one `@JSExport def main` method that you call to initialize it, and a library with multiple `@JSExport`ed methods. It all works the same way: the `@JSExport`ed functions are exposed, and people can call them. This repo shows how to make a NPM library using Scala.js - https://github.com/rockymadden/scala-node/ https://github.com/rockymadden/scala-node/ If you want to learn how to use `@JSExport` properly, the [core documentation](http://www.scala-js.org/tutorial/basic/ http://www.scala-js.org/tutorial/basic/) and [Hands-on Scala.js](http://www.lihaoyi.com/hands-on-scala-js/ http://www.lihaoyi.com/hands-on-scala-js/) are great.
saosebastiao 10y ago
No questions, just praise. I love your scala work, and would love to take my company far enough to be able to approach you to work full time writing scala.
- difftest 10y ago
  Sincere praise!
nilknarf 10y ago
Great post! Just curious, why didn't you include emscripten (C/C++) in your comparisons?
curious2learn 10y ago
Which resources (books/tutorials) do you recommend for learning Scala.js for someone who does not know Scala or Java or any JVM language, but knows a decent amount of Python, Julia, Go, Javascript, Dart etc. I should add that I am not interested in JVM (at least, now). I want to know what are good resources if one intends to use Scala only for the JS side of things.
- merb 10y ago
  Actually you should start out with https://www.amazon.de/Programming-Scala-Martin-Odersky/dp/0981531687 https://www.amazon.de/Programming-Scala-Martin-Odersky/dp/09... Even when it's targeted at the JVM. Scala.JS usage isn't that hard after you read half of the book.
oever 10y ago
Closure Compiler uses type annotations on variables and functions that give information on null and undefined. These annotations look like {?Object|undefined} (Object may be null or undefined) and {!Object} (object is guaranteed to not be null). In Java, NullPointerExceptions is huge problem. IDEs have plugins to check for this error, but there is no standard solution. Does Scala help in avoiding NullPointerExceptions? Do function signatures specify if a value may be null?
- gmartres 10y ago
  Scala does not have non-nullable types currently (but that might happen in the future), in practice this is not a problem simply because using null is seen as a code smell and basically no Scala library API expects parameters to be null or return null, optional values are usually represented with the standard library class Option: http://www.scala-lang.org/api/2.11.8/#scala.Option http://www.scala-lang.org/api/2.11.8/#scala.Option
  - oever 10y ago
    One of the main points of the blog is that Scala.js integrates well with the JavaScript apis and those apis are full of null. A typical loop in the DOM looks like this: var node = element.firstChild; while (node) { // do something node = node.nextSibling; } Perhaps those interfaces use the Option class?
    - oever 10y ago
      I wrote a small test function. It appears that Scala.js has no default protections against null values from the browser DOM. def printNodes(targetNode: dom.Node): Unit = { var c = targetNode.firstChild while (c != null) { if (c.nodeValue != null) { println(c.nodeValue) } c = c.nextSibling } } The return value from firstChild and nextSibling can be null.
  - deleted 10y ago
    [deleted]

k__ 10y ago

3 things I don't like about Scala: 1. It's based on the Java platform. 2. It's excessive use of operator overloading. 3. Mad implicit conversions all over the place. (yes, I exaggrated a bit ;))

atemerev 10y ago
1. Java platform is excellent. Also, Scala.js is now Scala for JS platform, and scala-native is coming soon. 2. Have you seen languages like APL or J? Now that's operator overloading. '+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention. 3. In modern Scala, implicit _conversions_ are discouraged unless you know what are you doing. Besides, Scala IDEs are excellent in showing applied implicits anywhere in the code (you do use an IDE, right?)
- stcredzero 10y ago
  '+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention. As always: cost/benefit! There is a price for the "context switch" out of one set of conventions into another. Sometimes, the benefit far outweighs the cost. For example, there are certain environments where you can jump out of the programming language and simply write a method in SQL. Not embed SQL in code in a string, you can simply write prepared statements as a method. For certain applications, this can be beneficial. The problem I have with operator overloading, is that it allows the average programmer to switch conventions using some of the the most commonly used conventions with barely a sign that something special is going on. It's too easy to use. It's too easy to miss. It's too easy to get a moment of confusion from it when debugging. (What, I'm in a method? Oh, operator overloading!) And it doesn't produce a great benefit all that often. Yet it has a "nifty" factor that encourages in experienced programmers to make use of it -- precisely the people who probably shouldn't be making that decision.
- k__ 10y ago
  Thanks for the reply :) 1. Java platform is overengineered, everytime I had to set up stuff like Maven, I missed the easy JS days. 2. True story, I can infer what a '+' between two strings means, but what about all the non-intuitive operators? (List concats etc. pp.) 3. Not a big fan of IDEs. More of an editor dev, but good to know ICs are now discuraged. I got myself "Programming in Scala" back in the days and it seemed to me, that the Scala makers thought of IC as Scalas killer feature :D

s_m 10y ago

Great article. I'm not a particularly sophisticated Scala user but I love using Scala.js for all the reasons described in this piece. Thanks for all your work on it!

weego 10y ago

I've backed the current iteration of my career on Scala and like the idea and some of the practicalities of Scalajs but it is destined to be limited to fun projects. The unavoidable problem is by committing to Scalajs you are accepting that you can no longer go out and get one of any number of JavaScript contractors or staffers to come on board and develop / maintain you client code and have to always have a Scala developer for that job as well which is a magnitude of time and expense different. The underlying notion of Scala to X ie Scala Native has lots of potential but Scalajs is more of a segue.

JohnnyConatus 10y ago
Seconded. I love Scala but when I hire for Scala devs there are so few that I just hire the smartest developer I can find with FP experience and their first task is learning Scala. If I was starting something now I'd be tempted to use TypeScript if I wanted one language on the front-end and the back-end.

harveywi 10y ago

Scala-js is fantastic for all of the reasons mentioned in the article. It is one of those tools that has become indispensable when I write web applications. Here is a web app that I built using scala-js: http://experimental.worldcat.org/vandrmapping http://experimental.worldcat.org/vandrmapping

virtualwhys 10y ago

Article is a total tour de force. The OP has contributed so much to the Scala community; somehow he's a Python + Coffeescript developer by day, and an absurdly prolific Scala library author in the evenings. As for Scala.js, representing browser interactions in types is such a relief, and to have the entire Scala language available is almost too good to be true: client-server interop is seamless. Really the only negative for me is the Scala collections library. Of the @100KB Hello World[1] generated blob half of that is Scala collections. There's a small initial "tax" to pay basically, and thereafter size increase is on par with normal javascript. [1] not totally true, vanilla Hello World is more like 40KB, but once you define a Scala collection then generated blob doubles in size.

eggy 10y ago

Very nice article. I am itching to play around with Scala.js because of it. I had chosen Purescript over Elm, since I have read about Elm being constricting once you move outside of most of the examples use cases.

hongboz 10y ago

For people who want to do typed functional programming on JS platform, there is another candidate: BuckleScript for OCaml: https://bloomberg.github.io/bucklescript/js-demo/ https://bloomberg.github.io/bucklescript/js-demo/ The compiler is compiled into JS and native code. It generates highly readable JS code and easier FFI. It compiles super fast (generally 10~100 faster than Scala) and generates optimized code.

querulous 10y ago
there's also elm and purescript, both of which are haskell likes
- nv-vn 10y ago
  As well as GHC JS (not that I'd recommend it over Purescript)
  - premium-concern 10y ago
    The huge difference is that Scala.js is production-ready, the other ones mentioned aren't.
    - tel 10y ago
      Purescript is pretty production ready. It's in use in production in a number of places.
    - willtim 10y ago
      By what measure is Scala.js more production ready than ghcjs?
      - tel 10y ago
        I feel like you've not seriously used each of them. Ghcjs is very interesting, but also very, very early. The ecosystem is tiny, the compiler produces huge and slow builds, the interop is tricky, the semantics imperfect. It may be a very long time before any of those are resolved, too! Compiling a lazy language to Javascript is no simple trick. Luite deserves all the praise in the world for getting it this far... but there's just a long way to go. So, in the terms of this article, Ghcjs might be around the same place Scala.js was 2 years ago. In the mean time, Scala.js has taken off in a lot of ways. It's yet to be seen what will happen with Ghcjs.

asciihacker 10y ago

The livecoding with ScalaJS was especially impressive: http://www.lihaoyi.com/post/TalksIveGiven.html#live-coding-scalajs http://www.lihaoyi.com/post/TalksIveGiven.html#live-coding-s...

CuriouslyC 10y ago

Scala is a cool language, but I can't help feeling that Javascript has a very strong culture around it that pretty much dooms adoption of things that don't feel "Javascript-y". I think the strong commitment to being a Javascript superset is the reason Typescript is blowing up the way it is.

smrtinsert 10y ago
absolutely agree. they nailed it by repurposing any js dev as a potential ts user. part of the reason ill be pushing ts soon at my current position.

kevindeasis 10y ago

What's a good way to learn how to use other languages in the browser asides from javascript?

raquo 10y ago
For Scala.js there are a lot of resources, e.g. http://www.lihaoyi.com/hands-on-scala-js/ http://www.lihaoyi.com/hands-on-scala-js/ is a good start.
- kevindeasis 10y ago
  How does scala get embedded in the browser? I can't seem to find it on that document? I know you can use asm.js but it looks like they're not using asm.js
  - whateveracct 10y ago
    What do you mean? It gets compiled to vanilla JS. You can use sourcemaps to link to your original source file for debugging as well.
    - kevindeasis 10y ago
      I was looking for this: >It gets compiled to vanilla JS thanks

saskurambo 10y ago

Also haxe have nice features like scala.js bu have a c like syntax conservative and is more practical. Big interaction with externs js with external types definition, dynamics and untyped blocks. And can interact with npm, webpack, closure and browserify. Js code generated is really small

stijlist 10y ago

It's a little strange that ClojureScript is omitted from the sections where it compares favorably to Scala.js, e.g.: > If you look at other compile-to-JS languages like: > - Google Web Toolkit which lets you compile Java to Javascript, > - The Opal Ruby Compiler for Ruby > - Brython, PyJS, Skulpt, Transcrypt or RapydScript for Python > - Various flavors of C#-to-Javascript (Salterelle, Bridge.Net, JSIL) > - Or Haskell-to-Javascript compilers (Haste, Faye) > You'll notice one thing in common: none of them have a standard way of writing code that runs on both their "original" runtime (JVM, MRI, CPython, CLI, ...) and on Javascript. And the reason why is straightforward: none of them are compatible enough, complete enough to really let you write "full" Java/Ruby/Python/C#/etc.. ClojureScript is mentioned in the article, but only for this specious comparison: > Clunky Interop > Many other languages are not as fortunate. For example, here's how you create an element in ClojureScript, compared with Javascript (let [paragraph (.createElement js/document "p")] (set! (. paragraph -innerHTML) "Bold!")) var paragraph = document.createElement("p") paragraph.innerHTML = "It works!" > Now, the conversion between these two snippets is mechanical, so it's not something you need a PhD to perform. Nevertheless, it is clear that using Javascript APIs in ClojureScript, while looking like ClojureScript, looks almost nothing like the Javascript it represents. > This mapping is something that everyone who wishes to learn Clojurescript will have to internalize. This seems misinformed at best - both Clojure and ClojureScript have interop as a first-class concern, and interop forms are exactly the same between them. I appreciate the work that Li's done, but I'm disappointed by what seems like a rather disingenuous omission of the only other language which fulfills Li's criteria. Interop, IDE support (IntelliJ), parent language compatibility, static optimization (judging by the payload size numbers, ClojureScript utilizes dead-code elimination more effectively than Scala.js), performance (ClojureScript immutable vectors are faster to build than JavaScript arrays, far from the 1-2x Scala.js slowdown cited in the article!) - there is (and has been - since 2011) a compile-to-JavaScript language that is in the same league as Scala.js, and arguably eclipses it on many dimensions. A language-agnostic comparison can't reasonably leave out ClojureScript.

tel 10y ago
Except for: types. That's a big deal about what the author liked about Scala.js.

lihaoyi 10y ago

For all the people asking "Why didn't I talk about X"... The real reason is that this 24-page heavily-researched blog post is already too damn long lol

dk8996 10y ago

This is such a cool tool, being a Scala developer and not really loving writing JavaScript. The only thing is that creating binding for JavaScript lib sounds like a bit of a pain.

cromwellian 10y ago

The comments on jsinterop with respect to GWT are stale, GWT has a rich non-JSNI based JsInterop system now, as well as a generator that can read Closure and Typescript files and produce typed Java interfaces and classes for calling external JS. It even converts Java8 lambdas directly into JS functions and the reverse. Also, the design restrictions to ban runtime reflection in GWT are a codesize decision. Allowing reflective calls basically inhibits optimization and forces the retention of tons of metadata. The Deferred Binding mechanism is essentially dependency injection before DI and annotation processing existed, because GWT hails from 2007. We now recommend using Dagger2 for DI, and Annotation Processors for code generators, so that the system of compile time reflective calls is all part of the standard tool chain. In the era of mobile browsers, I think 100k is a bridge too far for a hello world, especially in the developing world, so restrictions to the JRE runtime which allow much greater code pruning are a necessary evil. It hasn't really prevented an enormous amount of code sharing. For example, Google Inbox shares 70% of its Java code between Web, Android, and iOS (via J2Objc)