Instant Pages vs Instant Web?

Again an interesting ALA-article about web performance (or the lack thereoff), triggered by Facebook’s “Instant Articles” announcement;

I think we do have to be better at weighing the cost of what we design, and be honest with ourselves, our clients, and our users about what’s driving those decisions. This might be the toughest part to figure out, because it requires us to question our design decisions at every point. Is this something our users will actually appreciate? Is it appropriate? Or is it there to wow someone (ourselves, our client, our peers, awards juries) and show them how talented and brilliant we are?

This exercise clearly starts at the design-phase, because thinking about performance in development or testing-phase is simply too late.

ALA about Angulars shortcoming: it’s the server, stupid!

In “Let links be links” at A List Apart Ross Penman discusses some of the dangers of building single-page-apps that entirely rely on client-side JavaScript (using e.g. AngularJS or Ember) and more importantly proposes a solution;

When dynamic web page content is rendered by a server, rendering code only has to be able to run on that one server. When it’s rendered on a client, the code now has to work with every client that could possibly visit the website. […] If framework developers could put in the effort (which, admittedly, seems large) to get apps running in Node just as they run in the browser, initial page rendering could be handled by the server, with all subsequent activity handled by the browser. […] If this effort could be made at the outset by a framework maintainer, then every developer using that framework could immediately transform an app that only worked on the latest web browsers into a progressively enhanced experience compatible with virtually any web client—past, present, or future. […]