

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

I've spent a lot of time adding UI features to my new (mostly CRUD) webapp that I know I'm going to either tweak or totally override via javascript/ajax.  I feel an obligation to get the app working with no javascript/jquery, even though I know that the group of people using the site with javascript turned off are going to very small.<p>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?
======
Lazare
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.

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

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

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

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

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

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

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

------
CyberFonic
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?

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

~~~
CyberFonic
"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?

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

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

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

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

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

