Hacker News new | ask | show | jobs
by vander_elst 4147 days 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.
3 comments

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.

Try Facebook's flow.

http://flowtype.org/

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.

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.

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 other 3 languages being HTML, CSS & JS