Canistilluse.com
blog.jim-nielsen.com
blog.jim-nielsen.com
Related: Stop Pushing the Web Forward (2015) https://news.ycombinator.com/item?id=9961613
Yes the classic memory-related bugs come from the engine, but the comment explicitely mentioned leaks and I don't think that was about the memory ones. Many of the new "features" turned out to leak sensitive or at least identification-enabling information. Imo having remote code execution without a big red warning that this is stupid and you should not do it that users can't click away without being forced to think about it just isn't a good idea, even if it is sandboxed. At the very least we should have a permission-based system where users need to authorize every single Javascript API, for every single connection/file/database/whatever and be unable to ignore it without disabling the APIs. That would imo be the best compromise since web-devs would be forced to think about what they are doing to users computers¹ while still allowing applications to be built.
¹ My hope being that they wouldn't include [bullshit fontend framework] except when absolutely necessary
https://twitter.com/JimMcKeeth/status/692596120464150528/pho...
Indeed, users don't read error messages, and will just click whatever they think they need to click to move on.
Few years ago, at revolution, Chrome told us about MITM attack and refused to connect to Google servers, while Firefox noticed nothing.
Few years later, attackers used my Chromium, which I used for work, to spy on my Firefox window, which I use for private browsing, by capturing of whole screen when Chromium sit unused. (I have it recorded on video).
I do freakishly experimental webdesign at times (like for designer portfolios, where freakishly experimental webdesign is kinda part of the thing), but for everything where it is much more about the info and the content I will bend over backwards to use semantic html (and even with those freakish sites I will try).
If you never looked at your website via lynx or used a screenreader I highly encourage it. It will give you a different perspective on things.
It’s been open-sourced and forked here if people would like to help keep it alive:
...which the text-to-speech reader probably pronounces as "ay eleven why".
Similar to i18n and l10n for internationalisation and localisation.
Interestingly unlike w3c, so it's not standing for aaaaaaaaaaay :)
A11y is probably the easiest one to remember because it looks like ally. Which is what you're being by worrying about accessibility when you yourself don't rely on the standards.
Agree with you re: screenreaders.
Look at <select multiple> for example—the browser built-in is borderline unusable. Anything that requires combining a click with the shift and ctrl/cmd keys is not going to go down well with the average user. Same goes for <select>s that need more advanced behaviour like filtering. There's <datalist>, but it's incredibly basic and pretty useless for most cases you'd want that sort of input.
The web is an app platform whether we like it or not, and I'd like to see a robust set of browser-native controls with mechanisms to customise styling and behaviour. It would improve accessibility, improve performance, reduce page sizes (because we wouldn't be re-implementing the whole world in JS), and it would at least go a little way to offsetting the slow erosion of quality desktop software that web technologies are bringing.
Now, if you wanted to say that HTML's standard widgets should be allowed to reflect the platform-native look-and-feel (for example, adding a "selected" checkbox on touch-screens, or supporting long-press to select items, or whatever) instead of being tied to Windows 95 appearance and behaviour by backwards-compatibility concerns, then yeah, I'd agree with that.
Even in the early desktop era when it was popular, many non-enthusiasts probably just didn't know how to use a UI control like that. It just didn't cause a problem because most people didn't use computers much.
I would bet that most internet users today have never even used a UI where that control is popular.
Never done tech support I take it!
It makes me think when I'm designing things. If I have problems with stuff like that, how can I make it better.
Then there's the way styles are so different, especially on the web. Horribly user-hostile. How does this site mark something as important, assuming it bothers in the first place? Who knows. And if I'm only planning to be on it for 30s, I'm not going to learn that.
It's a standard UI control and it is used pretty often.
Or you could just use a better control.
Many users don’t even know you can use a key shortcut to copy/paste.
"‡ On a phone or tablet or whatever, ignore us, we're just confusing you."
And it's also completely not discoverable. I only know how it works when I read from HTML book back in the day.
Just because it was the standard doesn't mean it's easily learned.
If you absolutely have to put words in my mouth, please make them at least a little less stupid ones. Maistuivat vähän paskalta.
This is part of the problem. Your average user at temporal point X has difficulty combining mouse clicks with keyboard modifiers. You build interface around that notion and in a later temporal point Y your average user cannot combine those at all and you have lost input mode. Your average user has problem distinguishing single click from double click. You install debounce logic, train them there is no difference between the two and lose input mode.
The web is a shitty platform for apps, because currently it is supposed to be used from at least proper PC, touchable handheld device, embedded in controlling container and in relatively near future virtual environments. Game developers have tried for literally decades to bridge the gap between PCs and consoles and mostly failed at that with both platforms being relatively static. The web being a moving target is much more difficult to fit on different device classes. Yet we try to do that and as a result are moving to the lowest common denominator.
For grand strategy / RTS, yeah, that's kind of a function of the complexity. Most other game genres are fairly well defined in the expected control schemes on both platforms now though.
This is how computers have worked since pretty much day 1, not just the web. I remember getting computing classes in school, but it seems the current generation is completely ignoring all of that and instead just plays on their phone.
More built-in widgets would be great though.
I like to imagine that if browser makers had collaborated better on standardising CSS hooks into the default widgets, we would not have seen such strong adoption of tools like bootstrap. We possibly would have had a different pathway through template+controller libraries too.
As a FED, I didn’t help. I rode the gravy train along with Backbone, Angular and React. I wish I had fought harder and spoken more eloquently on the practicality of a11y-first semantic mark-up and progressive enhancement. I caved in to the demands of the agencies who took me on to get stuff done in the trendy stacks.
Is there a reason the element has to be implemented that way? Correct me if I'm wrong, but aren't the details of how it works up to the browser? It only works that way because every OSs native select widget worked that way and once upon a time browsers actually tried to integrate well with the OS and used native widgets.
These users need to retake the computer literate 101 class.
When I'm in elementary school, we learned how to multi-select in the tutorial system that comes with Windows 3.1.
I don't know why Windows XP deleted these very important tutorials and replaced them with a webpage.
Seriously, I've seen pages that create links by using a styled <span> tag with an onclick even that merely called a function that set document.location using a hard-coded value.
Did developers forget that `<a href=....>` exists?
[0]: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
I think it's OK for Google to make Chrome into an OS and cram whatever they want into it as fast as they can.
Regular web browsers don't necessarily need to be on the same feature treadmill/death march (assuming they could keep up.)
We seem to be trying really hard to reinvent the applet systems of the 1990s, but in a way that brings systems with 10-100x the memory and CPU resources to their knees and requires huge armies of programmers to implement. I guess JavaScript/webasm is better than Java in some ways.
> Regular web browsers
Chrome is a "regular web browser". It holds a 70% market share among web browsers.
> Regular web browsers don't necessarily need to be on the same feature treadmill/death march (assuming they could keep up.)
They either don't need to be on the same death march, or keep up. You can't have both.
Currently, it's a major problem, because Chrome churns out 40-70 new web APIs with every release which happens every two months or so [1]
So, no, it's not OK for Google to convert Chrome into an OS.
It certainly is an insane amount of feature churn.
But the right perspective might be to look at the impact on end users.
The issue for end users seems to be that they occasionally encounter "web sites" (really web apps) that only work properly with Chrome. This is sort of a bummer for iOS users, but for the most part they seem to get by just fine. Perhaps there will be a tipping point where the "web" becomes unusable from iOS, but it hasn't happened yet.
I consider this a comparable problem to encountering web sites that only worked with Internet Explorer, or Flash, or Silverlight, or Java. Certainly annoying, but not really catastrophic.
If you're prioritizing looking at new things over accessibility and cross-browser support then you are making that choice; browser vendors are not forcing it upon you.
Browser vendors do a lot to make it possible to write robust code that doesn't break in the future. Maybe they could do more, but if web devs are failing to leverage the features that are there already then why would they? A whole lot of the responsibility for the broken ass nature of the web is not due to browsers.
For instance Safari on iOS reports support for drag and drop events, but they aren't actually triggered. Another I encountered recently is the "accept" attribute on input file type. On iOS, you can't set specific file type, just mime type, but you have no way to detect that except by using the user agent. Then you have the buggy releases that make a feature seemingly supported, but is actually unusable in practice (looking at you IndexedDB on Safari).
This means using a library like Modernizr is almost mandatory. Also, what do you feature-test? Everything? Feature-testing something that has been available for 20 years sounds like a waste of time on the face of it, but the "alert" case has shown us that if you really want to do it correctly, you can't assume anything. I am not saying it is not possible to do it properly, but it is not that simple. For anything non-critical, I understand waiting for things to break then fixing them instead, it's way less efforts.
I've done it by testing with historic browsers alongside modern, and challenging myself to make it work with all of them, JS and noJS, without errors, reliably.
In the process, I found a set of "lowest common denominator tags which work across almost anything. I use these to build the "base" HTML. Then, I add JS with feature-checks to allow older browsers with JS enabled to still run it, though it doesn't do much at the moment.
I think it's a worthwhile exercise to learn where the roots of the web are, and how it evolved, and allows you to write much more resilient code in general. The reason for this is that the longer a technique or syntax has been in use, the longer it's likely to continue to be used.
Lindy effect is the name of the trend.
Most of the older browsers are covered by three VMs: Windows 95, Windows ME, and Windows NT 4.0.
Most Windows Netscape can run in Wine, so I can use symlinked .wine directories to switch versions.
I also do occasional testing at Best Buy or Walmart (many thanks to those places) at a cross-section of their available devices -- a couple of desktops, a couple of phones and tablets of each flavor, etc.
I also often ask people if I can test out my website with their device (or if they want to participate in a 5-minute user study)
For difficult things like Mac IE, I just have a couple of devices e.g. G4 Macs and iOS 7 iPad.
Of course, there are text-mode browsers, which I usually install with apt or whatever.
I also use online emulator services like BrowserStack, they have a pretty good slice in their free tier, and a couple of minutes is enough for smoke testing.
Also, I sometimes come across public devices, such as desktops in survival center, library, hotel, or public community space, and I test on those.
With my own devices, I test across various public wifi locations, so that I can provide workarounds for e.g. content blockers or inadequate proxying.
I use Charles Proxy locally to simulate low-bandwidth connections and other common issues.
I have also asked rare use-case users, such as visually impaired, to test using a script, usually through topical Facebook groups.
That's about all I can think of for now, there's probably more.
This reminds me of Spolsky's blog post about Fire and Motion. [0] He gives the example of Microsoft creating an endless stream of new technologies which kept their competition busy (eg: ODBC, RDO, DAO, ADO, OLEDB, ADO.NET, ...). Get the competition to spend their resources keeping up rather than competing.
0: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
See jQuery (both Ajax and selection), Moment/Temporal, etc
This to refer to my annoyance of browser makers leaving incomplete implementations stagnant for years.
As an example, the <dialog> element, a browser-native standardized spec as promising replacement for alert. Except that it doesn't work, it's inaccessible at its core.
And nobody fixes it, it's just left in this broken state forever.
<section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all.
CSS columns, a simple and easy way to distribute text, were unusable for 8 years because Mozilla refused to fix their own small bug. Which pales compared to the extraordinary amount of Webkit bugs that are absolutely never ever fixed.
Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process.
I could go on, but I'll sum it up as the failure to address extremely common real world problems, and to just let broken buggy solutions linger. When you accept a standard and implement it, bloody finish the implementation. Fix bugs. Otherwise, what is the point?
I'd call this hardening the web. There's no reason I can see why you can't harden it whilst also making progress on new features.
The features we're talking about here are in the developer space, not the end-user space. When a browser maker implements a brand new web standard, I don't think the correlation with new end-users is that strong. It takes forever before any new standard is popularized and widely used.
Check release notes of browsers, almost all features no user will ever directly experience.
sed "s/users/devs/g" previousComment
MDN/caniuse cover quite a lot of this already.
> <section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all
They do a lot for Reader view and I’m fairly certain they help with screen readers where heading hierarchies might otherwise be ambiguous.
- - -
Overall, I share your concerns but feel they’re overstated. Mostly because I remember the bad old days of NS4, IE4-6, etc. The web as a set of reliable standards isn’t perfect but it’s worlds better than I ever anticipated.
Just as a matter of perspective: when I started web dev, I learned and used by rote dozens upon dozens of hacky incompatibility workarounds. I moved more backend in recent years, but have had more web work over the last year. I can count on one hand the number of browser compatibility issues I’ve had to address (yes, all Safari). And not because build tools are helping. If anything build tools are the biggest source of frustration for me now.
But it doesn't lessen my annoyance. How can you deliver a 90% implementation, and then let it rot for a decade? Effectively delivering 0%, because it's unusable. It just doesn't make sense to me.
I'm not sure about Reader view, but <section> does nothing for screen readers as it comes to headings. It doesn't start a new nesting level. You can label a section and this way mark it as a landmark to a screen reader, but that's something you can do on any element.
Meanwhile, developers trying to keep up incidentally may use <section> in an effort to produce more semantic value over a <div>, but they all use it incorrectly. Perhaps because just understanding how to use it correctly seems impossible. Or, better said, it has no function at all: https://www.scottohara.me/blog/2021/07/16/section.html
We're close to being down to two browser engines that matter, one of them with well over half total market share, and they still don't bother to fix forms. You're right about the costs, they're immense. Billions isn't an overestimate for ball-parking the figure, I'd say.
Shit, Firefox, you want to do something to stay relevant, be the first to do that right. Go nuts with some (well-considered) non-standard extensions, behaviors, and tags, worst case no-one uses them and no other browsers adopt them, best case you achieve arguably the greatest thing your project ever has (which is saying something—early FF, especially, was awesome). It may be too late (like every other idea I can come up with to save FF, they should have started at least a decade ago) but it's worth a try.
https://blogs.windows.com/msedgedev/2019/10/15/form-controls...
It's a restyle into the timely (cough) flat design. I guess any progress is good progress, but it's meh.
Firefox can't do anything regarding relevance. It's not an engineering problem, they can't push their browser, they have no reach.
I don't think that's true, considering they became popular originally though features and overall program quality. I wasn't using it and recommending it to (and/or installing it for) everyone I knew back in the Phoenix/Firebird/FF1.x days because of advertising or whatever, but because it was excellent and solved a lot of problems for people, and that exact mechanism is how they gained a foothold to begin with—every power-user and nerd was doing exactly what I was, and pushing everyone who'd listen to switch to Firefox.
There are other ways to gain relevance, obviously (say, promoting your browser prominently on your search engine) but simply being better than alternatives definitely can work. The proof is that it already did, for Firefox in particular, once.
Firefox has no meaningful presence on mobile, whilst both Google and Apple can push their own browser to billions of users. Google in particular also pushes it from services having billions of users, like Youtube or Gmail.
Mozilla has no such thing, it can't push anything. It has no platform.
Your historical reading is correct. The lack of progress in IE created a temporary vacuum for a better browser to jump in. That doesn't mean the situation is repeatable, as this vacuum doesn't exist right now. Instead, Chrome is speeding away from Mozilla's budget-cut team.
Make native HTML UI elements much better, and add behavior and new tags that should have been added to the spec 10-15 years ago. Bake ad-blocking in (though Brave stole their thunder for that, a bit). Build in federated social networking to the browser itself, to give people a reason to install FF (would it work? I don't know—but it might). Do something more than "we pointlessly redesigned the UI again, and we've almost caught up to 2nd-best on battery life and performance!" each release. They may as well give up, if that's all they're going to do.
Since we're in a salty mood, let's keep it going. jQuery, the much despised jQuery. Inspired by jQuery, browsers now have native DOM APIs that are somewhat equivalent, reducing the need for jQuery.
Except that their syntax is terrible, and chaining isn't possible on most methods. So an elegant chained one-liner in jQuery becomes a blob of ugly syntax spanning many lines using native methods.
A massive regression.
Is it not usable for users with assistive technology? Is it a bad UX for them? Is it broken or buggy? Does the polyfill not workk? etc.
To sum it up, <dialog> is a specced standard of which the first implementation appeared 8 years ago. It is a perfect example to illustrate my original rant.
It is a feature in high demand, almost every web application needs it. Hence it makes sense to have a native control and for each browser to implement it, eventually.
No such thing happened. A broken implementation is delivered, and more importantly, never fixed. It doesn't work cross browser and in the browser where it works, it actually doesn't. And now, nothing happens, they just gave up on it.
Which indeed leaves us with custom implementations, but my point is that we shouldn't need those. It was specced for a reason, it's high on the list of developers needs.
> tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago.
With the announced intent to get rid of window.alert/confirm (discussed elsewhere in this HN post comments), it would be nice if dialog got some attention as a replacement... I'm not sure what we're going to do when it goes away; everyone has to roll their own replacement? Doh.
Here it is in the standard: https://html.spec.whatwg.org/multipage/workers.html#dom-shar...
Safari/Webkit removed it in 2015 (edit: maybe even earlier!) and never reintroduced it: https://caniuse.com/sharedworkers
Here is the apparent reason for cherry picking features:
> The implementation of Shared Web Workers was imposing undesirable constraints on the engine. It never gained any adoption.
https://stackoverflow.com/a/48193804
Edit: Here is the ticket for it’s reinclusion https://bugs.webkit.org/show_bug.cgi?id=149850
Turns out it was removed temporarily because of internal architecture changes, and never reintroduced because of lack of adoption. Of course the biggest barrier of adoption is Safari not supporting them, so talk about a self fulfilling prophecy.
> This feature was originally removed temporarily during multiprocess bring-up, and actual usage on the web has been pretty low. We're willing to reconsider if there is significant demand.
It was only 4+ years after it was dropped from Safari that anyone started to ask about Safari support for it again, so it had kinda fallen to the wayside due to lack of interest.
On a long enough timeline, the survival rate of all APIs goes to zero. (Except Lisp, which is Eternal).
The philosophies around entropy isn't really relevant here IMO. The web should continue to be evergreen.
Something completely new would fasttrack innovation. It could leave out all the quirky workarounds and get advanced features built in or easily extensible. When adoption is high enough it could include a legacy box, to run good old HTML based content.
Have any attempts at this sort of thing ever been made?
Something like websockets is not exactly accessible to a beginner, but there is a huge need for online content that supports live interaction.
You are right that it's not going to be easy to get everyone on board, but that should not be a reason to stop trying.
Of course, what's junk and what's not might be controversial, but that's where it got its start.
Theory: A lot of those people tend to survive by jumping from metaphorical ship to ship (API or software or whatever). So to them, the reality is that the ship you're currently on pretty much always feels like it's sinking, and you're always looking out for signs. You write articles lamenting sinking ships, because that's your reality.
These people also may feel like the universality of decay can be stopped in the current context, by moving away from a decaying ship/system. It's more of a question of where the decay isn't as bad, or as seemingly needless.
Example Pro: After a while you can get really good at evaluating ships. Con: It feels useless to build your own ship; you're afraid you'd have to jump from your own ship and wouldn't that feel awful.
Other people survive by building ships. They're cool with decay, because building new stuff that works better is interesting. Their job is to support their stuff, and to a lesser degree to patch others' stuff, like maybe their supply ship, or a friend's ship. To people like this, the reality is that holes just happen. So you learn to deal. Maybe you even learn to love patching holes, and you get so good at building ships that your ship's holes are downright fascinating anyway.
These people aren't usually as worried about decay. But they may have a problem of eventually going down with their ship, or finding that their ship is no longer just a ship but also a lot like a baroque form of floating junk pile.
Example Pro: Obvs, you can build ships. Con: People will try to jump on your ship, and they'll probably tell you they think it's sinking, and expect you to do something about it.
For a second, ignoring safety concerns, what should change in how we serve some HTML, JS, CSS and some images in 20 years? Sure, there are plenty optimizations and new technologies to utilize for sites that need high performance or to use certain hardware functionality, but when you just want to display some simple content, none of that is really relevant. Why couldn't i build my personal website with some mostly static content and have it work for many years, while i'm not tied down with constantly maintaining it?
Even now, that's not the case. I decided to build my own site in Ruby on Rails, since it feels mostly stable - however i need the exact same version of Ruby both on my local machine and the server for it to work (using containers for development isn't always a pleasant experience, even though using them for packaged software is great). I also need to rely on dozens if not hundreds of packages, as well as bunches of native extensions, for example, to connect with a SQLite database to serve some simple dynamic content. Of course, i also need to update the OS (thankfully Debian unattended upgrades are pretty stable, except for the one time when they broke GRUB entirely and the server couldn't boot), as well as the web server and there's no guarantee that the SSL/TLS certificate provisioning from Let's Encrypt also won't change in the future.
To that end, the above goal is impossible - i can't just keep building new things, since i have to spend time maintaining what i've already built, even if nothing changes about what i need from these projects functionally, just because sooner or later a rug will be pulled out from under my feet.
Edit: i've actually written a blog post on the topic of updates, called "Never update anything": https://blog.kronis.dev/articles/never-update-anything
Doesn't sound so stable to me…
> Why couldn't i build my personal website with some mostly static content and have it work for many years, while i'm not tied down with constantly maintaining it?
You can, HTTP still works and even oldschool HTML mostly works¹.
If you only need sqlite as a db you could easily compile a static binary that will run forever (as in foreseeable future) and serve content via unencrypted HTTP. If you then use a reverse proxy that can be automated with certbot you will have a system where all the maintenance work is done by the EFF, the reverse proxy developers and your distro's packaging team.
I can understand why they'd complain about version mismatches when installing dependencies, since in those circumstances failing fast prevents me from running into deprecated functions down the road, as would happen with PHP. However, the fact that different versions of Ruby/Rails are available in different OS distros and such basically mandates that i use containers OR that i just change the contents of my Gemfile to reflect the version that i will be using during build, which carries the aforementioned risks.
That said, Ruby and Rails are both far more stable than the current npm or pip ecosystems, given that the development has slowed down in Rails somewhat and isn't broken every week due to some package introducing breaking changes. That's not to say that it's better in most conceivable ways (for example, in regards to scalability), but as far as batteries included solutions go, it's pretty okay.
> If you only need sqlite as a db you could easily compile a static binary that will run forever (as in foreseeable future) and serve content via unencrypted HTTP.
Actually, static binaries are perhaps one of the better ways to ship software, especially with static linking, as long as you're ready to take certain security risks in the name of long term stability, though that doesn't prevent you from building new versions in an automated fashion either, at least before something breaks down the line and hopefully your tests alert you about needing manual intervention.
It feels like Java sort of tried to be this, as did .NET, but there is too much functionality that depends on reflection and standard library classes out there, that many projects are stuck on JDK 8, and the whole .NET/Mono --> .NET Core --> .NET cycle is as promising as it is also problematic to deal with. As for actually workable options nowadays, i'm not too sure - most ways to encapsulate scripts in static binaries fail miserably (containers allowing to mitigate this, but don't address the root issue) and otherwise there aren't too many technologies that are good for this out there.
If i wanted to go down that route, i'd probably go with Go, since it doesn't have the problem of needing JDK (and GraalVM is still brittle, for example with Spring Boot, an issue that Go doesn't have). Any other options that you can think of? I really like the idea behind Lazarus/FreePascal, though their web server offerings are really lacking, which is sad.
As for HTTP, i largely agree - read only sites don't necessarily have to be encrypted, even if that can hurt SEO.
> If you then use a reverse proxy that can be automated with certbot you will have a system where all the maintenance work is done by the EFF, the reverse proxy developers and your distro's packaging team.
I am already doing this, but as the Caddy v1 --> v2 migration showed, even web servers and their integrations are subject to churn and change. I'd say that it's only a question of time until Apache/Nginx/Traefik + Certbot run into similar issues, either with new methods for getting certificates being needed, or something changing elsewhere in the supply chain. And even then, your OSes root CA might need to change, which may or may not cause problems. Old Android phones have essentially been cut off from internet for this very reason - the fact that i can't (easily) install Linux on those devices and use them as small monitoring nodes for my homelab disappoints me greatly, especially since custom ROMs brick hardware devices due to lacking driver support.
So sadly if i get hit by a bus tomorrow, it's only a matter of time until my homepage stops functioning and the memory of me disappears forever. Of course, that's just a silly thought experiment, since i recall another article on Hacker News which pondered how someone could keep code running for centuries. It didn't look too doable.
I meant compile your whole logic and libraries into one (big) binary so you won't depend on any runtime that might ever change except for your operating systems syscalls.
> most ways to encapsulate scripts in static binaries fail miserably [...] and otherwise there aren't too many technologies that are good for this out there.
LUA is about as stable as it gets, (minimal) WASM runtimes will also probably live forever. (Or are, most likely, interchangeable if not) For both of them you'll need to build the interface yourself, so any breaking change will at least be your own fault.
> Any other options that you can think of?
Rust, or if you are a bit masochistic C or even C++. Rocket 0.5 (Rust) looks really nice (as in ergonomic) as a webserver and iirc you can statically link with musl instead of glibc.
> I'd say that it's only a question of time until Apache/Nginx/Traefik + Certbot run into similar issues
But then youll at least have http as a fallback
> So sadly if i get hit by a bus tomorrow, it's only a matter of time until my homepage stops functioning and the memory of me disappears forever.
I think what you want is a trust fund :D
Because web pages and simple web scripting is often done by non-professionals, who cannot be expected to follow standards processes in perpetuity to keep their pages/scripts working. They often author a few pages and move on with other things in life, which is why browsers being ultra-conservative about breaking stuff is important for the robustness of the Web.
FWIW although I'm actually a fan of decay, I think its a terrible idea to deprecate `alert()`. I get it that it's abused, but it's also an important part of learning js -- it's the easiest way to make a side-effect. (No, `console.log()` isn't easy because you have to open dev tools, which is scary and hard. A simple modal dialog is far friendlier and immediate and visceral and gives a feeling of power.)
I am a professional software engineer at my day job, and we strive to keep our software up to date etc as the world changes.
But I am also exactly this non-professional developer in my after-hours. I have written a number of little web apps that solve some small need, and I really have zero interest in maintaining them over time.
When I wear that hat, I really appreciate the conservatism of most web stuff.
Professionals can't keep up with standards processes either. Because Chrome employs people to work on them. Who's going to pay me to keep track of literally hundreds of standards currently in development?
<3
Because information can be perfectly copied? If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. Whatever data will still exist as a perfect copy.
(In fact, rumors are that George RR Martin does exactly that, and sends whatever he writes to his publisher on 3.5" floppies)
Nothing we store digitally need ever be lost so long as some basic stewardship is performed. For now that means moving data to newer storage formats, making redundant copies, using error-correcting codes, etc. Maybe eventually we'll get the mythical "store all your data in a diamond" 3D / 5D holographic storage that always seems to be a few years off.
Somehow, we've managed to take that natural feature away.
That being said, in an archival sense, it would be a shame and seems unnecessary to lose anything, since perfect preservation is achievable. But archival preservation, is different from staying in active use with a healthy community of practitioners perpetually ad infinitum.
So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever.
Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way.
Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay!
Obviously we can still make sure great consideration is made both before adding something new and before removing it.
There’s no getting away from the balancing act between change and conservation.
There's the physical degradation of mechanisms and data storage substrates themselves. That's ... not insignificant, but a minor part of the whole situation.
The short-term strength and long-term technical debt of digital is dependencies. Sure, you can spin up some bare-metal or virtualised instance of a system from last month, or five years ago, or twenty years, ago, or fifty. Odds are that the emulation will run faster than the original.[1]
But with time and complexity, dependencies started to expand.
One of the underheralded changes of the 1990s wasn't so much Free Software as what it wrought: an ever expanding and accelerating increase in the number and specificity of dependencies. Tarball distribution gave way to packages, with dependency-resolution, some better (APT), some worse (RPM). Crucially, dependencies didn't simply have to be resolved at build time, once in the lifecycle of an executable, but at install time, once per installation.
The explosion of Web apps and frameworks triggered another violent expansion of the situation with both even more dependencies, more deeply nested ones, but runtime dependencies where prerequisites are identified and fetched from remote hosts.
At runtime.
Which makes the current appified-web immensely flexible and convenient, but also fantastically brittle.
(Of course, the old-school type scan extend this story back to interpreted vs. compiled languages, JIT, hardware-specific variations, high-level vs. machine langauge, binary, and toggling in programmes. It's been a long process.)
But as bits of that infrastructure fall apart, you'll find that digital does in fact decay.
________________________________
Notes:
1. At a gig some years back, a cow-orker told of a uni prof they'd studied under, who did work on the the B and BCPL programming languages. Those are precursors to C. Back in the day when auto manufacturers were looking at automated systems controls, he convinced them that C was far too complex and high-level, and that they should use the more performant BCPL. Which they did. And still do (or did as of a decade or two back), running under several generations of emulation. Faster than the initial hardware implementation. Mind I'm taking them at their word....
Sadly, this is no longer the case, since nowadays OSes rely far too much on the Internet. For example, your Docker and VS Code repositories eventually will deprecate and remove certain versions of software that you might have been using. Furthermore, npm and pip packages will also decay in a similar manner and eventually Maven repositories will drop off the Internet one by one.
Installing software from DVDs or flash memory is no longer the normal for all of the OS and the rise of the private package repositories without having the tooling in place to ensure that we can download .deb or similar files with all of their dependencies into an installable collection that can be persisted in such a manner is an utter failing of the modern age.
For an example, just look at these:
- https://superuser.com/questions/876727/how-to-download-deb-package-and-all-dependencies
- https://stackoverflow.com/questions/13756800/how-to-download-all-dependencies-and-packages-to-directory
>Sadly, this is no longer the case, since nowadays OSes rely far too much on the Internet.
That seems like an issue with current work, not with past work. And yes, it's an issue. Figuring out how to archive tools and buildchains is important.
Although, do modern OSes rely too much on the Internet, or does the modern development ecosystem?
I'd say both.
Operating systems should be developed with offline first in mind, instead of giving into the prevalence of downloading things from the Internet. For example, Debian has apt-cdrom which allows updating /etc/apt/sources.list and adding packages from DVDs or CDs. That is good, the next logical progression of which would be doing the same for any storage medium - flash memory, HDDs, SSDs etc., just a set of tools to easily create package mirrors on these storage devices and to read them from the OS to make airgapped environments even easier.
Instead, as things currently stand, downloading a package with all of its dependencies is perhaps needlessly hard if you don't want a full mirror, but only need something like gcc with everything it depends on in one gcc-with-all-dependencies.deb file. And the situation isn't necessarily much better with the way how Flatpak and Snap packages want to handle updates, while there are definitely valid arguments to be made about automatically updating packages over the internet, as Debian unattended upgrades already does, relying on it too much makes software brittle.
For example, just look at this: https://unix.stackexchange.com/a/541583
It took Flatpak until 2020 to address this, i'm not even sure what the situation is with snap packages and using them in air gapped environments, since that's also only in beta: https://docs.ubuntu.com/snap-store-proxy/en/airgap
I apologize if the above sounds a bit like rambling, but the bottom line is that if developers truly cared about airgapped environments, then using and managing them would be as easy as the alternatives, not less so. Be it in regards to tools, to how packages are managed, or even just the day to day experience while using them.
And that trend extends deeply both into the OS itself, as well as the software that's used by it (especially in cases of non-standard update mechanisms, like some browsers like to do), as it does with the development ecosystems nowadays. It's surprisingly how little pushback something like snap got, instead of the community delaying its utilization until all of the concerns have been addressed.
I'm not saying that we shouldn't innovate in regards to package management, apt over apt-get showed that there definitely can be improvements in regards to usability, it's just that we as an industry should never be satisfied with using half baked solutions.
I think that's pretty impressive as far as API age.
I'd rather say that the "universality of decay" is a U-shaped curve. Just have a look at old arcade and console games... they went out of fashion, the hardware (sometimes literally) rotted, but emulator technology is getting better and better all the time - the result is you can use any modern computer or many smartphones (!) to run all that stuff that is sometimes many decades old.
All that any kind of technology needs to survive into modern ages is one (single or group of) person that engineers an appropriate abstraction layer. Polyfills, virtual machines and other emulators, FPGA-based hybrids... the list is endless.
Why not do the same exact thing for alert()s?
Yes, this is a problem when people code their websites against current iterations of a browser. It's not a problem regarding Chrome removing window.alert() but rather a problem that happened at development of the site, not at the iteration of browser (which is being discussed here)
> browsers are allowed to ignore those prompts
Unless previously marked as "Block future popups", is there any browser that currently (by default) doesn't block JS execution upon window.alert()? AFAIK, all browsers currently do.
> now they have to fix their code
Yeah, good luck maintaining the web with that mindset. There are countless of websites that will basically vanish (rather, stop working) if you change the execution model of browsers too much.
But large swaths of the web currently are just online because someone set it up well 20 years ago and has never touched it since. Maybe they can't even modify it at this point.
So any change needs to consider the historical impact the change can have. Hopefully the people working on browsers and standards have a bit better mindset than "now they have to fix their code", because otherwise we're utterly screwed.
If it's legal to do so, then your code needs to be ready for it. Relying on a browser's specific version behavior is brittle.
And no, not all browsers currently do, all the browsers you've used in some specific scenarios behaved the way you thought, but there were already ways for it to fail before.
As nice as it is, MDN and all the other websites are just paraphrasing what is in the specification, and sometimes omitting crucial information. Yes, Javascript and web technologies are accessible and can seem simple, but the reality is a lot more nuanced than it is portrayed in most places.
Google, alongside all of those that push Chrome wrapped in whatever kind of package, have managed to turn the Web into ChromeOS.
I expect job adverts for HTML 6 to be about years of experience developing ChromeOS applications.
Recent things like Zoom native app being incredibly insecure but the same company's webapp being much better kind of proves the point.
It shouldn't be difficult to see that GIMP and LibreOffice can run on this runtime with similar privacy.
We typically download native executables over HTTP. Then check for application updates over HTTP.
Privacy respecting WASM apps can do the same.
This is the new Java, not the new SaaS.
Spend some time learning about marketing solutions.
So native apps may use, Web uses it all the time.
Every horizontal line on the network tab in developer tools is yet another piece of telemetry information.
Native apps have access to whatever user they run under.
Again whatever native apps can do, web apps do all the time.
Another example: Microsoft Word can include a bug that makes opening a doc file run whatever command, including wiping the system. Google Docs can't do it.
It's much simpler to see telemetry in a web app - just open the Network tab. The fact that it's harder to do with a desktop app does not at all means it isn't there. Give wireshark a spin.
You don't get it, yes desktop apps can do telemetry, and many do.
Web applications not only have all your data, every page interaction is fed into marketing engines regardless of your opinion on that.
You keep making these bombastic statements with no data behind. Not all web applications store every page interaction into a marketing engine. For example, I have a web application - as you navigate no additional network requests are sent (it's SPA!), and anyway I don't really have access to those the server logs because they're hosted by some Netlify-like service. See? Web application without you data that doesn't feed your interactions into a marketing engine.
Some web apps track, some desktop apps track. But clearly and without any doubt an executable running in your operating system can potential do much more than a web app you open with your up-to-date browser. An executable can even... open a web app!
Discord web app has a track record from everyone you ever spoke with, where you where when each sentence was written, who the people you talk to were.
All Web apps track, there are no exceptions, unless you are talking about some hobby stuf written by yourself.
This isn't true. Yes, web apps have tons of telemetry, and every web request is logged server-side. But native apps do MORE:
- Native apps can look at what processes you're running. Web apps can't.
- Native apps can look at what software is installed. Web apps can't.
- Native apps can accurately determine exactly what operating system and browser you're using, while web apps either have to rely on a User-agent (which is trivially spoofed), or perform fingerprinting in order to come up with a guess.
- Native apps can see exactly what hardware you have. Web apps can't.
- Native apps have read/write access to every file on your system, subject to user-level permissions. Web apps require explicit selection from the user for file access. A native app can easily send your /etc/passwd file to a remote server, and can enumerate the local users.
--
Look, nobody is disputing that web apps have tons of telemetry, yet you keep responding as if that's what people are arguing with you about. What we're disputing is the exact statement I quoted. You implied that the telemetry of a native app is a subset or equal to the telemetry of a web app, and that's just plain false. It's very much the other way around. The telemetry of a web app is far less than a native app.
A native app may know which browsers I have installed, but how would it know which of the umpteen ones I have I actually regularly use (if I don't do so while running the app)? The Web app, OTOH, is running in that browser, so yeah, of course it has a better chance of knowing that.
Your "umpteen" browsers is very much an edge case.
It's at least possible (albeit potentially difficult) for a native application, should it have have such tracking, to have that tracking removed. Software "crackers" have shown, time and again, that so long as the code is present on a machine it can be made to run in whatever manner is desired.
The fact that I can see access log in my web server is just a helpful tool for me as a developer to improve my services. I think the majority of sites use this in good faith and keep products healthy.
If your threat model involves secret services tracking your activity down based on downloading favicon.ico, then you might have more serious problems than architectural choices of the web platform.
And they own your data as well.
At my day job, we make a web application for health records that can be deployed inside an air-gapped intranet. Surely you don't think that's feeding a marketing engine?
It's a separate question of how a patient can be sure of that fact. There's actually not a really reliable way a patient could even become aware of the existence of this product, since they would never see it or be informed of it. Patients are not users of this product. Users could ask their IT department for a log of outgoing internet-bound requests from the servers. Or ask whether those servers even have the capability of contacting arbitrary third parties.
I mean, one could also be running around in a supermarket in a balaclava without intending to rob the cashier -- but would you assume someone you saw doing that wasn't going to do exactly that?
In fact, that's pretty similar to the technique that you'd use to check on a local app too, except it's built into the browser.
I'm not particularly interested in convincing anyone that some app is or isn't leaking their data. If you don't want to use web stuff, don't use it. But I do take issue with assertions that 100% of all web apps must be doing that kind of stuff. It's obviously not true. You can develop your own web app from scratch that doesn't do it, which is sufficient to form a counter-example.
And one counter-example does not a summer make. As long as 99% (typical Internet statistic, i.e. pulled from my mether regions) of web apps harvest your data for sale, that last percent won't get the benefit of the doubt: it's far too difficult and uncertain to find out which percent that would be.
Bearded Man #1: But I have a beard.
Marshall: Well, then you're an alien.
Bearded Man #1: No I'm not.
Marshall: Yes you are.
Bearded Man #1: No, I'm not.
Marshall: Well, then you can't grow a beard.
Bearded Man #2: But he has a beard.
Marshall: Well, then he's an alien.
Bearded Man #3: He's not. He's from Pittsburg.
While local apps are getting sandboxed properly: https://docs.flatpak.org/en/latest/sandbox-permissions.html
It seems it need user to manually select a file/folder to be used, like Android or iOS does.
> While local apps are getting sandboxed properly: https://docs.flatpak.org/en/latest/sandbox-permissions.html
It looks good, but it seems many applications still require filesystem=host to run (https://flatkill.org/2020/). Also, its sandbox solution isn't going to work on Windows, Mac and BSDs.
please select your home directory for our super-awesome functionality
I'm sorry, but the likeliness of zero days in a c++ program that was too stupid to handle char arrays or multithreading is way off the charts vs heap spraying bugs in a VM.
I'd argue that native applications therefore are far more vulnerable than web applications.
Desktop applications can track your every click with HTTP requests to their server.
The runtime does not determine this.
And if by offline you mean PWAs, unless you are doing Hello World, that app cache is going to be cleared and then analytics can be updated.
Finally, there is very little a pure PWA can do without doing HTTP and Websocket requests.
Desktop code cannot be verified. Web code can be verified. This argument goes both ways.
If we're talking about the web-equivalent of Desktop Apps: There's electron, which can do far more than HTTP requests and WebSockets - but that on the other hand is also too bloated, right?
Sometimes I wish people would just make up their mind, stop complaining, and start trying to fix it. We had servo, and we had a nice modular and privacy respecting future for everybody; and then we messed it up because apparently nobody really cares about it.
Please explain the crowd how you verify the SaaS server side.
Electron is an abortion, that will eventually follow Active Desktop footsteps after its fashion hype curve dies out.
In any case, Electron based apps can do whatever user account they run under.
HTTP is simply the delivery mechanism for a self-contained WASM application. Just like it is the delivery mechanism for most native binaries now.
If it's in your browser, you can see the code it's running and the data it is transmitting. And you're only a single uBlock Origin (other other browser add-on) filter away from blocking it.
My gentoo install would like to have a word with you
That is a remarkable ability.
Do not let the crimes of Web 3.0 blind you to this.
Tracking and disrespect for privacy are utterly orthogonal.
It's rare that a self-hosted piece of software is not present on this list. As you can see, the coverage is pretty extensive.
I think in the end, it doesn't matter as much. These are meant to be deployed for a cohesive user base that numbers between a single geek and an entire region of a country or small org.
They most often use libre data formats and protocols to store and communicate data. In such a situation, the network effect is less pronounced, and measuring market share isn't as important. As long as the service works reliably and meets user needs, I don't think people will clamour to replace them with proprietary solutions.
Having an interface I can just stand up on a port and access locally through multiple different browser options, or even expose to remote if the user wants, and it will be the same across every OS for zero additional shipped library cost, and works in every programming language, is an amazing thing.
For RDP, clients are easy to come by (but not ubiquitous), but the server side tech is limited, and generally OS based and not application provided.
For VNC, client and server tech is easily available as a library to all, but it's still an additional layer on top of your application which you need to layer on and then communicate as a separate step to any client that needs remote access.
I'm not familiar with views, but I'm not sure how it could be any easier to use than VNC without limiting where it can be easily deployed.
Opening a port and taking a few commands is simple. There are myriad libraries to help handling requests, and in some languages rolling your own is a matter of tens of lines. The client requires nothing that every person that would want to use it doesn't already have, and if you want to support remote access, you literally just change the interface you bind to from localhost to 0.0.0.0 or the actual IP address. All additional firewall config is something you would likely have to deal with in every other technology as well.
Now, don't get me wrong, I'm not saying this is the best UI paradigm to target. There are many things better about specific UI libs, but none of them can even come close to the cross platform capability and simplicity of just using HTTP+HTML. Do I want major applications delivered this way? No. Do I think it should be the ultimate choice for most programs that have time and resources to do otherwise? Probably not. Do I appreciate that I can write a Perl/Python/Rudy/JavaScript script and package it with its runtime or ship as a script (or just use a compiled language) and it will just work on basically any platform I'd want to run it on, and a client (browser) exists for everything someone would want to use to configure it? Hell yes.
Web apps are still the most secure platforms to date, nothing widespread really came close in terms of sandboxing & safety.
There's a reason everybody asks you to download their native app, tracking is much easier there.
No one asks you to download native apps for desktop platforms, unless it is some Electron garbage for whatever reason, usually for stuff that is available to PWAs anyway.
All ask for native apps on mobile, because development just sucks less.
Whatever, it is great that people believe Web apps are so safe with their data, more fun when creating analytics rules.
They are not ephemeral. They are far more persistent than anything you could install locally, because all the data now resides on someone else's computer. The "ephemerality" paradigm of web apps has been a strong contributor to that trend.
There's such a small number of people who have written their own pieces of visual web client technology, and an uncountable number who consume it.
I've entertained the idea of writing a partially compliant web browser and releasing that for fun. It's still totally possible to write your own web browser today.
You will of course need to put in effort than an exceptionally small number of people have, and even after you do that, you'll only have something partially compliant. But it will be valid!
Hell, you could build an HTML5 valid web browser that didn't even use CSS. Invent your own thing. Make JSON style sheets or something.
Anyway. We don't have enough people toying around with web tech. For years, I've only ever seen people toy around with the easy. Things like making little web clients to help you with API requests instead of turning to curl, or rehashing a CSS framework for the nth time.
And frankly it's sad to see because its so uninspired and boring.
Where are the people creating basic web browsers that use C# as a programming language instead of JavaScript? Or people inventing a new hypertext markup language as an alternative to HTML that still uses HTTP as a transport protocol?
It all works great, right up until the moment you have to interop with another language/runtime that doesn't understand your bespoke async. Callbacks (and layers over them such as tasks/promises) are uglier and necessitate opt-in async, but you can interop them to anything that speaks the C ABI.
Having everything switch to blocking and have to start using mutexes and other multithreading primitives would be a giant change to the language.
Edit: I’m mistaken because now it also blocks the event that would be able to toggle the while condition.
Apparently they are. How disappointing, I really like how useful they are for quickly getting something working and maintaining a consistent and expected experience for the user.
Will they just remove the API (so a JS error) or will it default to "no"?
Here is a list of issues I often have with JS-based alternatives that do not exist with alert/confirm/onbeforeunload:
- the escape key does not close the modal
- tab focus is not restricted to the modal
- the modal is not properly announced by screen readers
- the positions of confirm and cancel buttons differ across sites, leading to misclicks
- the modal is not or very hard to use on mobile
So in a way I agree with you: there might be more user friendly solutions. But the average alternative that people come up with will be worse, not better.
In your opinion, what's terrible about these from a UX perspective? Is it just the styling or something else?
The alternative to a default confirm prompt is going to be someone including Bootbox in their site, which I'm not sure how that's much better
I use alert, confirm and prompt a lot because it's the simpler way to notify the user, ask for confirmation or ask some input that just works, in all browsers, with vanilla JavaScript, without having to code any CSS (that I hate), or including huge frameworks.
They are used extensively in all enterprise software, where you don't need to be fancy but need to produce something that works reliably.
Removing them to me is a terrible idea. More terrible if there are not alternatives to these, yes there is the dialog API that is supported only by Chrome, and it's not as simple as the good old alert, prompt or confirm functions. And we know that in the enterprise world we would have to wait years to have all the browsers compatible with new APIs, there are still a ton of people that uses Internet Explorer...
By the way this is a so big breaking change that to me would require a new version of HTML entirely. To the point where the browsers if they encounter a old HTML document they keep the old behavior. But they removed the DTD with HTML5 leaving just <!doctype html> that to me was a terrible idea.
The original proposal of the author of that issue is to use NotificationAPI but that is not supported in IE. And a lot of web apps in B2B are extensively using alert and confirm.
I feel this is a solution for websites abusing this feature that will cause a lot of maintenance effort spent in a lot of legit applications.
Here is a better alternative (of course with a lot of drawbacks that I cannot think now in 5 minutes): make the dialog timeout after a period by default. When timing out the dialog disappears without any action/change happening in the rendered page.
Here’s a non-exhaustive list of breaking changes to the web platform:
---
8 points by buu700 on Aug 17, 2018 | parent | favorite | on: OpenPGPjs has passed an independent security audit
We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP.
Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive! [Narrator: They didn't.]
That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are:
1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever.
2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance.
All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
Although i guess im kind of surprised that worked. I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked (?) Seems like a bad failure case that could just happen without anything makicious going on, but maybe i just dont understand how service workers work well enough.
I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked
Well... that did actually happen on occasion, although IIRC it was considered to be an edge case browser bug in the ServiceWorker and/or Persistent Storage implementations rather than expected behavior, since the locally installed worker shouldn't have been wiped before its replacement had been successfully fetched. We had to set up a support page with instructions to unpin the keys through about:config / chrome://net-internals, which wasn't really ideal. (Both browsers did end up actually fixing this, not that it ultimately did us much good.)
It requires a rather curious definition of “breaking change” to consider this one.
> A̶r̶r̶a̶y̶.̶p̶r̶o̶t̶o̶t̶y̶p̶e̶.̶f̶l̶a̶t̶t̶e̶n̶ ̶b̶r̶e̶a̶k̶s̶ ̶M̶o̶o̶T̶o̶o̶l̶s̶ renamed to Array.prototype.flat
That doesn’t belong in the list at all; it’s a prime example of the platform bending over backwards to avoid a breaking change, for better or for worse (it means that future users are stuck with an inferior name, see also contains which got renamed to includes because of, if I recall correctly, MooTools again).
It's <plaintext> which basically means "stop parsing for rest of the page". There's no way to close the tag. It's super easy to implement which is probably why it's still around.
Deprecated 28 years ago in HTML 1.1, yet still supported in all major browsers. Test page over here: http://9ol.es/TopLevel/example.html reference rendering: http://9ol.es/tl.png
There's some modern timing issue in chrome I think, it's intermittent Looks like there's a bug.
My original post on the hack, blowing off the cyber dust from 2014: https://news.ycombinator.com/item?id=7850301
I'll have to check the blink source whenever I have some free time. There's probably a strange way around it (for instance, maybe convincing the browser it's a really old website and it reverts to the traditional policy for compatibility or perhaps maybe there's another strange old feature I can leverage, I dunno I'll have to check). And yes, I know this is just pure theater and it's completely useless, I still want to do it well!
You can change the box colors at the bottom of the site :)
I don't understand how e.g. reddit allows text-as-images when that is discriminatory for people with eyesight issues.
https://caniuse.com/?search=blink
thanks, caniuse!
Dear Mr. Software Developer, as you might know all useful software now runs on the web. Writing a web browser is no small task, this is why at Google and W3C we pride ourself in growing our spec beyond any reasonable proportions to make sure you don't try to create a competitor to render a simple HTML5 page. After all, why would you?
Fixed that for you. It’s not being reconsidered; The Chrome team makes decisions for the web whether you agree with them or not. They might pull the “proposal” only to just do it again later. [1]
More context on the same blog [2]
1: https://www.quirksmode.org/blog/archives/2017/09/chrome_brea...
2: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
IMHO the argument on the blog mischaracterizes the situation - Chrome didn't break these properties but changed how they're interpreted under pinch-zoom. This was done precisely to keep backwards compatibility (on desktop browsers): at the time, the vast majority of pages assumed pinch-zoom can't happen on desktop (something that was becoming more common). The status quo meant zooming in on a desktop page would cause it to "swim" as various "fixed" elements shifted around, JS drop-down menus appeared in the wrong place, etc. This happened virtually everywhere one looked: facebook, twitter, apple.com, etc.
The blog basically argues for "make pages fix themselves" which, even if major sites do, is unrealistic in the long tail.
> They might pull the “proposal” only to just do it again later
It's not nefarious, this often happens in response to feedback and real world experience to try and minimize disruption. In this case, developers convincingly argued that there should be an API to better react to pinch-zoom before making the change.
There's more in Intent to Remove: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
--- start quote, emphasis mine ---
We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal
--- end quote ---
It ought to be a lot easier than this detective-work to discover this plan. Like, we should probably all know about it, and stop using these user-agent modals now working to replace all use of them?
(rails-ujs, for instance, still uses window.confirm for opt-in "are you sure" on form submissions. not sure what a good replacement is honestly. This is something I would hope to see people discussing and figuring out...)
The author could have used the date relative view. 8 years (implemented in all major browsers 2012, deprecated in 2020) is not short-lived in my book.
that being said, this post definitely strikes a chord with me. instead of adding a new index of deprecated features, it think it speaks more to the fact that caniuse needs to rethink how they approach deprecated features.
Edit/correction: Core JS 1.2 was Netscape Communicator 4.0, which was in beta in 1996 and launched in June 1997! (The 4.0x series was still pre-ECMA, as opposed to the 4.x series.)
I'm guessing that the depreciation of HTML imports is why they don't work anymore.
You may find that the component does still work in Firefox (which never implemented the stuff that Chrome eventually removed, and for which Polymer included polyfills).
Also, my hobby horse: HTML imports were removed, not just deprecated (or depreciated). Two (three!) very different things.
It was a bad situation which I hope is never repeated.
"We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome."
So chrome just changes it. And then officially applys for the spec change, so other browsers might follow - or not.
I mean, why pretending at all, that you care about the spec, when you are fat monopolist?
This is how the spec process works:
1. You find out if you want to implement something
2. You find out if others want to implement something
3. You implement your something (for simple things in a testbed for complex things as an experimental change over multiple development versions)
4. You demonstrate the something works
5. You demonstrate others are intending to ship as well (For complex things you may have to wait until others are comfortable with their working implementations)
6. If you had a bad experience and many discussion points in 4/5 you go back to 4 and refine until you had a good experience and your spec is merged.
You imply the Chromium authors went 1, 3, ship because you read about step 1 happening. In reality they consulted with Firefox and Safari prior to merging code into the codebase or simply lobbing a spec proposal over the fence. https://github.com/whatwg/html/pull/6297
For me, that comes a bit out of the blue - and seems to be a "making facts" attitude by chrome, not discussing things.
Also canistilluse makes no claim about whether the deprecation matches standards or not. For reference the standards change was actually approved back in February, per the link in my above comment, so it is actually according to standards.
So whether or not you can still use it today, the bigger question is will you be able to use that website 10 years or longer into the future? Because any book ever printed can still be read today (assuming you know the script and the language it was written in), I think the longevity of the web will top out at a couple of decades at best before the digital termites and worms will consume the devices that could have rendered the content you are interested in.
Plain ascii text will likely live the longest, with markdown as a good second. Anything that executes will likely simply die.
Kinda obvious that the browser you get from the ad company for free is not for you if you do not like ads.
This still makes problem with old apps.
I'm also of the opinion that chrome devs should first try to write a "javascript for absolute beginners" tutorial before giving sage advice what such a tutorial should teach and what it shouldn't.
... though I can sort of understand the viewpoint. From a browser developer's PoV, you could probably never be too early in teaching about the event loop, promises, callbacks and async/await. Except that this seems at odds with how programming and JS is actually learned by users.
This reminds me a bit of the Java language design, where you're in theory supposed to understand classes, objects and static methods before you can even write a "hello world" program.
The main reason is the gigantic size of the web and the state most of the web is in. Unmaintained. There's no team to update anything, so you're purposefully breaking the web.
If alerts were as common as notification permission requests, it would be absolutely infuriating.
Disabling notification requests is a simple browser setting and I haven't even bothered with it. If alerts were as common as notification requests, I'd do whatever it took to disable them.
But currently browsers are Katamari Damacy balls endlessly accumulating more and more code. How long can we keep just adding without removing anything?
What you're suggesting is an archivist's nightmare.
Not to mention the breakage and work effort during such change periods.
Browser makers have declared they’d like to remove them altogether: https://github.com/whatwg/html/issues/2894. But they’re too popular to remove under current policies unless they’re really causing harm, and I do believe there’s serious risk of them classifying it that way. (They’re actually a bit of a maintenance burden, as three of the few remaining synchronous things.)
Remember also the big difference between deprecation and removal. I’d go so far as to say I think it’s likely that alert/prompt/confirm will be deprecated and produce console warnings in at least one major browser before four years pass, though I don’t believe they’ll yet have justified going ahead and removing it.
The post is by a random dev who doesn't work at a browser, and it was closed by someone who does after they said they don't deprecate things unless they plan on removing them.
> I figured it deserved some more implementer input especially since there seems to be interest in removing them eventually
It’s not spelled out clearly, but I believe from what I’ve seen of processes there and from what I’ve read elsewhere that he’s talking about implementer interest rather than just-anyone interest. Consider also how Chromium actively gathered usage statistics and Firefox wants to, which you only do if you want to remove the thing.
They definitely want to remove it altogether, they just don’t reckon it’s feasible at this time, and it’s definitely not a high priority for them.
There are other sources, most likely to be found in previous discussions on HN of this rough topic, but regular search for this stuff is just about impossible now because it’s been drowned by stuff pertaining to the block in cross-origin subframes.
(bryik and anonydsfsfs have now found better citations, refer to their comments.)
https://github.com/whatwg/html/issues/6897#issuecomment-8857...
there's also another reply to the parent with a link to the chromium issue tracker confirming this
In fact, almost every argument for their removal seems to be made by the same person. There doesn’t seem to be any other evidence of browse makers having consensus on this.
https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
Can’t remember being harmed by an alert() since forever. Last time was probably six or seven years ago when pop-under ads where still a thing.
Last I checked, frame sets have been deprecated for something like a decade, but they still work fine.
It seems like deprecation on the web really just means "if you're new here, know that this is considered bad practice now and we're only listing it for completeness"
CanIUse should just color these deprecated features in orange, meaning "it works but don't use it".
The very browsers that pushed that change founded Let's Encrypt to provide free certificates prior to pushing sites towards HTTPS. That's the opposite of a profit motive. There are also more free alternatives like ZeroSSL since.
To be clear, what I mean is that forcing HTTPS-only is something that is required by profit motivated corporations. They see the potential risk of an HTTP downgrade attack as being enough motivation to completely kill HTTP. And unfortunately even Mozilla is going along with it. HTTP has it's place for human persons and human person run sites. It allows free communication without having to exist only on the whim of some CA or your mega-corp browser's decision if your cert is too long, too short, or too something.
I did not mean that the founding of LetsEncrypt was profit motivated. LetsEncrypt is good for what it is. But forcing HTTPS and not allowing HTTP at all is very, very bad for the web. Especially since cert CA usage follows a powerlaw like normal and nearly everyone centralizes in LetsEncrypt.
Why has google (via lighthouse and pagespeed insights) been pushing webp so hard if it has only recently gone majority green?
This will break tons of stuff. What's the recommended replacement?
* use of geolocation & crypto APIs on http hosts
* websql
* changes in how browsers provided accelerometer data
* multipart/x-mixed-replace
Also the thread itself talks just about iframe alerts.
I am automatically suspicious of web techs not supported by Safari.