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

131–140 of 159 posts

Re: The Future of JavaScript MVCs

#131

Post by jpatte »

lucian1900 wrote: post #126
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.

It's not really about a choice of language.

My point is that if Om claims to be superior to other JS MVC frameworks - as it is presented as "the future of MVC frameworks" - it needs to be good (if not superior) in many aspects. Performance is a big deal all right, but another aspect (which seems essential to me) is that using this framework should be easy, concise and intuitive. And I've been kinda disappointed to see that the sample code given to present Om in action is not. At all. If I wanted to fiddle a bit with this code right now, to add a few features for example (like adding a timestamp besides each item indicating when it was created), I wouldn't have any clue where to start.

What bothers me is that Om has clearly been written with ClojureScript in mind, so in a way this framework is supposed to be sublimated by the language. It should "feel" right. And I know it's possible with other frameworks (and my comparison with Knockout+TypeScript was meant to illustrate that), so I expected it to be the case with Om.

Re: The Future of JavaScript MVCs

#132

Post by jamii »

jarpineh wrote: post #117
jamii wrote: post #94

Earlier quoted context omitted.

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

Ah, I see. Thanks for the pointer. The docs on connections pane list only JavaScript, CSS and HTML can be evaluated, so I did not try with ClojureScript. I however did try to connect from LT to nREPL which had a running bREPL to external browser. That did not work (no connection), though I have no idea if it even should... ;) I'll see how it goes and will post to the LT group if I stumble on something.

> The docs on connections pane list only JavaScript, CSS and HTML can be evaluated

Ah, that's because its a two stage process. You need something that can compile cljs to js (eg nrepl) and something that can eval js (eg browser, node, lighttable).

I think I was confused about that at first too. We should figure out how to make it clearer.

Re: The Future of JavaScript MVCs

#133

Post by EvilTrout »

swannodette_ wrote: post #102
ef4 wrote: post #83

Earlier quoted context omitted.

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

I looked at that benchmark and there's a few huge red flags right away:

1. It's not running Ember in production mode which is much faster.

2. It's running an older release candidate version of Ember.

3. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops.

I re-ran the benchmarks with the latest production mode Ember.js and removed the incorrect run loop usage got the following results:

https://gist.github.com/eviltrout/8058560

It's still slower than ReactJS but much less so than before. In fact it's now #3 in that benchmark suite behind ReactJS and Backbone (and much faster than ReactJS in the completing benchmark), although I wouldn't be surprised if the other frameworks were set up as incorrectly too.

Re: The Future of JavaScript MVCs

#134

Post by X4 »

cia_plant wrote: post #81
chongli wrote: post #77

Earlier quoted context omitted.

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

Why don't you precompute the space things use, including the text that is drawn using a matrix? You could easily calculate the baseline of anything by just doing matrix multiplications then.

However, I think you would still end up using a hack. The general idea of creating a replacement for the DOM has bugged me for a while too. It is a great to replace the DOM completely by a statemachine, I think. We need a New Document Model that supports "Batch Operations", is "Stateful" and uses the latest best performing algorithms published to do so.

Components are the CORRECT way, I fully agree with the facebook team here.

It seems that there is one guy who ALREADY DID all those things and replaced the DOM by something that's more akin to 2013's technology requirements. Link: http://www.nidium.com/

Re: The Future of JavaScript MVCs

#135

Post by rgbrgb »

Is there any reason we couldn't mod the JQuery object to work on a virtual HTML tree that syncs with the DOM on requestAnimationFrame?

Couldn't this even be done at the browser level?

I think I must be missing something.

Re: The Future of JavaScript MVCs

#136

Post by swannodette »

EvilTrout wrote: post #133
swannodette_ wrote: post #102

Earlier quoted context omitted.

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

I looked at that benchmark and there's a few huge red flags right away: 1. It's not running Ember in production mode which is much faster. 2. It's running an older release candidate version of Ember. 3. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops. I re-ran the benchmarks with the latest production mode Ember.js and remo…

Thanks for the clarifications!

Re: The Future of JavaScript MVCs

#137

Post by drcode »

rgbrgb wrote: post #135

Is there any reason we couldn't mod the JQuery object to work on a virtual HTML tree that syncs with the DOM on requestAnimationFrame? Couldn't this even be done at the browser level? I think I must be missing something.

That wouldn't change the amount of DOM thrashing caused by jQuery, it would only improve rendering (and perhaps reflow) performance, but would not improve the cost of DOM manipulation.

Re: The Future of JavaScript MVCs

#138

Post by drcode »

jpatte wrote: post #131
lucian1900 wrote: post #126

Earlier quoted context omitted.

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

It's not really about a choice of language. My point is that if Om claims to be superior to other JS MVC frameworks - as it is presented as "the future of MVC frameworks" - it needs to be good (if not superior) in many aspects. Performance is a big deal all right, but another aspect (which seems essential to me) is that using this framework should be easy, concise and intuitive. And I've been kinda disappointed to se…

I dunno- I'm a clojurescript guy, and it seems pretty "sublimated" to me.. I think the problems React.js and Om are trying to solve are more critical when dealing with large & complex applications... I think one would see the benefits more clearly in those cases (though it feels a simpler to me as it is already)

Re: The Future of JavaScript MVCs

#139

Post by rgbrgb »

drcode wrote: post #137
rgbrgb wrote: post #135

Is there any reason we couldn't mod the JQuery object to work on a virtual HTML tree that syncs with the DOM on requestAnimationFrame? Couldn't this even be done at the browser level? I think I must be missing something.

That wouldn't change the amount of DOM thrashing caused by jQuery, it would only improve rendering (and perhaps reflow) performance, but would not improve the cost of DOM manipulation.

Can you expand on that a bit? As I understand it, om/react don't improve the cost of DOM manipulation, they just reduce the amount of DOM manipulation that's done by only altering parts of the DOM that have changed. Couldn't you do the same type of change checking on the virtual DOM tree so that you only touch the actual DOM when it changes?

Re: The Future of JavaScript MVCs

#140

Post by peterhunt »

MatthewPhillips wrote: post #125
peterhunt wrote: post #64

Earlier quoted context omitted.

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?

It works well on iPhone 4S and up. And it works, but not great, on all android phones I've tried (including Firefox os on zte open!)

The point of rebuilding scrolling is to get the scroll position every frame so you can update the UI (ie rotate a photo or fade the left nav). You don't get scroll events during momentum scrolls so you have to rebuild it.

Post reply on HN