build script combining all js and css files before packaging about youtube HOT 4 OPEN

it's just general context: we don't know all our code;

I mean its right there, you can just read it all in one-two sittings :-). Im at ~30% at this point by only reading stuff related to rewrites or bugs I go over.

many JS features (in a browser) can either run async

Not necessarily buys us anything, or even makes stuff worse. Sure we can call everything inside ImprovedTube.ytElementsHandler asynchronously - this will give browser time to draw stuff it wants to draw first just to immediately trigger costly repaint. By changing elements as they are being added to html (by youtube.com /desktop_polymer.js) most(all) are changed in flight before first painted.

& we might want to draw & test our little dependency graph. (All of which doesn't directly relate to split files)

https://www.youtube.com/watch?v=y8OnoxKotPQ

but yes, there are still horrible race conditions. Every time I see a workaround with setimeout its another problem :( Or that Firefox bug #2242 #2137 (comment) where autoplay was called before we grabbed player. There are still little gremlins like that hiding in the code, working only by chance and sheer luck.

Can you show me a working implementation of this in the wild?

webpack?

higher load time so opposite effect, we actually need most of the stuff being loaded, gating it behind async load just shifts where the delay happens. Pushing more work to client side is always nonsense when choice is that or doing the work offline while packaging.

• Our extension.inject-function (and the commented out version below it) only went live in version 4.0,

It looks like extension started with all the code in Isolated execution context, stuff that now lives in \js&css\extension\ , but later someone decided to keep piling more stuff injected directly into page (whats now in js&css\web-accessible).
My uneducated not really supported by any evidence guestimate is at least half, if not all of it, can be moved back to Isolated world removing most/any need for manual injection and waiting. Moving everything back to World:ISOLATED would also remove the need for sending whole config to just injected scripts. I dont know if we need any code running in MAIN at all at this point (having read ~30% of codebase).

So we can make it more performant/async, loading stuff conditionally only (features being enabled.)

doing more work, especially in js, is almost never faster

• Or the build script can remove it along with the concatenating (while it could stay for testing without building)

build script wouldnt remove anything, but compact it into one file making extension.inject one fast operation instead of synchronous chain.

Another thing. Chrome supports World: MAIN. This:

  "content_scripts": [ {
	  "world": "MAIN",
	  "js": [ "js&css/web-accessible/core.js", "js&css/web-accessible/functions.js", "js&css/web-accessible/www.youtube.com/appearance.js", "js&css/web-accessible/www.youtube.com/player.js", "js&css/web-accessible/www.youtube.com/themes.js", "js&css/web-accessible/www.youtube.com/playlist.js", "js&css/web-accessible/www.youtube.com/channel.js", "js&css/web-accessible/www.youtube.com/shortcuts.js", "js&css/web-accessible/www.youtube.com/blocklist.js","js&css/web-accessible/www.youtube.com/settings.js", "js&css/web-accessible/init.js" ],
	  "matches": [ "https://www.youtube.com/*" ],
	  "exclude_matches": [ "https://www.youtube.com/audiolibrary/*", "https://www.youtube.com/tv*", "https://www.youtube.com/live_chat_replay*" ],
	  "run_at": "document_start"
   }, {
	  "css": [ "js&css/extension/www.youtube.com/styles.css", "js&css/extension/www.youtube.com/night-mode/night-mode.css", "js&css/extension/www.youtube.com/general/general.css", "js&css/extension/www.youtube.com/appearance/header/header.css", "js&css/extension/www.youtube.com/appearance/player/player.css", "js&css/extension/www.youtube.com/appearance/details/details.css", "js&css/extension/www.youtube.com/appearance/sidebar/sidebar.css", "js&css/extension/www.youtube.com/appearance/comments/comments.css" ],
	  "js": [ "js&css/extension/core.js", "js&css/extension/functions.js", "js&css/extension/www.youtube.com/night-mode/night-mode.js", "js&css/extension/www.youtube.com/general/general.js", "js&css/extension/www.youtube.com/appearance/sidebar/sidebar.js", "js&css/extension/www.youtube.com/appearance/comments/comments.js", "js&css/extension/init.js" ],
	  "matches": [ "https://www.youtube.com/*" ],
      "exclude_matches": [ "https://www.youtube.com/audiolibrary/*", "https://www.youtube.com/tv*", "https://www.youtube.com/live_chat_replay*" ],
	  "run_at": "document_start"
   }]

Instantly automagically injects /web-accessible/ leaving \js&css\extension\init.js to flat out just call

extension.storage.listener();
extension.storage.load();

and \js&css\extension\core.js:

extension.storage.load = function () {
	chrome.storage.local.get(function (items) {
		if (chrome.runtime.lastError) {
			return reject(chrome.runtime.lastError);
		}
		extension.storage.data = items;
...

		extension.events.trigger('storage-loaded');
		extension.messages.send({
			action: 'storage-loaded',
			storage: items
		});

		extension.ready = true;
		extension.events.trigger('init');
	});
}

TLDR no waiting for injection, just start running as soon as chrome.storage.local.get callback executes. Sadly as I mentioned somewhere else Firefox just implemented it 29 days ago, but afaik not shipped in 127.

• Or we can come up again with a single file / index again for everyone, that's easy to navigate with ctrl+F or so.

more work refactoring everything

• CSS: Our storage-loaded event: unlike for each ... setAttribute, we could add settings as a string of classes to the ( need not add it- and replace _ either)

there is no CSS loaded event (thankfully!), its all handled by browser now.

	"content_scripts": [
		{
			"all_frames": true,
			"css": [
				"js&css/extension/www.youtube.com/styles.css",
				"js&css/extension/www.youtube.com/night-mode/night-mode.css",
				"js&css/extension/www.youtube.com/general/general.css",
				"js&css/extension/www.youtube.com/appearance/header/header.css",
				"js&css/extension/www.youtube.com/appearance/player/player.css",
				"js&css/extension/www.youtube.com/appearance/details/details.css",
				"js&css/extension/www.youtube.com/appearance/sidebar/sidebar.css",
				"js&css/extension/www.youtube.com/appearance/comments/comments.css"
			],

• VS: we could have simple css in an array too (as we said before,) to reduce css and where we want convert the logic/dependencies to JS (lines of CSS which check two toggles),

browser does it much better internally

• while the complete themes can be split each in another file loaded conditionally, so that all usage will be free of all their code (except at most one). (yet the file can also be shortened a lot

sound good in theory, but javascript routines rarely if ever can beat browser executing native code. All the themes take maybe 100KB of ram. The only problem with themes and CSS in general now is relying on attributes by value (CRIME!), those make CSS cpu heavy. Instead of it-theme=black we should switch to it-theme-black or even lighter styles on body <body class="it-theme-black">
Those are crimes of the highest order: https://github.com/search?q=repo%3Acode-charity%2Fyoutube+*%5B+language%3ACSS+path%3Ajs%26css%2Fextension%2F&type=code
Still we are talking maaaybe single digit percentage CPU utilization on one core with modern CPUs :) Maybe on something like crappy ARM/Atom/Pentium Celeron N Chromebooks it would make the slightest difference battery wise.

• While it will be good to support ublock/adblock rules sooner than later, which look similar to our css, and they are licensed free, we should compare what they do already.)

Thats what uBO is for :) plus most third party browsers started incorporating their own blockers in anticipation of MV3.
I would seriously steer clear of any blocking when dealing with Youtube.

IO

While splitting code in files can results in random reads costing ~0.1ms per file (or ~10ms for HDD), which means reading ~50kb less in the same time (or ~1mb for HDD) for each that is not on the same sector nor in swap or the storage device's cache or the SSD's SLC) - Extensions size isn't limited, so we should check if browser's still won't cache every extension's code (up to x MB), or else editing their code). ( - Or we could build every user's personal extension in the 10mb database quota storage.local after every change of settings. Since at least those <= 10mb should be faster/cached already, yet otherwise Database can consume more IO )

its not the fetching that is slow, its the javascript doing the fetching. Changing to asynchronous javascript wont make it any faster.

webpack makes some sense ONLINE when instead of loading x-xxMB x.js file over wifi\mobile one can load thin shim and start executing something unrelated either while rest of that x-xxMB loads in the background, or sacrificing latency for async fetching on demand. https://tonsky.me/blog/js-bloat/
But extension is local, we dont care about that, what we do care about is this stupid synchronous loop in js&css/extension/core.js
In Firefox loading random YT clip the first js&css/web-accessible/core.js is injected right at the top, while
last js&css/web-accessible/init.js is the last node in HTML document injected long after whole thing loaded. This means there is a high chance browser already started executing YT javascript before our js&css/web-accessible/init.js runs. Bad for intercepting autoplay, bad for codecs, might even miss some early nodes in ImprovedTube.ytElementsHandler()

from youtube.

build script

👍 (and or we could meaningfully merge some again for everyone )

it has to do this stupid synchronous

why?

loss of git history

(*it's not lost but causing an extra click)

Originally posted by @ImprovedTube in #2391

it has to do this stupid synchronous

why?

stuff in later files relies on stuff declared in earlier ones. Not a problem if combined into one.

Originally posted by @raszpl

or, to make things able to wait for each other, it might not take too many lines of code? @raszpl i mean while easiest, it isn't fully intuitive to merge, when UI & JS often isn't just procedural already, if the loop could pre-load all at once & start each in the right nano second, given each requirement. (if that's right, then the remaining question could be just if many files will cause any significant IO considering the sum of all users, and the few whom might have old, full, worn storage that breaks tomorrow)

Originally posted by @ImprovedTube

or, to make things able to wait for each other, it might not take too many lines of code?

thats how it works now, synchronous waiting for all the files loaded one by one is slow and bad

it isn't fully intuitive to merge

?

type /js&css/web-accessible/core.js > web-accessible.js
type /js&css/web-accessible/functions.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/appearance.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/themes.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/player.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/playlist.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/channel.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/shortcuts.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/blocklist.js >> web-accessible.js
type /js&css/web-accessible/www.youtube.com/settings.js >> web-accessible.js
type /js&css/web-accessible/init.js >> web-accessible.js

in a build script when packaging for release. Source code can stay fragmented.

Originally posted by @raszpl

yes

thats how it works now, synchronous waiting for all the files loaded one by one is slow and bad

, which isn't fully / permanently required. since (ideally) most can run at once, or else wait for a specic event
( thats all i meant @raszpl )

Originally posted by @ImprovedTube

yes

thats how it works now, synchronous waiting for all the files loaded one by one is slow and bad

, which isn't fully / permanently required. since (ideally) most can run at once, or else wait for a specic event ( thats all i meant @raszpl )

Can you show me a working implementation of this in the wild?

Originally posted by @raszpl

from youtube.

it's just general context: we don't know each of our code; many JS features (in a browser) can either run in parallel & we might want to draw & test our little dependency graph. (All of which doesn't directly relate to split files)

Can you show me a working implementation of this in the wild?

webpack?

• Our extension.inject-function (and the commented out version below it) only went live in version 4.0, after we also lost the author, who maybe only wanted to make development easy. So we can make it more performant/async, loading stuff conditionally only (features being enabled.) - Or the build script can remove it along with the concatenating (while it could stay for testing without building) - Or we can come up again with a single file / index again for everyone, that's easy to navigate with ctrl+F or so.

• CSS: Our storage-loaded event: unlike for each ... setAttribute, we could add settings as a string of classes to the <html> ( need not add it- and replace _ either)

  • VS: we could have simple css in an array too (as we said before,) to reduce css and where we want convert the logic/dependencies to JS (lines of CSS which check two toggles),
    otherwise this is only for custom colors (and other theme options we can add, all of which should not disable the previous full theme selected, but just overwrite some of it, being injected after it.)
  • while the complete themes can be split each in another file loaded conditionally, so that all usage will be free of all their code (except at most one). (yet the file can also be shortened a lot

• While it will be good to support ublock/adblock rules sooner than later, which look similar to our css, and they are licensed free, we should compare what they do already.)

IO

While splitting code in files can results in random reads costing ~0.1ms per file (or ~10ms for HDD),
which means reading ~50kb less in the same time (or ~1mb for HDD) for each that is not on the same sector nor in swap or the storage device's cache or the SSD's SLC) - Extensions size isn't limited, so we should check if browser's still won't cache every extension's code (up to x MB), or else editing their code). ( - Or we could build every user's personal extension in the 10mb database quota storage.local after every change of settings. Since at least those <= 10mb should be faster/cached already, yet otherwise Database can consume more IO )

from youtube.

hi! @raszpl Adding any points doesn't mean taking any counter-position in a debate! (+ "webpack?" (several features) was to answer the question unrelated to the thread #2415) )

In Firefox loading random YT clip the first js&css/web-accessible/core.js is injected right at the top, while
last js&css/web-accessible/init.js is the last node in HTML document injected long after whole thing loaded. This means there is a high chance browser already started executing YT javascript before our js&css/web-accessible/init.js runs. Bad for intercepting autoplay, bad for codecs, might even miss some early nodes in ImprovedTube.ytElementsHandler()

👍 this can be documentation for this project as long as it is like this!

Timing:

will give browser time to draw stuff it wants to draw first

async, didn't mean too patient but in parallel

setimeout its another problem :(

( feel free 👍 (https://github.com/search?q=repo%3Acode-charity%2Fyoutube+setTimeout&type=code), besides the one in autoplayDisable() )

Declarative programming

CSS:

Our storage-loaded event: unlike for each ... setAttribute, we could add settings as a string of classes to the ( need not add it- and replace _ either)

no loaded event

*scroll to bottom at #2197

styles on body

yes, i think checking value of CSS attribute will run a few times slower in millions of times per second than checking for classes. How many of each are we running per second yet?

crimes of the highest order: https://github.com/search?q=repo%3Acode-charity%2Fyoutube+*%5B+language%3ACSS+path%3Ajs%26css%2Fextension%2F&type=code

Thanks for caring! Can be adjusted, while these feature's user count might increases

Thats what uBO is for :)

Rule syntax's equal a(/the browser-extension-)frame-work! (also to set JS variables such as YouTube flags.)
or to make universal visual fixes (/additions) https://github.com/code-charity/crowd-fixes.
(old news)
Other projects have a lot of intersection with our CSS (Youtube Unhook and this for example: https://github.com/gijsdev/ublock-hide-yt-shorts/blob/master/list.txt ). So our's could be shorter and contributors of both should work on the same lines /files. Not to be outdated most of the time.
While custom code is only really required for the smaller and more unique half of features.

build script wouldn't remove anything

(yes, would replace the file injection function)

loading stuff conditionally only (features being enabled.)

*(=in the given state it will be a minimal change to only load half the files depending what features are enabled or not. Said to be complete, even if that might remains slower to load at first and the code isn't split optimally for that.)

web_accessible_resources

was added here along with a Manifest3 guide i think:
Dec7 2021 - Migrated to manifest v3 ( "web_accessible_resources":[{"resources": ["youtube-scripts.js"],"matches":["https://www.youtube.com/*"]}], )
more: #2299 (comment) )

it might helps to keep frequently called small files in the browser's in-memory cache (to check exactly)
and use APIs when CSPs might not (music detection code)

custom color ... themes
themes

still wanted to appreciate:

injecting all of them, even not used themes

#2073 (comment)
the case for this is: we shouldn't increase any load for everyone (most users) in favor of one feature (some or few users)
so it could make sense to have a ~15kb file per theme, while the small size makes it more likely to stay in memory.)

IO:

All the themes take maybe 100KB of ram. The only problem with themes and CSS in general now

from youtube.