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)
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.)
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.
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.
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.
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.
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.
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.
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.
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
It's not really a simpler language than Scala - it's less powerful and as a result many of its libraries are simpler (probably - there's no real Kotlin library ecosystem yet, for all we know they may end up combining the worst aspects of Spring and ScalaZ), but the language itself is a mess.
Scala.js uses much of the scala compiler infrastructure and is worked on by many of the same people; while typesafe doesn't support it commercially it's hardly "completely third party".
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
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?
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.
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.
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
If you're in for the long haul (say 2+ years) I'd go with scala - it's ultimately a better language with a much more complete and powerful type system than typescript. It's also good to learn at least one functional language to pick up the functional techniques (which are ultimately valuable in any language), so if you've never learnt a functional language before I'd recommend it.
But typescript will get you most of the "quick wins" of type safety and is very easy to migrate to, so it's probably a better choice in the short and medium term (at least in terms of immediate productivity).
I'm more into a long haul so scala sounds pretty cool.
But what just rushed into my mind is that angular 2 will be in typescript so learning scala would only be relevant for server side code. And using two languages when one can handle both doesnt sound quite convicing :/
Would you still recommend scala when I want to work with angular 2 in the near future?
Scala can be very good at interop - I still use Wicket (Java) for my Scala web UIs. And I'm confident that the Scala.js folk will have a good answer for doing UI, whether that ultimately means Angular 2, another existing framework, or a native Scala.js UI framework.
All that said, if you're thoroughly committed to Angular 2 (a mentality I don't really understand - I love Wicket but if an equally OO framework existed in native Scala then I'd use that instead) then using anything other than Typescript is probably an unnecessary risk factor.
30 comments
[ 4.3 ms ] story [ 71.1 ms ] threadAs for the bloat, it isn't much. Compiled Javascript for our full-fledged app is about 180KB (gzipped) + external libraries such as React.
If I told you I had a way to remove 180KB from every page load, you'd be all over it. :)
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.)
1. http://www.gwtproject.org/
2. https://github.com/konsoletyper/teavm
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/MbLWIqp...
Kotlin is barely at 1.0 at the moment though.
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.
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.
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-can...
Scala.js uses much of the scala compiler infrastructure and is worked on by many of the same people; while typesafe doesn't support it commercially it's hardly "completely third party".
Babel and ES6 should be fine too.
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.
For example, look at this: 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.
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
But typescript will get you most of the "quick wins" of type safety and is very easy to migrate to, so it's probably a better choice in the short and medium term (at least in terms of immediate productivity).
I'm more into a long haul so scala sounds pretty cool.
But what just rushed into my mind is that angular 2 will be in typescript so learning scala would only be relevant for server side code. And using two languages when one can handle both doesnt sound quite convicing :/ Would you still recommend scala when I want to work with angular 2 in the near future?
All that said, if you're thoroughly committed to Angular 2 (a mentality I don't really understand - I love Wicket but if an equally OO framework existed in native Scala then I'd use that instead) then using anything other than Typescript is probably an unnecessary risk factor.