6 ms·

Progressive Enhancement Makes Me Sad

57 points by oliverdunk 11y ago

hashkb 11y ago
I was hoping for good arguments so I could justify laziness but am almost as pleased to have that hope lampooned.
daigoba66 11y ago
> 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 11y ago
  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)
cmrx64 11y ago
Poe's law has struck me down here. Either author is an asshole, or author doesn't know how to do good parody.
- dllthomas 11y ago
  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 11y ago
    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.
    - giaour 11y ago
      It's no more outlandish than any of the comments that end up on @ShitHNSays
    - dllthomas 11y ago
      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."
- hyperpape 11y ago
  "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?" I love Poe's law, but this is not an instance. It's not really that funny either, but it's obvious parody.
  - cmrx64 11y ago
    But that's something that people have actually done, for example http://www.salon.com/2015/04/30/i_secretly_lived_in_my_office_for_500_days/ http://www.salon.com/2015/04/30/i_secretly_lived_in_my_offic... as a written account of it...
    - hyperpape 11y ago
      Yes, people have done it. But have they argued that everyone should do so in order to avoid going on trains?
- HelloNurse 11y ago
  If you are confused, blame contemporary web development, an involuntary parody of what it should be.
- draw_down 11y ago
  The existence of Poe's law isn't a license to just stop thinking critically.
  - cmrx64 11y ago
    I'm not sure what you're getting at.
zeveb 11y ago
Heh, excellent. He really had me there for a moment.
jschwartzi 11y ago
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 11y ago
  Read it again. You actually disagree with it.
  - dack 11y ago
    I'm pretty sure jschwartzi was kidding :)
fishtoaster 11y ago
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.
- baggachipz 11y ago
  > 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. My last gig totally fell victim to this. Every time we'd add a new feature, some other group of features would suddenly become "critical to launch" and by the time we did actually launch, there was no more runway. :(
- egeozcan 11y ago
  > it's clear by the end that it's satire If you hadn't written this, I would have dismissed this article after reading the first two paragraphs. Thank you. > but there are many apps which just don't fit particularly well into a document I think hard but maybe because I've been working on a CRUD web-app for so long, I can't come up with any examples other than demos/games and then, I doubt any reasonable person would expect them to run without running any code client-side. I even went through some random selection on my bookmarks and 99% of them were documents with some interactivity. Most of the exceptions were document editors, and I think even they could, if the developer felt masochistic, fall back to text boxes and buttons. I sincerely hope that's not my lack of imagination.
jhpriestley 11y ago
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-why-client-side.html http://www.onebigfluke.com/2015/01/experimentally-verified-w... 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 11y ago
  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 11y ago
    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 11y ago
      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.
  - jhpriestley 11y ago
    Put some numbers up. This whole debate is driven by so much vague thinking and so many unfounded assumptions. What realistic, year 2016 HTML client is so slow that it can't run 100K or so of string interpolation in a millisecond or two? Quite aside from the supposed benefits of performing computation on a server, the idea that web applications are bottlenecked by HTML generation is already absurd.
jff 11y ago
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.
ebiester 11y ago
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.
- rvdm 11y ago
  Wouldn't that be refreshing! enter office politics
- aarongustafson 11y ago
  > 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…
wahsd 11y ago
#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.
chris_wot 11y ago
I'm not really sure why progressive enhancement is considered hard...
- chriswarbo 11y ago
  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.
rvdm 11y ago
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 11y ago
  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.
pmalynin 11y ago
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.
bjterry 11y ago
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 11y ago
  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.
placeybordeaux 11y ago
What is up with HN and promoting barely parody pieces?
- wcummings 11y ago
  People enjoy entertainment. Satire is entertaining.
  - placeybordeaux 11y ago
    I enjoy satire, but so many of these pieces are barely satire.

57 points by oliverdunk 11y ago

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

> 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 11y ago
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)

cmrx64 11y ago

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

dllthomas 11y ago
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 11y ago
  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.
  - giaour 11y ago
    It's no more outlandish than any of the comments that end up on @ShitHNSays
  - dllthomas 11y ago
    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."
hyperpape 11y ago
"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?" I love Poe's law, but this is not an instance. It's not really that funny either, but it's obvious parody.
- cmrx64 11y ago
  But that's something that people have actually done, for example http://www.salon.com/2015/04/30/i_secretly_lived_in_my_office_for_500_days/ http://www.salon.com/2015/04/30/i_secretly_lived_in_my_offic... as a written account of it...
  - hyperpape 11y ago
    Yes, people have done it. But have they argued that everyone should do so in order to avoid going on trains?
HelloNurse 11y ago
If you are confused, blame contemporary web development, an involuntary parody of what it should be.
draw_down 11y ago
The existence of Poe's law isn't a license to just stop thinking critically.
- cmrx64 11y ago
  I'm not sure what you're getting at.

zeveb 11y ago

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

jschwartzi 11y ago

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 11y ago
Read it again. You actually disagree with it.
- dack 11y ago
  I'm pretty sure jschwartzi was kidding :)

fishtoaster 11y ago

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.

baggachipz 11y ago
> 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. My last gig totally fell victim to this. Every time we'd add a new feature, some other group of features would suddenly become "critical to launch" and by the time we did actually launch, there was no more runway. :(
egeozcan 11y ago
> it's clear by the end that it's satire If you hadn't written this, I would have dismissed this article after reading the first two paragraphs. Thank you. > but there are many apps which just don't fit particularly well into a document I think hard but maybe because I've been working on a CRUD web-app for so long, I can't come up with any examples other than demos/games and then, I doubt any reasonable person would expect them to run without running any code client-side. I even went through some random selection on my bookmarks and 99% of them were documents with some interactivity. Most of the exceptions were document editors, and I think even they could, if the developer felt masochistic, fall back to text boxes and buttons. I sincerely hope that's not my lack of imagination.

jhpriestley 11y ago

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-why-client-side.html http://www.onebigfluke.com/2015/01/experimentally-verified-w... 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 11y ago
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 11y ago
  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 11y ago
    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.
- jhpriestley 11y ago
  Put some numbers up. This whole debate is driven by so much vague thinking and so many unfounded assumptions. What realistic, year 2016 HTML client is so slow that it can't run 100K or so of string interpolation in a millisecond or two? Quite aside from the supposed benefits of performing computation on a server, the idea that web applications are bottlenecked by HTML generation is already absurd.

jff 11y ago

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.

ebiester 11y ago

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.

rvdm 11y ago
Wouldn't that be refreshing! enter office politics
aarongustafson 11y ago
> 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…

wahsd 11y ago

#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.

chris_wot 11y ago

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

chriswarbo 11y ago
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.

rvdm 11y ago

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 11y ago
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.

pmalynin 11y ago

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.

bjterry 11y ago

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 11y ago
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.

placeybordeaux 11y ago

What is up with HN and promoting barely parody pieces?

wcummings 11y ago
People enjoy entertainment. Satire is entertaining.
- placeybordeaux 11y ago
  I enjoy satire, but so many of these pieces are barely satire.