Scala.js has a new website
scala-js.org
scala-js.org
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".
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...
As 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.)
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.