4 ms·

...because if it's say 98%, you have just thrown away 2% revenue.

gnaritas 13y ago
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.
- dreamfactory 13y ago
  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.
  - gnaritas 13y ago
    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.
    - dreamfactory 13y ago
      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.
      - gnaritas 13y ago
        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.
    - asdasf 13y ago
      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.
      - gnaritas 13y ago
        > It is doing the baseline correct 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.
        asdasf 13y ago
        >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.
        gnaritas 13y ago
        > 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.
        13y ago
- dllthomas 13y ago
  "Hardly, you have to consider the additional cost of attempting to support that additional 2%" That's certainly not how I calculate revenue...
  - gnaritas 13y ago
    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.
    - dllthomas 13y ago
      Obviously. This would have been a solid response to dreamfactory's comment.

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.

dreamfactory 13y ago
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.
- gnaritas 13y ago
  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.
  - dreamfactory 13y ago
    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.
    - gnaritas 13y ago
      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.
  - asdasf 13y ago
    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.
    - gnaritas 13y ago
      > It is doing the baseline correct 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.
      - asdasf 13y ago
        >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.
        gnaritas 13y ago
        > 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.
        13y ago
dllthomas 13y ago
"Hardly, you have to consider the additional cost of attempting to support that additional 2%" That's certainly not how I calculate revenue...
- gnaritas 13y ago
  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.
  - dllthomas 13y ago
    Obviously. This would have been a solid response to dreamfactory's comment.