Announcing Scala.js v0.1

http://www.scala-lang.org/news/2013/11/29/announcing-scala-js-v0.1.html

by llambda • 13 years ago

171 88 13 years ago

leokun4• 13 years ago

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?

jakozaur2• 13 years ago

Parsing JSON in Scala is very easy with lift-json: https://github.com/lift/lift/tree/master/framework/lift-base...

smenko• 13 years ago

Is this supposed to be ironic? Considering JSON.parse( {a: "B"} )

saryant4• 13 years ago

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.

http://www.playframework.com/documentation/2.2.x/ScalaJson

https://github.com/spray/spray-json

leokun4• 13 years ago

I use argonaut.io and it isn't really hard so much as tedius compared to JavaScript or Python.

alexatkeplar• 13 years ago

Lots of options, see the complete list here: http://stackoverflow.com/a/14442630

We use Argonaut at Snowplow.

auggierose2• 13 years ago

You can just use the Javascript Api's for that. So the answer would be incredibly easy.

tree_of_item• 13 years ago

It's exactly the same as in JavaScript: JSON.parse(...)

Scala has Dynamic types for when you want to play rough like that.

jakozaur2• 13 years ago

For those who haven't heard about it. The initial presentation: http://www.parleys.com/play/51c380bfe4b0ed8770356866/

auggierose2• 13 years ago

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

drewhk• 13 years ago

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

modersky• 13 years ago

It is open source. I am sure the committers would be happy to get additional help.

saosebastiao• 13 years ago

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.

SkyMarshal• 13 years ago

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.

smrtinsert2• 13 years ago

Not at all, there is a great deal of precedence in computer science for building durable interfaces on top of unstable ones.

smrtinsert2• 13 years ago

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.

ghostdiver• 13 years ago

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!

reality check, please

chc• 13 years ago

Have you looked into the tools and amenability of Scala to static analysis and found them lacking?

Also, it seems a bit odd to call Scala "syntactic sugar". It's a pretty unique language in its own right.

fhd22• 13 years ago

I suggest you RTFA, some highlights regarding your fears:

- Integrated with sbt (including support for dependency management and incremental compilation)

- Can be used with your favorite IDE for Scala

- Generates Source Maps for a smooth debugging experience (step through your Scala code from within your browser supporting source maps)

anotherfadjs• 13 years ago

Scala is outside of reality, it's academic diarrhea.

It's nothing but syntactic sugar (more like salt) for Java's async functionality and we all know that anything made from shit is expected to be shit.

krisajenkins• 13 years ago

Anyone know how the compilation times compare with regular Scala?

acjohnson554• 13 years ago

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.

chris_overseas• 13 years ago

Take a look at Kotlin (http://kotlin.jetbrains.org), it was designed to address the issues you mention.

sjrd2• 13 years ago

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

julianduque• 13 years ago

It supports Node.js or is only for web applications?

romanovcode2• 13 years ago

It supports Javascript. Node.Js runs on Javascript.

Draw your conclusions.

sjrd2• 13 years ago

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.

[1] https://github.com/jonas/scalajs-benchmarks

memracom• 13 years ago

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.

seanmcdirmid3• 13 years ago

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

jebblue• 13 years ago

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

I left C# to do Java, Java is a step up from C#.

profquail3• 13 years ago

What niche do you see Scala filling on .NET that isn't already handled by F#?

Case in point, .NET already has FunScript, an F#-to-JS compiler: http://funscript.info/

FunScript also provides a way to do strongly-typed interop with TypeScript, via F#'s type providers.

seanmcdirmid3• 13 years ago

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.

romanovcode2• 13 years ago

Why would you need Scala on .NET when you have F# and C# that are completely the same thing.

pkolaczk2• 13 years ago

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.

dragonwriter2• 13 years ago

Neither F# nor C# are "completely the same thing" as Scala.

peq2• 13 years ago

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?

mdellabitta• 13 years ago

Imagine a polyglot project where some major .Net libraries are already in use, but ongoing development or integration was done in Scala.

I'm not saying it's a good idea, but there's a use case there.

klibertp• 13 years ago

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

dragonwriter2• 13 years ago

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.

lihaoyi• 13 years ago

Fun demos using Scala.js:

http://lihaoyi.github.io/scala-js-games/ http://lihaoyi.github.io/scala-js-game-2/

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 =)

wodenokoto• 13 years ago

As someone who doesn't really know anything about scala, why is this a cool thing?

While such an early release is definitely aimed at scala enthusiast, I'd still like a sales pitch for the rest of us.

fhd22• 13 years ago

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.

acjohnson554• 13 years ago

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.

antoinec• 13 years ago

Anyway, the answer of his questions has definitely its place in this thread, so it's a good thing that someone is asking it.

zschuessler• 13 years ago

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.

fat0wl3• 13 years ago

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.

saryant4• 13 years ago

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.

dysoco• 13 years ago

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?

tkellogg• 13 years ago

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.

swannodette2• 13 years ago

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.

ismail• 13 years ago

Remember to write the slidedbread.js in under 30 lines :)

ShardPhoenix• 13 years ago

This is exactly what I've been hoping for - I'd like to write little games/etc in Scala, but it's a lot easier to distribute JS.

macmac• 13 years ago

They will be adding prefix notation next...

coldcode• 13 years ago

Is there anything Javascript can't do?

nickbarnwell• 13 years ago

Threads.

technomancy• 13 years ago

Precise numerics.

swannodette2• 13 years ago

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.

nine_k• 13 years ago

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.

efnx• 13 years ago

Type safety.

peq2• 13 years ago

ints

myth_drannon• 13 years ago

So now it's Dart vs Scala. Great to have some good options.

haosdent• 13 years ago

I think it's Dart vs ClojureScript vs Scala.

solomatov• 13 years ago

You forgot about GWT.

jroseattle• 13 years ago

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.

Announcing Scala.js v0.1

Related Stories