found drama

get oblique

Tag Archives: front-end

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.

initial thoughts on Aurelia

by !undefined

Introducing Aurelia:

My first reaction is (of course) that this is why a lot of developers look at JavaScript and the web front-end see only thrash, and feel only fatigue. And in this case in particular (given Eisenberg’s previous project involvements), it smells a bit of icarian hubris.

And in that respect, you won’t find me among the early-adopters. (Taking a page from “sometimes better isn’t better if it’s different” here.)

That being said, this isn’t to suggest that there is nothing interesting happening in the Aurelia project. Count me with Tom Dale (here, and a couple of the tweets that immediately follow) in that the pluggable data-binding seems like a huge takeaway here and that we are going to see that in every framework, that you can’t have a compelling inter-op story without that. But much of the rest of what’s being pitched here (e.g., modularized code, no external dependencies, “just vanilla JavaScript”) — that’s all stuff that we’ve heard before.

(As a brief aside re: the icarian hubris remark above: let’s not lose sight of the easy-to-see flip side of that: that if anyone is going to propose a new framework, who better than someone like Eisenberg? who better than someone has been deep into other projects like this? And/but that’s also where the disappointment comes from — that it just winds up feeling like yet another technical leader decides to zig instead of zag, to go off and create a new thing instead of doing the hard work of taking something and making it better.)

“more than just picking a few JavaScript solutions”

by !undefined

Planning A Front-end JavaScript Application:

Thoughtful piece by Cody Lindley over on the Telerik Developer Network. Even if you don’t agree with all of his points, he definitely sketches out a good framework for how to approach the problem of getting your application off the ground.

A couple of additional points here:

  1. Don’t get caught up in the specific technologies that Lindley is using in this article. They’re just there as examples, and he doesn’t appear to be strongly advocating for any of them — just that you consider something to fill in that blank on your project.
  2. There’s a bit of YMMV going on here depending on the specifics of your situation. That being said, most of the key lessons here should be easy to adapt — give or take a couple of questions on the checklist.

Again: look past any knee-jerk disagreements you might have (e.g., API first development; e.g., no RWD for “web apps”) and draw out the larger questions.