I really don't understand what's the big deal about making sure your site works without JS, it's just some extra work that you're going to have to do anyway later down the line (and it will be more complex then).
But if your web page is a complex application, having to support no-JS either shuts you out from from a huge set of interface tools, or forces you to maintain two interfaces in tandem. To me, 2% doesn't justify that, particularly when you can just politely inform the user that their browser has a significant feature disabled, and inform them how they can remedy the situation so that your site works.
On the whole, I agree that my blog should degrade, and data-entry type applications should work as well, but saying that everything should is completely overlooking an entire category of application for which it's perfectly acceptable, in my opinion.
By the way, not sure if you're the author of Markup.io, but it's pretty cool.
It is pretty cool though.
...which is why JS is filling that gap. :)
Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar? It takes 2-4 seconds for that to go away on my computer. If you design for progressive enhancement, you can interact immediately and when JS is ready, it simply enhances what's already there. If done right, it's all the same interface.
If you don't mind waiting, your users may not agree: Google and Amazon both have noted significant losses in revenue at page delays much shorter than 2 seconds.
Well, taking a look at "Basic HTML view"... considerably less awesome.
You should be able to show the message list right away. You can start scanning your messages immediately. You can click normal links and submit forms.
Now that's awesome.
I don't mind waiting the second or two.
I'm pretty happy browsers don't show a big "Loading..." message until everything is loaded instead of painting the page as soon as possible. Shouldn't we be avoiding that too?
The bulk of that interface can be progressively enhanced.
For example, the message list and side navigation can be normal links. When JS comes along, they get actions (show this view, show this message) that override the default actions of those links (navigate to the page /message_view?id=foo).
If you try to use them in those first few seconds, they act as normal links-- they aren't broken, they just weren't enhanced yet. You can start using the page faster.
Explain to an investor, "We don't have features X, Y, and Z, which our competitors have, because we were spending time maintaining the non-JS version for 2% of our user base.".
It's something each business probably has to measure for itself, but the people saying, "I don't see what the big deal is," just aren't looking hard enough.
The problem with bending over backwards for non-js is that you double your dev cycles (no AJAX, need regular forms for everything), lose dynamic menus (want to duplicate those?), lose a ton of instrumentation you may be doing, etc.
I think it's perfectly fine to say "non-js means you have a read-only experience". Even facebook doesn't go that far -- you can't even log in without js enabled! (And they're definitely in the camp of 2% * 500M).
What will people do who have js disabled? They'll get a tech friend to help, because that disabling was probably a misconfiguration :).
At some point you have to prioritize your time to work on the features that help 95% of your users.
I would think you are being generous. A marked advantage of JS based RIA is rapid time to market, it is a simpler development model that provides superior usability when done correctly. The old page post model is a considerably slower development model. Hence all the server side frameworks, people have been trying to crack that nut, in the page post model, since someone bolted up CGI POST to a script and spit out some dynamic HTML.
It's worth reminding ourselves that the business and technical constraints of different web applications vary widely and so strategies will also vary widely.
For example, if you are building a greenfield app and your purpose is to try to search for a product/market fit, it generally doesn't make sense to optimize for the 2% of non-js users yet. You haven't yet found a steady source of revenue meaning that (1) you probably can't afford the extra effort and (2) your app's features are likely going to change drastically.
2x more work does not justify 2%
We snubbed 2% of our potential user base and reinvested the money we saved in increasing the conversion rate of the 98%. Further we are going to use some of that money to chase additional revenue streams. If we exploit all available revenue models and hit a wall with upping the conversion rate, we will look at creating a separate none JS version of the site with reduced functionality, so that the two distinctive development models are not intertwined therefore reducing out maintenance burden.