Progressive Enhancement Sucks
Progressive enhancement, it’s not worth it.
Ok so you host a site that has 10% IE users, or god forbid worse. So in that case you must support IE at-least > 7. Or you’re still concerned about the less than 1% of users who have javascript disabled.
So you build your site progressively. Starting from the bottom up, IE6 to IE7 to IE8 to IE9 then finally you’re allowed to support modern browsers.
And then tell me how long you spent getting up to the point of IE9. Was it all really worth it? How much longer do we expect browsers to be so gimped. And further more, what is your audience?
Yes progressive enhancement is necessary for maybe Facebook, or New York Times which wants to access every single shitty computer in the world.
But for the rest of us, is it really worth it?
To me, it’s not. Why?
- The code bloat.
Simply put, anyone who supports progressive enhancement, or graceful degradation, has to support the fact that there is a significant amount of code bloat. At the very least from conditionals such as if IE then else if FIREFOX then else if WEBKIT then
- Single Page Apps (The Future)
Progressive enhancement is great, in theory.
But what if you come into an app thinking this is going to be a Single Page App. HTF (How the fuck) do you build a SPI using graceful degradation. (Hint the answer is you don’t)
Imagine Gmail or Pivotal Tracker without javascript
I know! It doesn’t make sense. You have to wait for page refreshes, IE makes a loud *click* sound and the little commet starts revolving around as the giant block of HTML is sent up. It’s really all so very 1990s.
Now-a-days are very different. Almost every site has javascript enabled. Statistics prove that it’s absolutely silly to support the around less than %$1 of browsers that don’t have JS enabled.
You’ll basically be building two applications. One crappy one that supports JS disabled browsers. And one super slick modern one that adopts gracefully degrading CSS3, ecmascript-5 JS, and HTML 5.
Which app sounds worth investing in? TimeHappiness is valuable
We have a really talented dev team at Art.sy. The best front-end programmers I’ve ever worked with. But even so we are wasting at-least weeks if not months supporting old versions of IE.
Quickly we are realizing that Thick Client architecture is the future. When phones are as cheap as < $200 for a computer that has a dual core processor at > 1ghz with the latest and greatest browsers, we start to realize our ideas of pumping giant block of HTML are old school, and now our clients can do all the UI processing by simple asking our API for JSON.
However, by offloading our awesomeness to our clients, we rely on our clients.
That means if our client is using IE 7, IE8, or even IE9 which doesn’t support the latest browser technologies, we are forced to accomodate this shit.
In comes the shims and army of helpers. The endless stories of refactoring this CSS3 powered feature to use a steamy pile of ugly javascript work-arounds.
I can literally see the years fall off my colleges like bad dandruff every-time we have to pick up a cross-browser story.
Happy developers make fast & efficient developers who care about the code they write. Don’t underestimate the value of a happy dev team.- Fuck it
There comes a point at which you have to make the tough decision to balance “is it worth my developers time to accommodate crappy browsers”.
And that is a hard ass question answer. But looking at the atmosphere, at-least to me, if you are starting a company in 2011+ it’s time to take the mentality fuck it.
By the time you actually gain momentum IE7, IE8, IE9 could be a thing of a the past.
Or maybe not.
Regardless it’s not worth wasting your precious iteration time trying to accommodate 10% of your very early stage clients who use shitty browsers when you could be spending that time iterating on your product. (By the time you become legit that 10% could become chrome (or IE 10) users)
- Product-market fit is #1
Iteration is key.
I’m a big fan of fast iterations and EDD. To have to stunt your development to accomodate shitty browsers will only waste time when you realize that feature needs to be entirely scrapped (or not).
Meet the bottom line polish you can, and when nobody complains it’s time to try something else.
Eventually, and I really mean eventually, people will start to twiddle their thumbs. That’s the time to support old IE fully. (Or that’s the time to make that fade in have a quint-ease with 3570 timeout).
Regardless, it will be quite a while until you reach that point. And until you reach that point, I say fuck it.
Bug Driven Development is somewhat of a joke. But it does make a good point. Why develop & polish features that could be thrown away tomorrow?
Yes you will get complaints. Lots of complaints.
But it’s necessary to filter what are fundamentally important critiques of your strategy and what is simply saying “I don’t like the typeface georgia, can our logo be blue!?!?!?” or “WTF!?!? When I click on this image it blips for a second and is 10 pixels off to the left!?!?!?”
It’s important to take as much criticism as possible in strides. But what will truly matter in the long run is the ability to be flexible and adaptive.
This goes for code & design. For this I have one very important point. That is
- Modularity
Solve problems in individual chunks.
Unfortunately this may come at the sacrifice of DRY but dependent code in favor of sometimes-less-dry but independent code. Or the sacrifice of a top-down-cohesive design, in favor of modular & iterative design.
But ultimately until you feel you’re done experimenting this is a very important value to instill in everyone.
Don’t get caught up on progressive enhancement, don’t get caught up on waterfall process, don’t get caught up on scrum process, don’t get caught up on anything.
Fundamentally build your team to be adaptive, to handle any quick sway and turn that startups are in-avoidably susceptible to and you are on a good start.
Finally: To fundamentally build your team to be adaptive means to not give a shit about old IE unless you really have to. :)