Colby Russell
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 Russell
Let's be clear: the Web is not yet another SDK. For pages that don't rely on nonstandard APIs or the equivalent of UB, that they should continue to work is the general intent. It's the reason for the motto "don't break the Web".
This is not being communicated well enough, it seems.
Colby Russell
Related:
"[This] is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release."
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Most programmers have this short-term mindset and seem to think the Web is the same.
Adrian Cochrane
@colby I do have to wonder when the JS-Web, the app-web, will collapse under its own weight though...
I'm striving to save what I can in that eventuality!
wizzwizz4
@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.
Colby Russell
@wizzwizz4 the whole point of what?
wizzwizz4
@enkiv2 @colby The whole point is that the web is not supposed to be that.
The "modern web" is the antithesis of the web.
![𒀭𒂗𒆠 ENKI ][e](https://social.076.moe/avatar/3215-48-20221221192637.webp){kind=small}
𒀭𒂗𒆠 ENKI ][e
@colby
strong "our payroll is cobol code running on big iron and the last guy who understood it died in 1996" vibes tbh
𒀭𒂗𒆠 ENKI ][e
@colby
the notion of web browsers still existing in the year 2043 is horrifying
Colby Russell
@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 Russell
@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
@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
@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.
Colby Russell
@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.
wizzwizz4
@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.
Colby Russell
@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...
０７６萌ＳＮＳ is a social network, courtesy of ０７６. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All ０７６萌ＳＮＳ content and data are available under the Creative Commons Attribution 3.0 license.