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

81–90 of 159 posts

Re: The Future of JavaScript MVCs

#81

Post by cia_plant »

chongli wrote: post #77
cia_plant wrote: post #69

Earlier quoted context omitted.

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.

What about line height? Judging by some of the responses I've seen on Stackoverflow, calculating this involves running a loop and querying the pixel colours from the canvas's buffer; a very ugly hack, if you ask me!

line height is straightforward enough, if you draw text with line height on N then you should move N pixels down for the next line.

Text baseline is the tricky part - if you want to e.g. put a taller piece of text next to a shorter one, then they should be put together so they share a baseline, but there's no decent way to get the text baseline.

The hack I use is to draw the text in a hidden span, and put a 1px inline-block span next to it, and check where the 1px span ends up. This works though it is ugly.

Re: The Future of JavaScript MVCs

#82

Post by bguthrie »

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…

I agree––I've found this tremendously exciting. Thanks @swannodette for the code and the writeup.

Re: The Future of JavaScript MVCs

#83

Post by ef4 »

swannodette wrote: post #26
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…

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.

Re: The Future of JavaScript MVCs

#84

Post by d_j_s »

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/

Re: The Future of JavaScript MVCs

#85

Post by rtfeldman »

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 using a nicer one?!

Count me in! I already have a serious project in mind for this.

Re: The Future of JavaScript MVCs

#86

Post by adrianm »

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…

I hear your pain - I can't live without a REPL, and a stable browser REPL for ClojureScript development is a must.

I personally use Emacs and Austin to hook the browser REPL into nrepl. Here are some sample files that you can take a look at.

Here's a sample project.clj: https://github.com/aamedina/foundation/blob/feature/cljs/pro...

I've become a fan of Stuart Sierra's Reloaded workflow: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r...

Here's my dev/user.clj

https://github.com/aamedina/foundation/blob/feature/cljs/dev...

Some notes about what I did here: you start the server by running (go), you can quit the CLJS repl easily by typing in :cljs/quit as normal and return to the user namespace and then safely (stop) or (reset), stop will stop the server and reset will refresh all of your Clojure namespaces (useful if you're writing macros in Clojure for use in ClojureScript).

Aside from this, just turn on cljsbuild auto with :optimizations :none, and code recompiles are sub-second.

Hope any of this helps you.

Re: The Future of JavaScript MVCs

#87

Post by rads »

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]?

I've seen two libraries suggested on the React mailing list:

http://swannodette.github.io/mori/

https://github.com/hughfdjackson/immutable

The first one uses the same data structures from ClojureScript.

Re: The Future of JavaScript MVCs

#88

Post by _sh »

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.

Thanks for posting this. Forgive me for not looking over your code before asking: how does Om compare with Pedestal? Am I correct in thinking there is a lot of architecture overlap, with Pedestal's application state map occupying a similar role to React's virtual DOM, and mutation through message tuples in channels?

Both frameworks seem to offer similar advantages: decoupled model and view, UI state playback (VCR style) and instrumentation. How significantly do these frameworks differ? Or are we seeing different paths towards a convergence around a new set of model/view practices?

Re: The Future of JavaScript MVCs

#89

Post by phillmv »

swannodette wrote: post #31
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 ;)

> scaling rich complex client side applications.

Instagram's really not a good example here. Do comments and likes even update in real time?

Re: The Future of JavaScript MVCs

#90

Post by phillmv »

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…

The web's headed that way as well, we just call them services. That said, I'm not sure why MVC is inappropriate for component intra architecture.

I love how different programming communities never talk to each other.

Post reply on HN