4 ms·
Any additional technical requirements lead to more work (or less quality), and progressive enhancement is obviously a technical requirement. I think this is obv
by 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 agoHave 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.
- bjterry 11y agoNo, I have not. My experience is mostly with Yesod and Django. If progressive enhancement is truly a zero-overhead solved problem in these other frameworks that certainly sounds very interesting though.
- fishtoaster 11y agoI'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.