6 ms·

Scala.js has a new website

71 points by lihaoyi 11y ago

jiaweihli 11y ago
While I love scala, I have 2 concerns that have stopped me from using scala.js: 1) can I use typescript definitions to avoid writing everything myself? 2) how much bloat does this add to my app? (from overhead of standard libs and core)
- ramnivas2 11y ago
  There is a way to transform a typescript definition to Scala.js facade (https://github.com/sjrd/scala-js-ts-importer https://github.com/sjrd/scala-js-ts-importer). As for the bloat, it isn't much. Compiled Javascript for our full-fledged app is about 180KB (gzipped) + external libraries such as React.
  - sulam 11y ago
    Don't take this the wrong way, but I've been in the industry for a long time... and it amazes me that 180KB is considered not much... If I told you I had a way to remove 180KB from every page load, you'd be all over it. :)
    - Scarbutt 11y ago
      but the 180KB is not downloaded on every page load.
      - sulam 11y ago
        That's good! :)
    - spicyj 11y ago
      180KB is comparable to a medium-size image.
      - Ciantic 11y ago
        Yes you are right. Scripting time however can be massive, take for instance this hs.fi (Finnish daily), they have 354kB of JavaScript, but scripting time with Skylake 6700K is 1.13 seconds of the page load. With Q6600 it was 3.5 seconds. With latest chrome it's easy to measure scripting time as pie chart. Go to "Timeline" tab of developer tools and hit F5. (just few releases back one had to do it manually by starting timeline and stopping it.)
        girvo 11y ago
        So few people seem to run a profiler on their Javascript nowadays. It's a shame, really, as the tools are very powerful!
prohor 11y ago
For those from Java world wanting to write client-side, there is obviously also GWT[1] and another interesting option is TeaVM[2]. Interesting part of TeaVM is that it translates bytecode, so I guess it could do Scala as well. But I've never used it, so cannot recommend really. 1. http://www.gwtproject.org/ http://www.gwtproject.org/ 2. https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm
- pjmlp 11y ago
  I already write client side with Swing and JavaFX....
- sjrd 11y ago
  GWT doesn't do Scala. That puts it out of the equation as far as most Scala.js developers are concerned. Also, it's interoperability story is seriously lacking behind Scala.js. TeaVM is a fun and impressive project. However, although they can compile Scala-emitted bytecode (since a few weeks ago [1]), that's not their main focus. They are unlikely to ever optimize Scala code as well as Scala.js, because Scala.js focuses on optimizing idiomatic Scala. They do have an undeniable advantage over Scala.js, though, which is that they can also compile Java libraries used by a Scala program. [1] https://groups.google.com/d/msg/scala-js/3jbX9ajIbHM/MbLWIqpkBgAJ https://groups.google.com/d/msg/scala-js/3jbX9ajIbHM/MbLWIqp...
- merb 11y ago
  Scala's biggest concern is compilation time. However when comparing GWT and ScalaJS, mostly ScalaJS pulls ahead. So Java -> Js or Scala -> Js you would definitly prefer Scala.
raquo 11y ago
Speaking of bringing nice languages to the browser. Kotlin is a simpler language than Scala and also compiles to JS. Unlike Scala.JS which seems to be a completely third party project, Kotlin's compilation to JS is considered one of the primary features of the language. Kotlin is barely at 1.0 at the moment though.
- stewbrew 11y ago
  AFAIK javascript support is put on hold until 1.0 is reached. Kotlin/JS doesn't provide much help to make Kotlin/Java code run without modifications. So, it isn't there yet. ScalaJS on the other hand is fully functional.
  - raquo 11y ago
    Correct me if I'm wrong, but I think the relationship of Java and JS in ScalaJS and Kotlin is about the same: If your Scala/Kotlin code depends on any Java classes, you won't be able to compile it to JS. You can only compile pure Scala/Kotlin code to JS (and that comes with a few caveats in both cases). It's true that Kotlin's JS support is pretty raw today. There are virtually no docs for it for example. They do have a basic feature set working though. I think in a few months it should be in great shape.
    - stewbrew 11y ago
      Scala has a bigger runtime, which is supported by ScalaJS. ScalaJS also has implementations for some Java classes. There are also some Scala libraries with explicit support for ScalaJS around. Kotlin relies more heavily on the underlying runtime. Unless they re-implement a large part of the Java standard library in JS, they'll never achieve that level of compatibility.
- sjrd 11y ago
  Honestly, I am very doubtful about Kotlin's JS support to be a "primary feature". They have certainly advertised it as such since day 1, but the facts are that they have not treated JS as such in practice. Here are some of those facts: * They intend to release 1.0 without finalizing JS support [1] * The documentation for Kotlin on JS is virtually non existent * The primitive data types don't behave the same on both platforms [1] http://blog.jetbrains.com/kotlin/2015/10/kotlin-1-0-beta-candidate-is-out/#comment-40153 http://blog.jetbrains.com/kotlin/2015/10/kotlin-1-0-beta-can...
jinst8gmi 11y ago
This looks pretty neat. I personally hate working with JavaScript directly.
haxandra 11y ago
Also haxe can compile in javascript and have a type System much similar to Scala. And also macros, conditional compilation and inline functions and constructors. And can compile also in java, c#, c++, lua, php, python, flash
feedme 11y ago
Should I start learning scala or typescript? I'm developing nodejs + angularjs apps in my spare time and want to improve the code (native JavaScript 5 currently). Or should I start with babel and ES6?
- sukulaku 11y ago
  You could get a big improvement by switching to React :p Babel and ES6 should be fine too.
  - feedme 11y ago
    I started with angular and due to my limited spare time I simply dont have the time to learn both. I'm very interestend in React but focusing on angular (and angular 2 in the near future) sounds more promising (based on random articles and news). Do you think switching to react would be worth it? My angular pages are not very complex and I'm still relatively new to angular so switching could be possible.
    - Geee 11y ago
      There's not much to learn about React, compared to AngularJS, which is huge (and pointless IMO). For example, look at this: https://docs.angularjs.org/api/ng/directive/ngOptions https://docs.angularjs.org/api/ng/directive/ngOptions Why would you want to learn this kind of obscure syntax, just to make a simple select input (and still be limited in what you can do)? You don't need this kind of stuff in React because you build your views with pure Javascript and HTML.
    - sukulaku 11y ago
      Well, I believe React is the right way to do JavaScript UIs until something even better comes along. It's not about Facebook - it's about the design that promotes "functionality" and modularity etc. That's the big deal. Angular and Ember are both needlessly complicated to begin with, but even more so because of all the two-way state-mangling going on. So yes, switching to React will be ever-increasingly worth it, because the benefits of not having to deal with Angular will keep compounding over time. So instead of "opportunity costs", you'll have "opportunity benefits" :P

71 points by lihaoyi 11y ago

While I love scala, I have 2 concerns that have stopped me from using scala.js: 1) can I use typescript definitions to avoid writing everything myself? 2) how much bloat does this add to my app? (from overhead of standard libs and core)

ramnivas2 11y ago
There is a way to transform a typescript definition to Scala.js facade (https://github.com/sjrd/scala-js-ts-importer https://github.com/sjrd/scala-js-ts-importer). As for the bloat, it isn't much. Compiled Javascript for our full-fledged app is about 180KB (gzipped) + external libraries such as React.
- sulam 11y ago
  Don't take this the wrong way, but I've been in the industry for a long time... and it amazes me that 180KB is considered not much... If I told you I had a way to remove 180KB from every page load, you'd be all over it. :)
  - Scarbutt 11y ago
    but the 180KB is not downloaded on every page load.
    - sulam 11y ago
      That's good! :)
  - spicyj 11y ago
    180KB is comparable to a medium-size image.
    - Ciantic 11y ago
      Yes you are right. Scripting time however can be massive, take for instance this hs.fi (Finnish daily), they have 354kB of JavaScript, but scripting time with Skylake 6700K is 1.13 seconds of the page load. With Q6600 it was 3.5 seconds. With latest chrome it's easy to measure scripting time as pie chart. Go to "Timeline" tab of developer tools and hit F5. (just few releases back one had to do it manually by starting timeline and stopping it.)
      - girvo 11y ago
        So few people seem to run a profiler on their Javascript nowadays. It's a shame, really, as the tools are very powerful!

prohor 11y ago

For those from Java world wanting to write client-side, there is obviously also GWT[1] and another interesting option is TeaVM[2]. Interesting part of TeaVM is that it translates bytecode, so I guess it could do Scala as well. But I've never used it, so cannot recommend really. 1. http://www.gwtproject.org/ http://www.gwtproject.org/ 2. https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm

pjmlp 11y ago
I already write client side with Swing and JavaFX....
sjrd 11y ago
GWT doesn't do Scala. That puts it out of the equation as far as most Scala.js developers are concerned. Also, it's interoperability story is seriously lacking behind Scala.js. TeaVM is a fun and impressive project. However, although they can compile Scala-emitted bytecode (since a few weeks ago [1]), that's not their main focus. They are unlikely to ever optimize Scala code as well as Scala.js, because Scala.js focuses on optimizing idiomatic Scala. They do have an undeniable advantage over Scala.js, though, which is that they can also compile Java libraries used by a Scala program. [1] https://groups.google.com/d/msg/scala-js/3jbX9ajIbHM/MbLWIqpkBgAJ https://groups.google.com/d/msg/scala-js/3jbX9ajIbHM/MbLWIqp...
merb 11y ago
Scala's biggest concern is compilation time. However when comparing GWT and ScalaJS, mostly ScalaJS pulls ahead. So Java -> Js or Scala -> Js you would definitly prefer Scala.

raquo 11y ago

Speaking of bringing nice languages to the browser. Kotlin is a simpler language than Scala and also compiles to JS. Unlike Scala.JS which seems to be a completely third party project, Kotlin's compilation to JS is considered one of the primary features of the language. Kotlin is barely at 1.0 at the moment though.

stewbrew 11y ago
AFAIK javascript support is put on hold until 1.0 is reached. Kotlin/JS doesn't provide much help to make Kotlin/Java code run without modifications. So, it isn't there yet. ScalaJS on the other hand is fully functional.
- raquo 11y ago
  Correct me if I'm wrong, but I think the relationship of Java and JS in ScalaJS and Kotlin is about the same: If your Scala/Kotlin code depends on any Java classes, you won't be able to compile it to JS. You can only compile pure Scala/Kotlin code to JS (and that comes with a few caveats in both cases). It's true that Kotlin's JS support is pretty raw today. There are virtually no docs for it for example. They do have a basic feature set working though. I think in a few months it should be in great shape.
  - stewbrew 11y ago
    Scala has a bigger runtime, which is supported by ScalaJS. ScalaJS also has implementations for some Java classes. There are also some Scala libraries with explicit support for ScalaJS around. Kotlin relies more heavily on the underlying runtime. Unless they re-implement a large part of the Java standard library in JS, they'll never achieve that level of compatibility.
sjrd 11y ago
Honestly, I am very doubtful about Kotlin's JS support to be a "primary feature". They have certainly advertised it as such since day 1, but the facts are that they have not treated JS as such in practice. Here are some of those facts: * They intend to release 1.0 without finalizing JS support [1] * The documentation for Kotlin on JS is virtually non existent * The primitive data types don't behave the same on both platforms [1] http://blog.jetbrains.com/kotlin/2015/10/kotlin-1-0-beta-candidate-is-out/#comment-40153 http://blog.jetbrains.com/kotlin/2015/10/kotlin-1-0-beta-can...

jinst8gmi 11y ago

This looks pretty neat. I personally hate working with JavaScript directly.

haxandra 11y ago

Also haxe can compile in javascript and have a type System much similar to Scala. And also macros, conditional compilation and inline functions and constructors. And can compile also in java, c#, c++, lua, php, python, flash

feedme 11y ago

Should I start learning scala or typescript? I'm developing nodejs + angularjs apps in my spare time and want to improve the code (native JavaScript 5 currently). Or should I start with babel and ES6?

sukulaku 11y ago
You could get a big improvement by switching to React :p Babel and ES6 should be fine too.
- feedme 11y ago
  I started with angular and due to my limited spare time I simply dont have the time to learn both. I'm very interestend in React but focusing on angular (and angular 2 in the near future) sounds more promising (based on random articles and news). Do you think switching to react would be worth it? My angular pages are not very complex and I'm still relatively new to angular so switching could be possible.
  - Geee 11y ago
    There's not much to learn about React, compared to AngularJS, which is huge (and pointless IMO). For example, look at this: https://docs.angularjs.org/api/ng/directive/ngOptions https://docs.angularjs.org/api/ng/directive/ngOptions Why would you want to learn this kind of obscure syntax, just to make a simple select input (and still be limited in what you can do)? You don't need this kind of stuff in React because you build your views with pure Javascript and HTML.
  - sukulaku 11y ago
    Well, I believe React is the right way to do JavaScript UIs until something even better comes along. It's not about Facebook - it's about the design that promotes "functionality" and modularity etc. That's the big deal. Angular and Ember are both needlessly complicated to begin with, but even more so because of all the two-way state-mangling going on. So yes, switching to React will be ever-increasingly worth it, because the benefits of not having to deal with Angular will keep compounding over time. So instead of "opportunity costs", you'll have "opportunity benefits" :P