4 ms·

The major problem is testing. Many corporations have in-house Web applications—both custom and third-party—that they access through their Web browsers, and befo

by natesm 15y ago

The major problem is testing. Many corporations have in-house Web applications—both custom and third-party—that they access through their Web browsers, and before any new browser upgrade can be deployed to users, it must be tested to verify that it works correctly and doesn't cause any trouble with business-critical applications. Is this really necessary with Firefox or any WebKit browser? If your app is running in Firefox, presumably it's actually written properly to standards (as opposed to being written against whatever Microsoft shipped 10 years ago). Firefox 5 doesn't change that much, just like Chrome releases. (err, what version am I on? Who cares?)

kijinbear 15y ago
Exactly. This "new browser version will break everything" argument applies very much to Internet Explorer, but IMO not so much to better browsers like Firefox and Chrome. There might be minor quirks here and there, but those are never going to be serious enough to require more than a couple of days of testing if the app is standards-compliant to begin with.
- deleted 15y ago
  [deleted]
- zeddez 15y ago
  I am not sure that is true any more. As an example. Run something like Test 262(http://test262.ecmascript.org/ http://test262.ecmascript.org/) which is the official test suite for JavaScript 5 and you'll see how many compatibilitiy issues there are just for this single spec in Firefox. It's in the hundreds. Anyone of these could potentially break an app. And that is just for one of the many specs in Firefox.
  - kijinbear 15y ago
    Theoretically, you're right. But how many "enterprise" intranet apps actually make use of cutting-edge HTML5 and JS5 features?
    - zeddez 15y ago
      It's not about cutting edge or not cutting edge. The same inconsistencies are present in implementations for all the major specifications. It's worse in most cases as there aren't fully built out tests, so it's even more difficult to converge implementations to the specifications.
  - inimino 15y ago
    JavaScript version numbers and ECMAScript edition numbers are completely separate -- it's ECMAScript 5, not JavaScript 5.
  - bzbarsky 15y ago
    And how many of those are things where ES5 changed behavior from ES3 and Firefox still implements the ES3 behavior? Your problem there is really with the standard... But more importantly, intranet apps are not coded to standards to start with, so the whole discussion is moot.
    - zeddez 15y ago
      On the Mozilla technology page http://www.mozilla.com/en-US/firefox/technology/ http://www.mozilla.com/en-US/firefox/technology/ it specifically calls out ES5 support. There is no qualifier, so I am assuming that they believe they are fully supporting it. Your argument about Intranet apps not coded to standards seems circular. If browsers (like Firefox) don't implement the standards properly, then how can Intranet apps code to standards? It has to start with browsers.
      - bzbarsky 15y ago
        > it specifically calls out ES5 support. Yep. Support for all the new ES5 features... Doesn't guarantee that it's all bug-free, sadly. That said, you may be interested in the graph shown in http://blogs.msdn.com/b/ie/archive/2011/06/30/test262-industry-javascript-standards-test-available.aspx http://blogs.msdn.com/b/ie/archive/2011/06/30/test262-indust... (ignoring for the moment the "start at 50%" inanity). You may also be interested to note that changes continue to be made to the ES5 specification; the most recent ones happened just a few months ago. The whole moving target thing makes it hard to comply with all the edge cases at all times, obviously. I would not be surprised if there are now test262 tests that are testing the old language, and will need to be fixed just like browsers will need to be fixed. > Your argument about Intranet apps not coded to standards > seems circular. I wasn't making an argument; just stating a fact. But note that the non-standard assumptions that intranet apps make are not even in the sort of things that 262test shows as broken in browsers: the latter tend to be somewhat esoteric due to the obvious fact that browsers sort of agree on the JS used on the web. But intranet apps tend to be coded to particular DOM quirks (in areas where the standard often doesn't define behavior to start with), particular HTML parsing quirks (until recently there was no standard for parsing HTML), and so forth. Or put another way, intranet apps have a tendency to find situations where there is no behavior defined by a standard and depend on behavior in those situations, when the smart thing to do would be to avoid those situations entirely.
spanktheuser 15y ago
If your app is running in Firefox, presumably it's actually written properly to standards Unfortunately, as I learned in 10 years of corporate consulting work, that presumption isn't entirely true. The typical corporate webapp I've encountered was written to the corporate browser standard du jour, with very little attention paid to standards. It likely has poor unit test coverage and absolutely no automated testing of client-side markup or code. High profile apps are likely to be an exception - I recently worked on software that delivers market data to the people making billion-dollar trades. It's top notch and awe-inspiring in every respect. But for every one of these, there are 100 apps that let you change your insurance plan, submit new automated deposit instructions, request vacation time, check inventory levels, etc. All done on the absolute cheap by developers whose true skill set is usually integration with legacy ERP software. The devops folks are right to be wary of a new browser deploys in such an environment.

by natesm 15y ago

kijinbear 15y ago

Exactly. This "new browser version will break everything" argument applies very much to Internet Explorer, but IMO not so much to better browsers like Firefox and Chrome. There might be minor quirks here and there, but those are never going to be serious enough to require more than a couple of days of testing if the app is standards-compliant to begin with.

deleted 15y ago
[deleted]
zeddez 15y ago
I am not sure that is true any more. As an example. Run something like Test 262(http://test262.ecmascript.org/ http://test262.ecmascript.org/) which is the official test suite for JavaScript 5 and you'll see how many compatibilitiy issues there are just for this single spec in Firefox. It's in the hundreds. Anyone of these could potentially break an app. And that is just for one of the many specs in Firefox.
- kijinbear 15y ago
  Theoretically, you're right. But how many "enterprise" intranet apps actually make use of cutting-edge HTML5 and JS5 features?
  - zeddez 15y ago
    It's not about cutting edge or not cutting edge. The same inconsistencies are present in implementations for all the major specifications. It's worse in most cases as there aren't fully built out tests, so it's even more difficult to converge implementations to the specifications.
- inimino 15y ago
  JavaScript version numbers and ECMAScript edition numbers are completely separate -- it's ECMAScript 5, not JavaScript 5.
- bzbarsky 15y ago
  And how many of those are things where ES5 changed behavior from ES3 and Firefox still implements the ES3 behavior? Your problem there is really with the standard... But more importantly, intranet apps are not coded to standards to start with, so the whole discussion is moot.
  - zeddez 15y ago
    On the Mozilla technology page http://www.mozilla.com/en-US/firefox/technology/ http://www.mozilla.com/en-US/firefox/technology/ it specifically calls out ES5 support. There is no qualifier, so I am assuming that they believe they are fully supporting it. Your argument about Intranet apps not coded to standards seems circular. If browsers (like Firefox) don't implement the standards properly, then how can Intranet apps code to standards? It has to start with browsers.
    - bzbarsky 15y ago
      > it specifically calls out ES5 support. Yep. Support for all the new ES5 features... Doesn't guarantee that it's all bug-free, sadly. That said, you may be interested in the graph shown in http://blogs.msdn.com/b/ie/archive/2011/06/30/test262-industry-javascript-standards-test-available.aspx http://blogs.msdn.com/b/ie/archive/2011/06/30/test262-indust... (ignoring for the moment the "start at 50%" inanity). You may also be interested to note that changes continue to be made to the ES5 specification; the most recent ones happened just a few months ago. The whole moving target thing makes it hard to comply with all the edge cases at all times, obviously. I would not be surprised if there are now test262 tests that are testing the old language, and will need to be fixed just like browsers will need to be fixed. > Your argument about Intranet apps not coded to standards > seems circular. I wasn't making an argument; just stating a fact. But note that the non-standard assumptions that intranet apps make are not even in the sort of things that 262test shows as broken in browsers: the latter tend to be somewhat esoteric due to the obvious fact that browsers sort of agree on the JS used on the web. But intranet apps tend to be coded to particular DOM quirks (in areas where the standard often doesn't define behavior to start with), particular HTML parsing quirks (until recently there was no standard for parsing HTML), and so forth. Or put another way, intranet apps have a tendency to find situations where there is no behavior defined by a standard and depend on behavior in those situations, when the smart thing to do would be to avoid those situations entirely.

spanktheuser 15y ago

If your app is running in Firefox, presumably it's actually written properly to standards Unfortunately, as I learned in 10 years of corporate consulting work, that presumption isn't entirely true. The typical corporate webapp I've encountered was written to the corporate browser standard du jour, with very little attention paid to standards. It likely has poor unit test coverage and absolutely no automated testing of client-side markup or code. High profile apps are likely to be an exception - I recently worked on software that delivers market data to the people making billion-dollar trades. It's top notch and awe-inspiring in every respect. But for every one of these, there are 100 apps that let you change your insurance plan, submit new automated deposit instructions, request vacation time, check inventory levels, etc. All done on the absolute cheap by developers whose true skill set is usually integration with legacy ERP software. The devops folks are right to be wary of a new browser deploys in such an environment.