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

121–130 of 159 posts

Re: The Future of JavaScript MVCs

#121

Post by esailija »

programnature wrote: post #24
avolcano wrote: post #20

Earlier quoted context omitted.

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.

There are benchmarks comparing vanilla React to other frameworks: http://facebook.github.io/react/blog/#todomvc-benchmarks At least according to this data, React and Backbone are the fastest. (Om is faster than vanilla React) One suspects that with hand-optimization the other frameworks could be a lot faster, but the point of this post is that it is fast without hand-optimizations.

In general "faster without optimization" is completely meaningless because it doesn't mean fast with optimization, which is what actually matters.

Example: Average code written in node.js is typically just as slow as, say, PHP (in fact node.js was 3x slower than php in techempower benchmarks). However, it has potential to be much faster when optimized whereas PHP doesn't reward such optimization almost at all.

Re: The Future of JavaScript MVCs

#122

Post by peregrine »

jordwalke wrote: post #93
zaph0d wrote: post #63

Earlier quoted context omitted.

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

Would it be possible to maybe show an example of using Mori or similar with react?

Re: The Future of JavaScript MVCs

#123

Post by jpatte »

It may be because I'm not familiar with ClojureScript's syntax, but the whole sample application code seems like a real mess to me. It's full of boilerplate code and it is happily mixing application logic with DOM rendering. [1]

Compare this with an alternative JS MVC framework (like, say, Knockout.js) and another modern "javascript-compatible" language (like, say, TypeScript), and see for yourself. [2]

While I didn't run any benchmarks, it's safe to assume the Om demo is faster. However which sample do you think is easier to write, test and maintain? If "The Future of JavaScript MVC Frameworks" is supposed to look like the Om sample, sorry but I'll pass.

[1]: https://github.com/swannodette/todomvc/tree/gh-pages/labs/ar...

[2]: https://github.com/jpatte/TodoMvc-Knockout.ts

Re: The Future of JavaScript MVCs

#124

Post by swannodette »

d_j_s wrote: post #79

So I rewrote Backbone views to use a queue system that fires on requestAnimationFrame - https://github.com/danshearmur/backbone-fast-view I'm getting pretty good results with swannodette's benchmarks - http://danshearmur.github.io/backbone-fast-view/ I'm getting approx 150ms in Chrome for benchmark 1 and about 400 ms for Chrome for benchmark 2

About what I'd expect for the first benchmark, but that's the kind of intervention from the user that I think frameworks should not require. The time still spent by Backbone.js on the second one more or less illustrates why I don't believe in event oriented MVCs.

Re: The Future of JavaScript MVCs

#125

Post by MatthewPhillips »

peterhunt wrote: post #64
aboodman wrote: post #55

Earlier quoted context omitted.

Hi Pete, I'm also super interested in this combination. However, on my new moto x, the photo scroller drops to ~45 fps and looks pretty chunky. I also noted that you say the demos work best iPhone 5 on iOS 7, but unclear if you meant in contrast to earlier iPhones, or in contrast to Android, or both. Have you looked at all at the perf issues on Android?

Hey there -- The FPS drop on the photo scroller is likely due to jpeg decoding and painting on the main thread (I thought this was fixed in Blink but maybe not). Try "warming it up" by scrolling through all of the images a few times so the decoded jpegs get cached. I think this is the biggest perf problem on the Web today. The reason Android may "feel" sluggish while reporting good FPS is because Android simply has a…

Ditto on Firefox for Android, will try IE on WP later today. Although a solution that works on exactly 1 phone is not a solution I would ever use. To be honest, I don't get the point of reimplementing scrolling in JavaScript, can you explain why you wanted to do that?

Re: The Future of JavaScript MVCs

#126

Post by lucian1900 »

jpatte wrote: post #123

It may be because I'm not familiar with ClojureScript's syntax, but the whole sample application code seems like a real mess to me. It's full of boilerplate code and it is happily mixing application logic with DOM rendering. [1] Compare this with an alternative JS MVC framework (like, say, Knockout.js) and another modern "javascript-compatible" language (like, say, TypeScript), and see for yourself. [2] While I didn'…

I don't see how language has anything to do with you criticism.

Re: The Future of JavaScript MVCs

#127

Post by swannodette »

jpatte wrote: post #123

It may be because I'm not familiar with ClojureScript's syntax, but the whole sample application code seems like a real mess to me. It's full of boilerplate code and it is happily mixing application logic with DOM rendering. [1] Compare this with an alternative JS MVC framework (like, say, Knockout.js) and another modern "javascript-compatible" language (like, say, TypeScript), and see for yourself. [2] While I didn'…

While the TypeScript + Knockout combo looks pretty good, it doesn't look that much more expressive to my eyes. Certainly hasn't been my experience that Clojure or ClojureScript are hard to test and maintain.

Still thanks for the comparison!

Re: The Future of JavaScript MVCs

#128

Post by STRML »

kibibu wrote: post #105
STRML wrote: post #92

Earlier quoted context omitted.

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…

Yes, you're right; I shouldn't have put the "it's pretty simple" statement just a few sentences after "It's complicated" - clearly, depending on the app, undo functionality can get pretty hard to manage, especially when there are emails or complicated relations involved.

Re: The Future of JavaScript MVCs

#129

Post by STRML »

secoif wrote: post #113

The flame graphs are meaningless and misleading: om's graph is only looking at 260ms of data, while the backbone's is looking at 1200ms.

But that's the whole point; it's effectively the same operation, but Om takes 1/5 the time and takes a much more efficient path. Backbone with some simple RequestAnimationFrame deferral somewhat approaches that speed but in some cases Om still beats it by an order of magnitude.

Re: The Future of JavaScript MVCs

#130

Post by lucian1900 »

jarpineh wrote: post #70

This is like a dream coming true. I don't like Javascript's quirks, nor programming DOM with templates nor functions. I'm looking to build somewhat complex UIs without having to think in JS and manage state. React absolves me from DOM and ClojureScript keeps JS at bay. Only if starting ClojureScript development wasn't so hard. I'd like to use browser REPL, IDE like LightTable. I am used to LiveReload's speed which ma…

I don't think ClojureScript could become popular beyond a subset of Clojure users unless it becomes self-hosted, so it can be compiled without a JVM and eval in a browser with an extension. The JVM is not universally loved/acceptable.

I keep meaning to make a game with it, but always give up because it's so much more painful than pretty much any other to-JS language.

Post reply on HN