Earlier quoted context omitted.
> Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense. There are many, many cases of porn websites breaking the law.
Yes - writing PHP in 2024 is a crime that we should hold PH accountable for.
JavaScript Bloat in 2024
171–180 of 266 posts
Re: JavaScript Bloat in 2024
#172Any piece of software reflects the organization that built it. The data transferred is going to be almost entirely analytics and miscellaneous 3rd party scripts, not the javascript actually used to make the page work (except for the "elephant" category which are lazy loading modules i.e. React). Much of that is driven by marketing teams who don't know or care about any of this. All devs did was paste Google Tag Manag…
google tag manager is the best tool for destroying your page performance, previous job had google tag manager in the hands of another non-tech department. I had to CONSTANTLY monitor the crap that was being injected in the production pages. I tried very hard to get it removed.
Re: JavaScript Bloat in 2024
#173What's up with the React site? This is embarrassing...
Re: JavaScript Bloat in 2024
#174Earlier quoted context omitted.
I live in London which typically gets great signal everywhere. Except in the Underground network, where they're rolling out 5G but it's not there yet. Please Spotify, why do I need to wait 30 seconds for the app to load anything when I don't have signal? All I want to do is keep listening to a podcast I downloaded.
i will never understand what all the people on the tube are doing on their phones with no internet, do they have the entirety of youtube bufferred XD?
Well, with Youtube Premium you can actually download videos in advance and watch them on the go w/o Internet access required.
Re: JavaScript Bloat in 2024
#175What's up with the React site? This is embarrassing...
Maybe they forgot some `memo` so it re-renders everything including iframes all the time.
2) Rather, we intentionally unload interactive editor preview iframes to improve memory usage when you scroll away from them. We do load them again when you scroll up — and normally that would be instant because the code for them would get cached. But the author has intentionally disabled cache, so as a result they get arbitrarily high numbers when scrolling up and down.
Re: JavaScript Bloat in 2024
#176The React site part of this is not real. The author ticked "Disable cache" which means the same code (which powers the interactive editable sandboxes they're scrolling by) gets counted over and over and over as if it was different code. If you untick "Disable cache", it's loaded once and gets cached.
Re: JavaScript Bloat in 2024
#177Earlier quoted context omitted.
No. Native apps are not exempt from this either. Nothing justifies the bloat
are you deliberately not getting the point for some reason? How big is considered bloated in native apps, how big can a native app can get before it hurts accessibility because people cannot download it? Is it a few MB? Web apps are soon going to be if not already matching native apps in terms of complexity yet we are still distracted from the real problem and quibble about some arbitrary and frankly pathetic code si…
I'd say if it takes more than 50 megabytes to display a list of text, it's a problem :)
> yet we are still distracted from the real problem
Yes, I agree, "how broken the entire web stack" is the main problem. And the ungodly amounts of javascript you end up for the simplest problems is the symptom. However, neither caching nor PWA are the specific main problems in the web's brokenness :)
Re: JavaScript Bloat in 2024
#178The React site part of this is not real. The author ticked "Disable cache" which means the same code (which powers the interactive editable sandboxes they're scrolling by) gets counted over and over and over as if it was different code. If you untick "Disable cache", it's loaded once and gets cached.
Yeah but once per page, which is why it is okay to disable cache as the author wanted to simulate a cold load of each of those pages.
The only case when this code gets loaded is the literally the first cold load of the entire site — and it's only used for powering live editable interactive sandboxes (surely you'd expect a in-browser development environment to require some client-side code). It doesn't block the initial rendering of the page.
What is the problem?
Re: JavaScript Bloat in 2024
#179Earlier quoted context omitted.
Your editor downloads a 32.6MB ffmpeg WASM binary on every page load. Throttling the network to "Slow 3G", it took over four minutes of a broken interface before ffmpeg finally loads. (It doesn't cache, either.) A port of the Audacity audio editor to web[1] with WASM takes 2.7 minutes on the same connection, so the binary is totally reasonable, but I think claiming less than 2 MB is disingenuous. [1]: https://wavacit…
Sorry for that, we just focus on js bundle and don't realize how big the ffmepg.wasm is. Thanks for reminding, next step we will try to rebuild ffmepg.wasm and make it smaller.
Re: JavaScript Bloat in 2024
#180Earlier quoted context omitted.
> But for something like pornhub? Well PHP serves them just fine, Kind of fun to make this argument for Pornhub when visiting their website with JavaScript disabled just seems to render a blank page :) > how many people still vastly prefer the old.reddit.com site to their modern SPA Also a fun argument, the times I've seen analytics on it, old.reddit.com seems to hover around/below 10% of the visitors to subs. But I…
There might be a legal requirement for them to make sure you accept the "I'm 18" dialog before displaying anything.