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

It's a hard choice.<p>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.<p>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.<p>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. :)<p>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>Is this the "right" way to be doing this?</i><p>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?<p>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%.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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:<p>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.<p>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?<p>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.<p>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.<p>Still a nice to have, but if people can't update their software, they should 'suffer the consequences'.

Unobtrusive use of Javascript is a very neat one in my opinion. You seperate the content and structure from the presentation layer.<p>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.<p>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.<p>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.<p>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.