The Future of JavaScript MVCs

#1

Post by swannodette » Thu, Dec 19, 2013, 7:08 PM UTC

The Future of JavaScript MVCs
swannodette.github.io

Re: The Future of JavaScript MVCs

#2

Post by swannodette » Thu, Dec 19, 2013, 7:23 PM UTC

I apologize that the Om TodoMVC version is a little bit buggy at the moment, I put it together mostly to demonstrate the benefits of the React/Om model and it appears I missed a couple of TodoMVC behavior issues as they weren't important for demonstrating the approach - I'll try to clean up these annoyances later this evening.

Feel free to ask any questions.

Re: The Future of JavaScript MVCs

#3

Post by taybin » Thu, Dec 19, 2013, 7:26 PM UTC

But I just finished rewriting everything in angular!

Re: The Future of JavaScript MVCs

#4

Post by rubiquity » Thu, Dec 19, 2013, 7:27 PM UTC

What about long GC pauses and running for cleaning up all those wonderful immutable data structures? Immutability is great when it's at the forefront of how a language is designed. Plastering immutability all over hot code paths in a language that wasn't designed with immutability in mind isn't great.

Re: The Future of JavaScript MVCs

#5

Post by bretthopper » Thu, Dec 19, 2013, 7:29 PM UTC

There's two big highlights for me:

> Thus we don't need React operations like setState which exists to support both efficient subtree updating as well as good Object Oriented style. Subtree updating for Om starting from root is always lightning fast because we're just doing reference equality checks all the way down.

I don't think anyone actually likes using explicit setters/getters in frameworks like Backbone and Ember. Of course Angular avoids it but that's by the crazy "dirty-checking". Obviously the new Object.observe will help this situation, but I love how simple Om/CLJS makes this.

> This also means that Om UIs get undo for free. You can simply snapshot any state in memory and reinstate it whenever you like. It's memory efficient as ClojureScript data structures work by sharing structure.

> VCR playback of UI state

I can't wait for details on this. This has gotten me really excited about client-side apps again.

Re: The Future of JavaScript MVCs

#6

Post by ibdknox » Thu, Dec 19, 2013, 7:30 PM UTC

rubiquity wrote: post #4

What about long GC pauses and running for cleaning up all those wonderful immutable data structures? Immutability is great when it's at the forefront of how a language is designed. Plastering immutability all over hot code paths in a language that wasn't designed with immutability in mind isn't great.

In practice, unless you're animating at 60fps over hundreds of objects (and who would do that with dom elements?), you shouldn't run into any GC issues. LightTable uses ClojureScript datastructures for pretty much everything and there were only a small handful of cases we had to optimize. Any "normal" application probably won't ever have to.

Re: The Future of JavaScript MVCs

#7

Post by peterhunt » Thu, Dec 19, 2013, 7:33 PM UTC

ibdknox wrote: post #6

rubiquity wrote: post #4

What about long GC pauses and running for cleaning up all those wonderful immutable data structures? Immutability is great when it's at the forefront of how a language is designed. Plastering immutability all over hot code paths in a language that wasn't designed with immutability in mind isn't great.

In practice, unless you're animating at 60fps over hundreds of objects (and who would do that with dom elements?), you shouldn't run into any GC issues. LightTable uses ClojureScript datastructures for pretty much everything and there were only a small handful of cases we had to optimize. Any "normal" application probably won't ever have to.

For a little more color: these objects usually live in the new generation which I've observed doesn't drop frames even on mobile.

You can pull this up on an iPhone 4S or newer (it uses the same technique with tons of allocations but doesn't really drop frames): http://petehunt.github.io/react-touch

Re: The Future of JavaScript MVCs

#8

Post by augustl » Thu, Dec 19, 2013, 7:36 PM UTC

rubiquity wrote: post #4

What about long GC pauses and running for cleaning up all those wonderful immutable data structures? Immutability is great when it's at the forefront of how a language is designed. Plastering immutability all over hot code paths in a language that wasn't designed with immutability in mind isn't great.

Indeed.. Hopefully the VMs of tomorrow will be aware of immutable values, since no pause/coordination is required to GC them.

Re: The Future of JavaScript MVCs

#9

Post by mtrimpe » Thu, Dec 19, 2013, 7:37 PM UTC

I've been expecting this after seeing a few of your teaser tweets and as expected I absolute love it! I've been waiting for something like this ever since I read up on persistent data structures and functional reactive programming almost 10 years ago.

I'm wondering how this compare to the Javelin library as that seems to offer the same functionality when combined with hlisp. Would I be correct in saying that Om achieves the same by using ClojureScript's data structures and core.async to offload the FRP part to React?

Re: The Future of JavaScript MVCs

#10

Post by programnature » Thu, Dec 19, 2013, 7:38 PM UTC

rubiquity wrote: post #4

What about long GC pauses and running for cleaning up all those wonderful immutable data structures? Immutability is great when it's at the forefront of how a language is designed. Plastering immutability all over hot code paths in a language that wasn't designed with immutability in mind isn't great.

So far its not a big deal. I haven't seen perceptible GC pauses, not to say they aren't possible for some use case.