News for hackers. Stuff that matters.
Re:Alan Kay on “Should web browsers have stuck to being docu... by zelphirkalt on Sunday January 08, 2023 @07:19PM (#34305010)
Incredible, but also incredibly wasteful. Often websites send our CPU fans spinning for stuff, that should not even wake up a CPU fan. In that regard the browser ecosystem needs to seriously lose weight. We have more powerful machines than ever, but we are wasting their potential to no end with fat bloated web apps.
Re:Alan Kay on “Should web browsers have stuck to being docu... by agumonkey on Sunday January 08, 2023 @07:23PM (#34305049)
Maybe there will be a W3C spec for perf profiles. No js, no dynamic css, PDF life interactions. Maybe that is stupid, but with that information your browser can go into a different, near zero power, mode.
Re:Alan Kay on “Should web browsers have stuck to being docu... by KronisLV on Sunday January 08, 2023 @07:31PM (#34305131)
Didn't Google's AMP project set out to achieve something similar? https://en.m.wikipedia.org/wiki/Accelerated_Mobile_Pages (albeit as a bit of a walled garden)

Personally I almost wish that the majority of sites out there didn't pretend like they need to be highly dynamic, interactive and inevitably wasteful experiences.

Re:Alan Kay on “Should web browsers have stuck to being docu... by dmitriid on Monday January 09, 2023 @04:31AM (#34308462)
Google's AMP project was Google's weapon against Facebook's instant news or whatever it was called.

It had nothing to do with a quest for better performance. It had everything to do with ad impressions.

Re:Alan Kay on “Should web browsers have stuck to being docu... by 1vuio0pswjnm7 on Monday January 09, 2023 @05:54AM (#34308987)
As it happens, AMP pages look great in the text-only browser I use and are also an easy solution to many "paywalls". (The text-only browser does not autoload resources, run JS or process CSS.) Even without a browser, it is easy to request AMP pages using a command line utility, extract strings enclosed with "<p></p>" and produce an even smaller, readable web page with no ads.
Re:Alan Kay on “Should web browsers have stuck to being docu... by KronisLV on Monday January 09, 2023 @07:35AM (#34309630)
> It had nothing to do with a quest for better performance. It had everything to do with ad impressions.

Why not both? Even if the former was the "public justification", AMP pages still performed better than bloatware-ridden websites that otherwise took 2-10 MB to load, not even mentioning the amounts of JS and the impact of it on performance, especially on mobile devices (as well as batter usage on those).

Re:Alan Kay on “Should web browsers have stuck to being docu... by dmitriid on Monday January 09, 2023 @11:00AM (#34311803)
> not even mentioning the amounts of JS and the impact of it on performance

The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page.

A cold start for AMP was barely better than most of the top sites that used it.

It was cheating, pure and simple.

Edit: IIRC it was also preloading the entirety of the search carousel, too. And you could get into the carousel only if you had an AMP page.

Re:Alan Kay on “Should web browsers have stuck to being docu... by KronisLV on Tuesday January 10, 2023 @02:37AM (#34321677)
> The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page.

I wonder what he actual metrics are for how often that was used, what % of people chose one of the AMP results, because those were at the top of the list. That preloaded data might be common for most of AMP pages, which is much better than the mess of each site having different React/Angular/Vue bundle versions or even jQuery versions back in the day.

As a thought experiment, I wonder how much we could save on bandwidth, if all of the "popular" frameworks/libraries split their base code from each individual application's code (we already have code bundling, after all) and browsers included all of those packages of base code, preloaded.

Maybe even follow SEMVER as close as possible, so the browser can always ship the latest minor/patch release for a given major release, to cut down on space needed in the browser.

Something along the lines of:

  <script src="/browser/react@18"></script>
  <script src="/js/my-app-react-bundle.js"></script>
Whereas another app that needs an older version could use:

  <script src="/browser/react@17"></script>
  <script src="/js/my-older-react-bundle.js"></script>
And if you don't want to participate in such an initiative (or really want a custom version), you could always make sure that your web server serves the "/browser" directory itself.

After all, browser install sizes are already horribly bloated, a few dozen MB will hardly matter at this point, whereas each site needing 1-5 MB of JS is absurd, especially because those are re-downloaded for each of them, despite the fact that most sites out there use one of like 3-5 popular solutions.

Re:Alan Kay on “Should web browsers have stuck to being docu... by CyberDildonics on Sunday January 08, 2023 @07:29PM (#34305104)
That's not the fault of the browser ecosystem. Give people a real programming language and they will create terrible bloated software with it.
Re:Alan Kay on “Should web browsers have stuck to being docu... by layer8 on Sunday January 08, 2023 @07:56PM (#34305350)
There could be a standardized execution speed. Similar to the home computers of old, and video game consoles, developers would then have to make do with the fixed performance afforded by the platform.
Re:Alan Kay on “Should web browsers have stuck to being docu... by scarface74 on Sunday January 08, 2023 @07:50PM (#34305304)
Speak for yourself. I run a very battery efficient browser - running on a very efficient processor architecture that gets 10+ hour battery life that I don’t think I’ve ever heard the fan once - an M1 based MacBook Pro 16 inch.

My wife has a MacBook Air that doesn’t even have a fan.