Live data from Hacker News

Scala.js no longer experimental

scala-lang.org

11–20 of 135 posts

Re: Scala.js no longer experimental

#11

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.

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.

Re: Scala.js no longer experimental

#12

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.

The other 3 languages being HTML, CSS & JS

Re: Scala.js no longer experimental

#14

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 w…

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.

Re: Scala.js no longer experimental

#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?

Re: Scala.js no longer experimental

#16

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.

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

Re: Scala.js no longer experimental

#18

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

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.

Re: Scala.js no longer experimental

#19

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

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.

Re: Scala.js no longer experimental

#20

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.

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.

Post reply on HN