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

11–20 of 159 posts

Re: The Future of JavaScript MVCs

#11

Post by swannodette »

mtrimpe wrote: post #9

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

I haven't looked at Javelin enough to have a strong opinion about it. Om at the moment is completely focused on rendering EDN data and making that blazing fast. Personally I think representing UI components as generic data has a lot of legs.

I also don't really believe in templating languages, but I also think that functional boilerplate for rendering children is a bummer. I'd like to see a client side query language modeled after Datomic's Datalog syntax instead.

Re: The Future of JavaScript MVCs

#12

Post by girvo »

peterhunt wrote: post #7
ibdknox wrote: post #6

Earlier quoted context omitted.

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

Excuse my language, but holy shit that's awesome. I'm blown away by how... Native that feels, running on my 4S (iOS 7). 60fps the entire time. Jesus.

Re: The Future of JavaScript MVCs

#13

Post by ibdknox »

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 decisions of the DOM out of our programs. If nothing else, this gives us freedom, but as david is suggesting, I think this also gives us an opportunity to treat UI much more directly than we currently are. If you want to know what the state of your UI is, you just have to read linearly down through the code that produces your tree. No nest of dependencies, no state hidden in the UI components, you could even get rid of event hierarchies if you wanted.

More important than anything else, this gives us a chance to dramatically simplify our model for UI and magically be even faster than we were before. Sounds like a win to me.

[1]: http://en.wikipedia.org/wiki/Immediate_mode

Re: The Future of JavaScript MVCs

#14

Post by wheaties »

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?

Re: The Future of JavaScript MVCs

#17

Post by avolcano »

The title of this post is strange. This seems more like the future of JavaScript views than the future of models or controllers.

I don't see a large movement to immutable data structures on the horizon in JS. I can appreciate the performance implications in Om, and would be interested in using React + Mori to the same end, but I'm not sure that it would keep me from having mutable data structures to represent most of my application state.

There are so many now-solved problems in JS MVCs that were a complete trainwreck several years ago - client-side routing, sanely managing data, and intelligently organizing your code base - that all assume mutable data structures and traditional object-oriented paradigms.

This might be the future of ClojureScript (in fact, it should be the future of CLJS, as it's much more elegant than any other view solution I've seen for it), and functional data structures may be a clever way to optimize the DOM, but this certainly doesn't seem like the future of JavaScript to me.

Re: The Future of JavaScript MVCs

#18

Post by peterhunt »

girvo wrote: post #12
peterhunt wrote: post #7

Earlier quoted context omitted.

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

Excuse my language, but holy shit that's awesome. I'm blown away by how... Native that feels, running on my 4S (iOS 7). 60fps the entire time. Jesus.

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 (reverse engineered from iOS) to do the touch gesture stuff, then we can declaratively rotate, fade and translate everything as a function of this float.

Code is on github! And is actually in a reusable library!

Re: The Future of JavaScript MVCs

#19

Post by EvilTrout »

> Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we simply schedule a render of the data via requestAnimationFrame.

Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control.

Angular also would not update the DOM as many times as the backbone example as it uses dirty checking to get around this problem.

Re: The Future of JavaScript MVCs

#20

Post by avolcano »

EvilTrout wrote: post #19

> Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we simply schedule a render of the data via requestAnimationFrame. Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control. Angular also would not update the DOM as many times as the backb…

Yeah, I think it's rather misleading to compare om to the performance of the least optimized and most naive (on purpose, mind you) framework instead of a more robust one.
Post reply on HN