

Scala.jsFiddle: TodoMVC - lihaoyi
http://www.scala-js-fiddle.com/gist/9362801

======
royjacobs
I have to say this seems like an extremely elaborate hammer for a tiny nail.
The question is: If you have an application that is much less trivial than
this one, will the complexity scale accordingly or will it only increase
gradually?

The X-to-Javascript tools work best if the language actively embraces the
Javascript roots (TypeScript, CoffeeScript, etc) instead of trying to hide it
in abstractions. Sure, it's convenient to be able to use Scala collections but
do you really need to? Granted, this can be said of anything ("Do you need to
use C when there's asm?") but whenever you'll do something complex in a
language like this: At some point you'll have to debug, and that's the point
where you need to somewhat understand the underlying abstraction.

~~~
asolove
> The X-to-Javascript tools work best if the language actively embraces the
> Javascript roots

I don't think this is true. X-to-Javascript tools work best when they are
well-designed to fit both the norms of the original language and to solve the
problems of building user interfaces. JavaScript does that, so embracing JS
gets you lots of libraries, patterns, and design experience for free.

But it's also possible to create good designs in other ways. I'm quite fond of
ClojureScript, with its immutable data and pure functions. But using it with
the mutable DOM patterns forced me to choose between speed and writing
idiomatic Clojure. Now that we have ReactJS, I can write my interface as a
mostly-pure function over data, and have React do the heavy lifting of
figuring out how to update the DOM quickly.

This was a much longer route to get to a good design, but I think it's a much
nicer way to build web UIs.

The problem with Scala.js is it doesn't seem to have this same level of design
inspiration. It has the nice parts of Scala, and the warts of the DOM, and the
two don't even fit together the way that JS fits the DOM.

------
weego
As a Scala contractor I fear the day I turn up to a job and get presented with
a frontend layer that looks like that. The notion of a DSL in LanguageX ->
JavaScript is an interesting research project, but if the outcome is not only
way harder to read than LanguageX but also JavaScript it is perhaps a dead-end
street in terms of actual anything good coming out of it.

JavaScript really isn't hard, trying to avoid writing it by writing a more
complex language which gives you more JavaScript than you would have had
anyway really can't ever be a win surely?

~~~
weixiyen
Yeah this is really a waste of time, and it will never pick up. CoffeeScript
is the only language with a shot right now due to popularity.

~~~
erokar
I'd say TypeScript and Dart are contenders as well.

------
candybar
This is amazing! Scala right now doesn't really have a good story in terms of
user-facing apps - it's not impossible to piggy back on Swing and Android, but
that's about it for now. Definitely looking forward to seeing this mature!

As for the haters, there's no real reason at this stage to worry about "why
would you use this for that" \- people said the same thing about Java server-
side (it's slow and on servers, cross-platform doesn't matter), Javascript
server-side (it's single-threaded and clunky and people only use it because
they are forced to), C# for iOS development (but it's from Microsoft), etc,
etc.

------
polskibus
What next? A React integration layer to match Om, perhaps?

~~~
Ygg2
As much as I love idea of Om, I'd still like if there was a JS only version of
it.

~~~
asolove
I think this is pretty possible. You could use Mori [0] or another set of
persistent JS data structures. And you'd need to monkey-patch them to all
support being used as cursors like in Om. That'd be pretty cool for those of
us who can't sneak Clojure in at our day jobs.

[0] [https://github.com/swannodette/mori](https://github.com/swannodette/mori)

~~~
fredyr
What is it that's missing in just using plain React (with Mori or any
alternative)?

In my mind, what Om is bringing to React is idiomatic state management with
Clojure semantics. In js I think the local state model promoted by React is
reasonable.

~~~
Ygg2
Mostly immutability and the ability to update DOM on real changes, I assume.
The immutability comes with nice ability to easily undo things, at expense of
memory.

------
jbeja
Got some performance issues compare to others examples.

------
nikon
Webforms anyone?

