Ask HN: Does your web app work with javascript off?
12 comments
It's a hard choice.
I was recently involved in a project that was heavily focused on progressive enhancement - we started with a "standard" HTML app with forms and submit buttons. Every interaction required a full page load.
Then we started using Javascript to enhance the UX in such a way that it still worked without Javascript. It was a long and tricky process, because progressive enhancement is inherently quite fragile. You are basically taking an app, and then monkey patching it at runtime to be a different app. This is hard. :) Any change anywhere ripples through the whole app, and the entire thing is an offence against DRY; you are duplicating logic over and over and over.
Still, after a lot of time and effort... ...we gave up. We just couldn't get a slick, user friendly experience with JS, without the site breaking without JS. And frankly, the UX without JS was terrible anyhow. We rewrote the thing as a SPA (single page app). The codebase is much simpler, and the UX is great. :)
For us, the biggest pain point is our initial design had a server the emitted HTML; and accepted forms POSTed back to it. To enable AJAX, we then needed to duplicate a bunch of functionality so it would accept and emit JSON as well; this led to major headaches trying to keep all the logic in sync. If you DO want to maintain progressive enhancement...you need to figure out your site design from the start; it can't be an afterthought! If it's a complex project, you will live and die by your ability to keep your code DRY and enforce Seperation of Concerns.
I was recently involved in a project that was heavily focused on progressive enhancement - we started with a "standard" HTML app with forms and submit buttons. Every interaction required a full page load.
Then we started using Javascript to enhance the UX in such a way that it still worked without Javascript. It was a long and tricky process, because progressive enhancement is inherently quite fragile. You are basically taking an app, and then monkey patching it at runtime to be a different app. This is hard. :) Any change anywhere ripples through the whole app, and the entire thing is an offence against DRY; you are duplicating logic over and over and over.
Still, after a lot of time and effort... ...we gave up. We just couldn't get a slick, user friendly experience with JS, without the site breaking without JS. And frankly, the UX without JS was terrible anyhow. We rewrote the thing as a SPA (single page app). The codebase is much simpler, and the UX is great. :)
For us, the biggest pain point is our initial design had a server the emitted HTML; and accepted forms POSTed back to it. To enable AJAX, we then needed to duplicate a bunch of functionality so it would accept and emit JSON as well; this led to major headaches trying to keep all the logic in sync. If you DO want to maintain progressive enhancement...you need to figure out your site design from the start; it can't be an afterthought! If it's a complex project, you will live and die by your ability to keep your code DRY and enforce Seperation of Concerns.
You would have saved a lot of time and frustration by building the single page app first and putting analytics on it to see how many non-JavaScript clients you where getting (most are surprised at how few the number is) and then if the number justify it, build out an older style UI separate from the modern web app that just proxies data to the same REST services, then use a sniffer to decide where each client goes. This is a simpler solution than trying to layer on dynamic functionality while trying to support the least common denominator. 9 time out of 10 though, when faced with the decision, the effort to chase older browsers is better spent chasing a larger market like Mobile.
I know! :( It was definitely a learning experience.
And in regards to your comment on mobile: Agreed! Not only is getting a slick mobile client a much more important use of resources that stuffing around with progressive enhancement, but a good JSON/REST API is really really helpful when it comes time to get a mobile app working.
Thinking of webapps as client-server applications communicating via a JSON API is really helpful at the moment, I think.
And in regards to your comment on mobile: Agreed! Not only is getting a slick mobile client a much more important use of resources that stuffing around with progressive enhancement, but a good JSON/REST API is really really helpful when it comes time to get a mobile app working.
Thinking of webapps as client-server applications communicating via a JSON API is really helpful at the moment, I think.
Yes many people make that leap after a first iteration, but once you do the pattern becomes very clear and very powerful. Looking at your back-end as a platform for all future clients really helps as well.
Yeah, I should expand on this and say that, if you want your page to be bilingual, it helps to have a central gateway through which your data will pass. If you know that you're going to want to request X, Y, and Z as JSON later, then there should be an intermediate form of the data as something which you could easily serialize into JSON -- and your HTML pages are then just a particular loose-and-quick view of that data.
Is this the "right" way to be doing this?
This is a subjective question and there is a lot of dogma surrounding the question. I tend to answer my questions with dollars as in are the dollars there to chase that market and would the money to chase that market be better spent chasing a larger market? My second question to myself if which is less costly to develop and maintain? Finally a little more hard to quantify but which can I make better conversions with?
The first one is pretty easy, for a good deal of sites the percentage of browsers that do not support or have JavaScript turned off is usually less than 1% I have seen numbers as high as 2% either way, it is below niche at best. It is pretty easy to make the statement that the money would be better spent chasing mobile or even in advertising for the 99% than it would be to chase the 1%.
The second one is a little more subjective but I have found for me and my team that writing UI's 100% in JavaScript/HTML/CSS simplifies the architecture and increases our time to market. I personally feel the worst solution is to sprinkle JavaScript into a server side solution such as PHP, ASP, or JSP it creates a more complex stack and complicates the solution requiring more layers and more specializations. With the UI being in all client side technologies, it becomes very easy to stub JSON messages and use those as the contract between front end and back end teams. I actually prefer the modern way of developing web application over the old server side model.
Finally I feel that the flexibility of JavaScript solutions and there rapid development model give them the edge on building UI's for conversion, simple tweaks can be made to the UI and delivered without the need for a full deployment of back end services. As well their are UI metaphors that just cannot be done in page-post. While I will be the first to note that this is subjective it works well for myself and my team and we have delivered some very large, adaptable, yet maintainable applications in JavaScript.
This is a subjective question and there is a lot of dogma surrounding the question. I tend to answer my questions with dollars as in are the dollars there to chase that market and would the money to chase that market be better spent chasing a larger market? My second question to myself if which is less costly to develop and maintain? Finally a little more hard to quantify but which can I make better conversions with?
The first one is pretty easy, for a good deal of sites the percentage of browsers that do not support or have JavaScript turned off is usually less than 1% I have seen numbers as high as 2% either way, it is below niche at best. It is pretty easy to make the statement that the money would be better spent chasing mobile or even in advertising for the 99% than it would be to chase the 1%.
The second one is a little more subjective but I have found for me and my team that writing UI's 100% in JavaScript/HTML/CSS simplifies the architecture and increases our time to market. I personally feel the worst solution is to sprinkle JavaScript into a server side solution such as PHP, ASP, or JSP it creates a more complex stack and complicates the solution requiring more layers and more specializations. With the UI being in all client side technologies, it becomes very easy to stub JSON messages and use those as the contract between front end and back end teams. I actually prefer the modern way of developing web application over the old server side model.
Finally I feel that the flexibility of JavaScript solutions and there rapid development model give them the edge on building UI's for conversion, simple tweaks can be made to the UI and delivered without the need for a full deployment of back end services. As well their are UI metaphors that just cannot be done in page-post. While I will be the first to note that this is subjective it works well for myself and my team and we have delivered some very large, adaptable, yet maintainable applications in JavaScript.
Do whatever is easiest first. JS can be pretty, but hard -- at least, the DOM is much harder than HTML. Get an HTML serialization of your data working first, before you try to use client-side JS to write this data dynamically into a form -- not because it helps us, but because JS mappings are harder than PHP echos.
It will also give you a better appreciation of the places where Web 2.0 can really streamline a system. Just to give an example, Gmail is a massive JS app which uses a frankly unbelievable number of divs to reimplement an iframe window where you can view your email and/or lists of email subjects. It's quite possible that the communications reduction is so big that this is important to Gmail, but you're not that size yet, so just use an iframe rather than reimplementing that functionality in a special way.
There are other situations where JS is a bad technology. I should be able to navigate your site without JS, and if you demand JS for navigation you're probably doing it wrong. I should potentially even be able to log in, if you're not using OpenID or BrowserID or client-side crypto.
AJAX can be useful for creating chat applications, or for situations where you want to be able to see, query, and throw away lots of little pieces of information. Javascript is also useful when you want a control which should never hit the server, like folding a tree of comments -- which I recently implemented as a user script for HN.
That's another plus of using HTML, by the way: it makes it easier for scripters to hack on your site to add their own personal features. I tried to do user scripting on Gmail at one point, it was damn near impossible. Their divs belong to memorably named classes like "vI8oZc cN" and "nH w-asV" and "mq nH oy8Mbf". Such are the perils of trying to build your iframes dynamically out of divs.
Anyway, once you start to get into user interactions, JS becomes much more fun and important. If I am coming to your site to play an HTML5 game, then I already know I need to turn off NoScript, you don't have to tell me. If you've got an interaction which simply screams "drag and drop", then do that instead. Some of the nice uses of JS I've seen recently amount to visualizing graph networks and allow you to drag nodes around to optimize the display; that's a good candidate for a JS implementation.
JS is not merely for facilitation, and can have real uses on a CRUD-type site. Just be sure that you're not reinventing something which already exists without JS, like iframes, URLs, and so forth.
It will also give you a better appreciation of the places where Web 2.0 can really streamline a system. Just to give an example, Gmail is a massive JS app which uses a frankly unbelievable number of divs to reimplement an iframe window where you can view your email and/or lists of email subjects. It's quite possible that the communications reduction is so big that this is important to Gmail, but you're not that size yet, so just use an iframe rather than reimplementing that functionality in a special way.
There are other situations where JS is a bad technology. I should be able to navigate your site without JS, and if you demand JS for navigation you're probably doing it wrong. I should potentially even be able to log in, if you're not using OpenID or BrowserID or client-side crypto.
AJAX can be useful for creating chat applications, or for situations where you want to be able to see, query, and throw away lots of little pieces of information. Javascript is also useful when you want a control which should never hit the server, like folding a tree of comments -- which I recently implemented as a user script for HN.
That's another plus of using HTML, by the way: it makes it easier for scripters to hack on your site to add their own personal features. I tried to do user scripting on Gmail at one point, it was damn near impossible. Their divs belong to memorably named classes like "vI8oZc cN" and "nH w-asV" and "mq nH oy8Mbf". Such are the perils of trying to build your iframes dynamically out of divs.
Anyway, once you start to get into user interactions, JS becomes much more fun and important. If I am coming to your site to play an HTML5 game, then I already know I need to turn off NoScript, you don't have to tell me. If you've got an interaction which simply screams "drag and drop", then do that instead. Some of the nice uses of JS I've seen recently amount to visualizing graph networks and allow you to drag nodes around to optimize the display; that's a good candidate for a JS implementation.
JS is not merely for facilitation, and can have real uses on a CRUD-type site. Just be sure that you're not reinventing something which already exists without JS, like iframes, URLs, and so forth.
JavaScript is a requirement for my work applications. We have a lot of core components that get used in almost all of our projects and they rely heavily of JavaScript and jQuery. I know for certain there is no interest in providing a non JavaScript UI flow for our users as it would require far too much time and money to rework existing frameworks and components.
For my personal projects I had thought about allowing for non JavaScript users. I started making sure that things worked under both scenarios but in the end I figured that if you don't have JavaScript enabled you really aren’t going to get use of the main features of the project. So now I don't bother and can use that time for adding more features rather than a user path for a very small minority.
For my personal projects I had thought about allowing for non JavaScript users. I started making sure that things worked under both scenarios but in the end I figured that if you don't have JavaScript enabled you really aren’t going to get use of the main features of the project. So now I don't bother and can use that time for adding more features rather than a user path for a very small minority.
First of all it depends on the app. If it's a public service I personally find that having this constraint of making your app work with JavaScript off leads to a better web architecture. It doesn't break the web and pays off in the long run for whoever might integrate with your app or whatever products might consume it now or in the near future. Graceful degradation is not all about the end-users.
So my advice would be if you're building a JavaScript only app you have to really know what you're doing, because it's very easy to get carried away with it. Keep in mind that you risk making it "incompatible" with the web. When a need arises to be "compatible" you might end up finding yourself building second version of the same app.
So my advice would be if you're building a JavaScript only app you have to really know what you're doing, because it's very easy to get carried away with it. Keep in mind that you risk making it "incompatible" with the web. When a need arises to be "compatible" you might end up finding yourself building second version of the same app.
I had to re-check the date of the post and it isn't 2006 but 2012 !!! Three observations:
1) If your users aren't using a HTML5 compliant browser then they should update. Supporting a multitude of outdated browsers is just way too big a workload.
2) Using JavaScript/AJAX intelligently reduces the load on your server. Why generate all that HTML on demand at the server when you have a dual core CPU with a couple of Gigs of RAM twiddling its thumbs at the client end?
3) With mobile apps, your users will thank you for minimising the amount of traffic your app generates. Why push down full pages when only the data needs to be sent?
1) If your users aren't using a HTML5 compliant browser then they should update. Supporting a multitude of outdated browsers is just way too big a workload.
2) Using JavaScript/AJAX intelligently reduces the load on your server. Why generate all that HTML on demand at the server when you have a dual core CPU with a couple of Gigs of RAM twiddling its thumbs at the client end?
3) With mobile apps, your users will thank you for minimising the amount of traffic your app generates. Why push down full pages when only the data needs to be sent?
I'd say a couple of years ago - gradeful degradation was a must.
Nowadays - unless you're running some kind of viral service (facebook, twitter etc.) that benefits from masses instead of customers, it's not a requirement.
Still a nice to have, but if people can't update their software, they should 'suffer the consequences'.
Nowadays - unless you're running some kind of viral service (facebook, twitter etc.) that benefits from masses instead of customers, it's not a requirement.
Still a nice to have, but if people can't update their software, they should 'suffer the consequences'.
"Can't update" ??? Why would that be ?
* Corporate policy - Fred Flintstone Enterprises? Still running IE 4 !
* Underpowered computer - buy a new one!
* Don't know how - pay someone to do it for you!
Google Chrome runs on Windows, Mac & Linux and it auto-updates. What's there not to like?
* Corporate policy - Fred Flintstone Enterprises? Still running IE 4 !
* Underpowered computer - buy a new one!
* Don't know how - pay someone to do it for you!
Google Chrome runs on Windows, Mac & Linux and it auto-updates. What's there not to like?
Unobtrusive use of Javascript is a very neat one in my opinion. You seperate the content and structure from the presentation layer.
In practice though, many sites main functions depend on JS. I can imagine that for large projects the costs of optimizing the view of your site without JS can become too large.
In practice though, many sites main functions depend on JS. I can imagine that for large projects the costs of optimizing the view of your site without JS can become too large.
For work, no. We're heavily based around mapping tools which don't degrade well (if at all) so optimizing for the non JavaScript users makes little sense for us.
Most of my personal projects also require JavaScript because they're things that I build to play around with new technology.
Most of my personal projects also require JavaScript because they're things that I build to play around with new technology.
Nope. If you head to my site, and try to use it without Javascript it'll work for simple browsing but not for content creation.
It's a decision I made early on not to support a vanishing minority of users who have javascript off by choice or by force.
It's a decision I made early on not to support a vanishing minority of users who have javascript off by choice or by force.
For my big business app at work: No. Javascript is a hard requirement. The UI flows it enables are just too valuable.
For my personal stuff: Yes... i have a pretty weak browser on my personal phone, sticking to simple HTML is in my own best interests.
For my personal stuff: Yes... i have a pretty weak browser on my personal phone, sticking to simple HTML is in my own best interests.
there is a difference between a web site and a web app. a web site can and likely should work with js off. Once you dive into the realm of building web apps, then you basically give up on that idea. As you said, it is a small demographic anyway.
Is this the "right" way to be doing this? Should I just be using javascript based UI elements and ajax from the start? Is there a standard practice with regards to this issue?