The Future of JavaScript MVCs

Post by mnicky » Sat, Dec 21, 2013, 8:59 PM UTC

phineas wrote: post #149

rads wrote: post #146

Earlier quoted context omitted.

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…

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?

Post by graue » Mon, Dec 23, 2013, 7:22 AM UTC

phineas wrote: post #149

rads wrote: post #146

Earlier quoted context omitted.

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…

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?

    var fooString = "foo";
    var secondFooString = fooString;
    secondFooString;  // => "foo"
    
    fooString = "bar";
    secondFooString;  // => "foo"

    var firstArray = [1, 2, 3];
    var secondArray = firstArray;
    
    firstArray[0] = 100;
    firstArray;  // => [100, 2, 3]
    secondArray;  // => also [100, 2, 3]

    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]

Post by peterhunt » Tue, Dec 24, 2013, 4:15 AM UTC

Joeri wrote: post #119

sebmarkbage wrote: post #49

Earlier quoted context omitted.

React does the diffing on the output (which is a known serializable format, DOM attributes). This means that the source data can be of any format. It can be immutable data structures and state inside of closures. The Angular model doesn't preserve referential transparency and therefore is inherently mutable. You mutate the existing model to track changes. What if your data source is immutable data or a new data struc…

So, maybe i'm misunderstanding, but, the perf advantage is that react waits until the next RAF and then only updates the parts of the DOM that actually changed? So, now i'm wondering: why can't the browser do that? Isn't this whole middle-man approach something to eventually be optimized out?

Post by eliseumds » Wed, Dec 25, 2013, 11:33 PM UTC

cia_plant wrote: post #69

masklinn wrote: post #42

Earlier quoted context omitted.

> much less complicated for such applications. I'm uncertain that having to reimplement all your high-level drawing routines by hand and figuring out how to handle responsive and reimplementing all activation and behaviors on top of that is less complicated than just using what the DOM provides. Even text wrapping must be done by hand when you're using canvas.

I've written text wrapping and responsiveness code for canvas, in javascript - I don't think the complexity is even of the same order of magnitude as React or Angular.