4 ms·

I've been watching Clojure for a while, and I love the spirit of this work. However, as a framework author, I feel obliged to point out that of course you can

I've been watching Clojure for a while, and I love the spirit of this work. However, as a framework author, I feel obliged to point out that of course you can create a more expressive and performant UI framework in a language with S-expressions, macros, and value semantics. What's hard is doing it in JavaScript. :) It also feels a bit like reverse logic to cite ever-faster JavaScript VMs as a reason to choose a new framework for performance reasons -- shouldn't it matter less exactly how you structure your application logic when you're running on a "fusion reactor"? -- but I realize there's some subtlety here about lower constants enabling better algorithms. (Still, if your framework includes a language compiler or gets to take advantage of an expressive macro system, it should be able to run on anything.) Once it's possible to compile ClojureScript without booting up a JVM -- which could happen if it becomes self-hosting -- I'll make a Meteor package for it. I'd also like to see the compile times get a little shorter and the runtime library get a little smaller.

rads 13y ago
The main features David talks about in the post are available in vanilla JavaScript: > If you're a JavaScript developer, I think taking a hard look at React is a really good idea. I think in the future, coupling React with a persistent data structure library like mori could bring JS applications all the way to the type of flexible yet highly-tuned architecture that Om delivers. I think there are a couple reasons Mori and other libraries like it haven't caught on in the JS mainstream: 1. It's clunky to use them in vanilla JS compared to the default mutable objects and arrays. While you gain simpler semantics, the code becomes harder to read, and that tradeoff isn't always worth it. 2. Most JS developers are not experienced with building programs around immutable values.
- phineas 13y ago
  would you mind simply explaining a little more what an immutable value is? I Understand immutable as something that cannot be changed. > all of our collections are immutable How can a collection which is data that eventually ties into a db be unchangeable?
  - mnicky 13y ago
    http://en.wikipedia.org/wiki/Persistent_data_structure http://en.wikipedia.org/wiki/Persistent_data_structure :)
  - graue 13y ago
    Think of strings in JavaScript. Those are already immutable: var fooString = "foo"; var secondFooString = fooString; secondFooString; // => "foo" fooString = "bar"; secondFooString; // => "foo" We set the variable fooString to point to a different string, but the original, underlying string hasn't changed. In JavaScript, we can think of a string as a value. This is not the case with arrays in JavaScript: var firstArray = [1, 2, 3]; var secondArray = firstArray; firstArray[0] = 100; firstArray; // => [100, 2, 3] secondArray; // => also [100, 2, 3] Because we can change the underlying contents of the array, an array in JavaScript isn't a value. It's a place: a reference to a location in memory. The underlying value could be changed at any time. But, using Mori, collections are values, just like strings: var firstVec = m.vector(1, 2, 3); var secondVec = firstVec; firstVec = m.assoc(firstVec, 0, 100); firstVec; // => [100, 2, 3] secondVec; // => still [1, 2, 3] Instead of modifying firstVec in place, mori.assoc creates a new vector that is identical to firstVec except for the change we want. We then assign the result to firstVec. secondVec is unchanged. We are unable to go in and change the underlying values because a vector is a value, not a place. The most obvious way to build this would be to deep-copy the entire collection when it's changed, but that would of course be way too slow and wasteful — imagine copying a one-million-long array just to change one element. Clojure, ClojureScript and Mori minimize unnecessary copying using a very thoughtfully designed data structure you can read about here: http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-... The short story is that, surprisingly, you get "effectively O(1)" copying when you use assoc.
- dgreensp 13y ago
  That's true, on all counts. Meteor could use Miro inside minimongo on the client, for example, and turn objects into vanilla JS before passing them to the app, if that implementation offered significant performance benefits (or equal or better performance and cleaner code, though the size of the Miro payload would also have to be weighed). Once the app has to deal with Miro objects, though, it starts to feel less like the JavaScript people know.

rads 13y ago

The main features David talks about in the post are available in vanilla JavaScript: > If you're a JavaScript developer, I think taking a hard look at React is a really good idea. I think in the future, coupling React with a persistent data structure library like mori could bring JS applications all the way to the type of flexible yet highly-tuned architecture that Om delivers. I think there are a couple reasons Mori and other libraries like it haven't caught on in the JS mainstream: 1. It's clunky to use them in vanilla JS compared to the default mutable objects and arrays. While you gain simpler semantics, the code becomes harder to read, and that tradeoff isn't always worth it. 2. Most JS developers are not experienced with building programs around immutable values.

phineas 13y ago
would you mind simply explaining a little more what an immutable value is? I Understand immutable as something that cannot be changed. > all of our collections are immutable How can a collection which is data that eventually ties into a db be unchangeable?
- mnicky 13y ago
  http://en.wikipedia.org/wiki/Persistent_data_structure http://en.wikipedia.org/wiki/Persistent_data_structure :)
- graue 13y ago
  Think of strings in JavaScript. Those are already immutable: var fooString = "foo"; var secondFooString = fooString; secondFooString; // => "foo" fooString = "bar"; secondFooString; // => "foo" We set the variable fooString to point to a different string, but the original, underlying string hasn't changed. In JavaScript, we can think of a string as a value. This is not the case with arrays in JavaScript: var firstArray = [1, 2, 3]; var secondArray = firstArray; firstArray[0] = 100; firstArray; // => [100, 2, 3] secondArray; // => also [100, 2, 3] Because we can change the underlying contents of the array, an array in JavaScript isn't a value. It's a place: a reference to a location in memory. The underlying value could be changed at any time. But, using Mori, collections are values, just like strings: var firstVec = m.vector(1, 2, 3); var secondVec = firstVec; firstVec = m.assoc(firstVec, 0, 100); firstVec; // => [100, 2, 3] secondVec; // => still [1, 2, 3] Instead of modifying firstVec in place, mori.assoc creates a new vector that is identical to firstVec except for the change we want. We then assign the result to firstVec. secondVec is unchanged. We are unable to go in and change the underlying values because a vector is a value, not a place. The most obvious way to build this would be to deep-copy the entire collection when it's changed, but that would of course be way too slow and wasteful — imagine copying a one-million-long array just to change one element. Clojure, ClojureScript and Mori minimize unnecessary copying using a very thoughtfully designed data structure you can read about here: http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-... The short story is that, surprisingly, you get "effectively O(1)" copying when you use assoc.
dgreensp 13y ago
That's true, on all counts. Meteor could use Miro inside minimongo on the client, for example, and turn objects into vanilla JS before passing them to the app, if that implementation offered significant performance benefits (or equal or better performance and cleaner code, though the size of the Miro payload would also have to be weighed). Once the app has to deal with Miro objects, though, it starts to feel less like the JavaScript people know.