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

91–100 of 159 posts

Re: The Future of JavaScript MVCs

#91

Post by STRML »

d_j_s wrote: post #84
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

The requestAnimationFrame part with simple backbone views is pretty straight forward: https://github.com/danshearmur/backbone-fast-view/blob/maste... I'm sure doing a similar thing with LayoutManager wouldn't be too hard. I think LayoutManager uses _render internally too so you may want to call it something else. It also definitely does make the benchmarks faster http://danshearmur.github.io/backbone-fast-view/

That's great - benchmark 2 is essentially a bunch of useless work, and it appears to really speed things up by making sure we only actually touch the DOM every 16ms, instead of constantly.

I'd imagine a Backbone integration with React would get us even closer. I'm not sure if it actually makes sense to go too far with an LM conversion as React appears to do a better job. But LM could certainly benefit from waiting until RAF.

Re: The Future of JavaScript MVCs

#92

Post by STRML »

bretthopper wrote: post #76
porker wrote: post #74

Earlier quoted context omitted.

>> VCR playback of UI state > I can't wait for details on this. This has gotten me really excited about client-side apps again. Why? I'm curious what I'm missing about it and the possibilities you see?

Going beyond the normal Undo to error/state correction. A lot of JS apps right now just ask a user to refresh the page when something goes wrong. This provides an easier way to get back into a previous working state.

It gets complicated; you have to store the inverse of every API call you use in order to back it out in order to have proper Undo support. IMO the UI is the easiest part of it, as you normally just reuse methods you already use in your app.

For example:

* Rename model: inverse is to rename back to stored name

* Delete model: inverse is to create with same data

* Create model: inverse is to delete the model

* Add model to collection: inverse is to remove from collection

.. and so on. It's pretty simple. I use something similar to JS-Undo-Manager[1] to manage it. Om isn't going to get you around needing to make those calls and your UI should (generally) be able to handle executing the inverse of an action at any time.

1. https://github.com/ArthurClemens/Javascript-Undo-Manager

Re: The Future of JavaScript MVCs

#93

Post by jordwalke »

zaph0d wrote: post #63
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]?

We built our own immutable object utilities that prevent mutating anything in the object graph. These immutable objects look and feel just like regular objects/arrays, so you can use functional map/reduce etc. The only thing you can do with them besides reading their properties, is to create a new version of the previous object with changes applied. We then use object identity to detect when things could not have possibly changed between render cycles. We prune off those paths that will not need to be updated, justifying the pruning based on dependent data's object identity remaining the same over time. Same object identity across two points in time necessarily implies that their deeply immutable data structures have not changed, therefore their generated output could not have possibly changed.

Re: The Future of JavaScript MVCs

#94

Post by jamii »

jarpineh wrote: post #75
swannodette wrote: post #72

Earlier quoted context omitted.

The first build of ClojureScript app is somewhat slow because we need boot the JVM, compile ClojureScript, and then analyze and compile your code. After the first compile it should be sub second. I always use the auto build mode and when I'm developing I don't use any optimizations. Works well enough for me. I'd start with this, http://swannodette.github.io/2013/10/27/the-essence-of-cloju...

Thank you, yours is what I tried first and it's definitely fastest, sub second after first compile. However there is no REPL like cljs-start and couple of others I tested have. Between cljsbuild, Austin and LightTable I haven't yet found a stable and fast solution yet. I'll try adding these various REPLS to your example and see what happens. External browser with REPL inside LightTable seems easiest for a noob like m…

> External browser with REPL inside LightTable seems easiest for a noob like me. Unfortunately LT doesn't support that use case yet...

It certainly does :)

On the connections panel click 'Add connection' and then 'Browser (External)'

The first time you do that it will give you a script tag to add to your page. Once you've added that and loaded the page in the browser, try again and it will connect.

You can email me (jamie@kodowa.com) or the LT group (light-table-discussion@googlegroups.com) if you have any problems :)

Re: The Future of JavaScript MVCs

#95

Post by john2x »

I'm really excited about this. Until now I've hated working with Javascript because of a combination of the language itself, and its primary domain (the DOM).

Seeing React.js at JSConf.asia last month got me excited that I don't have to touch the DOM anymore, but I still had to deal with Javascript the language itself.

And now this comes along. Now I don't have to deal with DOM (or at least it offers better abstractions for working with it) and I get to use the most pleasant language I've tried so far.

Christmas came early. :)

Re: The Future of JavaScript MVCs

#96

Post by malandrew »

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…

For zippers, check out this library:

https://github.com/dyoo/js-tree-cursor

Re: The Future of JavaScript MVCs

#97

Post by gfodor »

This is really cool, and I am one of those people who rolls their eyes whenever there is another article about some newfangled way to build Javascript apps on HN.

One logical step from here is instead of having a one-to-one correspondence between the "virtual" DOM and the browser DOM is to introduce a higher level meta representation based upon the context. This seems like a logical path towards a generative, projectional approach to controlling UI and browser document rendering in general. It's been tried before in several contexts and the hacks I've tried myself have always been to hard to get my head around since it's a complex problem, but this seems like it could be a really decent foothold to build a projectional, transform-based paradigm. For example, having a meta-DOM that encodes mathematical notation (probably inspired by LaTeX), which gets transformed into the current virtual DOM, which is used to update the real DOM. User manipulates a integral on screen, and the downstream transformations are performed lazily and efficiently all the way to the screen. This type of lazy evaluation from document to screen is essentially the core challenge (from a engineering standpoint) in building a usable real-time projectional editor like that demonstrated by intentional software back in 2010 [1].

[1] http://www.infoq.com/presentations/Intentional-Software-at-W...

Re: The Future of JavaScript MVCs

#98

Post by cnp »

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.

WOW! Totally native.

Re: The Future of JavaScript MVCs

#99

Post by peterhunt »

gfodor wrote: post #97

This is really cool, and I am one of those people who rolls their eyes whenever there is another article about some newfangled way to build Javascript apps on HN. One logical step from here is instead of having a one-to-one correspondence between the "virtual" DOM and the browser DOM is to introduce a higher level meta representation based upon the context. This seems like a logical path towards a generative, project…

That's exactly what we encourage :) composition of higher level components that render down to other high level components that eventually render to (virtual) DOM.
Post reply on HN