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

61–70 of 159 posts

Re: The Future of JavaScript MVCs

#61

Post by smrtinsert »

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.

Dashboard are such a use case and in the age of 'big data' pretty common.

Re: The Future of JavaScript MVCs

#62

Post by dustingetz »

asolove wrote: post #59

Om looks very interesting and seems to handle exactly what I've been looking for. We have reactive widgets, which is great for making changes in the data automatically update the UI. But the hard part is closing the loop: how does the widget communicate back to the data about changes? It would be interesting if we had a zipper-like abstraction, so that the widget gets handed both its data and a function to call when…

> so that the widget gets handed both its data and a function to call when it wants to change just its data

this is precisely how React works.

Re: The Future of JavaScript MVCs

#63

Post by zaph0d »

jordwalke wrote: post #57

Jordan, from the React core developer team here. Awesome post, swannodette! This is exactly how we intended React to be used. As swannodette said, at Facebook, we use persistent data structures, in order to prune the update search space for comment updates. We've seen as much as a 10x improvement in update speed for certain operations. React is a really great fit for Om, persistent data structures, and functional pro…

Hi Jordan, ReactJS looks really awesome. Curious, what kind of persistent data-structures do you use at Facebook? Are they similar to the ones on Clojure[Script]?

Re: The Future of JavaScript MVCs

#64

Post by peterhunt »

aboodman wrote: post #55
peterhunt wrote: post #18

Earlier quoted context omitted.

Thanks! The secret sauce is that you can animate CSS transforms every requestAnimationFrame without breaking out of React's natural data flow. So we declaratively express the UI as a function of a single float which represents the scroll position (i.e. how open/shut the nav is or what position in the photo viewer you're at). When we do that, we can use the excellent Zynga Scroller touch gesture physics engine (revers…

Hi Pete, I'm also super interested in this combination. However, on my new moto x, the photo scroller drops to ~45 fps and looks pretty chunky. I also noted that you say the demos work best iPhone 5 on iOS 7, but unclear if you meant in contrast to earlier iPhones, or in contrast to Android, or both. Have you looked at all at the perf issues on Android?

Hey there --

The FPS drop on the photo scroller is likely due to jpeg decoding and painting on the main thread (I thought this was fixed in Blink but maybe not). Try "warming it up" by scrolling through all of the images a few times so the decoded jpegs get cached. I think this is the biggest perf problem on the Web today.

The reason Android may "feel" sluggish while reporting good FPS is because Android simply has a huge problem with touch event latency in the browser that you can't get around. This is where iOS really kicks Android's ass, at least on the web.

So the reason I limited to iPhone 5 and iOS 7 was because I can guarantee the touch latency and that the images fit in texture memory. Maybe they don't on the moto x.

Re: The Future of JavaScript MVCs

#65

Post by coldtea »

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.

>What about long GC pauses and running for cleaning up all those wonderful immutable data structures?

Yes, what about them? Have they been measured to be a problem with this approach?

If anything, it leads so colletions of objects of small lifetimes, that are quickly collected by the GC.

Re: The Future of JavaScript MVCs

#66

Post by asolove »

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.

"Immediate mode" is used as a metaphor here. He doesn't want to actually do graphics work. He wants to send things out to get drawn and have them get batched up appropriately and only rendered when needed.

Re: The Future of JavaScript MVCs

#67

Post by peterhunt »

munificent wrote: post #60
jamii wrote: post #51

Earlier quoted context omitted.

I'm guessing he means http://en.wikipedia.org/wiki/Entity_component_system While some big games have used it, a lot more games are still stuck on class hierarchies.

Those aren't orthogonal. There's a pretty wide design space for component systems. Lots of games use "components", where game entities are split into pieces for different game domains (rendering, AI, etc) without going all the way down the entities/components/systems path. It is true that most games don't use MVC. I think that's because MVC isn't a good fit for games . It seems to work fine for business apps, though…

I think swannodette's post is less about MVC and more about declarative manipulation of the DOM. As long as you have a function somewhere that creates that representation and a way of handling events you can use any sort of architecture you want.

Re: The Future of JavaScript MVCs

#68

Post by asolove »

dustingetz wrote: post #62
asolove wrote: post #59

Om looks very interesting and seems to handle exactly what I've been looking for. We have reactive widgets, which is great for making changes in the data automatically update the UI. But the hard part is closing the loop: how does the widget communicate back to the data about changes? It would be interesting if we had a zipper-like abstraction, so that the widget gets handed both its data and a function to call when…

> so that the widget gets handed both its data and a function to call when it wants to change just its data this is precisely how React works.

Yeah, took me a second to wrap my head around the Om todo code. I've updated my comment with links to show how it works.

Re: The Future of JavaScript MVCs

#69

Post by cia_plant »

masklinn wrote: post #42
cia_plant wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: The Future of JavaScript MVCs

#70

Post by jarpineh »

This is like a dream coming true. I don't like Javascript's quirks, nor programming DOM with templates nor functions. I'm looking to build somewhat complex UIs without having to think in JS and manage state. React absolves me from DOM and ClojureScript keeps JS at bay.

Only if starting ClojureScript development wasn't so hard. I'd like to use browser REPL, IDE like LightTable. I am used to LiveReload's speed which makes loading changes instantaneous. But ClojureScript compiling seems to be still slow(ish) and I have already found half a dozen of different cljsbuild configuration examples. Compiling simple cljs files can take anything from sub second to 20 secs, and I don't understand why.

Could you perhaps tell more about your development process, Swannodette? How do you develop ClojureScript apps? I don't see anything beyond base cljsbuild in Om's project.clj. I confess I haven't yet had time to play with Om and see how fast it can be compiled.

Post reply on HN