11 ms·

Companies have far too much internal plumbing to permit browsers to auto-update themselves. Being feature-compatible with the latest SV-poster-child website is

Companies have far too much internal plumbing to permit browsers to auto-update themselves. Being feature-compatible with the latest SV-poster-child website is insignificant compared to maintaining stability for the tax-management team's internal web app. I was once involved in an IE6 -> IE8 upgrade for a Fortune 100 corporation. It took nine months to analyze all the possible impacts and implement mitigations before the first internal production release. And that was fast on account of teams being forced to particpate by C-officer mandate. By the time the deployment was finished, which required several more months, IE10 was mainstream in the Real World.

bernardlunn 10y ago
Holy moly, that is so toxic and innefficient! Big companies have a big problem.
- fbender 10y ago
  Yeah the problem is they hired big software companies to develop sub-par software (in terms of being future proof, platform agnostic, and standards-compliant – if there were any standards to begin with) that worked for their needs at that point in time. Now they have to deal with the legacy.
alkonaut 10y ago
It's amusing how we see web apps as the solution to deployment woes. I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks.
- Pica_soO 10y ago
  Eh, yes, and the yells of "Over budget, we can not afford new machines for the whole team, just because your app is not 386 backwards compatible." And the partial rollouts, with teams being split into and stuck- and demanding you hack together tooling on the fly to allow for work to continue anyway. And the horrible cross-application databases, which would went inconsistent if you didn't include basically a reduced data version controlling in every of your applications. And those proto-typed tools, made by some intern in obscure languages, that would in secrecy fester into the "Main-Tool" of a department. And all hell would break loose, if some virtual environment update would break those env-dependcies. You know what- it was bad back then. Real bad. And today is better. And even nostalgia cant save it.
  - alkonaut 10y ago
    You wouldn't have to use antiquated tools and practices just to use desktop apps. I'm not arguing to use the old apps, I'm arguing that a lot of new development should be desktop when it's often made as web apps without thought. We threw all the good stuff with desktop out at the same time as we moved to intranets. You can still have centralized deployment, thin clients etc, but have the niceties of proper native apps (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc). Even on mobile where native has fewer benefits than on desktop we can't make web based apps that are better than native ones. A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse.
    - donatj 10y ago
      > A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse. This. Click, wait, click, wait, click, wait is in no way better than how quickly you can fly with a well memorized set of keyboard shortcuts in a native app.
      - nine_k 10y ago
        I use keyboard shortcuts extensively in gmail, jira, stash, and a bunch of other apps. There's no problem implementing it. The designer should just think about it.
      - untog 10y ago
        This is not a web vs. native problem. You can implement keyboard shortcuts in a webapp. You can neglect to implement keyboard shortcuts in a native app. This is all about attention to detail, which internal corporate apps almost always lack.
        10y ago
- FLUX-YOU 10y ago
  >I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks. You mean where everything runs on the UI thread? Gotta pass on that. :)
  - donatj 10y ago
    In my experiences being forced to use various SPAs from various venders, more often than not async just means I need to behave single threaded rather than the app lest I wish to trigger race conditions that desync the local model and I end up having to hard refresh.
  - wcummings 10y ago
    But (most) browser apps are single threaded and you can block the UI if you do anything intensive on the client-side.
    - fbender 10y ago
      There quite a few ways around that with async APIs and WebWorkers, even ServiceWorkers now. A lot of devs just don't use them properly. Edit: Did you mean the browser itself could freeze? That's a thing of the past with Firefox being the last browser to separate the content and chrome process. So the web page may freeze, the browser window itself shouldn't.
      - wcummings 10y ago
        Those are relatively new features, and aren't used a whole lot.
        fbender 10y ago
        WebWorkers are not a new "feature". The last browser to support it was (on desktop) IE in v10 (4 years ago) and on mobile Android 4.4 (3 years ago). Though that doesn't really matter since you can polyfill it, which obviously does not give you multithreading in those older browsers but it still forces you to think async. Regarding other APIs, a great number has been available since many years, and any newly introduced API since at least 5 years is either non-blocking or async.
- hiram112 10y ago
  I think it became harder to write true desktop apps once VB6 was killed off in favor of .Net with its higher learning curve. As bad as a real language VB6 and it's GUI builder were, it did allow even amateurs to write a decent working crud app in minimal time.
  - matwood 10y ago
    I still think VB6 was the pinnacle for writing line of business CRUD apps. I've been told there are still some VB6 apps I wrote ~15 years ago running at a big enterprise I once worked for.
    - ComodoHacker 10y ago
      Delphi was the pinnacle. But VB had definitely set the trend.
    - alkonaut 10y ago
      I find C# and WinForms at least as simple as vb6. They did make Lightswitch to really dumb down the one-off crud app development, but I'm not sure if that still lives.
donatj 10y ago
At my previous company we used IE8 for the internal crap, and up to date Chrome for everything else. Basically all the issues the internal junk had stemmed from JavaScript; they were JUST forms! No legitimate need for JS. If you just need a form, just build a simple POSTing <form> without any JS. It will stand the test of time. A simple form from 1996 will still work today. A livescript enabled form from 1996 however almost certainly will not.
tomelders 10y ago
I think this is a weak argument. The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. That has never been true. The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. If you roll your own software, you either commit to constantly updating it, or you commit to throwing a ton of money down the drain when its rots away to the point where it is no longer fit for your workflow or for the world it operates in. Software is never finished, only abandoned.
- DougN7 10y ago
  I question if you've worked with large enterprises. They freeze everything for a decade or more. Think about a bank with 500 offices, a dozen tellers at each office. Having their internal web app that everyone uses go down because of an auto upgrade could cost them hundreds of millions. They have a very different risk appetite.
  - tomelders 10y ago
    Ive actually been working in banks mainly. But on the business side. At the upper echelons there is a real appetite for change. Banks realise that they have become software companies, but that their businesses are groaning under the weight of antiquated systems and processes and it is holding them back. But even the board can only affect so much. The only reason an auto update would take down an app is if all development has stopped. As part of the process you should be testing against upcoming releases of chrome so you spot these problems well in advance. But if dev has stopped, then yes, you will have a problem.
    - riprowan 10y ago
      Dev stops. That's reality. If you hand-wave it away, your tellers go down, and you, the CIO, lose your job. Not all software is under your direct control. Once business processes achieve a stable working state, it is imperative that they maintain uptime, sometimes in excess of six-sigma uptime. Imagine your business is NASA. Are you going to let mission systems auto-update 18 secs before launch?
radicalbyte 10y ago
The problem is that Chrome remove features without providing any viable replacement. For example Flash: currently the Chrome audio APIs do not cover all of the functionality provided by Flash. You cannot, for example, pause the recording of audio. If you have a product which requires that functionality then you're stuck. You can't upgrade. In the recent past I was in just that position: we had no choice but to block Chrome upgrades, at least until such a time as we could implement the functionality ourselves. It would be much better if Chrome would just leave the functionality in there; or maybe provide a special "Enterprise" build which includes all of the features behind feature flags. All they need to do is make that configurable by Group Policies and you've made Enterprises happy (and we can keep upgrading the core browser).
- nothrabannosir 10y ago
  > You cannot, for example, pause the recording of audio. You can use the Web Audio API (getusermedia) and set an audio pipeline filter that stops sending data while a boolean flag is set. I don't know if you mean a different API entirely, and I don't mean to disagree---just FYI :)
  - radicalbyte 10y ago
    Thanks, that is indeed so. I must say that the Chrome team have been really fantastic about it (they reached out to me after asking on twitter). It's just the age old resources problem: not only do you have to change the frontend, you also need to make changes on the server. That more than doubles the work (quadruples in our case because the server requires far more QA effort). That comes at the cost of other features, features which are more valuable.
- johnward 10y ago
  I've had discussions internally and the it staff basically said they will not considered actual support for Chrome. However they let us install any browser and support reps just instruct people to use certain browsers for antiquated software.
- coredog64 10y ago
Jean-Philipe 10y ago
> Companies have far too much internal plumbing to permit browsers to auto-update themselves. What plumbing might prevent a browser update? I can't think of a good use case.
- simonw 10y ago
  Poorly written intranet web apps that break between browser versions. Especially likely if those apps were only tested in one specific browser -especially if it was an older version of MSIE.
  - sangnoir 10y ago
    Even the most perfect web apps won't save you from breakage when there is a botched browser release- such as the recent Chrome update that blocked all sites using certs from a specific CA.
nommm-nommm 10y ago
IE6 was an exception though... It it's day websites were specifically made to run on IE6, which was highly non-standard, and nothing else. Nothing is made to run on only Chrome 38 now. We aren't in the world of <blink> and <marquee> anymore. Most companies I know of (customers) let browsers auto upgrade now or they vet upgrades and they get pushed to client machines in a few days.
EvanAnderson 10y ago
It's not just "internal" plumbing. We've had to stop Chrome updates in our Customer sites, from time to time, because "cloud hosted" applications were rendered unusable by updated Chrome versions. Eventually the third-parties got their acts together, but we would have had user-facing outages if we hadn't been cautious with allowing Chrome updates to deploy. I'm glad that the ability to "freeze" the Chrome version exists.
kurthr 10y ago
I hope Google are going to do continuing security updates for every enterprise release of Chrome for the next 10 years, LOL! At least limit the company browser to only internal apps (still not safe!). Perhaps they could de-feature the enterprise browser for better support&security? You would hope that using standards compliant web apps would make upgrading/testing less of an issue for corps. Using ancient versions of IE to get work done was awful and in the current security environment, I don't think it's safe for a browser that's not in its own VM. Heck, you could use Chrome Remote Desktop!
dispose13432 10y ago
>Companies have far too much internal plumbing to permit browsers to auto-update themselves. Being feature-compatible with the latest SV-poster-child website is insignificant compared to maintaining stability for the tax-management team's internal web app. So why don't they have two browsers - one for internal use only (IE6), which is firewalled to only internal network shares and another browser (Chrome, whatever) which can only go to the real internet? At least that way you'll be browsing the wild internet safely.
- beefield 10y ago
  > So why don't they have two browsers I definitely do not claim they were right, but one of my previous employer's (not a software company) IT department insisted that additional applications in employee's computers were an extra workload for them to maintain. (Occasionally also security was used as an excuse). So the text editor that was allowed was notepad and the browser was IE.
eikenberry 10y ago
IE6 upgrades were much different than other browser updates because it was the last IE to support ActiveX applications. There were many internal enterprise apps written in it that kept IE6 alive for years until they could be rewritten. There is no equivalent in modern browsers.
gtjrossi 10y ago
As an engineer that worked on IE, I can totally sympathize. Your story is one repeated throughout almost every enterprise of sufficient size. That said, there's a middle-ground we should strike here. At some point, being out of date (sometimes as much as half a decade or more!) on your browser trumps the cost of keeping internal software up to date. This is not to mention the network costs of third-parties attempting to support your users browsing the public web and on browser vendors that take investment away from their latest versions to continue to support legacy software.Allowing indefinite suspension of upgrades by IT is definitively a mistake. It adds insult to injury that Google is repeating a mistake which we all learned so much about via IE and older versions of Firefox. We will all collectively pay for this if they don't course correct. The middle ground here is providing extended support channels like what's being done for Firefox and Edge. Chrome already has Canary, Dev/Beta, and Stable channels. A slower moving, more stable channel for businesses would be a natural solution here. This gives businesses time to test and adapt, limits the total number of versions in the wild that must be supported by browser vendors and web developers, and provides just enough paternalistic motivation to keep your internal software in a good state (upgrading to support latest browsers is a forcing function for testing, performance tuning, security tightening, etc.).

bernardlunn 10y ago

Holy moly, that is so toxic and innefficient! Big companies have a big problem.

fbender 10y ago
Yeah the problem is they hired big software companies to develop sub-par software (in terms of being future proof, platform agnostic, and standards-compliant – if there were any standards to begin with) that worked for their needs at that point in time. Now they have to deal with the legacy.

alkonaut 10y ago

It's amusing how we see web apps as the solution to deployment woes. I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks.

Pica_soO 10y ago
Eh, yes, and the yells of "Over budget, we can not afford new machines for the whole team, just because your app is not 386 backwards compatible." And the partial rollouts, with teams being split into and stuck- and demanding you hack together tooling on the fly to allow for work to continue anyway. And the horrible cross-application databases, which would went inconsistent if you didn't include basically a reduced data version controlling in every of your applications. And those proto-typed tools, made by some intern in obscure languages, that would in secrecy fester into the "Main-Tool" of a department. And all hell would break loose, if some virtual environment update would break those env-dependcies. You know what- it was bad back then. Real bad. And today is better. And even nostalgia cant save it.
- alkonaut 10y ago
  You wouldn't have to use antiquated tools and practices just to use desktop apps. I'm not arguing to use the old apps, I'm arguing that a lot of new development should be desktop when it's often made as web apps without thought. We threw all the good stuff with desktop out at the same time as we moved to intranets. You can still have centralized deployment, thin clients etc, but have the niceties of proper native apps (good multi screen/multi window support, better, good support for complex interactions like shortcuts, ctrl-clicks etc). Even on mobile where native has fewer benefits than on desktop we can't make web based apps that are better than native ones. A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse.
  - donatj 10y ago
    > A clean understandable web UI is good for a seldom used app, but a lot of the intranet apps are "constant use" and were faster to use in their legacy dos implementation than the newer web version. Browser hell just makes the problem worse. This. Click, wait, click, wait, click, wait is in no way better than how quickly you can fly with a well memorized set of keyboard shortcuts in a native app.
    - nine_k 10y ago
      I use keyboard shortcuts extensively in gmail, jira, stash, and a bunch of other apps. There's no problem implementing it. The designer should just think about it.
    - untog 10y ago
      This is not a web vs. native problem. You can implement keyboard shortcuts in a webapp. You can neglect to implement keyboard shortcuts in a native app. This is all about attention to detail, which internal corporate apps almost always lack.
      - 10y ago
FLUX-YOU 10y ago
>I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks. You mean where everything runs on the UI thread? Gotta pass on that. :)
- donatj 10y ago
  In my experiences being forced to use various SPAs from various venders, more often than not async just means I need to behave single threaded rather than the app lest I wish to trigger race conditions that desync the local model and I end up having to hard refresh.
- wcummings 10y ago
  But (most) browser apps are single threaded and you can block the UI if you do anything intensive on the client-side.
  - fbender 10y ago
    There quite a few ways around that with async APIs and WebWorkers, even ServiceWorkers now. A lot of devs just don't use them properly. Edit: Did you mean the browser itself could freeze? That's a thing of the past with Firefox being the last browser to separate the content and chrome process. So the web page may freeze, the browser window itself shouldn't.
    - wcummings 10y ago
      Those are relatively new features, and aren't used a whole lot.
      - fbender 10y ago
        WebWorkers are not a new "feature". The last browser to support it was (on desktop) IE in v10 (4 years ago) and on mobile Android 4.4 (3 years ago). Though that doesn't really matter since you can polyfill it, which obviously does not give you multithreading in those older browsers but it still forces you to think async. Regarding other APIs, a great number has been available since many years, and any newly introduced API since at least 5 years is either non-blocking or async.
hiram112 10y ago
I think it became harder to write true desktop apps once VB6 was killed off in favor of .Net with its higher learning curve. As bad as a real language VB6 and it's GUI builder were, it did allow even amateurs to write a decent working crud app in minimal time.
- matwood 10y ago
  I still think VB6 was the pinnacle for writing line of business CRUD apps. I've been told there are still some VB6 apps I wrote ~15 years ago running at a big enterprise I once worked for.
  - ComodoHacker 10y ago
    Delphi was the pinnacle. But VB had definitely set the trend.
  - alkonaut 10y ago
    I find C# and WinForms at least as simple as vb6. They did make Lightswitch to really dumb down the one-off crud app development, but I'm not sure if that still lives.

donatj 10y ago

At my previous company we used IE8 for the internal crap, and up to date Chrome for everything else. Basically all the issues the internal junk had stemmed from JavaScript; they were JUST forms! No legitimate need for JS. If you just need a form, just build a simple POSTing <form> without any JS. It will stand the test of time. A simple form from 1996 will still work today. A livescript enabled form from 1996 however almost certainly will not.

tomelders 10y ago

I think this is a weak argument. The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. That has never been true. The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. If you roll your own software, you either commit to constantly updating it, or you commit to throwing a ton of money down the drain when its rots away to the point where it is no longer fit for your workflow or for the world it operates in. Software is never finished, only abandoned.

DougN7 10y ago
I question if you've worked with large enterprises. They freeze everything for a decade or more. Think about a bank with 500 offices, a dozen tellers at each office. Having their internal web app that everyone uses go down because of an auto upgrade could cost them hundreds of millions. They have a very different risk appetite.
- tomelders 10y ago
  Ive actually been working in banks mainly. But on the business side. At the upper echelons there is a real appetite for change. Banks realise that they have become software companies, but that their businesses are groaning under the weight of antiquated systems and processes and it is holding them back. But even the board can only affect so much. The only reason an auto update would take down an app is if all development has stopped. As part of the process you should be testing against upcoming releases of chrome so you spot these problems well in advance. But if dev has stopped, then yes, you will have a problem.
  - riprowan 10y ago
    Dev stops. That's reality. If you hand-wave it away, your tellers go down, and you, the CIO, lose your job. Not all software is under your direct control. Once business processes achieve a stable working state, it is imperative that they maintain uptime, sometimes in excess of six-sigma uptime. Imagine your business is NASA. Are you going to let mission systems auto-update 18 secs before launch?

radicalbyte 10y ago

The problem is that Chrome remove features without providing any viable replacement. For example Flash: currently the Chrome audio APIs do not cover all of the functionality provided by Flash. You cannot, for example, pause the recording of audio. If you have a product which requires that functionality then you're stuck. You can't upgrade. In the recent past I was in just that position: we had no choice but to block Chrome upgrades, at least until such a time as we could implement the functionality ourselves. It would be much better if Chrome would just leave the functionality in there; or maybe provide a special "Enterprise" build which includes all of the features behind feature flags. All they need to do is make that configurable by Group Policies and you've made Enterprises happy (and we can keep upgrading the core browser).

nothrabannosir 10y ago
> You cannot, for example, pause the recording of audio. You can use the Web Audio API (getusermedia) and set an audio pipeline filter that stops sending data while a boolean flag is set. I don't know if you mean a different API entirely, and I don't mean to disagree---just FYI :)
- radicalbyte 10y ago
  Thanks, that is indeed so. I must say that the Chrome team have been really fantastic about it (they reached out to me after asking on twitter). It's just the age old resources problem: not only do you have to change the frontend, you also need to make changes on the server. That more than doubles the work (quadruples in our case because the server requires far more QA effort). That comes at the cost of other features, features which are more valuable.
johnward 10y ago
I've had discussions internally and the it staff basically said they will not considered actual support for Chrome. However they let us install any browser and support reps just instruct people to use certain browsers for antiquated software.
coredog64 10y ago

Jean-Philipe 10y ago

> Companies have far too much internal plumbing to permit browsers to auto-update themselves. What plumbing might prevent a browser update? I can't think of a good use case.

simonw 10y ago
Poorly written intranet web apps that break between browser versions. Especially likely if those apps were only tested in one specific browser -especially if it was an older version of MSIE.
- sangnoir 10y ago
  Even the most perfect web apps won't save you from breakage when there is a botched browser release- such as the recent Chrome update that blocked all sites using certs from a specific CA.

nommm-nommm 10y ago

IE6 was an exception though... It it's day websites were specifically made to run on IE6, which was highly non-standard, and nothing else. Nothing is made to run on only Chrome 38 now. We aren't in the world of <blink> and <marquee> anymore. Most companies I know of (customers) let browsers auto upgrade now or they vet upgrades and they get pushed to client machines in a few days.

EvanAnderson 10y ago

It's not just "internal" plumbing. We've had to stop Chrome updates in our Customer sites, from time to time, because "cloud hosted" applications were rendered unusable by updated Chrome versions. Eventually the third-parties got their acts together, but we would have had user-facing outages if we hadn't been cautious with allowing Chrome updates to deploy. I'm glad that the ability to "freeze" the Chrome version exists.

kurthr 10y ago

I hope Google are going to do continuing security updates for every enterprise release of Chrome for the next 10 years, LOL! At least limit the company browser to only internal apps (still not safe!). Perhaps they could de-feature the enterprise browser for better support&security? You would hope that using standards compliant web apps would make upgrading/testing less of an issue for corps. Using ancient versions of IE to get work done was awful and in the current security environment, I don't think it's safe for a browser that's not in its own VM. Heck, you could use Chrome Remote Desktop!

dispose13432 10y ago

>Companies have far too much internal plumbing to permit browsers to auto-update themselves. Being feature-compatible with the latest SV-poster-child website is insignificant compared to maintaining stability for the tax-management team's internal web app. So why don't they have two browsers - one for internal use only (IE6), which is firewalled to only internal network shares and another browser (Chrome, whatever) which can only go to the real internet? At least that way you'll be browsing the wild internet safely.

beefield 10y ago
> So why don't they have two browsers I definitely do not claim they were right, but one of my previous employer's (not a software company) IT department insisted that additional applications in employee's computers were an extra workload for them to maintain. (Occasionally also security was used as an excuse). So the text editor that was allowed was notepad and the browser was IE.

eikenberry 10y ago

IE6 upgrades were much different than other browser updates because it was the last IE to support ActiveX applications. There were many internal enterprise apps written in it that kept IE6 alive for years until they could be rewritten. There is no equivalent in modern browsers.

gtjrossi 10y ago

As an engineer that worked on IE, I can totally sympathize. Your story is one repeated throughout almost every enterprise of sufficient size. That said, there's a middle-ground we should strike here. At some point, being out of date (sometimes as much as half a decade or more!) on your browser trumps the cost of keeping internal software up to date. This is not to mention the network costs of third-parties attempting to support your users browsing the public web and on browser vendors that take investment away from their latest versions to continue to support legacy software.Allowing indefinite suspension of upgrades by IT is definitively a mistake. It adds insult to injury that Google is repeating a mistake which we all learned so much about via IE and older versions of Firefox. We will all collectively pay for this if they don't course correct. The middle ground here is providing extended support channels like what's being done for Firefox and Edge. Chrome already has Canary, Dev/Beta, and Stable channels. A slower moving, more stable channel for businesses would be a natural solution here. This gives businesses time to test and adapt, limits the total number of versions in the wild that must be supported by browser vendors and web developers, and provides just enough paternalistic motivation to keep your internal software in a good state (upgrading to support latest browsers is a forcing function for testing, performance tuning, security tightening, etc.).