3 ms·
The bigger problem was the poor experience when anything failed and your users got an inscrutable error page or, if it was a gap in functionality rather than a
by acdha 1y ago
The bigger problem was the poor experience when anything failed and your users got an inscrutable error page or, if it was a gap in functionality rather than a hard compatibility error, parts of the page didn’t work as expected and you might not even notice if depended on a browser / MS shared library version you didn’t use.
Philosophically I like the idea but that era needed a lot more attention to tool quality and interoperability. I’m not sure anything anyone on an XML-based standards committee did after the turn of the century mattered as much as it would have if the money had been spent improving tools and avoiding things like so many tools relying on libxml2 / libxslt and thus never getting support for newer versions of XPath, XSLT, etc.
- johannes1234321 1y agoNot sure the experience on failures of PHP scripts of that time was any better :)
- acdha 1y agoEvery alternative was massively better for two key reasons: the first is that it happened on the server where you knew about it and could control what happened[1], and because you only had one kind of server to monitor whereas client side errors had to be tested in a wide range of client OS and browser combinations, much larger than today where automatic updates are just taken for granted. There was a third way in which PHP was often better: continuing after errors has drawbacks from a security and correctness perspective but as a user it was often the case that you could read what you wanted on a partially functioning page. I think we’ve largely matured out of the point where that’s good, but people often did benefit at the time. 1. remember, this was before things like Sentry happened for front end error collection, and XML-related issues still can’t be handled by JavaScript even now.