7 ms·

Scala.jsFiddle: TodoMVC

38 points by lihaoyi 13y ago

polskibus 13y ago
What next? A React integration layer to match Om, perhaps?
- Ygg2 13y ago
  As much as I love idea of Om, I'd still like if there was a JS only version of it.
  - asolove 13y ago
    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 13y ago
      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 13y ago
        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.
weego 13y ago
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 13y ago
  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 13y ago
    I'd say TypeScript and Dart are contenders as well.
  - untog 13y ago
    Right now, yes. I say this as a developer that works primarily in CoffeeScript - I wonder if, when ES6 is finally available to all, interest in CoffeeScript will wane. Certainly half the reason I'm using it is to avoid some of the warts in JS.
- kybernetikos 13y ago
  > 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? I've had massive business value from writing code in a more type safe language and then transpiling it into a number of other languages, including javascript.
- actsasbuffoon 13y ago
  I get your point, but to play Devil's Advocate: Assembly is about as simple as it gets. The venerable 6502 chip only had around 40 instructions. At one point it was the most popular programming language in the world (if you clump all the variants together). Every other programming language you can write just gets compiled down into more Assembly than you would have if you just wrote Assembly by hand, and it will probably be less efficient. Yet despite all of that, there are very clearly some big wins to be had by writing in those other languages.
royjacobs 13y ago
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 13y ago
  > 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.
nikon 13y ago
Webforms anyone?
jbeja 13y ago
Got some performance issues compare to others examples.
candybar 13y ago
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.

38 points by lihaoyi 13y ago

polskibus 13y ago

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

Ygg2 13y ago
As much as I love idea of Om, I'd still like if there was a JS only version of it.
- asolove 13y ago
  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 13y ago
    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 13y ago
      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.

weego 13y ago

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 13y ago
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 13y ago
  I'd say TypeScript and Dart are contenders as well.
- untog 13y ago
  Right now, yes. I say this as a developer that works primarily in CoffeeScript - I wonder if, when ES6 is finally available to all, interest in CoffeeScript will wane. Certainly half the reason I'm using it is to avoid some of the warts in JS.
kybernetikos 13y ago
> 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? I've had massive business value from writing code in a more type safe language and then transpiling it into a number of other languages, including javascript.
actsasbuffoon 13y ago
I get your point, but to play Devil's Advocate: Assembly is about as simple as it gets. The venerable 6502 chip only had around 40 instructions. At one point it was the most popular programming language in the world (if you clump all the variants together). Every other programming language you can write just gets compiled down into more Assembly than you would have if you just wrote Assembly by hand, and it will probably be less efficient. Yet despite all of that, there are very clearly some big wins to be had by writing in those other languages.

royjacobs 13y ago

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 13y ago
> 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.

nikon 13y ago

Webforms anyone?

jbeja 13y ago

Got some performance issues compare to others examples.

candybar 13y ago

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.