Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of JavaScript MVCs

swannodette.github.io

Post reply on HN
Print view View original

41–50 of 159 posts

Re: The Future of JavaScript MVCs

#41

Post by dmak »

wheaties wrote: post #14

Been playing around with RxJs and wonder how much difficulty would it be to combine React with this? RxJs seems to work particularly well with Angular but I know Back one much better. is there harmony between the two?

I think it really depends on what you are trying to accomplish. For one thing, a quick peak into React revealed to me that there isn't two-way data binding. I think React and Angular have a lot of friction. They both seem to do well with data binding in their respective ecosystems.

Re: The Future of JavaScript MVCs

#42

Post by masklinn »

cia_plant wrote: post #22
ibdknox wrote: post #13

We've been thinking about this a lot lately for some of the projects we've been doing for Light Table and we've essentially been doing the same thing as what David's proposing here. What react ultimately opens up is a way to do immediate mode UI [1] on top of the DOM _efficiently_, which changes things pretty dramatically. It means we can start to treat the browser as just a renderer and get the infectious design dec…

If you want to do immediate mode, then why would you use the DOM at all? Canvas is supported in IE9+, and is much less complicated for such applications.

> 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.

Re: The Future of JavaScript MVCs

#43

Post by STRML »

swannodette wrote: post #39
STRML wrote: post #21

I'm not great at reading ClojureScript - but I'd really like to port some of the optimizations from Om, such as the rendering on requestAnimationFrame and usage of shouldComponentUpdate to Backbone.LayoutManager[1]. Swannodette, if you're around, do you have a minute to give a more in-depth explanation of how that works? 1. https://github.com/tbranyen/backbone.layoutmanager/wiki

If you're using Backbone.js I would just rely on React to deliver the requestAnimationFrame enhancement. As far as shouldComponentUpdate, just make your component implement a better one. To be honest at this point there is little that Om does over React other than provide really good defaults ;)

Thanks for the input. I'll look into it. We've been talking a bit about doing a more general rewrite of LM and I've been looking for ideas that would make it worthwhile (not just cleaner code, but better perf or features). This might be one of them.

Re: The Future of JavaScript MVCs

#45

Post by dmak »

peterhunt wrote: post #40
EGreg wrote: post #23

How is this different from the dirty checking that Angular does in its ModelView update cycle?

This is copied from a comment of mine on Reddit which should cover it: http://skulbuny.com/2013/10/31/react-vs-angular/

That seemed more like a rant about Angular than an unbiased comparison. I had the impression that the writer didn't do things the "Angular way" when he said, "Since composing directives is so annoying, they end up being basically mini-jQuery apps that are pretty hard to maintain."

Re: The Future of JavaScript MVCs

#46

Post by DannoHung »

bretthopper wrote: post #5

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 Em…

Are there a lot of details to explain? An immutable data structure means that modifications to the structure tend to be memory cheap. So you save every instance you care about secure in the knowledge that it doesn't waste much space. Then to perform forward or backward operations, you just switch which version you're looking at.

Re: The Future of JavaScript MVCs

#48

Post by peterhunt »

dmak wrote: post #41
wheaties wrote: post #14

Been playing around with RxJs and wonder how much difficulty would it be to combine React with this? RxJs seems to work particularly well with Angular but I know Back one much better. is there harmony between the two?

I think it really depends on what you are trying to accomplish. For one thing, a quick peak into React revealed to me that there isn't two-way data binding. I think React and Angular have a lot of friction. They both seem to do well with data binding in their respective ecosystems.

Our (React core) team has experimented with React+RxJS before: https://github.com/facebook/react-page/commit/082a049d2a13b1...

We think that "two-way binding" is actually very, very hard to get right since it flies in the face of the way data flows in a von Neumann program.

Instead, we provide some sugar that lets you get the conciseness of two-way binding but without making it hard to debug or understand performance: http://facebook.github.io/react/docs/two-way-binding-helpers...

But we don't really recommend that for newbies since it's important to understand how the data flows in your program before covering it up with sugar.

Re: The Future of JavaScript MVCs

#49

Post by sebmarkbage »

EGreg wrote: post #23

How is this different from the dirty checking that Angular does in its ModelView update cycle?

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 structure every time (such as a JSON response)?

Dirty checking and Object.observe does not work on closure scope state.

These two things are very limiting to functional patterns obviously.

Additionally, when your model complexity grows, it becomes increasingly expensive to do dirty tracking. However, if you only do diffing on the visual tree, like React, then it doesn't grow as much since the amount of data you're able to show on the screen at any given point is limited by UIs. Pete's link above covers more of the pref benefits.

Re: The Future of JavaScript MVCs

#50

Post by jaredly »

DannoHung wrote: post #46
bretthopper wrote: post #5

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 Em…

Are there a lot of details to explain? An immutable data structure means that modifications to the structure tend to be memory cheap. So you save every instance you care about secure in the knowledge that it doesn't waste much space. Then to perform forward or backward operations, you just switch which version you're looking at.

maybe "details" is the wrong way to phrase it. I'm excited to see /a real world implementation/, either proving that it really is that simple, or showing what other complications arise.
Post reply on HN