Ask HN: Does your web app work with javascript off?

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.

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.

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.

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.

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.

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?

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

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.

Most of my personal projects also require JavaScript because they're things that I build to play around with new technology.

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 personal stuff: Yes... i have a pretty weak browser on my personal phone, sticking to simple HTML is in my own best interests.