What if a bug in Chrome (layout rendering, dom, ..) breaks your application? It's a corner case, possibly it will never happen. But this solution makes impossible for you to roll out a patch by just changing Chrome version bundled.
User will notice a bug in your application and maybe none of his frequently visited web-apps/web-sites exhibits the same bug, so you won't have the user engaged to update (or downgrade!) his Chrome version.
All in all you're breaking one thumb rule which is to use fixed versions of dependencies for your products, so to be sure they always work as intended. As a side note, how is one going to test a GUI build this way? Should it be tested against all Chrome versions that may be possibly installed at least at one customers premises?
This isn't even as bad as the situation is and has been for web developers for the last 30 years. I can't even think of something that has ever had support dropped in chrome, and if that happened it would be with years and years of advance notice. Why the FUD?
Yep, this happens fairly often - We run on chrome directly so can't control updates, and a recent update made our dialogs invisible (funnily enough, if you clicked in the right spots you could still interact with it and open dropdowns etc). They'd show when you resized the browser window or otherwise forced chrome to re-render it (disabling the animation worked around this).
We also had a case not long ago where a chrome update introduced a bunch of bugs with stylus input on Chromebooks (a mission critical use case for us)- there we just had to tell people to downgrade to 66 or wait for the 68 update, there was no viable workaround.
> What if a bug in Chrome (layout rendering, dom, ..) breaks your application? It's a corner case, possibly it will never happen. But this solution makes impossible for you to roll out a patch by just changing Chrome version bundled.
Did already have this 5-6 versions ago. We had been unable to fix it without changing a lot of ui. 2 Chrome releases later it was fixed again.
It's not different at all, but you might not want to add this "breaking" scenario to any component in your app, or you might accept the risk - up to you.
If you accept the risk for any component to break you'll eventually end-up spending your time fixing something other people broke, offering a poor experience to your end customer.
Mind that in corporate environments getting authorized as a software supplier to deploy an update could take weeks if not months, in the meanwhile the customer perspective is that "your product broke" (and made them lose money) - this is why I like to ship as many dependencies as possible in the final bundle.
This is my opinion, maybe biased by the market sector I'm working in. Not saying it should work the same way for everyone, just my 2c.
Carlo seems to rely heavily on Puppeteer and the DevTools protocol. The DevTools protocol has a history of major breaking changes every couple of Chrome versions, so it is very likely that the app will stop working in a couple of months if it's not kept up to date.
