found drama

get oblique

Tag Archives: performance

re: Slatkin on PPK on client-side templating

by !undefined

One Big Fluke › Experimentally verified: “Why client-side templating is wrong”:

By Brett Slatkin (“One Big Fluke”).

If you followed PPK’s AngularJS post

from January (and his follow-up

client-side templating post

), then this is a worthwhile reply in its own right — and somehow I missed it when it ran.

Whereas PPK argues largely from a position of principle, Slatkin throws experiments and data at it, and while he arrives at different conclusions, he’s also gracious about the whole thing, drawing the conclusion thusly:

The take-away here is to choose the right architecture for your problem.

What’s good about this post is that he dug deep into this problem, cut it up a bunch of different ways, and remained open to the possibility that either approach might “win”. Which isn’t to say that his experiments were perfect (if some flaws aren’t obvious to you then check out the comment thread where several “improvements” are enumerated) or that there isn’t some speculation going on, but we have some good applied science here to give us a sensible picture.

Two important things here though:

First, it’s hard not to read Slatkin’s post as a refutation of PPK’s. This is unfortunate because, dogmatic though his tone may be, PPK offers up plenty of good points that you should consider when making these choices for your application. Whether you like AngularJS or not, whether you think client-side templates are a good fit for your problem or not, these thoughts are at least worth mulling over.

Which leads to my second point: it’s my sincere hope that people go with Slatkin’s real take-away, and that development teams have the discipline to look at their application, to analyze the data it’s producing about their audience etc., and to think about their goals for the future — and to design and build their applications with those data in mind. It’s entirely too easy to cargo cult decisions from posts like this one (and/or from PPK’s) and just assume that you got it right because you read something compelling from someone smart. By all means take their data into consideration, but no one else’s data is meaningful to you.

Abraham Polishchuk on AngularJS Performance

by !undefined

AngularJS Performance in Large Applications:

Abraham Polishchuk presents us with a fairly comprehensive break-down of some performance do’s-and-don’t’s for large AngularJS applications. (Although there’s nothing in here specifically about the sizes of the applications themselves.) He covers some basic JavaScript performance techniques at the beginning before diving into the AngularJS specific items. The key takeaways seem to be (1) to limit the number and contents of scopes and (2) to avoid the AngularJS event system. Some of it reads like FUD (“Don’t use filters!”) but there’s also good advice here, especially w/r/t/ limiting scope and in particular his points about limiting the use of `$watch`.

That being said: this seems to align with my recent criticism — that it isn’t so much that AngularJS itself isn’t performant, but that it’s (arguably) too easy (using the “by default” features) to get youself into a poor performance situation.

Linkdump for June 6th

by Rob Friesel

JavaScript Memory Profiling Oriented toward profiling in the Chome Dev Tools, but the underlying principles hold true across browsers. Lots of detail in here. (tagged: JavaScript performance memory garbage collection profiling ) Script-injected "async scripts" considered harmful Ilya Grigorik: The inline JavaScript solution has a subtle, but very important (and an often overlooked) performance gotcha: […]

Linkdump for March 16th

by Rob Friesel

Silicon Valley’s Youth Problem Written by Yiren Lu for; such a great piece. This pull quote doesn't quite summarize it, but it comes close: Since the acquisition, Biswas, who is 32, has fought to retain the spirit of the vanguard, but his struggle reveals an implicit fear — that young engineers might be willing […]

Linkdump for March 5th

by Rob Friesel

Debugging JavaScript in a Hostile Environment E.J. Dyksen, writing at Mutually Human. It's an interesting story of how they handled the debugging for this particular environment (WebBrowser Control in a VB app), even if the solution itself is not especially novel. The one surprise (to me) was that the Angular $log service was not mentioned. […]

Linkdump for January 14th

by Rob Friesel

Bulletproof Accessible Icon Fonts Hot on the heels of Ian Feather's piece on SVG vs. icon fonts (vide infra), the Filament Group published their own lessons learned about using icon fonts in the wild. (tagged: accessibility fonts icon fonts ) Software in 2014 Tim Bray's current "state of the union" on the software engineering field, […]

Linkdump for December 16th

by Rob Friesel

AngularJS – Perceived Performance Github user @mendhak has this proposed directive for measuring load time performance of different components in a single-page app. Tl;dr: "loading" a portion of the page may be deferred for one reason or another, but once it is in fact "finished" (based on some user-defined version of "finished") it requests an […]

Linkdump for August 14th

by Rob Friesel

Why mobile web apps are slow Drew Crawford (Sealed Abstract) wrote this a few weeks ago and I finally (finally? finally!) got around to reading it start-to-finish. The best part about it is that (as he says in the first paragraph) his discussion is entirely fact-based. And where possible he is also illustrating his methods […]

Linkdump for August 10th

by Rob Friesel

5 Myths About Mobile Web Performance Michael Mullany, Sencha CEO, writing for the company's dev blog: Every mobile browser has a feature area where it outperforms other browsers by a factor of 10–40x. The Surface outperforms the iPhone on SVG by 30x. The iPhone outperforms the Surface on DOM interaction by 10x. There is significant […]