5 ms·

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 go

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.
- fishtoaster 11y ago
  I feel like google maps is a great example. Yes, you could technically make that a server-rendered page with a touch JS. But most of the benefit of google maps derives from its interactivity. If I were creating a new startup to build google maps, I'd have to consider: the best version of my product is the one with lots of heavyweight JS. 99.9% of my users will be able to use it. 80% will get a decent experience. It'd take me 60% longer to build a version that degrades gracefully. My competitors are breathing down my neck- is it worth spending that time? Most apps aren't as clear-cut as a video game or a blog. One company I worked at was a 2-sided e-commerce site (think "Craigslist for X"). It started server-side. We started adding more and more functionality to the main view, a grid of items. Quick-look popups and complex interdependent filters, and as-you-type search are what stick out in my mind, although there were others. We ended up rebuilding that page, and the decision was made to skip progressive enhancement so we could focus our limited resource on improving the javascript-heavy experience. We already had a mobile app and a mobile-specific site, so the only people that would be bothered by this would be the people with JS disabled on their desktops (a vanishingly small minority) or those with slow desktop connections (we only supported US sellers/buyers at the time, so that skewed us more towards fast internet). Another company was building an online version of a well-studied mental health technique (cognitive behavioral therapy). You can get this from a therapist, and it works quite well (measurably so), but it's quite expensive. You can get it from a $20 book, and it works well (measurably so), but completion rates are like 20% of when you do it with a therapist. Turns out that self-improvement is hard and people don't like doing hard things. So this company was building an online program that measurably worked. However, one of the key value propositions is that people should complete it at a higher rate than a book. Ideally at the same rate as a therapist (but cheaper and more convenient). To do that, the company needed every possible UX technique they could get their hands on. They needed every bit of interactivity at their disposal. In that case, it seems like a pretty good argument for focusing effort on a js-only app, even though the underlying content is largely a text-book.
  - egeozcan 11y ago
    Google Maps just shows some maps, and some metadata served next to them. Scrolling is not, at least for me, is the primary way to interact. All different zoom levels and map tiles are documents. I think Google Maps is a great candidate for progressive enhancement as maps are historically one of the most common documents. I mean, I totally understand what you are saying. However, not having enough resources for implementing progressive enhancement to make ninety something percent have the best experience for eighty something percent of the time and not having something suitable for progressive enhancement are different things.
smadge 11y ago
> 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.
- tuxracer 11y ago
  > Progressive enhancement leads to less initial effort. This is definitely not true across the board. I created a video player for reddit (http://dailyblocks.com http://dailyblocks.com) a while back which is completely client side rendered. Having done it this way I didn't need to setup or look for any server side technology. Simply put it up on any host that can serve up an HTML and JS file and be done with it. > Single page and script heavy applications are more complex and take more time to develop and debug than server side rendered applications. This also wildly varies depending on skill set and circumstances. Being a completely client side app all of the debugging tools come for free in my browser. If you happen to be more familiar with a different set of debugging tools then it's possible client side code takes more time for you to debug, but that's hardly a universal statement. > They often duplicate logic between the client and the server. Not true for isomorphic web apps. But again, depending on skill set this may or may not be more time consuming for you personally.
- lmm 11y ago
  Have you built anything with a modern single page application framework? It's really no harder to get started with than e.g. rails - you run a command that sets up a project skeleton, run another command to run the app, and then work on it.
  - smadge 11y ago
    I developed a hybrid mobile app using webpack/react/rxjs/cordova, so I have some experience with the ecosystem. Unless you are entirely using third party services, your single page application is probably contacting at least one service you also have to write. Now you have 2 applications to worry about, not just one. It adds complexity to your development, build, and release process. That complexity might be worth it.
aarongustafson 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 The thing is, PE is all about creating a workable, universal baseline that can be enhanced. It is a Minimum Viable Product. If you don't know if your product is, at its core, fulfilling a need, why spend the extra time making it fancy? > 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. A prototype is naturally a quickly assembled thing (often held together by chicken wire and duct tape) that you use to test the viability of an idea. Build prototypes however you want. Of course I'd argue that a bare-bones MVP would be the cheapest way to test an idea, but it doesn't really matter. A prototype should never be your production product unless you know it to be robust though. You should expect to rewrite most of your prototype in order to make it production ready. Unless you follow PE, of course, in which case you should have a solid, usable baseline that you can enhance into your amazing final product. > 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. I would counter-argue that we naturally gravitate toward doing stuff that's fun for us or gives us the opportunity to show off our skills. We over complicate things because we like challenges. Take the "dog age" example. An MVP would be uploading a photo and having the age guessing take place on the server side. One enhancement would do that via Ajax, another would add tap getUserMedia if it's available. In the end, the product works no matter what. There are very few "apps" that would not work in a PE scenario; it's all in how you look at them. The problems we are solving today on the Web are not new problems. For a great, brief talk on these topics, watch Adam Silver discuss at EnhanceConf: http://m.youtube.com/watch?v=UlzG6-fI00g http://m.youtube.com/watch?v=UlzG6-fI00g

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.

fishtoaster 11y ago
I feel like google maps is a great example. Yes, you could technically make that a server-rendered page with a touch JS. But most of the benefit of google maps derives from its interactivity. If I were creating a new startup to build google maps, I'd have to consider: the best version of my product is the one with lots of heavyweight JS. 99.9% of my users will be able to use it. 80% will get a decent experience. It'd take me 60% longer to build a version that degrades gracefully. My competitors are breathing down my neck- is it worth spending that time? Most apps aren't as clear-cut as a video game or a blog. One company I worked at was a 2-sided e-commerce site (think "Craigslist for X"). It started server-side. We started adding more and more functionality to the main view, a grid of items. Quick-look popups and complex interdependent filters, and as-you-type search are what stick out in my mind, although there were others. We ended up rebuilding that page, and the decision was made to skip progressive enhancement so we could focus our limited resource on improving the javascript-heavy experience. We already had a mobile app and a mobile-specific site, so the only people that would be bothered by this would be the people with JS disabled on their desktops (a vanishingly small minority) or those with slow desktop connections (we only supported US sellers/buyers at the time, so that skewed us more towards fast internet). Another company was building an online version of a well-studied mental health technique (cognitive behavioral therapy). You can get this from a therapist, and it works quite well (measurably so), but it's quite expensive. You can get it from a $20 book, and it works well (measurably so), but completion rates are like 20% of when you do it with a therapist. Turns out that self-improvement is hard and people don't like doing hard things. So this company was building an online program that measurably worked. However, one of the key value propositions is that people should complete it at a higher rate than a book. Ideally at the same rate as a therapist (but cheaper and more convenient). To do that, the company needed every possible UX technique they could get their hands on. They needed every bit of interactivity at their disposal. In that case, it seems like a pretty good argument for focusing effort on a js-only app, even though the underlying content is largely a text-book.
- egeozcan 11y ago
  Google Maps just shows some maps, and some metadata served next to them. Scrolling is not, at least for me, is the primary way to interact. All different zoom levels and map tiles are documents. I think Google Maps is a great candidate for progressive enhancement as maps are historically one of the most common documents. I mean, I totally understand what you are saying. However, not having enough resources for implementing progressive enhancement to make ninety something percent have the best experience for eighty something percent of the time and not having something suitable for progressive enhancement are different things.

smadge 11y ago

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

tuxracer 11y ago
> Progressive enhancement leads to less initial effort. This is definitely not true across the board. I created a video player for reddit (http://dailyblocks.com http://dailyblocks.com) a while back which is completely client side rendered. Having done it this way I didn't need to setup or look for any server side technology. Simply put it up on any host that can serve up an HTML and JS file and be done with it. > Single page and script heavy applications are more complex and take more time to develop and debug than server side rendered applications. This also wildly varies depending on skill set and circumstances. Being a completely client side app all of the debugging tools come for free in my browser. If you happen to be more familiar with a different set of debugging tools then it's possible client side code takes more time for you to debug, but that's hardly a universal statement. > They often duplicate logic between the client and the server. Not true for isomorphic web apps. But again, depending on skill set this may or may not be more time consuming for you personally.
lmm 11y ago
Have you built anything with a modern single page application framework? It's really no harder to get started with than e.g. rails - you run a command that sets up a project skeleton, run another command to run the app, and then work on it.
- smadge 11y ago
  I developed a hybrid mobile app using webpack/react/rxjs/cordova, so I have some experience with the ecosystem. Unless you are entirely using third party services, your single page application is probably contacting at least one service you also have to write. Now you have 2 applications to worry about, not just one. It adds complexity to your development, build, and release process. That complexity might be worth it.

aarongustafson 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 The thing is, PE is all about creating a workable, universal baseline that can be enhanced. It is a Minimum Viable Product. If you don't know if your product is, at its core, fulfilling a need, why spend the extra time making it fancy? > 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. A prototype is naturally a quickly assembled thing (often held together by chicken wire and duct tape) that you use to test the viability of an idea. Build prototypes however you want. Of course I'd argue that a bare-bones MVP would be the cheapest way to test an idea, but it doesn't really matter. A prototype should never be your production product unless you know it to be robust though. You should expect to rewrite most of your prototype in order to make it production ready. Unless you follow PE, of course, in which case you should have a solid, usable baseline that you can enhance into your amazing final product. > 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. I would counter-argue that we naturally gravitate toward doing stuff that's fun for us or gives us the opportunity to show off our skills. We over complicate things because we like challenges. Take the "dog age" example. An MVP would be uploading a photo and having the age guessing take place on the server side. One enhancement would do that via Ajax, another would add tap getUserMedia if it's available. In the end, the product works no matter what. There are very few "apps" that would not work in a PE scenario; it's all in how you look at them. The problems we are solving today on the Web are not new problems. For a great, brief talk on these topics, watch Adam Silver discuss at EnhanceConf: http://m.youtube.com/watch?v=UlzG6-fI00g http://m.youtube.com/watch?v=UlzG6-fI00g