|
|
|
|
|
by aaronwhite
5005 days ago
|
|
Your opening digression is a bit harsh. We're all experienced web-devs, with the accumulated knowledge of building websites that have reached in excess of several hundred million individuals. SEO - True. There are many different strategies to deliver solid SEO results using technologies like Spar. You can use headless browsers to pre-render and deliver on-demand rendered content, if you know your URL space completely, you can pre-render all documents. Spar isn't an attempt to solve SEO for you, you may not even care if you are building a phone-gap app, for instance. So does that invalidate the technology? Accessibility: I'm 100% behind accessibility, and if the compatible tricks don't work... do you still make your site accessible for IE3? No... screen- readers MUST catch up. We can all do what we can to help, but shouldn't engineer for the past, which is an orthogonal concern from accessibile technology choices. Page-performance - I'll challenge the several orders of magnitude claim, we've seen incredible performance w/ the approach, and best-case you're only talking about first-page speed, even ceding that it becomes a much different story later on... and if you're building an 'app' thats a big difference. |
|
> do you still make your site accessible for IE3? No...
I subscribe to the ideas behind progressive enhancement, so I don't have to make that choice. An application can be built that works everywhere, for every technology, with little development overhead (and in my experience, the lowest-experience-first PE approach generally leads to better code anyway.) This isn't just theory - I've done it with apps large and small, and it works. I highly suggest http://filamentgroup.com/dwpe/ to find out more.
> best-case you're only talking about first-page speed
I'd also argue that that's what matters most to visitors - numerous studies show that there's a dropoff as that first page takes longer to load. Here we have the difference between loading a page, being useful, and then loading scripts vs loading an (empty, so faster) page, load libraries, load templates, then load data, then push the template to the screen. Additionally, if you're doing server rendering, you can probably cache that first hit at the web server level and avoid even hitting the web application at all.
The difference won't matter if you have a tiny app, so you don't have much js to download - but it will make a big difference if you have anything reasonably-sized.