I was very sceptical of Scala.js, but decided to use it in a low risk project (http://github.com/underscoreio/doodle) to render to the HTML canvas and I am shocked at how well it works. The community is moving very quickly as well, and many advanced Scala projects have had the necessary tweaks applied to run in Scala.js.
Looking at broader trends, there is a clear movement towards static typing on the Javascript VM, as in-browser programs become more complicated. Google is developing SoundScript, there has been talk about gradual typing in ES7, Facebook has their type checker etc. To some extent I think adding static types to (the mess that is) Javascript is more work than may be worthwhile. I see the most practical developments in the alternative JS languages, such as Elm and Purescript, and now Scala.js, that start from a cleaner slate. The Javascript committee have done a shockingly good job making Javascript a compilation target with tail calls and so on in ES6.
I'm skeptical of any x-to-JS compiler as usually I end up debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want.
On the other hand the Scala people know how to write compilers. We're live, in production, with Scala since 2011 and it's a joy: it actually delivers what's promised. Heard the same thing from Twitter, LinkedIn and Netflix too.
So maybe it worth a try; especially if it will integrate with ReactJs / React Native. Sounds like a match made in heaven.
> debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want.
Please forgive me for the accusation, but I've heard many people say this same statement to later found out they just meant "Well it's never happened to me... but it could... but it happened to this person I know...".
I personally can't think of many situations where you'd debug the machine generated javascript instead of using a sourcemap, can you give more detail on your experience?
To me this sounds like the same argument against C compilers: "You'll just end up debugging the generated asm anyway!".
Turns out (mature) compilers are generally better at writing code than humans, and most of the time you don't have to debug their code, only your own. Almost every time I've heard someone say "I found a bug in the compiler!", they didn't.
I've found 3 compiler bugs during my 15 years as professional developer.
One was a optimizer bug sprintf in a for loop reset the ecx register so the loop became infinite and the last two where valid code that crashed the compiler (how do I know that, because the crashes dissappeared with small modifications of the code, like newlines). But yeah they are pretty rare.
Depends if you're trying to debug optimized code or not... sometimes I try to do that since I'm too impatient to recompile something at -O0. Sometimes it works, sometimes I end up wasting more time than the recompilation would have taken.
I've had this happen with Clojurescript. If I recall correctly, runtime errors refer to the generated code, rather than to the source. So it can be hard to diagnose what exactly is going wrong.
This may have changed since I was last working with Clojurescript.
There's a difference between a lightweight transpiler like JSX and a compiler.
ClojureScript is pretty lightweight, but GWT and Scala.js compile process is not an easy one. Even Bootstrap.js optimization with Google Closure Compiler is an uphill battle. Try it with --compilation_level ADVANCED_OPTIMIZATIONS
Sourcemap does not help much with compiler bugs or if the compiler people have different opinion from you on how something should be translated.
At least for CoffeeScript, the generated code is so close to the the original source that the mapping is obvious. I've never needed to get the source map working.
I'm skeptical of any x-to-JS compiler as usually I end up debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want.
I can't speak to any other x-to-JS transpiler but I've been writing ClojureScript almost every day for close to two years and this has never been an issue. At the very least this has to be dependent on which 'x' we're talking about.
Yeah, you could maybe even get the JSX-style syntax with React by using Scala's XML support. I'm not sure if it would actually work, but it's a cool idea.
So here's my question, how come no browser has a way for a java applet to manipulate the DOM? We've got GWT compiling java to JS, we've got this compiling scala to JS.. and the JVM was originally built to run inside of a browser. Why can't we just close the circle? I guess people don't want their website visitors to see a "you must upgrade java" popup first thing?
There was - it was called LiveConnect - but like most things to do with Java and the browser(s), it languished in a half-supported state, and really isn't worth thinking about any more.
As are applets - a great idea, implemented poorly, and now essentially lost to the annals of history.
We used to do it because dealing with cross-browser compatibility was a pain. For instance, I used to use a 1-pixel applet instead of XMLHttpRequest for AJAX (slightly before they coined the term "AJAX") and applets for rendering live-updated XML-based diagrams (instead of SVG) in both cases because it simply made things less buggy and less of a pain to support at the time. But that was in 2004 to 2007.
But once we've written something, and it works, we're often a little slow updating it to newer tech, because we can't write a paper out of "the same thing I published earlier, but now using SVG and XHR instead of applets".
If it still just-about works, there's less impetus to rewrite it.
There are quite a few applets demonstrating chemical reactions/bonds or physical equations etc., and as such applets are relatively common in teaching materials for high school (/secondary education) physics and chemistry, at least with teachers (I had or) I have substituted.
They are obviously years old and rarely signed, which is a shame because quite often there are plenty of demos, none of which I can run with modern default settings of a PC (and sometimes I wouldn't have enough credentials to do anything about it, anyway).
Fundamentally, the languages able to run in the browser are only limited by what the browsers want to implement. It would be great if browsers could render QML, or could use <script type="text/python"> or <script type="text/scala"> or whatever but that requires browsers to either depend on an external JVM or include on in the browser. Or you need to put the QML runtime in the browser or as a dependency. Or you have to put a Python interpreter in the browser or as a dependency.
None of those languages have a secure sandbox and writing one is incredibly difficult, even for a language designed to run in such an environment (Java). Native Client might be interesting here to build sandboxes for other languages.
Lua was made with embedding in mind. You can start a VM with an empty global environment (no standard libraries etc..) but there is not a big benefit in jumping from js to lua because they are so similar.
Aren't they doing Dart as well? That has optional typing. Plus they have GWT, which is Java to JS.
Don't get me wrong, I'm super grateful to receive their fruits of labor for free, but this looks like a case of the left hand not knowing what the right hand is doing.
You've hit the nail on the head with left-hand-right-handedness at Google. Every interaction I've had with that company reveals behavior reflective of this condition. You've gotta scratch the surface to find it, but lately it's not very deep. When I interview places, and the interviewer gives me a single question, I hit them with something almost no one expects ("If you could change one thing without veto, what would it be?"). When I interviewed there at Google some time ago (I turned down their offer because of the answers I got to this question), six out of the seven interviewers I asked replied with some variation on "All the low-hanging fruit has been picked, and most people aren't in a position to solve the gnarly problems, so I wish I could do work that challenges me." This immediately sent up red flags with me, along with the weird sense of hivemind I got at the Googleplex. It wasn't exactly like wandering around a Borg cube, but it was close. Then recently the company I work for has had visitors from Google, and while I'm not involved in the interactions personally, there's a huge sense of this left-hand-right-hand problem even among teams working on the same product, just different groups. This is probably the case with all large corporations after a certain critical mass, but I'm personally experiencing a selection bias for Google in particular.
When I interview places, and the interviewer gives me a single question, I hit them with something almost no one expects ("If you could change one thing without veto, what would it be?")
I will remember this one. That's a great question for interviews.
Even from the POV of the interviewer it's a great question. I'd give my answer then brainstorm with the interviewee about how they would propose solving that problem.
Would you feel comfortable asking an interviewee the same question about their last job? It could give a sense of how they think / why they are looking for a new spot but might be a little invasive.
Not a bad thing to let two or more projects compete to encourage innovation, than granting each team exclusive privilege to represent the whole company in the area.
I think this is fairly typical of large companies. For example, Facebook also has a framework called Javelin that predates React by a few years and had it's own take on functional reactive programming. It's best to think of a large company as several small companies pursuing their own agendas.
> Don't get me wrong, I'm super grateful to receive their fruits of labor for free, but this looks like a case of the left hand not knowing what the right hand is doing.
Its more a case of not all the eggs being put in one basket. Google exploring many avenues to the same broad goal in parallel has been a widely observed phenomenon for a long time.
There just are programmers who feel static typing is the only correct way to program. Google has always been in that camp (company wide directive, I suppose). Meanwhile, most of the internet runs on PHP.
I hope it will play out so that the statical types people can use something with statical types, and the dynamic types people can happily continue with their static types.
I really wonder whether we won't get more conversion to static types. I think the popularity of dynamic typing languages is more due to the fact that static typing used to be a major pain. But with type inference being where it is, I think most languages can start moving to static typing without any costs to the users
The biggest representation of this is all the Pythonistas moving to Go. Well there's not that many, but the fact that Go "feels" like Python shows that maybe "fast and easy to use" is not as tightly coupled to "lack of typechecks" as we once thought
I've learned Go by doing a MOOC on discrete optimization. Mostly, it was fine and fun. But eventually I switched back to JavaScript out of frustration because some things were simply too complicated.
Just look at the sorting library of Go. I don't think they have solved the problem of static types in a satisfactory way.
This is personal impression, but there haven't really been any advances in research per se, but there's been a lot of advances in tooling.
Now having type inference is an "expected" feature of most languages, now that there's a good amount of institutional knowledge. Along with first-class functions and the like. These are old things but it takes a while to propagate
That's funny, I'm currently writing a Canvas visualization, the code base is getting bigger than anticipated, hence messier than I'd like. When I saw this article I thought "damn, I bet this would be way easier managed in Scala, if I only knew Scala".
If you want to learn Scala allow me to make a shameless plug:
- We are using Doodle as the tool for exploring Scala in free events running in San Francisco and Edinburgh in March. More will be scheduled later.
- We are using the design of Doodle as a case study in our online Essential Scala course. This is a paid course, with the first iteration starting in late Feb at a crazy 50% discount (75% off for diversity applicants).
Let's say I want to use Scala.js to build, not an application, but a JavaScript library. The library exposes a JavaScript API that JavaScript code can call. The library's objects can be used in full from JavaScript.
Can I do this with Scala.js? If so, how?
Very few, if no, *-to-JavaScript cross-compilers can do this. For example, Dart might seem to be that language, but on closer inspection, it's not. Your library is locked inside a JavaScript VM-like data structure.
Although you can get a JavaScript object out of Dart-to-JavaScript compiled library, you need to manually hook up every function in its API yourself. In other words, it's not practical to use Dart to build a JavaScript library that exposes a sophisticated JavaScript API.
I understand why these types of compilers lack reflection support, but it still bothers me (and general makes me want to avoid them). JavaScript is naturally a very dynamic environment, and both Java and Scala have some pretty strong dynamic capabilities of their own.
But somehow when they are combined (GWT or Scala.js) you end up with something that is more static than Java or JavaScript. I know the reasons have to do with the static compilation optimization, but I still think this is a huge downside relative to languages that are designed for the browser from the start.
In Scala one can perform reflection purely at compile-time using macros [1]. This lets you to generate code that would have required reflection in other languages with a much better performance. For example pickling [2] library uses macros to statically generate highly efficient serialisation and deserialisation boilerplate.
I don't understand why compilers can't simply emit global variables containing structural descriptions of types. It seems like such a trivial thing to do. It would increase the size of the binary, but it would be possible to disable in projects that aren't using reflection, even automatically if the code never imports the reflection package.
Oh yes, compilers could do that. But because of the code explosion, everyone would actively stay away from that feature. And we, compiler writers, don't want to support a feature that's not used.
Ceylon does this when compiling to JS because it has to support reified generics both on the jvm and in the browser. I don't like the size of the model though. It's huge.
That's exciting. I have worked extensively with Scala during my Master's project. What I'd really like to know is what this means in the context of the current trend of JavaScript (both client and server-side).
I'm currently working exclusively on MeteorJS, Node.JS and Angular and fail to see the relevance other than porting Scala applications to the web and making Web App development easier for developers familiar with Scala. However, without the kind of structure and inherent capabilities that a MeteorJS or DerbyJS offers, what's the USP here?
Scala.js, Clojure.js etc. treat JavaScript as assembly language and the browser as a target architecture. It's not about porting applications. It is about accessing the same data structures and abstractions on both ends of the wire when writing code.
For languages like Scala this means things as obvious as keeping class based inheritance with traits when writing client code for the browser. Those classes can share the same hierarchy with the server side.
This means that the decisions about where to execute a feature becomes less likely to be driven by differences between client and server language features. The effort can be put into determining which execution environment better solves the problem.
This sounds great. I have not really used Scala before. 3 questions:
- How good do IDEs understand Scala these days? Compared to C#/Java, where IDEs instantly know a crazy lot about your code. I am looking at features like IntelliSense, marking wrong code, marking typos, marking unused code, telling me about unhandled Exceptions etc.
- Is there any difference, on the IDE side, between Scala support and Scala.JS support?
- Is a development cycle possible, where I save and I can instantly reload the page in my browser to see the differences?
- (Bonus Question) How well does it integrate with React. If my memory is not fooling me, Scala supports something like Inline-XML. Can I write React-Code, like I write JSX code with it? Any examples?
- IDEs for Scala are pretty good, nowadays. They do all of what you mentioned (except unhandled exceptions, because that's a Java-specific thing).
- There's no difference between Scala and Scala.js support. To your IDE, Scala.js is Just Scala.
- There is a development cycle, absolutely, and it's pretty fast! With Workbench (https://github.com/lihaoyi/workbench) you don't even need to reload the page: it does so automatically!
- For React, there is essentially scalajs-react (https://github.com/japgolly/scalajs-react). It does not support inline-XML per se, because it relies more on ScalaTags instead (https://github.com/lihaoyi/scalatags), but at some point there was a proof of concept showing it was possible to implement with macros.
- How good do IDEs understand Scala these days? Compared to C#/Java, where IDEs instantly know a crazy lot about your code. I am looking at features like IntelliSense, marking wrong code, marking typos, marking unused code, telling me about unhandled Exceptions etc.
IntellIj has a very nice plug-in, it will tell you a lot about your code, including suggestions of best practices. The down side is that the more "functional" your code gets, the slower IDE becomes(that's also true for Eclipse), but chances are that when that happens, you won't care about having an IDE.
So IntellIj will be great to get you started, it does help a LOT.
Is there any difference, on the IDE side, between Scala support and Scala.JS support?
Not sure about this, it seems like you can just code in IntelliJ/Eclipse, but the debugging has to happen in the browser, it does work very nicely(you debug the scala code, not the generated javascript)
Let me contradict the other answers with my personal experience: the two IDEs for Scala I know, Scala-IDE (Eclipse based) and IntelliJ are relatively bad.
- They are very slow.
- They have poor refactoring support (Scala-IDE's support is still marked as experimental; all but the simplest refactoring will often randomly break code, either by not doing a full refactor, or by introducing gibberish).
- Until the latest version of Scala-IDE, you couldn't inspect variable contents while debugging. I can confirm the latest version does let you inspect variables, but I'm not sure how stable this is.
- This is the killer disadvantage for me: both Scala-IDE and IntelliJ give spurious compilation errors pretty often, even for relatively trivial code. I know there are valid technical reasons why this isn't solved yet, but to me it's unacceptable that an IDE for a statically typed language gives spurious compilation errors: after all, compile-time errors are the main tool a statically typed language gives us. It's the one feature that absolutely must work correctly.
- Even trivial autocomplete randomly stops working for Scala-IDE. This may be related to the spurious compilation errors.
I've been told the unofficial recommendation from the Scala community is to disable incremental compilation in the IDE and compile with SBT. Consider what this says about the maturity of current IDEs.
- Refactoring is limited, will sometimes refuse to happen, and will sometimes randomly move 1 character into the wrong place in the file. So yes it does "break", but not in a way that's hard to fix.
- Variable inspection when debugging has always worked fine for me.
- Scala-IDE never gives a "full" spurious compilation error (one that shows up in the problems tab and with a full icon on the left) - or rather, no more than Eclipse in Java does (the kind where you have to refresh / clean the project do sometimes happen). On some constructs it will show a spurious "presentation" compiler error (red underline, simpler icon on the left), but it's easy to visually tell the two apart. I never think code is broken when it isn't.
- Autocomplete never stops working. It does sometimes get slow (several seconds)
- I have automatic compilation on save (no incremental config), manual/explicit saving. It's a workflow I'm happy with.
> - Variable inspection when debugging has always worked fine for me.
Are you using version 3 or 4? In version 3 this definitely didn't work, as stated in the changelog for version 4 ( http://scala-ide.org/docs/changelog.html, look for M3 "Show variable values in hovers when in suspended debug mode". It should be noted that for me, in version 3 selecting and watching a variable doesn't work either). This seems to be fixed in version 4, which was officially released on 2014-12-16.
> - Scala-IDE never gives a "full" spurious compilation error
True, this seems to be mostly a presentation issue, albeit a very distracting one. However, in my experience occasionally one of these errors will prevent the application from launching from Eclipse (for debugging, for example), which seems very odd.
In my experience, autocomplete sometimes stops working completely. Or maybe I'm really impatient :)
> Are you using version 3 or 4? In version 3 this definitely didn't work, as stated in the changelog for version 4 ( http://scala-ide.org/docs/changelog.html, look for M3 "Show variable values in hovers when in suspended debug mode"
Oh, I didn't realize you meant hovers; I never use that (even in Java), I always use the pane with the variables in.
> In my experience, autocomplete sometimes stops working completely.
I sometimes get the "autocompletions took longer than 2 seconds to complete" warning, but after I dismiss it they are there.
I program in Scala at work full time using Intellij and I'm having a great experience. No weird compilation errors, quick, responsive. Works almost as well as with Java files.
Awesome. My own experience is more with Scala IDE, which is terrible. I tried IntelliJ for a brief time last year, saw it had spurious compilation errors, and the gurus at my office told me it was even worse than Scala IDE (but you know how gurus are...).
Out of curiosity:
- Do you have incremental compilation enabled with IntelliJ?
- Do you ever experience a compile error in the IDE for code that SBT is able to compile successfully?
Our codebase is a few years old so we are using maven for our builds instead of SBT. I've been using the intellij incremental compiler and it seems to work well. Once in a while it will complain so I hit the reimport button on maven and then its fine. There is no code in our codebase that maven compiles but Intellij can't. I do remember using spray.io and Intellij had a hard time with that library but recently the problem has gone away.
You are correct. Scala.js compiles Scala code to JS, not bytecode. A number of core Java classes have been ported to Scala.js so they can be used anyway, though. (see http://lihaoyi.github.io/hands-on-scala-js/#JavaAPIs for a mostly exhaustive list so far)
Nope. The current trend in JavaScript has nothing to do with a type system.
Here, you have one industrial-strength statically typed language that you can write both the front-end and the back-end in. The end goal is to simplify the development of complex web apps, the thesis statement is that static types could make this end goal easier to reach.
I personally hope that within some time this could be adopted on the large scale, I really feel the need for a statically typed language for the front end.
However, the biggest obstacle I can see is the learning curve.
I'm concerned that using Scala.JS will complicate cause there's a lot more to Web Apps than just JavaScript. And JavaScript works very well in the context of HTML etc. Plus JQuery - I don't see a point in doing it the Scala way when JQuery and other libraries are just as efficent and I will likely use them anyway.
Using Scala adds a 4th language cause the JS is inevitable.
I think you're misreading the situation. Scala.js sits on top of Javascript, and leverages everything in the JS ecosystem. Interoperability is central to the Scala.js story.
For example, I'm building a product with a moderately complex front end. I'm using about 10-15 JS libraries, including JQuery and JQuery UI, as part of that. I just write a strongly-typed facade on top of each library, describing what it does (which takes just a few minutes), and I'm off to the races. Similarly, other folks are doing things like writing Scala.js adapters for React, Angular, and so on.
So Scala.js isn't in competition with the existing JS libraries. Far from it: I think of it as a much better way to use the Javascript resources that already exist...
> Plus JQuery - I don't see a point in doing it the Scala way when JQuery and other libraries are just as efficent and I will likely use them anyway.
I won't speak about Scala in particular, but using a statically typed language with a strong type system is much more about safety than about "efficiency" (whatever this means). Javascript is brittle, and the idea of doing any kind of refactoring on a large JS codebase is terrifying. Compiling to JS from a more typesafe language makes sense, and you can write bindings for most JS libraries.
I actually don't think its so much about code safety either. To me the real top advantage of static typing is that it leaves the code self-documenting, easier to navigate around, easier to refactor as you say...etc.
Having said that the flexibility JS gives you is huge, I've played with Scala and its at the opposite end of the scale. I don't mind that but I am more interested in things like gradual typing being added JS, even if that just ended up being checked at run-time, because it gives you some of the big advantages of static typing without sacrificing all the of the dynamic goodness.
Yeah I plan to ta, to be honest I like what I've seen/used of TypeScript too. However I'm thinking the big win will be in the longer term when JS picks up some of the ideas.
Think of Scala as a library for JavaScript. It's keywords are no more or less a part of JavaScript than jQuery's '$' or CoffeeScript operators.
Unlike CoffeeScript though, using Scala to generate JavaScript does not require attention to the way JavaScript works any more than JavaScript requires attention to x86 instructions when run on V8 via Node.
Take a look at https://github.com/sinelaw/inferno
It aims to add a type system to a subset of Javascript. It's not quite ready yet, but it already shows quite some promise.
There's also Flow and Google's Closure/et-al, but they are more lenient and accept more valid and invalid programs.
If I just want types+js, Typescript is already pretty mature and widely supported (e.g. good integration with node, support for lots of popular libraries via DefinitelyTyped). What does this inferno offer over that?
According to the author of Inferno, TypeScript copies all the "bugs" and error-prone behaviors of JS, and is also a superset, not a subset. Inferno being a subset lets you use all your JS tooling directly with Inferno code.
The "Hello World" example yields a 3500 LOC js file. I expected a high count but that still managed to shock me. Well, I'm still pretty excited about this announcement and looking forward to give it a try.
The important thing is that it doesn't grow proportionally.
Adding a second line to your "Hello World" doesn't give you 7000LOC, just like using jQuery in two places instead of one doesn't automatically double jQuery's library size.
> It’s mostly about the strong typing for me. Nothing revolutionary about that idea, but it’s just as true on the client as on the server: having the compiler type-check your code makes it much quicker to get complex, sophisticated systems up and running.
I used to believe that this was obviously true. Then I went from doing a lot of programming in JS where even with a large codebase, I could see the code fail in seconds to programming in Scala where type errors would not always appear in the editor, but you'd have to do a compile step that takes ages to actually see them.
Now I'm much less sure about the benefits of typing. What is actually useful is fast failure and short iteration cycles. Seeing the errors as you write is the fastest failure there is, but if I have to run a 30 second build to see a type error, that is much worse than dynamic types but seeing the error in less than a second.
Its true that carefully thought about types can catch errors you might not see immediately, but you can fix this to some extent with putting effort into making sure your code fails fast, and adding unit tests and while this doesn't give you proof-level guarantees, for most practical work, with discipline, it's good enough (even if emotionally unsatisfying).
Maybe one day I'll find a system that lets me encode constraints into the type system and have it actually tell me about violations quickly, and I'll happily leave dynamic land behind (for most things), but I've come to the conclusion that arguing about type systems misses the point, and the point is that failing fast is better than failing late. Within a single environment, failing at application startup is better than failing at an arbitrary point in the future. Failing at compile time is better than failing at startup. Failing at edit time is better than failing at compile time. But if your compile time is slower than my runtime, you're losing.
Not my experience in scala. I've had a lot of places where in the Scala plugin for intellij, it incorrectly highlights errors, or doesn't discover the error until a full build.
- library availability: in Scala.js you have quite a number of core libraries available (see www.scala-js.org), but you also have direct access to JavaScript libraries
- interoperability with JS: Scala.js has its own TypeScript-like definition classes. But you can also interop in a dynamically typed way with the js.Dynamic type. In any case, the interop is very natural. Even the Scala syntax is close to JS syntax so method calls and property access just look the same.
- Code size: not exactly great, but manageable.
- Code speed: Scala.js has a very good optimizer that brings down typical macro benchmarks between 0.7x and 2x the time of the JS version (yes, 0.7x means it's actually faster!)
- Debugging capabilities: because of Source Maps, you basically step through your Scala.js code and step break points right inside your browser. All modern compile-to-JS languages have that.
This (asynchronous execution) means we are forced to use cooperative multitasking, which is probably not good for reduced latency, and therefore bad for responsiveness (compare to the Windows 3.11 days where we were forced to use cooperative multitasking).
Yes, I know most JS programs today use asynchronous execution successfully in practice, but to use it as the basis of a language platform is not a good idea IMHO. Especially when it comes to UIs, which need the responsiveness.
EDIT: web-workers are not a solution, because you can't share large data-structures efficiently between web-workers.
If I understand you, I think it's a bit much to expect ScalaJS to somehow change the platform it is targeting, which is the browsers as accessed via Javascript (ie. without requiring plugins which would have made it DOA for most use cases). If browsers don't want threads that share data via Javascript control, and it appears they don't, and by design, then what is the alternative for ScalaJS? Same situation as with Javascript.
As mentioned upthread, hello world isn't really representative. A more useful metric is probably what I'm doing -- a large, complex single-page business app with lots of specialized gadgetry.
Including the standard Scala.js prelude (100-200k), that currently clocks in at a bit under a megabyte. That's quite reasonable for a program of its complexity, and loads pretty fast. And once that is loaded and in the browser cache, the UI is lightning fast afterwards...
Hello worlds are about 100 KB not gzipped, but this is not a good measurement. As your application grows, this doesn't grow as fast. Scala.js is meant for medium to large size applications anyway.
Traceur (ES6 compiler) itself has a runtime of several hundreds kb. Nothing you can't avoid at some point. There is an overhead for sure. But in most cases, execution time is spent in native calls (Dom rendering especially).
With the JVM of the near future [0] running JavaScript natively, that could change again. Long before you know it, you'd be running java-scala-clojure-javascript code inside of the same jvm on the server, and on the client...
It's already out in Java 8 but the parser can choke on large js files. I tried loading some Ceylon code compiled to js into the webview but it froze. I think it will have the same problem with Scala.js
I know it's a shameless plug, but if you want to convert any Java bytecode with less semantic differences than scala.js and full reflection support you might want to give https://www.defrac.com/ a try.
Not really the same thing, scalajs is supposedly has full compatibility with Scala, but it doesn't try to go beyond that. Its embracing JavaScript as a platform.
100% code reuse across all platforms is unachievable. What a lot of do today is complete horseshit relative to the state of the art, but different platforms have different ui conventions and following their rules can't be abstracted away into some library, obeying these conventions requires some intuition about human psychology.
By embracing the JavaScript platform, the scalajs folks are leaving the playing field open as to how to deal with multiple platforms. Maybe we can hook up scalajs to react and react native, there seems to be a bit of hype around that.
It's not unrecommended, but it's definitely not where it shines most. It's difficult to get below the 100 KB not gzipped size. Although if you use jQuery in your JS hello world, you also gather up 33 KB just for jQuery, so it's still the same order of magnitude.
Looking at broader trends, there is a clear movement towards static typing on the Javascript VM, as in-browser programs become more complicated. Google is developing SoundScript, there has been talk about gradual typing in ES7, Facebook has their type checker etc. To some extent I think adding static types to (the mess that is) Javascript is more work than may be worthwhile. I see the most practical developments in the alternative JS languages, such as Elm and Purescript, and now Scala.js, that start from a cleaner slate. The Javascript committee have done a shockingly good job making Javascript a compilation target with tail calls and so on in ES6.