This is a game changer. I've used it over the last few 3 or 4 months, and it is really stable and usable. I am betting an entire (although academic) project on it: http://proofpeer.net (note that Clojure is mentioned there as a language of choice, but I switched to Scala since then as Scala provides a similar level of conciseness with all the goodies of a powerful static type system with support for both Java and Javascript).
Wow! I started working on a very similar idea half a year ago -- with machine learning and everything (my domain was proofgraph.org). I had to suspend it since it is larger than a one mans freetime project. I am very glad that someone started with a similar idea!
Will it be open source? I would be happy to contribute (I work full-time with Scala).
I like static typing, but do you ever get the feeling that we've collectively gone off the deep end with the whole backwards compatibility hacks that compile-to-javascript languages represent? Think about it...we have implementations of static languages on top of a dynamic runtime that translates it back to a static runtime. We have non-GC languages that have developed ways to compile to a GC language and avoid GC. It is absolutely amazing, and completely silly at the same time.
Indeed. It's almost as if the ECMA should just freeze all JavaScript development, and replace it with a standard, low level, high performance compiler target that all browsers can implement instead, and then just let the industry/community write competing compiled languages for it. That's essentially where browsers are heading anyway with asm.js and NACL.
For everyone who still loves JS and prefers it over Coffee/Type/Clojure/etc-scripts, just make a JS compiler and keep all its quirks and wtfs.
I also keep thinking of it as a game changer. Why ever bother with prototypes again when you have case classes, or callbacks when you have function shorthands. I fully expect Scala.js code to be more concise and maintainable than Javascript code, and will probably perform better too thanks to the Closure compiler.
I remember how years ago I complained about how Javascript was the only language aviable for the web.
Nowadays you can even run sliced bread on Javascript... though, wouldn't it be better to focus on developing languages on top of asm.js or PNacl so we wouldn't rely on JS?
I completely agree. While asm.js has its problems, its moving in the right direction. Honestly, it seems like this wouldn't be too hard to add a backend target for asm.js, if its implemented well.
Note that asm.js (and probably PNaCL as well) currently offers very little for languages like Scala that need good GC. Until that's addressed simply targeting JavaScript is going to be best approach for these languages.
I don't think running a garbage collected languages on asm.js will ever make any sense (since it would mean implementing and shipping your own GC as part of the application source). So, yeah, you're right. Scala (as-is) is not a good language to target any of the "native" targets like asm.js.
The second one has some performance issues, and bugs out initially when first opened in FF (need to refresh before it works properly) but otherwise it's pretty fun =)
Mmmmm basically I think it's because Scala itself is in a really captivating position, so seeing these utilities emerge makes it that much more promising.
I've switched from RoR to Scala on Play framework and at this point it's one of those things where you use & say "this is sick" but are still discouraged because the community is so small in comparison.
But with Akka, with the Typesafe Console & other niceties you realize "hm.. well... maybe the community isn't as large but they are prepping the toolset to be immensely powerful". And here is one more tool on that belt. I'm sure the reason is different for others, but just note that Scala is a JVM language competing in the same space as Ruby/Python, as well as with some of the functional languages. That alone is huge and making it a great general purpose language.
In my mind, Akka is the reason to use Scala right now. Actors are an incredibly powerful abstraction for building highly-concurrent, highly performant systems and the features Akka brings along—remoting, clustering and now event sourcing—make it a fantastic tool for these applications.
But then, I'm a backend developer and Akka is more useful in that realm.
Play still needs some work IMO. It's great if you need the real-time steaming or a very performant web app but otherwise the lack of scaffolding and other features will really slow you down. I love it but it's still early for most uses. If you come in expecting Rails, you'll be disappointed. For instance, you need to write your own authentication layer, Play doesn't provide one.
OTOH, I was able to write a real-time cluster monitor in Play for our Akka-based backend and the streaming component took less time to write than the setting up the app—it's that straightforward.
IMO, if you need them, Play's other features more than make up for its less polished aspects and I fully expect those to get fixed in time, especially now that Typesafe has brought Play under its wing.
In regard to missing components, the goal is not to provide the kitchen sink, but rather the tools to build your house.
This is where RoR, Django, etc. differ from Play. Play just provides the basic MVC stack along with essentials like, modular routing (AKA sub projects), excellent form generation and validation, http request wrappers (AKA action composition) for say, authentication ;-), an OK template layer (could be better, generics not supported), etc.
Agreed, Play will not give you the rapid fire dynamic language based framework development experience, not while getting your feet wet at any rate.
On the flipside, you've got the JVM ecosystem at your finger tips, a static type system backing your every (errant) move, blazing fast performance in production, and general zero-stress on deploy, the shit just works.
yeah i agree it may not be ultra-streamlined for rapid application development yet, but i don't have any critical work i need to do with it. to me it's really just an excuse to learn Akka. When I read about Netflix's async Java libraries (RxJava I think its called) I realized how the Java world really has an edge in making advanced web apps.
The more polished frameworks are better for building apps quickly, sure, but as a technically-oriented developer (I am full-stack, usually above DSL) I'm more interested in making my mark by understanding some useful persistence/eventing/concurrency stuff. If we can master this, I believe it will be the thing that finally brings a unified model to web app development that simplifies the entire end-to-end flow without requiring redundant code or limited choices about persistence scopes.
It's strange that they don't have some scaffolding and authentication features, but as you said they'll come in time. It's just odd because they are on the more trivial end of the toolset.
But that doesn't turn me off and maybe that's the point. It's not really meant for someone trying to make a CRUD app. Sure it should and will be able to do this well, but to me the JVM is the place where people are really trying to dig past CRUD and get to some novel data-and-event-driven apps.
Lucky for me this is something I'm learning as a hobby so I don't have to support production-level apps with it anyway. But yeah to me it feels like they've taken a lot of the attractive features of Django/RoR and backed them with some more serious language features. This may be a bit delusional since I guess Ruby & Python are legitimate in their own right, but.... well, as you can tell, I'm more excited for a JVM language to try to introduce stronger modern design patterns into the framework world. MVC on it's own is dead & done (er... solved), it's the extra unifying logic layers that are more important now.
heh here is where i need to apologize for not paying attention to .NET :(
i had a bad experience with it in my early days of webdev. moreso my fault than microsoft, but by the time it was over i was firmly lodged in the open source world.
Netflix has many other cool Java libs besides just RxJava, but by all means give credit where credit is due. Interesting to know
I've used Akka with Java. It certainly works but it's a bit of a pain just because Java is so verbose. Some features like the FSM helper aren't available in Java either.
I'm sure this is going to read as dickish, but I personally would be much more inclined to give a thoughtful response if your question showed some evidence of you having attempted to explore this question before asking other people to spoon feed you answers.
This is really one of those questions that _requires_ someone to spoon feed you the answer.
He is asking a Scala expert to describe how a port to JavaScript allows developers to take advantage of advanced Scala language features or tools. The alternative is spending hours working with Scala and coming up with the answer himself.
Being a discussion forum, I don't see why you have a problem giving away knowledge freely over HN.
I've got no problem at all answering people's questions, if you look at my comment history. I just think this particular question was both vague and lazily written. It's natural that a question requires more effort to answer than to ask, but a thoughtfully asked question clues potential answerers into what the asker already knows and has already attempted to do to educate themselves. Like "I know Scala is X and Y, but why would these things be useful on the browser side?" or if you don't know anything about Scala in the first place, "I read Wikipedia about Scala but didn't understand Z, could someone explain this?"
You're looking for a sales pitch for Scala? I can't provide that, but I'd argue that having the same language on two rather different platforms is pretty cool/useful in any case.
I'm finding a sort of corollary of JavaScript being a byte-code equivalent for the web, what with everything being translated to compilation in js syntax.
Maybe the browsers need to move beyond JavaScript interpretation, and think about things more like a VM to allow actual scala/java/c#/ruby/python/erlang/lua/something-completely-new/etc. to be executed in context.
Or, maybe a more forward-thinking approach would be to consider "docker in the browser" -- containers that run in execution. Probably a performance nightmare, but I'm thinking of an interesting compilation of bits -- CMS done well in Ruby, an e-commerce cart in Python, data charts in Erlang, and enterprise-based workflows in Java -- all working together, client-side.
Disclaimer: it's a holiday and I'm enjoying a nice cabernet sauvignon. Thought clarity and consistency may not necessarily be present at this point in time.
I wonder how complicated it is to parse JSON in Scala.js. It's pretty involved in regular Scala and incredibly easy in JavaScript, so what's it like in Scala.js?
There's also Play-Json, Spray-Json, various wrappers for Jackson and a few others I don't remember. We use Play-Json and its macros a lot at the company I work for and I contributed a performance fix for it a while back. I wouldn't consider Play's JSON inception to be "pretty involved" at all if you're using case classes.
JSON is always going to be a bit more difficult to parse in statically typed languages than dynamically typed ones.
The amusing part is that most APIs use JSON as if it were statically typed - except for null/undefined, very few APIs return values of more than one possible type for a given key[0].
It doesn't always have to be so bad, though, even in statically typed languages. For example, I created a tool in Go to automatically generate struct definitions, given an example JSON response: https://github.com/ChimeraCoder/gojson
In the time that I've been using it (since last December), I don't think I've run into any issues with an API returning an incorrect type for a particular key[1].
[0] For the record, I'm not complaining. The alternative would be a nightmare to deal with.
[1] Though they do sometimes return a different object altogether; this is an issue regardless of which type system you use.
Given that it uses reflect I bet your library very slow. I wonder how it compares to parsing JSON in Python or node.js.
> except for null/undefined,
That's not a small issue.
Not only do JSON responses for API's vary a great deal from request to request, some handle errors without HTTP response code's. So the JSON you get back can be very different then you might expect otherwise.
> Given that it uses reflect I bet your library very slow.
Look carefully - what I wrote is not a library; it's a standalone binary. It's run exactly once, when you write the code, so speed isn't an issue.
> That's not a small issue.
Depends on the language. In Go, it's very easy to allow a JSON value to be null and/or undefined by making the value it unmarshals to a pointer (which you should be doing already anyway).
What's harder (in most languages, not just Go) is dealing with a value that could be (say) either a string, or a 64-bit int. Or, worse, a string whose value just happens to be a 64-bit number. When that happens (which is thankfully rare), it breaks the "JSON should be self-documenting" motto.
> So the JSON you get back can be very different then you might expect otherwise.
This is an issue no matter what language you use. You have to know what the set of possible response structures is in order to know what keys to query/access.
Incidentally, the one place I often have to deal with values of different types for the same key is from a java app that is poorly converting XML -> JSON and converts a list with a single element into just the element.
Scala's compile times (along with other aspects of its development experience) are among my biggest annoyances with the language. It just seems like it should be way better than it is for such an intellectually advanced language.
I've been investing a lot of time in learning Scala because I think that it's at the head of the vanguard of a software engineering revolution, but with some of its ergonomic issues, I can't help thinking it's eventually going to lose out to something that's more elegant from a design standpoint and has better tooling.
Lightly? I'd say one of the most important features were removed - implicits and most of the typesystem magic. Kotlin feels just like Java with lambdas, better null checking. slightly improved generics and some minor syntactic refinements. Most of its "features" will be obsoleted by Java 8.
It's basically equivalent to Scala for the compilation itself (no noticeable difference).
But the browser refresh in dev mode can take up to 5 seconds (or down to under 1 sec, depends on the machine).
There is a tool that helps with this by using clever tricks to refresh the browser without reparsing the standard lib:
https://github.com/lihaoyi/scala-js-workbench
Too bad that there is not more effort on Scala.NET instead of this. Lots of people are comfortable with writing Javascript in the browser so all of these compilers emitting Javascript end up being little more than a technology demo. But Scala on the .NET vm would really fill a gap.
I used to wish for this also. But then I found C# to be pretty good; maybe it doesn't have as many features as Scala, but it is definitely a step up from Java.
The demand for Scala on .NET just doesn't seem to be that large, couple with the fact that reified generics make encoding Scala directly kind of difficult (Nikolay Mihaylov spent a lot of time on that).
How so? I started out in Java, then did a lot of Scala for a couple of years, and have been mainly working in C# for the last 6 years afterwards. The only things I miss from Java are anonymous inner classes and some of the better debugging features (hot code replace) that Visual Studio hasn't really matched yet (edit and continue is not as robust).
I miss many things from Scala in comparison, but C# has some good features that almost make up for it.
F# is primarily functional, Scala is much more of a hybrid of both OO and FP; so Scala has things like traits that are actually advanced OOP constructs, while F# tries to push you more in the direction of pure FP.
The tradeoffs are different also. F# focuses a lot on performance in the spirit of Caml, whereas Scala is a bit more free to dive into more powerful features that go against that spirit. This is my grock at least of my conversations with Don and Martin over lunch when Don was doing his sabbatical at EFPL.
Why would you need anything on .net which already runs on the JVM? Is there any platform where you can install .net but not the JVM? Or does .net have a significantly better performance than the JVM?
Wouldn't it be a direct competitor for F# then instead of "filling the gap"? Scala has some more features, but the idea of fast and expressive functional-oop language is basically the same for both of them.
Also, F# was there first, has very good support in IDEs, integration with core .NET, etc. I think Scala would have a rather hard time on CLR (I may be biased, I don't know Scala very much and I worked with OCaml long before F# happened).
IIRC, Scala.NET was basically killed by the fact that .NET reified generics and Scala's generics are pretty fundamentally incompatible, which means a .NET implementation of Scala would either not be very Scala or not have a good .NET interop story.
Scala integrates OOP and FP in a truly elegant way, F# is mostly FP with some OO bolted on it as an afterthought, and C# is much closer to Java than to Scala. You may argue whether Scala is really more expressive than F# (IMHO it is), but regardless of it, they are not the same thing.
F# doesn't have "OO bolted on it as an afterthought". Sure, F# strongly favors the FP approach to things, but the language's OO features are important -- critical, even. Without support for OO programming, F# wouldn't be able to easily consume existing .NET (C#, VB.NET, etc.) libraries, nor would you be able to use F# to implement components/libraries to be easy consumed by C#. The ease of interop'ing with C# is one of F#'s best features, IMO, and an important part of the wider adoption it's now seeing.
True, but its main target is definitely the browser. The stand-alone interpreter of Node.js can run code written in Scala.js, and is actually used for benchmarks (along with d8) [1]. However, Scala.js does not emit Node.js modules, nor does it provide any built-in way to import other Node.js modules.
Javascript is obviously Turing-complete, so it is as powerful as any other language, and you can implement any other programming language on top of it.
The trick is not wasting too much performance while doing that. Fortunately Javascript performance is already not bad, and specific subsets like asm.js can have their performance optimized even further.
So your question is not unlike "what an x86 command set cannot do?", just for a 50-100x slower command set.
Not completely true, you already have WebWorkers, and if you're targeting, say, JavaScriptCore on iOS and OS X Mavericks then threads are an option via running multiple JS Virtual Machines - JSValues may be passed between them.
Fun stuff, but again, doesn't come with any tools. Microsoft Typescript is much better on that matter.
What javascript universe needs right now is not some more of syntactic sugar clusterfuck followed by debugging nightmare, but real tools, static code analysis. I don't want to waste my precious time dealing with closure compiler+scala something combo.
It's fun from programmers POV, but still it won't make me pay my bills!
