Yup, that's always in the back of my mind when people talk about javascript-enabled user stats. Of course, it's perfectly possible that the OP IS recording accurate(-ish) JS usage stats, it's just more involved than other client stats that are readily provided to the server, so less likely. If 99.99% wasn't just a figure plucked out of the air, it sounds believable that it's being obtained 'correctly', since it's not 100% :)
Hardly, you have to consider the additional cost of attempting to support that additional 2%; it could very well cost more than it's worth in development time and long term complexity. Of course that's an app specific decision. Every market you specialize for has a cost, short term and long term, so it has to be worth it financially; businesses aren't in the habit of just being nice for no reason.
Revenue isn't the right metric; profit is. My point is that chasing revenue isn't what good businesses do, they chase profit. I don't care about 2% additional revenue if doing so reduces profit due to the extra development and maintenance overhead and neither should any sane business person.
Another way to put it is that vanilla HTML will support the full market so you have to be confident that moving away from it will cover that margin in revenue or savings just to break even. On a large commerce site for example, even a small percentage of revenue could be a staggering amount.
That's the opposite way of putting it. The way of extra work to support edge case users that often aren't worth the effort. Now maybe it's worth it for a big enough site, but for the average site I doubt it ever is. I think it perfectly reasonable to ignore users who disable JavaScript for most websites.
So do I tbh but nobody ever makes a proper business case in practise. If you are going to say that HTML is no longer the default protocol for serving content to browsers (and that it is therefore extra work to support rather than the other way round), it seems like quite a big step. I guess we can rationalise the tattered corpses of Java widgets, Flash, ActiveX, Silverlight by saying they had proprietary roots and no universal support but feels like there's a lot of handwavey stuff around client support, RESTfulness, SEO.
Of course HTML is the default protocol, but not vanilla HTML; many sites require JavaScript as well; the default is HTML + JavaScript not just HTML. Supporting non js enhanced HTML is extra work.
It isn't extra work or an edge case. It is doing the baseline correct thing. I can't count the number of fad obsessed "web developers" who ask us why we serve html instead of javascript crap, while they take 3 times as long to produce a broken version of the same thing.
You don't get to define what the baseline correct thing is for a business, profit does that. Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.
>You don't get to define what the baseline correct thing is for a business, profit does that
That's what I am using.
>Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.
I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.
> I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.
I simply don't believe you. It's a fact that it's more work to support both AJAX interactions and work with js disabled than it is to support just AJAX alone. There is no arguing this, it's more work to support 2 modes of interaction than it is to support only 1. You may find it a comfortable workflow for you, to start with vanilla HTML and then progressively enhance it, but regardless of how much you like the style, it is more effort and does have more long term maintenance costs to forever support 2 modes of interaction. No one who isn't completely full of shit would argue that progressive enhancement is less work.
I require no lecture about HN from you, I've been here since the beginning. I listed facts not personal experiences and I'm sorry you can't handle that and resort to lying.
> It's a fact that it's more work to support both AJAX interactions and work with js disabled than it is to support just AJAX alone
That is not a fact. It may well be your experience from the way your applications were written, but it is not a fact. You clearly do need a lecture, or you wouldn't be posting garbage.
Do you know that for a FACT, or are you just guessing?