Solving the OPTIONS Performance Issue With Single Page Apps: A worthwhile read, this talks a bit about the history of XHR, the origin of the X-Requested-With header, and how/why you should prefer an Accept header for content negotiation. In particular,…
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
), 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.
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.
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: […]
Silicon Valley’s Youth Problem Written by Yiren Lu for NYTimes.com; 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 […]
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. […]
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, […]
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 […]
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 […]
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 […]