8 ms·

Scala.js 1.0.0-RC1

100 points by sjrd 7y ago

utkarshkukreti 7y ago
Anyone know what's the minimum size of the compiled JS now? Is there any way Scala.js can produce code as compact as BuckleScript/ReasonML in the future? I like Scala's syntax but the last time I tried Scala.js, the output was several hundred kb for something slightly more than a Hello World -- it used some List and Seq functions. I'd bet the comparable ReasonML output would likely be in tens of kb (including List and Array functions from Belt).
- googleisevil6 7y ago
  As I noted in another comment, the output is close to unreadable. But you have source maps... (I don't know if Bucklescript has/needs them)
- sjrd 7y ago
  The bare minimum for a hello world is 6 KB (before gzip). But of course as soon as you start using Scala collections, it's getting bigger. The minimum for a realistic application is 90 KB (before gzip). That's less than your typical JavaScript framework, so for any realistic application it shouldn't be a concern.
  - googleisevil6 7y ago
    For refernce- Jquery unzipped is similar size- 87K and while it adds much more functionality, Scala collections easily trump jquery's in usability and power. SJRD, Would you also add a bit more info about how this size increases? I haven't cared much but it seems from your comments that the slope should be much less once you reach 90kb.
    - sjrd 7y ago
      Yes once you're at 90 KB the slope will be much less. It will simply grow with the actual code of your app.
      - ramnivasl 7y ago
        Indeed, once you end up pulling in most common Scala classes (collections, futures, etc.), adding new functionality to your app increases app size by very little. Our app has ~600KB gzipped js (attributable to Scala.js compiled code) + ~200KB of React and other libraries. The overall size has barely moved beyond +-100KB in last few years despite adding new functionality all the time. Once Scala.js supports lazy loading of modules (hopefully soon after 1.0), the size issue will have significantly less practical impact.
    - fnordsensei 7y ago
      ClojureScript ends up somewhere around the same size. Maybe it's some magic number that a full-featured environment converges to. Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll also reach for the Closure Library for a lot of stuff where one might reach for JQuery or equivalent otherwise. The stuff in there is of course optimized for Closure Compiler, and slims down quite well.
      - sjrd 7y ago
        There is a significant difference between CLJS and Scala.js regarding their use of GCC (Google Closure Compiler). In ClojureScript, GCC is a user-visible feature of the toolchain, so users are encouraged to use GCC-compatible libraries and the Closure Library in particular. In Scala.js, GCC is really an implementation detail of the toolchain, and its constraints are completely abstracted away from the user. This does not really encourage using GCC-oriented libraries like the Closure Library. The two approaches each have pros and cons: * CLJS' approach allows tree shaking across the CLJS code and the GCC-compatible libraries that are used. However, it makes it more difficult to use libraries that do not comply with GCC's Advanced Optimizations requirements, as one needs to declare the proper `externs` files. * Scala.js' approach means that you can use any JavaScript library out of the box, whether or not it was designed for GCC, and without having to declare any `externs` file. However, it means that GCC's tree shaking will not be applied across the Scala.js code and the JS libraries. It only applies to Scala.js' own code.
        fnordsensei 7y ago
        I think the externs file maneuver might be outdated. Admittedly, I'm using shadow-cljs as my go-to compiler (so I'm not sure what the state of vanilla is), but all I do is yarn add <package>, and then require it in the file where I want to use it, and interact with it as if it were any other library. Though it is true of shadow-cljs as well that it doesn't try to tree-shake external (non-CLJS/Closure) libs by default, though it will do it for project code and Clojure libraries.
- Mahnoor_Aslam 7y ago
  Why these rules are violated?
  - deleted 7y ago
    [deleted]
- LeanderK 7y ago
  While i understand your concern, i wouldn't use scala.js in a context where several hundred kb are an issue. I've tried it and it works great, but i think it only pays of if you implemented a complicated web-app with complicated server-side code, e.g. if you replace a desktop-application to manage some system with a web-based one. Something where showing a loading-screen on the first visit is totally reasonable.
- bad_user 7y ago
  Scala.js is being fed to the Google Closure compiler [1] for minification via tree-shaking, after applying optimizations on its own. Output can be unreadable, but debugging works via source maps. It's not perfect, but you should not get hundreds of KB for a Hello World. And indeed, the code cannot be as minimal as hand crafted code either. Note that this is often a false problem, because people often use a lot of JavaScript libraries without any tree-shaking in their build process, so if you do care about tens of KB, then you don't use JQuery, React, etc. A valid use case indeed, I've been there, but not for your typical app. [1] https://developers.google.com/closure/ https://developers.google.com/closure/
- virtualwhys 7y ago
  > the output was several hundred kb for something slightly more than a Hello World -- it used some List and Seq functions That's just nonsense, maybe 6 or 7 years ago that could have been the case. There's an approximate 100KB "tax" for pulling in Scala collections (i.e. as soon as you depend on List, Map, Seq, etc.), which is the price to pay for being able to use the power of Scala in the browser. > Is there any way Scala.js can produce code as compact as BuckleScript/ReasonML in the future? No, iirc, not without a redeisgn. There's a longstanding issue wrt lazy loading, which is slated to be worked on at some point post-1.0 -- I'd say that's probably the biggest missing feature, the ability to break out one's app into dynamic chunks, so for example a lightweight frontend/public facing area of an app can be isolated from the backend where all the heavy lifting is done. Perhaps with Dotty (AKA Scala 3) next year there will be further reductions in Scala.js code size, but no, nothing like BuckleScript.
The_rationalist 7y ago
Can this call js libraries and the DOM trivially like typescript? Or does it leverage ffi?
- sjrd 7y ago
  It's exactly like TypeScript. You write type definitions or you find them online, like in TypeScript, then you can call any JavaScript API using the relevant types. Full relevant docs at https://www.scala-js.org/doc/interoperability/ https://www.scala-js.org/doc/interoperability/
  - manx 7y ago
    Many TypeScript type definitions are also automatically converted to ScalaJS: https://github.com/oyvindberg/ScalablyTyped https://github.com/oyvindberg/ScalablyTyped
- jackcviers3 7y ago
  You can call js directly using dynamic. From the docs[1]: val document = js.Dynamic.global.document val playground = document.getElementById("playground") val newP = document.createElement("p") newP.innerHTML = "Hello world! <i>-- DOM</i>" playground.appendChild(newP) 1. http://ochrons.github.io/sjs2/doc/interoperability/calling_js.html#:~:targetText=Scala.js%20lets%20you%20call,is%20of%20type%20js.Dynamic%20 http://ochrons.github.io/sjs2/doc/interoperability/calling_j....
googleisevil6 7y ago
As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Scala.js interop with JS is very seamless. Do check out ScalablyTyped repo on Github, a Scala.js analogue of DefinitelyTyped. Being typed- one of the best things I like about Scala is that I can do something like this (provided by a couple of frameworks- Laminar, Scalatags et al) <pre> div( Seq( div( "div 1" ) ), div( "div 2" ), b( "bold stuff", i( "italic inside bold" ) ) ) </pre> No more mismatching tags, wrongly spelled tags, unclosed tags. Typechecked HTML in some sense. This would also be a good place to mention some alternatives where a mainstream language can also compile to JS so hopefully people can comment with their experience: 1) F#- Fable 2) OCaml- Bloomberg's BuckleScript 3) Go- Gopher 4) Haskell- GHCJS Other non-mainstream but compile-to-JS languages 1) PureScript 2) ELM 3) Clojure script (child comment) ... and of course... TypeScript! :) It should be noted that while Scala.js isn't as popular as some of it's alternatives in "popular" programmer culture, the author is very focussed on correctness and I don't know of anybody who has ever used Scala.js for a project but dropped it. (Happy to be corrected)
- LandR 7y ago
  ClojureScript too, if you don't mind dynamic typing.
  - mateuszf 7y ago
    Yeah, ClojureScript is amazing.
- flowerlad 7y ago
  > just not happy with the JVM memory reqs Are you not happy with JVM in general or not happy with how Scala uses the JVM? Things like Spark were written in Scala so I am curious what didn’t work for you.
threeseed 7y ago
Would highly recommend pairing this with Slinky (React for Scala.js). https://slinky.dev https://slinky.dev
- bad_user 7y ago
  Do you know how that compares with ... https://github.com/japgolly/scalajs-react https://github.com/japgolly/scalajs-react
- gedy 7y ago
  I'm disappointed that the (formerly?) built-in Scala XML handling could not be used for JSX vs these: Slinky: div( h3("TODO"), TodoList(items = state.items), form(onSubmit := (handleSubmit(_)))( input( onChange := (handleChange(_)), value := state.text ), button(s"Add #${state.items.size + 1}") ) ) scalajs-react: <.div( NoArgs(), Hello("John"), Hello("Jane"))
  - sjrd 7y ago
    If you're into JSX, then probably Bindings.scala is a better fit for you: https://github.com/ThoughtWorksInc/Binding.scala#step-3-create-a-dom-method-that-contains-data-binding-expressions https://github.com/ThoughtWorksInc/Binding.scala#step-3-crea...
    - gedy 7y ago
      Looks awesome, thank you!
atc 7y ago
No-one asked for this.
AzzieElbab 7y ago
Always been curious about workflow of people who use Scala.js. I am a complete newbie when it comes to frontend. How do you do frontendish interactive development considering scalac's slowness?
- sjrd 7y ago
  scalac is only slow when it needs to compile an entire project. But the Scala tooling ecosystem has invested a lot in incremental compilation, which means that most of the time when you make a change, only 1 or 2 files are recompiled, which is quite snappy. In turn, the Scala.js linker also performs its linking and optimizations incrementally, so that in an interactive development setting, the whole cycle is quite fast.
  - AzzieElbab 7y ago
    fine, but what tooling/workflow would one use for the type of development javascripters are accustomed to? Like make a change and immediately observe result on the page?
    - sjrd 7y ago
      Workbench [1], for example :) [1] https://github.com/lihaoyi/workbench https://github.com/lihaoyi/workbench
      - AzzieElbab 7y ago
        Thank you. Did not know about this plugin
      - ramnivasl 7y ago
        Also, if you use webpack (directly or through scalajs-bundler), the use of webpack-dev-server makes live loading automatic.
gedy 7y ago
I can't speak for everyone, but while I loved programming in Scala, I can't stand sbt[0] as a build tool. If I could use Scala.js without all this (e.g. Webpack or Rollup) could see myself using. [0] https://www.scala-sbt.org https://www.scala-sbt.org
- sjrd 7y ago
  sbt is not the only build tool that supports Scala.js. I at least know of support for Maven [1], Pants [2], Gradle [3] (a bit outdated that one, but an interested person could revive it), and there seems to be a path forward for Bazel [4]. That said, I would like to see a Webpack plugin for Scala.js as well. [1] https://github.com/random-maven/scalor-maven-plugin https://github.com/random-maven/scalor-maven-plugin [2] https://github.com/pantsbuild/pants/tree/master/contrib/scalajs https://github.com/pantsbuild/pants/tree/master/contrib/scal... [3] https://github.com/gtache/scalajs-gradle https://github.com/gtache/scalajs-gradle [4]
- nafg 7y ago
  Check out Seed - https://github.com/tindzk/seed https://github.com/tindzk/seed

100 points by sjrd 7y ago

Anyone know what's the minimum size of the compiled JS now? Is there any way Scala.js can produce code as compact as BuckleScript/ReasonML in the future? I like Scala's syntax but the last time I tried Scala.js, the output was several hundred kb for something slightly more than a Hello World -- it used some List and Seq functions. I'd bet the comparable ReasonML output would likely be in tens of kb (including List and Array functions from Belt).

googleisevil6 7y ago
As I noted in another comment, the output is close to unreadable. But you have source maps... (I don't know if Bucklescript has/needs them)
sjrd 7y ago
The bare minimum for a hello world is 6 KB (before gzip). But of course as soon as you start using Scala collections, it's getting bigger. The minimum for a realistic application is 90 KB (before gzip). That's less than your typical JavaScript framework, so for any realistic application it shouldn't be a concern.
- googleisevil6 7y ago
  For refernce- Jquery unzipped is similar size- 87K and while it adds much more functionality, Scala collections easily trump jquery's in usability and power. SJRD, Would you also add a bit more info about how this size increases? I haven't cared much but it seems from your comments that the slope should be much less once you reach 90kb.
  - sjrd 7y ago
    Yes once you're at 90 KB the slope will be much less. It will simply grow with the actual code of your app.
    - ramnivasl 7y ago
      Indeed, once you end up pulling in most common Scala classes (collections, futures, etc.), adding new functionality to your app increases app size by very little. Our app has ~600KB gzipped js (attributable to Scala.js compiled code) + ~200KB of React and other libraries. The overall size has barely moved beyond +-100KB in last few years despite adding new functionality all the time. Once Scala.js supports lazy loading of modules (hopefully soon after 1.0), the size issue will have significantly less practical impact.
  - fnordsensei 7y ago
    ClojureScript ends up somewhere around the same size. Maybe it's some magic number that a full-featured environment converges to. Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll also reach for the Closure Library for a lot of stuff where one might reach for JQuery or equivalent otherwise. The stuff in there is of course optimized for Closure Compiler, and slims down quite well.
    - sjrd 7y ago
      There is a significant difference between CLJS and Scala.js regarding their use of GCC (Google Closure Compiler). In ClojureScript, GCC is a user-visible feature of the toolchain, so users are encouraged to use GCC-compatible libraries and the Closure Library in particular. In Scala.js, GCC is really an implementation detail of the toolchain, and its constraints are completely abstracted away from the user. This does not really encourage using GCC-oriented libraries like the Closure Library. The two approaches each have pros and cons: * CLJS' approach allows tree shaking across the CLJS code and the GCC-compatible libraries that are used. However, it makes it more difficult to use libraries that do not comply with GCC's Advanced Optimizations requirements, as one needs to declare the proper `externs` files. * Scala.js' approach means that you can use any JavaScript library out of the box, whether or not it was designed for GCC, and without having to declare any `externs` file. However, it means that GCC's tree shaking will not be applied across the Scala.js code and the JS libraries. It only applies to Scala.js' own code.
      - fnordsensei 7y ago
        I think the externs file maneuver might be outdated. Admittedly, I'm using shadow-cljs as my go-to compiler (so I'm not sure what the state of vanilla is), but all I do is yarn add <package>, and then require it in the file where I want to use it, and interact with it as if it were any other library. Though it is true of shadow-cljs as well that it doesn't try to tree-shake external (non-CLJS/Closure) libs by default, though it will do it for project code and Clojure libraries.
Mahnoor_Aslam 7y ago
Why these rules are violated?
- deleted 7y ago
  [deleted]
LeanderK 7y ago
While i understand your concern, i wouldn't use scala.js in a context where several hundred kb are an issue. I've tried it and it works great, but i think it only pays of if you implemented a complicated web-app with complicated server-side code, e.g. if you replace a desktop-application to manage some system with a web-based one. Something where showing a loading-screen on the first visit is totally reasonable.
bad_user 7y ago
Scala.js is being fed to the Google Closure compiler [1] for minification via tree-shaking, after applying optimizations on its own. Output can be unreadable, but debugging works via source maps. It's not perfect, but you should not get hundreds of KB for a Hello World. And indeed, the code cannot be as minimal as hand crafted code either. Note that this is often a false problem, because people often use a lot of JavaScript libraries without any tree-shaking in their build process, so if you do care about tens of KB, then you don't use JQuery, React, etc. A valid use case indeed, I've been there, but not for your typical app. [1] https://developers.google.com/closure/ https://developers.google.com/closure/
virtualwhys 7y ago
> the output was several hundred kb for something slightly more than a Hello World -- it used some List and Seq functions That's just nonsense, maybe 6 or 7 years ago that could have been the case. There's an approximate 100KB "tax" for pulling in Scala collections (i.e. as soon as you depend on List, Map, Seq, etc.), which is the price to pay for being able to use the power of Scala in the browser. > Is there any way Scala.js can produce code as compact as BuckleScript/ReasonML in the future? No, iirc, not without a redeisgn. There's a longstanding issue wrt lazy loading, which is slated to be worked on at some point post-1.0 -- I'd say that's probably the biggest missing feature, the ability to break out one's app into dynamic chunks, so for example a lightweight frontend/public facing area of an app can be isolated from the backend where all the heavy lifting is done. Perhaps with Dotty (AKA Scala 3) next year there will be further reductions in Scala.js code size, but no, nothing like BuckleScript.

The_rationalist 7y ago

Can this call js libraries and the DOM trivially like typescript? Or does it leverage ffi?

sjrd 7y ago
It's exactly like TypeScript. You write type definitions or you find them online, like in TypeScript, then you can call any JavaScript API using the relevant types. Full relevant docs at https://www.scala-js.org/doc/interoperability/ https://www.scala-js.org/doc/interoperability/
- manx 7y ago
  Many TypeScript type definitions are also automatically converted to ScalaJS: https://github.com/oyvindberg/ScalablyTyped https://github.com/oyvindberg/ScalablyTyped
jackcviers3 7y ago
You can call js directly using dynamic. From the docs[1]: val document = js.Dynamic.global.document val playground = document.getElementById("playground") val newP = document.createElement("p") newP.innerHTML = "Hello world! <i>-- DOM</i>" playground.appendChild(newP) 1. http://ochrons.github.io/sjs2/doc/interoperability/calling_js.html#:~:targetText=Scala.js%20lets%20you%20call,is%20of%20type%20js.Dynamic%20 http://ochrons.github.io/sjs2/doc/interoperability/calling_j....

googleisevil6 7y ago

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Scala.js interop with JS is very seamless. Do check out ScalablyTyped repo on Github, a Scala.js analogue of DefinitelyTyped. Being typed- one of the best things I like about Scala is that I can do something like this (provided by a couple of frameworks- Laminar, Scalatags et al) <pre> div( Seq( div( "div 1" ) ), div( "div 2" ), b( "bold stuff", i( "italic inside bold" ) ) ) </pre> No more mismatching tags, wrongly spelled tags, unclosed tags. Typechecked HTML in some sense. This would also be a good place to mention some alternatives where a mainstream language can also compile to JS so hopefully people can comment with their experience: 1) F#- Fable 2) OCaml- Bloomberg's BuckleScript 3) Go- Gopher 4) Haskell- GHCJS Other non-mainstream but compile-to-JS languages 1) PureScript 2) ELM 3) Clojure script (child comment) ... and of course... TypeScript! :) It should be noted that while Scala.js isn't as popular as some of it's alternatives in "popular" programmer culture, the author is very focussed on correctness and I don't know of anybody who has ever used Scala.js for a project but dropped it. (Happy to be corrected)

LandR 7y ago
ClojureScript too, if you don't mind dynamic typing.
- mateuszf 7y ago
  Yeah, ClojureScript is amazing.
flowerlad 7y ago
> just not happy with the JVM memory reqs Are you not happy with JVM in general or not happy with how Scala uses the JVM? Things like Spark were written in Scala so I am curious what didn’t work for you.

threeseed 7y ago

Would highly recommend pairing this with Slinky (React for Scala.js). https://slinky.dev https://slinky.dev

bad_user 7y ago
Do you know how that compares with ... https://github.com/japgolly/scalajs-react https://github.com/japgolly/scalajs-react
gedy 7y ago
I'm disappointed that the (formerly?) built-in Scala XML handling could not be used for JSX vs these: Slinky: div( h3("TODO"), TodoList(items = state.items), form(onSubmit := (handleSubmit(_)))( input( onChange := (handleChange(_)), value := state.text ), button(s"Add #${state.items.size + 1}") ) ) scalajs-react: <.div( NoArgs(), Hello("John"), Hello("Jane"))
- sjrd 7y ago
  If you're into JSX, then probably Bindings.scala is a better fit for you: https://github.com/ThoughtWorksInc/Binding.scala#step-3-create-a-dom-method-that-contains-data-binding-expressions https://github.com/ThoughtWorksInc/Binding.scala#step-3-crea...
  - gedy 7y ago
    Looks awesome, thank you!

atc 7y ago

No-one asked for this.

AzzieElbab 7y ago

Always been curious about workflow of people who use Scala.js. I am a complete newbie when it comes to frontend. How do you do frontendish interactive development considering scalac's slowness?

sjrd 7y ago
scalac is only slow when it needs to compile an entire project. But the Scala tooling ecosystem has invested a lot in incremental compilation, which means that most of the time when you make a change, only 1 or 2 files are recompiled, which is quite snappy. In turn, the Scala.js linker also performs its linking and optimizations incrementally, so that in an interactive development setting, the whole cycle is quite fast.
- AzzieElbab 7y ago
  fine, but what tooling/workflow would one use for the type of development javascripters are accustomed to? Like make a change and immediately observe result on the page?
  - sjrd 7y ago
    Workbench [1], for example :) [1] https://github.com/lihaoyi/workbench https://github.com/lihaoyi/workbench
    - AzzieElbab 7y ago
      Thank you. Did not know about this plugin
    - ramnivasl 7y ago
      Also, if you use webpack (directly or through scalajs-bundler), the use of webpack-dev-server makes live loading automatic.

gedy 7y ago

I can't speak for everyone, but while I loved programming in Scala, I can't stand sbt[0] as a build tool. If I could use Scala.js without all this (e.g. Webpack or Rollup) could see myself using. [0] https://www.scala-sbt.org https://www.scala-sbt.org

sjrd 7y ago
sbt is not the only build tool that supports Scala.js. I at least know of support for Maven [1], Pants [2], Gradle [3] (a bit outdated that one, but an interested person could revive it), and there seems to be a path forward for Bazel [4]. That said, I would like to see a Webpack plugin for Scala.js as well. [1] https://github.com/random-maven/scalor-maven-plugin https://github.com/random-maven/scalor-maven-plugin [2] https://github.com/pantsbuild/pants/tree/master/contrib/scalajs https://github.com/pantsbuild/pants/tree/master/contrib/scal... [3] https://github.com/gtache/scalajs-gradle https://github.com/gtache/scalajs-gradle [4]
nafg 7y ago
Check out Seed - https://github.com/tindzk/seed https://github.com/tindzk/seed