Live data from Hacker News

Scala.js no longer experimental

scala-lang.org

21–30 of 135 posts

Re: Scala.js no longer experimental

#21
post #9

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?

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

Re: Scala.js no longer experimental

#22
post #15
post #9

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?

Link to F#-to-JS compiler?

http://funscript.info/

Re: Scala.js no longer experimental

#23
post #15
post #9

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?

Link to F#-to-JS compiler?

FunScript: https://github.com/ZachBray/FunScript/

WebSharper: http://www.websharper.com/

Blue Storm: https://www.assembla.com/spaces/bluestorm/wiki/

I got these from: https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

Re: Scala.js no longer experimental

#24
post #9

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?

How about running Scala in multiple threads? And how about dealing with structurally-shared data?

Re: Scala.js no longer experimental

#25
post #24
post #9

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?

How about running Scala in multiple threads? And how about dealing with structurally-shared data?

You don't run code in multiple threads, but Scala's ExecutionContext is not about threads, but about asynchronous execution and JS is fine with that.

Also, all of Scala's collections, including the persistent ones are supported.

Re: Scala.js no longer experimental

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

Re: Scala.js no longer experimental

#27

Earlier quoted context omitted.

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

Re: Scala.js no longer experimental

#28
post #24

Earlier quoted context omitted.

How about running Scala in multiple threads? And how about dealing with structurally-shared data?

You don't run code in multiple threads, but Scala's ExecutionContext is not about threads, but about asynchronous execution and JS is fine with that. Also, all of Scala's collections, including the persistent ones are supported.

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.

Re: Scala.js no longer experimental

#29

Earlier quoted context omitted.

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.

If you care about the learning curve:

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.

Re: Scala.js no longer experimental

#30

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

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

Post reply on HN