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

31–40 of 159 posts

Re: The Future of JavaScript MVCs

#31

Post by swannodette »

avolcano wrote: post #17

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…

React is used by Facebook and Instagram and many others - I think these companies know a thing or two about scaling rich complex client side applications. React + immutable data has been used by Facebook to get order of magnitude performance enhancements.

So I dunno, seems like it might catch on eventually ;)

Re: The Future of JavaScript MVCs

#32

Post by lazerwalker »

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.

There are many cases (e.g. accessibility for people using screen readers) where having your web site be a machine-parseable document is very valuable. There are cases where using Canvas for everything makes sense, but having it be the default feels like a step back in many respects.

Re: The Future of JavaScript MVCs

#33

Post by chrisege »

Not to take away from the other points in your post, but on the benchmarks, the backbone example is writing to localStorage, while the om example isn't.

The overhead from localStorage appears to account for a significant chunk of the difference in performance. You can remove the localStorage calls with 'Backbone.sync = $.noop' or similar. After doing that and clearing localStorage, benchmark one drops to around 350ms, and benchmark 2 drops to around 2000ms.

Of course, benchmark 2 is where your library really shines, and backbone still takes its time with that one.

Re: The Future of JavaScript MVCs

#34

Post by swannodette »

drcode wrote: post #25

I know it sounds crazy, but I think your post just outlined the next 5 years of web development innovation, swannodette- This ties together a lot of ideas that are extremely important, for the first time in one place. Thanks for doing this. I already have my own React.js+Clojurscript bridge for personal projects, because I think it's an extremely powerful web dev combination. I'm glad I can finally abandon my own lib…

Great to hear, it needs more work :) It's more or less a conceptual foundation at this point, but I think it's going to rock with help from the community.

BTW, it was your React mailing lists posts that also really got me digging into this.

Re: The Future of JavaScript MVCs

#35

Post by mtrimpe »

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.

Because there are millions of developers who can use the DOM and CSS to create their design and only a handful who can do the same with Canvas.

Re: The Future of JavaScript MVCs

#36

Post by swannodette »

chrisege wrote: post #33

Not to take away from the other points in your post, but on the benchmarks, the backbone example is writing to localStorage, while the om example isn't. The overhead from localStorage appears to account for a significant chunk of the difference in performance. You can remove the localStorage calls with 'Backbone.sync = $.noop' or similar. After doing that and clearing localStorage, benchmark one drops to around 350ms…

Not true, all Om timing information includes writing to localStorage. I just don't load the page from localStorage because that made benchmarking tedious for me.

Re: The Future of JavaScript MVCs

#37

Post by swannodette »

mtrimpe wrote: post #27
swannodette wrote: post #11

Earlier quoted context omitted.

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…

I'll be diving into the source code soon to figure it out, but are you then using core.async only to handle incoming user events or also to coordinate the rendering of the UI?

We just use React for events that update the state of the tree. For inter-component communication core.async seems promising.

Re: The Future of JavaScript MVCs

#38

Post by chrisege »

swannodette wrote: post #36
chrisege wrote: post #33

Not to take away from the other points in your post, but on the benchmarks, the backbone example is writing to localStorage, while the om example isn't. The overhead from localStorage appears to account for a significant chunk of the difference in performance. You can remove the localStorage calls with 'Backbone.sync = $.noop' or similar. After doing that and clearing localStorage, benchmark one drops to around 350ms…

Not true, all Om timing information includes writing to localStorage. I just don't load the page from localStorage because that made benchmarking tedious for me.

My mistake - i see that now. I think I lost sight of the single key for your example in with the hundreds of distinct keys from the backbone one.

Re: The Future of JavaScript MVCs

#39

Post by swannodette »

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 ;)

Post reply on HN