
Progressive Enhancement Makes Me Sad - oliverdunk
http://www.heydonworks.com/article/progressive-enhancement-makes-me-sad
======
fishtoaster
This is a weird piece, since it's clear by the end that it's satire, but he
has a few good points (whether he knows it or not):

1\. "But who’s to say there’s going to _be_ any users?" -> Which is true. If
you're just starting a project out, you have to decided whether it's worth an
extra X hours/days/weeks for any given bit of technical improvement, whether
it's progressive enhancement or something else. If it expands my potential
user base by 10%, but doubles my time to market, it may not be worth it.

2\. "The less time I spend on creating a robust architecture (boring) the more
time I have for creating features." -> Ignoring the "boring" remark, this is
true. I could spend a near infinite amount of time improving my architecture,
but at a certain point I reach diminishing returns. Where I cut off my
robustness work depends on the nature of the project, but every project has
_some_ point at which you'd improve user experience more by adding a feature
than improving performance. For an early prototype, that point may be quite
soon.

3\. "It’s all web apps now" -> I think the author is aware of this, but there
_are_ many apps which just don't fit particularly well into a document. It's
not clear whether the author really thinks all such apps are trivial (eg
detecting your dog's age), but I'd argue there are plenty of substantial apps
that don't fit that model well, and benefit substantially from being a full-on
js-heavy web app.

~~~
smadge
> whether it's worth an extra X hours/days/weeks for any given bit of
> technical improvement, whether it's progressive enhancement or something
> else

Progressive enhancement leads to less initial effort. Single page and script
heavy applications are more complex and take more time to develop and debug
than server side rendered applications. They often duplicate logic between the
client and the server. Alternatively, throw together some database queries and
hook them up to html templates, and you have the foundation for a
progressively enhancing site. You can then expend the extra effort to ENHANCE
your site by sprinkling in client side code and cutting edge css features.

~~~
fishtoaster
I suppose this is entirely subjective, but I have to disagree that an SPA is
inherently more complex and time-intensive that building equivalent
functionality mostly server-side. I split my time about evenly between
serverside development (Rails, then PHP before that, then Java before that)
and clientside (React, then Angular before that, then Backbone before that,
and jquery soup before that). I think it depends on the app, but I definitely
find certain kinds of apps are a lot easier in a large clientside framework.

Now, there are cases for each. Building a simple blog, you'd be right: a
server-rendered app with a sprinkling of JS for flavor would probably be a lot
easier. On the other hand, a site that behaves more like an app might be
quicker to build as an SPA. For example, an e-commerce site with complex
filtering (you can filter by size, but it goes 0-20 for shoes, sm-xl for
t-shirts, 10-70 for jeans, etc) and complex UI interactions available in-page
on each item such as one-click buying, searching for similar items, setting up
a price-alert, etc). You _could_ do that mostly server-side, but I'd argue
your frontend (at least on the item-browsing page) is heavier enough that it
may be easier to just build a js-first site to start with.

~~~
smadge
It all depends on the use case. I'm just trying to refute the parent comment.
In some situations, e.g. when you are starting with server side logic and
rendering, progressive enhancement is actually less effort. You get it for
free since all user agents support html. Some applications might justifiably
start out as single page applications. Other make more sense using the
metaphor of hyperlinked resources.

~~~
sanderjd
Here is my own personal experience: You're fighting user expectations by doing
things this way. Your users almost unanimously don't care how you architect
your application, but they are used to using Facebook, Gmail, Dropbox, AirBnB,
etc. etc. and they will eventually expect and ask you for the same sort of
experience, at which point you will put more time into tacking on dynamic
features to a static application than you would have spent designing a dynamic
application to begin with. Then you'll probably end up re-writing the complex
portions (and eventually all portions, because hybrids suck to maintain) in a
front-end framework and pulling out the back-end logic into a convenient API,
and coming to the conclusion that you would have started that way if you knew
you were going to end that way. Then you'll start looking at new applications
through that lens of whether your users will ever want that sort of dynamism,
and you'll start concluding pretty much every time (because nobody _ever_ asks
you to build a blog or publication site) that your users will want that sort
of thing, so you're better off going dynamic up front. Now you just have the
(smaller, IMO) problem of what to do about the users who don't want the
dynamic stuff, and if you're successful enough that you can afford to invest
in it, you can put the time into progressive enhancement, which (in my
opinion!) is easier than retro-fitting rich front-ends onto static apps.

This may all be wrong at each step, but hopefully it illuminates a bit how a
lot of us (otherwise sensible developers) ended up thinking it makes more
sense to start most things as rich-front-end+API apps.

------
rvdm
To me, the awkward "is this funny or not" approach to writing this article
fits in perfectly with the sentiment of the author (and my own) about the
subject.

In my 18 years as a web dev I've tumbled down every rabbit hole and been
caught by every trap ever.

We wanted animation? Great, learn some ActionScript. Now you want databases?
Add some MySQL and PHP. But then those weren't cool anymore and everything had
to be RoR and jQuery. Then we ended up writing monsters of jQuery code trying
to make sites feature packed and along came Backbone. After that there was
Angular, but then people realized SEO and accessibility still need to be
considered so now I spend my days writing what should have been as simple as:

<h1>Hello World</h1>

Like this:

React.createElement(

    
    
      'h1',
    
      {},
    
      'Hello World'
    

);

So the solution to HTML is now to simply give up on HTML and write everything
in JavaScript…

I like React, Redux, Node, etc a lot. The fact we can have Universal and
Native React and that there finally is a robust solution to most ( all? ) web
dev problems is fantastic. But the overhead in development time is
significant. When possible I use these tools, but in a lot of cases, I just
give up on it all and end up writing straight up HTML divs without any
flexboxes or animations or shivs or shims or 5's or 3's. Just the good old
stuff I was writing back in 1998.

When comparing web development to something like developing for iOS, this full
circle we've made does feel painful ironic. So much so it's hard to tell if
it's funny or not.

Small note to the author : love the beautiful big font on your site but you
have some colliding elements on iPad portrait.

~~~
fishtoaster
If you can accomplish what you want with just html, you absolutely should! :)
It doesn't work for a lot of use-cases, but it's great if it fits your use-
case.

------
ebiester
For the most part, I think people are talking past each other. For sites that
are document-based toward a wide audience, progressive enhancement makes the
most sense. For application-centric sites (For example, an internal admin app,
or a B2B application where SEO and phones aren't the primary interface) why
would I spend the money for the extra work?

It's almost as if your use case should determine your strategy.

~~~
aarongustafson
> For application-centric sites (For example, an internal admin app, or a B2B
> application where SEO and phones aren't the primary interface) why would I
> spend the money for the extra work?

If you have control over the end-user's environment, by all means do whatever
you want. But when you don't (let's say your building an online banking site),
you should ensure your real users can access it (and their money) no matter
what.

Of course locking into specific technologies is why IE6 continues to persist
(Intranets, South Korean banks), so that's some additional food for thought.
It may not be a concern in your specific instance but it's a risk if you don't
use web standards.

> It's almost as if your use case should determine your strategy.

:-) I wish more folks thought that way. When all you have is a hammer…

------
pmalynin
We've faced this problem when we were deploying our Meteor application. The
issue in particular was mostly for crawlability purposes and Twitter/Facebook
metadata. The first issue (crawlability) -- which, of course, directly impacts
users who cannot run javascript such as search engines [1] -- can be solved
trivially by sticking phantomjs in front and redirecting server-side depending
on UA. Combined with NGINX's caching you can then serve these rendered pages
without needing to hit phantomjs every single time. The nice thing is, if you
don't prune the "script" tags from the rendered pages, you can then just serve
these cached pages back to the user. The HTML will be rendered, then if you
have JS enabled the Meteor (React | Angular | JSFrameworkOfChoice) it will
just re-render the page.

[1] I am aware that Google now can run JavaScript, but I've found it to be
rather bad and to mangle my pages in quite horrible ways.

------
jschwartzi
I completely agree with this post. Most people don't realize what a burden it
is to write websites that function while taking less than a gigabyte of ram
and four cores. You shouldn't be browsing the newspaper with a device that's
older than two years anyway.

~~~
hashkb
Read it again. You actually disagree with it.

~~~
dack
I'm pretty sure jschwartzi was kidding :)

------
hashkb
I was hoping for good arguments so I could justify laziness but am almost as
pleased to have that hope lampooned.

------
bjterry
Any additional technical requirements lead to more work (or less quality), and
progressive enhancement is obviously a technical requirement. I think this is
obvious if you think of even the most basic web interaction: form submission.

With progressive enhancement, you have to have one form submission that
doesn't use AJAX, which means it POSTs to the server and the server accepts
the POST and replies with a fully-formed HTML document. Then, because you want
to delight your users with animations and a responsive low-latency feel, you
have an AJAX version of the form, which posts to the server and receives a
JSON response for client-side template rendering. You can share some code
between these two, but because rendering the whole page requires completely
different data from rendering just the component you are updating, there is a
bunch of conditional code.

You essentially have to build two models of your application, one on the
server side which knows the state of your application (is this modal open, is
this widget showing, have they collapsed this widget) and one on the client
side that separately maintains all the same state and has transitions between
them that will result in identical html. It has to be this way, otherwise your
UI is not going to be responsive, animated and delightful for users, and
you're going to lose in the marketplace. Since you have two models of the
state of your app, now you have to make sure they are always in sync. All the
testing and bugs and complexity maintaining that dual state could instead be
spent on building the next great feature for your users.

Now obviously, this is sensitive to context. If you work for a giant
enterprise and have more programmers than you know what to do with and clear
product requirements set by the market, you can spend the time to build a
product that addresses 99% of the users, even if going from 80% to 99% takes
80% more work. But if you are a startup, and you are either racing with
competitors to build out the functionality demanded by users, or still
exploring the functionality that will see successful adoption of your product,
you'd be crazy to slow yourself down to get every user running NoScript, IE10,
or whatever other old browsers. You just need to get your product working for
some subset of passionate users, then you can spend more engineering resources
on supporting users with older devices once you've proven out the market.
Otherwise you may not be around to do so.

~~~
kuschku
Have you worked with GWT before? Or Grails? Or RoR?

A lot of web frameworks do all those tasks for you.

In Grails, I can just specify a single piece of backend code, and it’ll work
as REST API with data in JSON or XML, it will work in webbrowsers, and I can
usually easily integrate it into mobile applications, too.

~~~
fishtoaster
I've done a bit of work with Rails' js tools. I hear they're getting better in
5, but I haven't paid attention to them in a while. Last I looked, they were
great if all you wanted to do was take a basic html form and make it act
pretty much the same but actually submit via ajax. If you wanted to do
anything more complex, it got tricky.

------
cmrx64
Poe's law has struck me down here. Either author is an asshole, or author
doesn't know how to do good parody.

~~~
dllthomas
Up until 3, I was leaning "not parody", but 3 _has_ to be parody.

 _" Then there’s trains. Urgh. So you’re having trouble downloading a client-
rendered, blocking-javascript-dependent web page over 2G because you’re on a
train? The solution’s staring you in the face: Stop travelling by train.
Either get a pad in the city center near your place of work or sleep under
your desk. That’s what I did, why can’t you?

Honestly, take some responsibility."_

~~~
mrgoldenbrown
The "take some responsibility" line is actually very close to what I hear real
people say all the time in discussions on poverty. Many people seem to firmly
believe the idea that poor people are only poor because they're lazy. It is
not hard for me to believe there are developers out there who would actually
say something like this.

~~~
dllthomas
I don't disagree that there are echoes of things that are actually said -
that's to be expected of parody. But it's the combination that's so over the
top. "If you (and your partner?) are not living in the (same) city center
where you (both) work, _you_ are responsible for our app's poor experience."

------
daigoba66
> There’s no “document” version of an app that guesses what age your dog is. I
> mean, what would that even look like?

I guess the author doesn't realize that code can live on a server. And the
answer to his query can simply be a "document".

Edit: I did not catch that the article is supposed to be a joke. If that's
true... I suppose it's not very funny.

~~~
oliverdunk
I'm not sure how apparent it is, but the post is a joke aimed at pointing fun
at people who agree with the arguments (I didn't write it, by the way)

------
chris_wot
I'm not really sure why progressive enhancement is considered hard...

~~~
chriswarbo
Yes, it's strange. Progressive enhancement _was_ the idea that you throw
together a simple, working site with HTML and POST forms, then once it's
working you can burn as much time as you like adding fanciful doodads with
CSS, Javascript, etc.

Now it's apparently easier to build a fanciful doodad than it is to write a
string of text.

------
jff
It's a little off-topic, but this was one of the few websites where I've had
to _shrink_ the text to make it readable. I'm not complaining, completely the
opposite--it just reminded me of an article the other day that said it's
better to be more accessible by default, and for instance my dad would have
probably been pretty happy with the default text size.

------
zeveb
Heh, excellent. He really had me there for a moment.

------
wahsd
#3 Encourages Bad Behavior ... I was in the middle of Silicon Valley at a
hotel that barely had a medium 3G signal and a weak LTE signal in pockets...
and that was outside the building facing the bay. If not even SV can muster
good signal strength that point is moot.

------
jhpriestley
The premise that server-side HTML generation is faster than client-side HTML
generation is simply false. See here for experimental confirmation:
[http://www.onebigfluke.com/2015/01/experimentally-
verified-w...](http://www.onebigfluke.com/2015/01/experimentally-verified-why-
client-side.html)

Why would offloading computation to a heavily-taxed central server speed
anything up? It doesn't make much sense. Nor is HTML generation a bottleneck
in most realistic applications.

~~~
joekrill
You almost confirm his point:

> Well, I’ve got a pretty good setup for starters: Fibre, 16GB RAM.

You're using a fairly decent desktop setup, and a top-of-the-line mobile
setup, and there's no talk about server-side specs. So yes, it's true that
"The premise that server-side HTML generation is faster than client-side HTML
generation is simply false." \-- in your one particular, very specific use
case.

~~~
JoeAltmaier
The server has to do it for everybody, right? If it scales at all, no server
is powerful enough. But mobile makes it more complex.

~~~
Retric
If you can afford to do X on a server. Then spending 10x the resources to load
in 1/10 or better yet 1/100th the time scales just fine.

Consider, there is no way for a single users machine to do a Google search in
any reasonable time frame. Google search works because they can scale out to
enough machines to keep everything important in RAM which drastically reduces
the workload per request. They can also cache results.

------
placeybordeaux
What is up with HN and promoting barely parody pieces?

~~~
wcummings
People enjoy entertainment. Satire is entertaining.

~~~
placeybordeaux
I enjoy satire, but so many of these pieces are barely satire.

