>wildly underestimate how many engineers work on Chrome.
It is completely insane how many people work on Chrome. It seems like it is time to deprecate web browsers and do something different. Like you get a frame-buffer to draw on with something like a wasm vm. Web pages get replaced by programs (which they essentially are anyway). Get rid of 99.9% of the cruft that has accumulated over the decades in browsers. If you want to have some of that cruft, that is a library you have to send.
Or go the other way and make web pages not programs at all, like they originally were. Unfortunately, just communicating information isn't cool, doesn't monetize, and certainly doesn't get clicks.
The biggest mistake the web ever made was leaving it up to to the website to choose how content renders.
It should be the users choice how their browser renders, it's their damn browser. Instead, browsers are built to follow standards that mostly favor the developers preferences above those of the person who actually own the device rendering it.
If a web browser allows images, then the website always has full control over how content renders. It's the default. HTML and related standards are trying to persuade developers to cede some of that control in the name of accessibility, user choice, searchability, device compatibility etc. that all-image websites lack. But this can only succeed if the developers still can do everything they want to. If they can't, then they'll fall back to images and everyone loses.
A lot of websites back in the 90s were just made up of images that were clickable using image maps. It was not a fun time.
I get what the parent comment is saying, though, and it's why I use Gemini (the protocol[0], not the AI). It doesn't align with corporate interests, but for now I consider that a good thing.
Users want an app platform that 1) works on every device, 2) is 1-click (no app installation / management, click a link and go), and 3) has advanced capabilities which let them easily do the task at hand.
Think "an interactive visualisation for choosing a seat when buying a concert ticket." That's not a "traditional" webpage, should work on whatever device the user is currently on (so native is unsuitable), and shouldn't require the user to install anything.
People clearly want web pages to be exactly this; we're on iteration #3 of the idea now. Iterations 1 and 2 were Java Applets and Flash, not necessarily in that order, and they were massively popular despite their shortcomings. Clearly, if we somehow deprecated the web as it is now (which is an utterly ridiculous idea, which makes me really curious what comments like yours are exactly trying to achieve here), as long as we keep it an open standard, users will choose browsers which offer this capability in some form. We should appreciate that the current iteration is an open standard which anybody is free to implement, instead of some proprietary blob that you need to license from Oracle or Adobe.
So do hackers. A big chunk of the open standards revolve around sandboxing malicious code, and given the amount of tracking happening anyway, fail at it.
This kills accessibility. You wouldn't even be able to select text unless the page implemented that feature itself. Screen readers would have nothing to work with. No high-contrast mode, no translation, no changing the font size, no reader mode........
Unfortunately none of the things you listed are what page vendors want you to have. They'd very much prefer you didn't. On the web, they're just too hard to prevent, so most don't bother.
I think that must be false. Serving the page as a static image was possible from the early days of the web, but vendors (mostly!) moved away from that as features like web fonts became available. I guess Flash was the big remaining exception. And remember Java applets? But even now as rendering to a canvas is possible, enabling animation and interactivity without necessarily including accessibility, websites are mostly not doing that. Accessibility is good for business. And sometimes it's legally required.
Software accessibility is bad for business - that's why it has to be legally mandated. There's no firm difference between "accessible", particularly to screen readers, and "amenable to end-user automation", and the latter is anathema to businesses.
As for the styling and fonts - it's all a bunch of low-key trade-offs here. The businesses want to exercise total control over the end-user experience, for sales/marketing and branding reasons. At the same time, going off the beaten path quickly makes development costs skyrocket.
Flash was a good choice back when all visitors were using a PC and there were like 3 different screen resolutions to choose from. Once laptops gained popularity, this started to shift, then pre-iPhone mobile briefly became consideration, and Flash stopped being sufficient; then iPhone came out, killed Flash, and started an era where every visitor has a different screen than the previous one. "Responsible web" became the cheapest option, and you can see its evolution as a trajectory towards giving more and more control over experience to developers, and less and less to the users.
I'm fine with it being legally enforced. The point is, web site owners mostly wouldn't move to "a frame-buffer to draw on with something like a wasm vm".
> Like you get a frame-buffer to draw on with something like a wasm vm. Web pages get replaced by programs (which they essentially are anyway).
The biggest thing standing in the way of this is actually Apple, since they don't allow competing browser engines or equivalent so you can't make something like this for iOS whatsoever.
Anyone care to guesstimate how much effort there would be in creating an actually-secure curl and openssl? Using something like Common Lisp or Lean, instead of C.
I as skeptical as the next guy when it comes to the claim that ambient audio modulates the fluorescent light. But I could sure use more details on what analysis was done to the photos. Sounds like there were several photos taken, say 100ms(?) apart. Then the photos were subtracted pixel-by-pixel to look at the variations in time (between photos) or spatially (neighboring pixels)? I still think a photo-diode AC-coupled to a high gain amplifier fed into an oscilloscope would be the more conclusive test. Do a audio frequency sweep from 100-10kHz. Both with the fluorescent light on, and then again with the light off (as a control, in case something else in the setup is sensitive to the audio).
I assume the idea is that you're effectively randomly sampling (with each shutter press) that amount of time of the sine wave. You should see a distribution of brightness if there's a signal present, unless you get unlucky and sample at the same brightness (many would be required). Capture many with and without audio signal present, compare std deviation. If they're the same, no signal.
But yes, truly terrible lab report. ;) Who knows if this data is meaningful.
I wonder if the original rumor came from a bulb with a failing ballast, with a "less stable" arc, or maybe with a mic/diaphragm integrated into it, that modulated the light by sinking some current? I always assume these more wizardly things are based in truth.
I suppose I could envision a scenario like: Service A has a "reset your password" option. Someone with a "user@popular-unicode-domain.com" tries to use this option. Normally this fails when mangled-popular-unicode-domain-plus-garbage.com can't be found. Enterprising malicious actor registers mangled-popular-unicode-domain-plus-garbage.com, and now gets a hold of user password reset requests.
I don't think that is a reasonable request for a response to a comment post, but in my experience, many lisp macro advocates come from other procedural / OO languages and aren't well acquainted with other programming paradigms, so they don't generally know what the don't know about other styles, say functional programming, and how to solve problems using higher order functions, etc. instead of reaching for macros. Which is OK. Not everyone has to become a programming language dilettante.
Or you could wrap arguments in lambdas (anonymous functions) for eagerly-evaluted languages. Lisp unfortunately has a bulky syntax for lambdas, compared to something like Smalltalk. Of course, you can fix this with reader macros in Common Lisp (but no one does). Clojure has a shorter syntax I believe as well: #().
The extraneous stuff is honestly fabulous, IMO of course. Just being able to listen to a four part fugue sensibly is a rare but accessible pleasure. And amusing dialogs as an instantiated dialectic for showing the truth synthesized from apparent opposites, is a great pedagogical learning.
It is completely insane how many people work on Chrome. It seems like it is time to deprecate web browsers and do something different. Like you get a frame-buffer to draw on with something like a wasm vm. Web pages get replaced by programs (which they essentially are anyway). Get rid of 99.9% of the cruft that has accumulated over the decades in browsers. If you want to have some of that cruft, that is a library you have to send.
reply