13 ms·

Scala.js no longer experimental

337 points by densh 12y ago

deleted 12y ago
[deleted]
heathermiller 12y ago
Or, said another way, Scala now officially runs on both the JVM and in the browser.
- scorpwarp23 12y ago
  Yea. However, wouldn't you think that the current trend in JavaScript makes this a confusing endeavour in terms of what the end result really is?
  - heathermiller 12y ago
    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.
    - vander_elst 12y ago
      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.
      - wildthing84 12y ago
        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.
        mercurial 12y ago
        > 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.
        colin_jack 12y ago
        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.
        stakent 12y ago
        Try Facebook's flow. http://flowtype.org/ http://flowtype.org/
        colin_jack 12y ago
        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.
        brudgers 12y ago
        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.
      - wildthing84 12y ago
        The other 3 languages being HTML, CSS & JS
      - Peaker 12y ago
        If you care about the learning curve: Take a look at https://github.com/sinelaw/inferno 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.
        lmm 12y ago
        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?
        Peaker 12y ago
        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.
- tootie 12y ago
  Am I correct in my inference that Scala in the browser cannot import Java classes? Meaning this isn't some backdoor to a Java-to-JavaScript compiler?
  - sjrd 12y ago
    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 http://lihaoyi.github.io/hands-on-scala-js/#JavaAPIs for a mostly exhaustive list so far)
  - bad_user 12y ago
    To add to what @sjrd said, while you cannot import Java classes, porting Java code to Scala.js is way easier than porting to Javascript ;-)
  - bad_user 12y ago
    To add to what @sjrd said, while you cannot import Java classes, porting Java code to Scala.js is way easier than porting to Javascript ;-)
scorpwarp23 12y ago
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?
- densh 12y ago
  You can still use all of your favourite JS libraries in Scala similarly to how one can can use Java libraries on JVM. http://www.scala-js.org/doc/calling-javascript.html http://www.scala-js.org/doc/calling-javascript.html
- brudgers 12y ago
  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.
drapper 12y ago
More and more languages have that now (F#, Ceylon, Haxe,...), I wonder how well it works in practice, especially in terms of: - libraries availability - code size and speed - debugging capabilities - ...and interoperability with JS (I recall that F# uses TypeScript definition files, that's a nice approach) Anyone has more experience with it?
- john2x 12y ago
  Link to F#-to-JS compiler?
  - quarterto 12y ago
    http://funscript.info/ http://funscript.info/
  - desdiv 12y ago
    FunScript: https://github.com/ZachBray/FunScript/ https://github.com/ZachBray/FunScript/ WebSharper: http://www.websharper.com/ http://www.websharper.com/ Blue Storm: https://www.assembla.com/spaces/bluestorm/wiki/ https://www.assembla.com/spaces/bluestorm/wiki/ I got these from: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
- sjrd 12y ago
  - 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.
kashif 12y ago
oh god! it was fine as an experiment but...
joajoa 12y ago
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/ https://www.defrac.com/ a try.
- adrusi 12y ago
  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.
mercurial 12y ago
I'm curious to know the size of a scala.js hello world program.
- sjrd 12y ago
  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.
- ArturSoler 12y ago
  Simple Scala.js JS "binaries" are quite big (from ~170kb before compression) because they add the part of the Scala standard library that they need. From there, though, output size does not increase fast.
- jducoeur 12y ago
  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...
  - Cyph0n 12y ago
    Thanks for the perspective. It seems like a viable option for the frontend of my planned product, which I hope to write in Scala + Play.
- smandou 12y ago
  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).
  - EugeneOZ 12y ago
therockhead 12y ago
How much of Scala and its APIs can be used? For example can you use Scala Actors in Scala.js?
noelwelsh 12y ago
I was very sceptical of Scala.js, but decided to use it in a low risk project (http://github.com/underscoreio/doodle 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.
- desdiv 12y ago
  Google is developing SoundScript 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.
  - DomBlack 12y ago
    Don't forget the Google Closure compiler in advance mode.
  - SanderMak 12y ago
    Also AtScript, for the upcoming Angular 2.0: https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/ https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...
  - noelwelsh 12y ago
    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.
julius 12y ago
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?
- sjrd 12y ago
  - 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 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 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 https://github.com/lihaoyi/scalatags), but at some point there was a proof of concept showing it was possible to implement with macros.
  - danieldisu 12y ago
    You have an alternative with a more closer syntax to the original one. https://github.com/xored/scala-js-react https://github.com/xored/scala-js-react
- caente 12y ago
  - 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) I owe you the bonus question :-P
725686 12y ago
Stop the programming language proliferation madness!
jsight 12y ago
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.
- noelwelsh 12y ago
  Reflection is very much the last option when using Scala, as it breaks the ability to statically reason about code.
  - nowxue 12y ago
    Yes, I agree. Although using macros is not as easy.
    - danellis 12y ago
      It's getting easier all the time, though. The interpolators (q etc) are great!
- densh 12y ago
  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. [1] http://docs.scala-lang.org/overviews/macros/overview.html http://docs.scala-lang.org/overviews/macros/overview.html [2] http://lampwww.epfl.ch/~hmiller/pickling/ http://lampwww.epfl.ch/~hmiller/pickling/
- adrusi 12y ago
  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. Maybe someone can explain this.
apo 12y ago
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. Is this possible in Scala.js?
- densh 12y ago
  Yes, this is possible. http://www.scala-js.org/doc/export-to-javascript.html http://www.scala-js.org/doc/export-to-javascript.html
  - apo 12y ago
    Exactly what I was looking for, thanks!
- euroclydon 12y ago
  Are you saying that Scala.js ships with a Scala VM in JS, like EMScripten?
  - sjrd 12y ago
    No, it doesn't. Scala.js is a compiler that emits .js code from your .scala code. There is no layer between the JS VM and that .js code.
wampler 12y ago
Is Scala.js recommended for small apps? Say something like Hello World?
- sjrd 12y ago
  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.
nowxue 12y ago
This is awesome, thanks to the scala.js team and community for the hard work.
cmstoken 12y ago
Looks like I'm gonna have to ditch React and IO now. I think those are getting outdated. Will be rewriting all apps in Scala.js.
- ignoramous 12y ago
  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... [0] http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html http://www.oracle.com/technetwork/articles/java/jf14-nashorn...
  - Gurkenmaster 12y ago
    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
aaronmck 12y ago
I can't wait for nice bindings to a JS plotting library (something on top of D3). One of the big missing parts of Scala for analysis...
- qiemem 12y ago
  Here you go: https://github.com/quantifind/wisp https://github.com/quantifind/wisp
Taig 12y ago
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.
- frowaway001 12y ago
  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.
kybernetikos 12y ago
> 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.
- frowaway001 12y ago
  Error highlighting is usually instantaneous.
  - kybernetikos 12y ago
    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.

337 points by densh 12y ago

deleted 12y ago

[deleted]

heathermiller 12y ago

Or, said another way, Scala now officially runs on both the JVM and in the browser.

scorpwarp23 12y ago
Yea. However, wouldn't you think that the current trend in JavaScript makes this a confusing endeavour in terms of what the end result really is?
- heathermiller 12y ago
  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.
  - vander_elst 12y ago
    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.
    - wildthing84 12y ago
      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.
      - mercurial 12y ago
        > 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.
        colin_jack 12y ago
        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.
        stakent 12y ago
        Try Facebook's flow. http://flowtype.org/ http://flowtype.org/
        colin_jack 12y ago
        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.
      - brudgers 12y ago
        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.
    - wildthing84 12y ago
      The other 3 languages being HTML, CSS & JS
    - Peaker 12y ago
      If you care about the learning curve: Take a look at https://github.com/sinelaw/inferno 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.
      - lmm 12y ago
        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?
        Peaker 12y ago
        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.
tootie 12y ago
Am I correct in my inference that Scala in the browser cannot import Java classes? Meaning this isn't some backdoor to a Java-to-JavaScript compiler?
- sjrd 12y ago
  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 http://lihaoyi.github.io/hands-on-scala-js/#JavaAPIs for a mostly exhaustive list so far)
- bad_user 12y ago
  To add to what @sjrd said, while you cannot import Java classes, porting Java code to Scala.js is way easier than porting to Javascript ;-)
- bad_user 12y ago
  To add to what @sjrd said, while you cannot import Java classes, porting Java code to Scala.js is way easier than porting to Javascript ;-)

scorpwarp23 12y ago

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?

densh 12y ago
You can still use all of your favourite JS libraries in Scala similarly to how one can can use Java libraries on JVM. http://www.scala-js.org/doc/calling-javascript.html http://www.scala-js.org/doc/calling-javascript.html
brudgers 12y ago
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.

drapper 12y ago

More and more languages have that now (F#, Ceylon, Haxe,...), I wonder how well it works in practice, especially in terms of: - libraries availability - code size and speed - debugging capabilities - ...and interoperability with JS (I recall that F# uses TypeScript definition files, that's a nice approach) Anyone has more experience with it?

john2x 12y ago
Link to F#-to-JS compiler?
- quarterto 12y ago
  http://funscript.info/ http://funscript.info/
- desdiv 12y ago
  FunScript: https://github.com/ZachBray/FunScript/ https://github.com/ZachBray/FunScript/ WebSharper: http://www.websharper.com/ http://www.websharper.com/ Blue Storm: https://www.assembla.com/spaces/bluestorm/wiki/ https://www.assembla.com/spaces/bluestorm/wiki/ I got these from: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
sjrd 12y ago
- 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.

kashif 12y ago

oh god! it was fine as an experiment but...

joajoa 12y ago

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/ https://www.defrac.com/ a try.

adrusi 12y ago
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.

mercurial 12y ago

I'm curious to know the size of a scala.js hello world program.

sjrd 12y ago
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.
ArturSoler 12y ago
Simple Scala.js JS "binaries" are quite big (from ~170kb before compression) because they add the part of the Scala standard library that they need. From there, though, output size does not increase fast.
jducoeur 12y ago
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...
- Cyph0n 12y ago
  Thanks for the perspective. It seems like a viable option for the frontend of my planned product, which I hope to write in Scala + Play.
smandou 12y ago
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).
- EugeneOZ 12y ago

therockhead 12y ago

How much of Scala and its APIs can be used? For example can you use Scala Actors in Scala.js?

noelwelsh 12y ago

I was very sceptical of Scala.js, but decided to use it in a low risk project (http://github.com/underscoreio/doodle 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.

desdiv 12y ago
Google is developing SoundScript 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.
- DomBlack 12y ago
  Don't forget the Google Closure compiler in advance mode.
- SanderMak 12y ago
  Also AtScript, for the upcoming Angular 2.0: https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/ https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...
- noelwelsh 12y ago
  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.

julius 12y ago

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?

sjrd 12y ago
- 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 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 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 https://github.com/lihaoyi/scalatags), but at some point there was a proof of concept showing it was possible to implement with macros.
- danieldisu 12y ago
  You have an alternative with a more closer syntax to the original one. https://github.com/xored/scala-js-react https://github.com/xored/scala-js-react
caente 12y ago
- 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) I owe you the bonus question :-P

725686 12y ago

Stop the programming language proliferation madness!

jsight 12y ago

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.

noelwelsh 12y ago
Reflection is very much the last option when using Scala, as it breaks the ability to statically reason about code.
- nowxue 12y ago
  Yes, I agree. Although using macros is not as easy.
  - danellis 12y ago
    It's getting easier all the time, though. The interpolators (q etc) are great!
densh 12y ago
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. [1] http://docs.scala-lang.org/overviews/macros/overview.html http://docs.scala-lang.org/overviews/macros/overview.html [2] http://lampwww.epfl.ch/~hmiller/pickling/ http://lampwww.epfl.ch/~hmiller/pickling/
adrusi 12y ago
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. Maybe someone can explain this.

apo 12y ago

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. Is this possible in Scala.js?

densh 12y ago
Yes, this is possible. http://www.scala-js.org/doc/export-to-javascript.html http://www.scala-js.org/doc/export-to-javascript.html
- apo 12y ago
  Exactly what I was looking for, thanks!
euroclydon 12y ago
Are you saying that Scala.js ships with a Scala VM in JS, like EMScripten?
- sjrd 12y ago
  No, it doesn't. Scala.js is a compiler that emits .js code from your .scala code. There is no layer between the JS VM and that .js code.

wampler 12y ago

Is Scala.js recommended for small apps? Say something like Hello World?

sjrd 12y ago
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.

nowxue 12y ago

This is awesome, thanks to the scala.js team and community for the hard work.

cmstoken 12y ago

Looks like I'm gonna have to ditch React and IO now. I think those are getting outdated. Will be rewriting all apps in Scala.js.

ignoramous 12y ago
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... [0] http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html http://www.oracle.com/technetwork/articles/java/jf14-nashorn...
- Gurkenmaster 12y ago
  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

aaronmck 12y ago

I can't wait for nice bindings to a JS plotting library (something on top of D3). One of the big missing parts of Scala for analysis...

qiemem 12y ago
Here you go: https://github.com/quantifind/wisp https://github.com/quantifind/wisp

Taig 12y ago

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.

frowaway001 12y ago
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.

kybernetikos 12y ago

> 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.

frowaway001 12y ago
Error highlighting is usually instantaneous.
- kybernetikos 12y ago
  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.