Combining JS CSS: 1. For developers 2. For performance: build script (can be optional for the extension to run) (Current folders aren't final either but complex /back form a thought of running on m.youtube or all HTMLMediaElements) #2415

ImprovedTube · 2024-06-25T21:54:27Z

advocate for build script combining all js and css files before packaging - this would actually make the >extension load faster. Currently it has to do this stupid synchronous one at time dance

youtube/js&css/extension/core.js

Lines 123 to 143 in 0601bf6

extension.inject = function (paths, callback) {

if (paths.length > 0) {

var element,

path = chrome.runtime.getURL(paths[0]);

if (path.indexOf('.css') !== -1) {

element = document.createElement('link');

element.rel = 'stylesheet';

element.href = path;

} else {

element = document.createElement('script');

element.src = path;

}

element.onload = function () {

paths.shift();

extension.inject(paths, callback);

};

(because we cant load out of order) before It can even load settings

youtube/js&css/extension/init.js

Lines 18 to 22 in 0601bf6

extension.events.on('init', function (resolve) {

extension.storage.listener();

extension.storage.load(function () {

resolve();

});

:(

Originally posted by @raszpl in #2391 (comment)

ImprovedTube · 2024-06-25T21:59:26Z

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

ImprovedTube · 2024-06-26T01:56:31Z

it's just general context: we don't know each & every of our code yet; 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 1. Concatenate some files again for everyone (+with an index in the top again?), since that's easy to navigate with ctrl+F. 2. make extension.inject more performant/async, loading stuff conditionally only (features being enabled.) 3. Then the build script can reduceremove that along with the optional concatenating (and minifying) for stores only.
(So some of all 3 things might make sense)
( Edited paragraph )
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 )

raszpl · 2024-06-26T15:47:34Z

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()

ImprovedTube · 2024-06-28T18:41:23Z

hi! @raszpl I should use structure before posting! (Just collecting 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 please (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.

Code in more than one file:

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)
so it could make sense to have a ~15kb file per theme, while the small size makes it more likely to stay in memory.)
and 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 to be fair and lean an feature used by for example 5% [or 20%] of our users shouldn't "pay for itself" and rather cost 20ms for the 5% of users [or 5ms for the 20% of users] than cost 1ms for 100% of users.

build script wouldn't remove anything

(yes, just replace the file injection function)

IO:

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

more RAM! AND an IOP for opening that file 😀

its not the fetching that is slow, its the javascript doing the fetching.

is it? i like counting /speculating IOPS

( - 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 )

(*..since for every change of settings of an extension, it might runs 100+ times without change. So hypothetically, if one could dynamically rewrite a single script, that could just have a single "big" read every time and a single "big" write for changes only.)

raszpl · 2024-07-04T11:45:11Z

hi! @raszpl I should use structure before posting! (Just collecting 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) )

Im not arguing as much as trying to share what I know :)

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!

dont take my word for it, test test test and verify. Might be my computer or config after all. I just rechecked and this time init.js lands just after HEAD, so it might have been my bogged Browser session. But even after HEAD is too slow - YT JS files loaded in HEAD might have started running at this point.

Timing:

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

~~async~~, didn't mean too patient but in parallel

Browser event loop is non intuitive https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop
What the heck is the event loop anyway? | Philip Roberts
https://jacobosity.medium.com/the-event-loop-b082639a804f
The way I understand it: DOM manipulation is synchronous. Async javascript means browser will throw async stuff that calls browser internal function (like appendChild) on the queue. With current synchronous implementation we have a chance of squeezing our stuff before repaint, with Async JS engine will actually yield to rendering thread and let browser paint before our DOM changes come in. The difference is microstutter when loading vs a flurry of microstutters when async functions all land DOM changes at different times making browser repaint them one by one.

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)
*scroll to bottom at #2197

I only understood that sentence today when rereading :D /slaps forehead/ You meant 'styles on body' which I so "creatively" mentioned later in my post :D

( need not add it- and replace _ either)

imo still need, better to have distinct private class names when injecting into foreign code, it- prefix nicely secures that

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?

You can get some sense of the cost using devtools performance tab, CSS cost is there https://nolanlawson.com/2022/10/22/style-performance-and-concurrent-rendering/

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

its not the feature at fault here, afaik those * are not needed there, but their presence makes those CSS rules super heavy (compared to proper rule)

Code in more than one file:

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.)

who decides which half? and how decides? :) and why decides when if can all load at once? The loading part is not slow, its the 'lets load one by one using js loop'

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)

anything you do in js will be heavier/slower than letting browser just load it all and handle on its own, anything. JS is pretty fast , but its downright pathetic when compared to Browsers native code and internal optimizations.

custom color ... themes
themes
injecting all of them, even not used themes

#2073 (comment) so it could make sense to have a ~15kb file per theme, while the small size makes it more likely to stay in memory.) and 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 to be fair and lean an feature used by for example 5% [or 20%] of our users shouldn't "pay for itself" and rather cost 20ms for the 5% of users [or 5ms for the 20% of users] than cost 1ms for 100% of users.

Afaik themes absolutely NEED to be loaded by the browser and not injected by js to make sure they get applied as fast as possible avoiding annoying black/white flash before actual color applies.

Whole extension when loaded takes 30MB of ram in Chrome/48MB in FF (about:processes), 100KB of Themes makes zero difference in comparison :)

more RAM! AND an IOP for opening that file 😀

its not the fetching that is slow, its the javascript doing the fetching.

is it? i like counting /speculating IOPS

then open devtools and look where js&css/web-accessible/ files are located in the YT html
Browser is able to inject all

				"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"

before HTML is even fetched from YT server, but our manually injected files are injected with huge delay. In Chrome all land after HEAD. In FF and Vivaldi first few somehow manage to squeeze just before HEAD.
If we got rid of /web-accessible/ moving all code to /extension/ there would be no delay, we would be up and running before YT even starts loading from the server.

(*..since for every change of settings of an extension, it might runs 100+ times without change. So hypothetically, if one could dynamically rewrite a single script, that could just have a single "big" read every time and a single "big" write for changes only.)

From what I understand half the point (main is obviously killing uBO) of Manifest V3 is Google fighting with dynamic code execution

ImprovedTube · 2024-07-08T05:48:45Z

hi @raszpl

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

Or an interesting thread: #2459

(*developer-documentation; Firefox is Nr.1 soon. )

CSS

crimes of the highest order: [github.com/search?q=repo:code-charity/youtube+*+language:CSS+path:js&css/extension/&type=code

As long as css processing happens from right to left,
you were right (long ago),, that we should build / inject much css with JS. And add some classes to specific elements later only, if they arent urgent and if the features are rarely used.

https://github.com/search?q=repo%3Acode-charity%2Fyoutube+*%3D+language%3ACSS+path%3Ajs%26css%2Fextension%2F&type=code
( searching for *= as *[... is semantically the same as [... )

Afaik themes absolutely NEED to be loaded by the browser and not injected by js to make sure they get applied as fast as possible avoiding annoying black/white flash before actual color applies.

(mainly background color)

( need not add it- and replace _ either)

imo still need, better to have distinct private class names when injecting into foreign code, it- prefix nicely secures that

Yes (at least in case of extension with similar but different features. And if we will offer to run some of this beyond youtube.com.) While replacing _ can be skipped if we write settings to at all.

extension.inject

Browser event loop is non intuitive developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop
What the heck is the event loop anyway? | Philip Roberts
jacobosity.medium.com/the-event-loop-b082639a804f

👍

Originally just meant to quickily agree in this topic & add that extension.inject could also be smarter (?)
Some of my sleepy content isn't l likely to be understood before the 2nd revision😆 :

(because we cant load out of order) before It can even load settings

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 1. Concatenate some files again for everyone (+with an index in the top again?), since that's easy to navigate with ctrl+F. 2. make extension.inject more performant/async, loading stuff conditionally only (features being enabled.) 3. Then the build script can reduceremove that along with the optional concatenating (and minifying) for stores only.
(So some of all 3 things might make sense)
( Edited paragraph )

ImprovedTube · 2024-07-27T09:28:32Z

(Assignments are not exclusive and mostly wishful)

ImprovedTube mentioned this issue Jun 25, 2024

Refactor: rename js&css directory #2391

Closed

raszpl mentioned this issue Jul 3, 2024

Add ESLint check #2438

Merged

ImprovedTube assigned raszpl Jul 27, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Combining JS CSS: 1. For developers 2. For performance: build script (can be optional for the extension to run) (Current folders aren't final either but complex /back form a thought of running on m.youtube or all HTMLMediaElements) #2415

Combining JS CSS: 1. For developers 2. For performance: build script (can be optional for the extension to run) (Current folders aren't final either but complex /back form a thought of running on m.youtube or all HTMLMediaElements) #2415

ImprovedTube commented Jun 25, 2024 •

edited

Loading

ImprovedTube commented Jun 25, 2024 •

edited

Loading

ImprovedTube commented Jun 26, 2024 •

edited

Loading

raszpl commented Jun 26, 2024

ImprovedTube commented Jun 28, 2024 •

edited

Loading

raszpl commented Jul 4, 2024

Timing:

Declarative programming & CSS:

Code in more than one file:

ImprovedTube commented Jul 8, 2024 •

edited

Loading

ImprovedTube commented Jul 27, 2024

Combining JS CSS: 1. For developers 2. For performance: build script (can be optional for the extension to run) (Current folders aren't final either but complex /back form a thought of running on m.youtube or all HTMLMediaElements) #2415

Combining JS CSS: 1. For developers 2. For performance: build script (can be optional for the extension to run) (Current folders aren't final either but complex /back form a thought of running on m.youtube or all HTMLMediaElements) #2415

Comments

ImprovedTube commented Jun 25, 2024 • edited Loading

ImprovedTube commented Jun 25, 2024 • edited Loading

ImprovedTube commented Jun 26, 2024 • edited Loading

raszpl commented Jun 26, 2024

ImprovedTube commented Jun 28, 2024 • edited Loading

Timing:

Declarative programming & CSS:

Code in more than one file:

IO:

raszpl commented Jul 4, 2024

Timing:

Declarative programming & CSS:

Code in more than one file:

ImprovedTube commented Jul 8, 2024 • edited Loading

Or an interesting thread: #2459

CSS

extension.inject

ImprovedTube commented Jul 27, 2024

ImprovedTube commented Jun 25, 2024 •

edited

Loading

ImprovedTube commented Jun 25, 2024 •

edited

Loading

ImprovedTube commented Jun 26, 2024 •

edited

Loading

ImprovedTube commented Jun 28, 2024 •

edited

Loading

ImprovedTube commented Jul 8, 2024 •

edited

Loading