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

101–110 of 159 posts

Re: The Future of JavaScript MVCs

#101

Post by vithlani »

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…

> A lot of the OO support in React is there as a concession, more than being considered a virtue. It's really cool to have the FP community involved in the UI space. Those people are already sold on FP and statelessness and get the luxury of programming in tomorrow's paradigms today (how ironic that FP has been around for decades!)

As Sir William said, "There is blood in the old ways yet".

Re: The Future of JavaScript MVCs

#102

Post by swannodette_ »

ef4 wrote: post #83
swannodette wrote: post #26

Earlier quoted context omitted.

While it's nice that Ember.js provides a run loop that's not enough, just batching all your updates into one place just puts all of the work together, you'll still going to pay for the work and in the worse case you have to hand coalesce, yuck. In Om if there is no work ... there is no work, it's implicit in the system! No need for hand coalescing your state changes. Angular.js still suffers as shown by the optimizat…

You're misunderstanding. There's no hand coalescing in Ember, and there's no duplicate work. If you change your models a thousand times in a row, you still get one redraw, fully automatically. The same holds for dependent computed properties. If you change a dependencies many times in a row, the dependent property only reevaluates once.

If that's really true for Ember.js that's great! I'm curious as to why it performs so badly? http://www.petehunt.net/react/tastejs/benchmark.html

Re: The Future of JavaScript MVCs

#103

Post by dminor »

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.

The goal isn't to do immediate mode, it's to implement UI in the simplest manner possible. Throwing away the DOM and reimplementing significant parts of its functionality in Canvas doesn't make life simpler.

Re: The Future of JavaScript MVCs

#104

Post by NVI »

swannodette wrote: post #2

I apologize that the Om TodoMVC version is a little bit buggy at the moment, I put it together mostly to demonstrate the benefits of the React/Om model and it appears I missed a couple of TodoMVC behavior issues as they weren't important for demonstrating the approach - I'll try to clean up these annoyances later this evening. Feel free to ask any questions.

http://swannodette.github.io/todomvc/labs/architecture-examp... has "//# sourceMappingURL=app.js.map" but the file is missing.

Re: The Future of JavaScript MVCs

#105

Post by kibibu »

STRML wrote: post #92
bretthopper wrote: post #76

Earlier quoted context omitted.

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

It's not pretty simple though.

In particular, if you have any triggers in your API they may need to be deferred until after undo is no longer possible, or have explicit commits. Lets say you have the ability to add a user to a group, and they will get an email about it. You accidentally add your boss to the "I hate my boss" group. How do you support undo in this case? Some sort of timeout before sending is really the only valid approach, but where?

One was is to do the deferred part on the client side, but this means closing the browser after adding somebody will mean they won't get notified at all. You really need to have support for undo in the API for this to be meaningful (or the "add to group" api returns a notification ID that you can cancel).

As an aside, I'm pretty sure the inverse of deleting a model is typically going to be far more complex than just recreating it. Deleting a social network profile, for example, involves deleting all photos, associations, posts, etc. Easier just to deactivate models so you get easy undo, and periodically flush deactivated objects.

Re: The Future of JavaScript MVCs

#106

Post by _pmf_ »

On another note: maybe if the installation of ClojureScript would be manageable in, say, an hours instead of having to search half a day among outdated information, more people would try it (and this is from someone who already uses Clojure and Leiningen a bit).

Clojure and its libraries has the worst documentation, and this malpractice seems to be continued in ClojureScript.

Re: The Future of JavaScript MVCs

#107

Post by TheHydroImpulse »

rtfeldman wrote: post #85

This kind of thing is exactly what makes me think CLJS is the current frontrunner to be the first compile-to-JS language to gain mass adoption without JS-like semantics (as CoffeeScript has). It's the performance. So many of us who want JS alternatives have made our peace with the idea that we'll have to sacrifice a bit of performance if we want to use a nice language. But being able to improve performance while usin…

For me, the non-idiomatic compiled JavaScript and Google's library that's stopping me. Wisp seems like a good solution with it being a Clojure dialect that provides super clean JavaScript that you can work with.

Re: The Future of JavaScript MVCs

#108

Post by chc »

_pmf_ wrote: post #106

On another note: maybe if the installation of ClojureScript would be manageable in, say, an hours instead of having to search half a day among outdated information, more people would try it (and this is from someone who already uses Clojure and Leiningen a bit). Clojure and its libraries has the worst documentation, and this malpractice seems to be continued in ClojureScript.

It's as easy as "lein new mies". Hard to get much easier.

Re: The Future of JavaScript MVCs

#109

Post by davedx »

_pmf_ wrote: post #106

On another note: maybe if the installation of ClojureScript would be manageable in, say, an hours instead of having to search half a day among outdated information, more people would try it (and this is from someone who already uses Clojure and Leiningen a bit). Clojure and its libraries has the worst documentation, and this malpractice seems to be continued in ClojureScript.

I had a few teething problems getting it configured properly, but I managed to get ClojureScript working from scratch on a Windows machine in about an hour, I think. What problems did you have? (Mine were Java related)
Post reply on HN