We're not doing very well when it seems like most programmers seem to think of the Web as indistinguishable from other platform "targets" (in the parlance of typical dev toolchains).
A user on HN writes that they "wonder" whether something in a Show HN submission will still work on "browser from 20 years (or more) in the future".
Original comment <https://news.ycombinator.com/item?id=34084284>
@colby
the notion of web browsers still existing in the year 2043 is horrifying
@colby
strong "our payroll is cobol code running on big iron and the last guy who understood it died in 1996" vibes tbh
@wizzwizz4 the whole point of what?
@colby Of what you were saying, I thought. More broadly, the point of the web.
(I don't think anything I'm saying here is useful to say to you; you already know it.)
Many web developers think of the web as a portable application platform, on which they should build a tower of abstractions. They rely on pixel-perfect layout implementation details, and consider "works on Firefox, Chrome and Safari" to be a success condition. This is not the point.
@wizzwizz4 for the linked Show HN submission to suddenly stop working at some point is def. a failure condition of something—whether that be the development practices that created it, or (in the event that it uses only standard APIs and it ends up breaking along the way, anyway) then a failure of the browser vendors and their stewardship of the Web, no matter how tall the towers of abstraction that are involved.
@wizzwizz4 most programmers have this ephemeral mindset of, "yeah, it works now, but will probably break sometime—doesn't everything break?" because they're only used to dealing with things that are constantly needing to be fixed (and getting paid for it). It's just considered normal.
The real point of my remarks: this is a terrible mindset. To have the same expectations of the Web is a sort of fatalism that encourages (sloppy) practices that lead to _more_ (v. likely avoidable!) breakage.
@colby The "modern web", as an API target, is not a long-term thing.
We've got things like WebUSB, which will only last as long as USB. We've got an entire set of APIs (Ajax, Canvas, Audio, DOM) that constitute security vulnerabilities (e.g. fingerprinting) in combination, but not alone – you *can't* implement them all, as defined by WHATWG.
Google keeps moving the goalposts (e.g. https://chromestatus.com/feature/6283184588193792, https://bugs.chromium.org/p/chromium/issues/detail?id=1065085, https://groups.google.com/a/chromium.org/g/blink-dev/c/zIg2KC7PyH0).
Those bad expectations are realistic.
@wizzwizz4 the thinking on the part of Google Engineers wrt the XSLT and Issue 1065085 links: exactly the mindset I'm talking about. They can't see the harm in rev'ing the "platform" because that's just, like, something intrinsic to software, right? (cf mobile)
The `<param>` element changes are a non-issue; by the time plugins are involved, you're already compromised. It's like relying on UB—that pain is self-inflicted.
Re: 1st paragraph—vague, dubious + almost def a double standard there...
@colby Fair enough about `<param>`. I absolutely agree that web browser developers shouldn't have this attitude – but since they do, isn't it good to act like they do?
CSS Grid is from 2017. Non-buggy ES6 is from 2016. HTML5 <main> (and friends) is from 2013. Aside from ARIA and IndieWeb (which are best-practices more than anything), the other good, sensible parts of the web all seem to be 2010-or-earlier.
The modern web is bad. The Chrome devs are going to break it, so we shouldn't target it.
@wizzwizz4 it's not good to embrace/roll with their attitude because it leads to more of the same (lackadaisical approach to just YOLOing along with yet another platform). This breeds and feeds on itself—on both sides.
Don't know what point your second paragraph is supposed to contain.
Chrome devs may very well choose to break their browser. Their loss.
@colby Okay, that makes sense.
Chrome is the main target of the "modern web", with Safari or Firefox a close second (depending whether the developer in question is a macOS user). If you're lucky, they'll also consider Chrome for Android and iOS Safari.
When Chrome devs break their browser, that's our loss. (Remember: autoupdates.) Chrome and Firefox are the only real implementations of GoogVM; basically every Chromium derivative follows Google's decisions to a T, and Firefox isn't far behind.