Comment by kenjackson | Hacker News Reader

Comment by kenjackson | Hacker News Reader

Parent Full thread

It's somewhat disingenuous to generalise that to 'a browser' when most browser makers have found that release model to be inadequate and their growing market share bears them out.

My point is that it's not inherent in the notion of a browser that enterprises have to upgrade. IE is simply the existence proof.

There's a conflation here, by enterprise, between browser-as-client for in-house apps and browser-as-web-browser. If your test for degradation is that the in-house apps continue to work then sure, that's verifiable. But if you acknowledge that the same program is used for both purposes then you would find it much harder to show that no degradation of user experience and productivity have occurred.

While most in the tech industry will not agree with me on this, but the inability to browse the general web would not be that grave of a detriment on the productivity of the enterprise.

I personally think the success or failure of the rolling release model with separate streams for early adopters depends entirely on the QA standards of the vendor.

This is necessary, but not sufficient. Another big thing they need to do is to not break code, even if intentional. Probably the bigget thing they can do here is to not introduce "experimental" features, and then tweak them over time. The way a lot of devs work, whether you like it or not, is to find a feature from the web that solves their problem, put it in their code and test it on their current browser. If it works then they're happy. Three months later when that feature changes, because the feature isn't finalized anyways, you now have a bunch of apps this guy wrote that just broke.

> The way a lot of devs work, whether you like it or not, is to find a feature from the web that solves their problem, put it in their code and test it on their current browser. If it works then they're happy.

It's not a matter of whether I like it, it's a matter of whether those people remain employed. It would be ridiculous to hold off on new features until they're fully supported just because of the unprofessionalism of some enterprise web devs.

> Probably the bigget thing they can do here is to not introduce "experimental" features, and then tweak them over time.

See, what we're talking about here in practice is the web standards development process. Currently it is collaborative and driven by experimentation, dialogue and feedback from the field. It has proven to be immensely successful in assuring cross-browser compatibility. What you're suggesting instead is a traditional software development approach where any relevant standards are either already nailed down, proprietary or made irrelevant by monopoly. This may have worked for Microsoft in the past. It's not going to work now.

it's a matter of whether those people remain employed. It would be ridiculous to hold off on new features until they're fully supported just because of the unprofessionalism of some enterprise web devs.

Of course they remain employed. Why? Because these browsers simply won't be used. It'a easier to fix the problem by not changing browsers than trying to hire the all-star enterprise dev team.

What you're suggesting instead is a traditional software development approach where any relevant standards are either already nailed down, proprietary or made irrelevant by monopoly.

Indeed I am. The enterprise isn't concerned with Mozilla doing something interesting with the web. That's not their business. That's up to Mozilla to figure out how to get it done right. GE could careless about Mozilla. If Mozilla ships a browser that works best for GE then they'll use it. If not, they won't. I think the answer is for the vast majority of enterprises now and in the future, they'll simply not use FF. Mozilla appears to actually want it that way. Everyone seems to be happy.

Reply on news.ycombinator.com