-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
comparing the new-unfinished & old version (any missing code to migrate?) #6
Comments
Two days of staring at this code and its starting to make sense :) Its actually quite logical and pleasant to work with.
I found an indirect way by sending events, calling functions directly or directly manipulating .dataset.value/.storage.value I also found few bugs:
this doesnt seem to work, looks like despite settimeout element is removed() before Event has a chance to reach it. I already have a patch for this almost ready.
the reason for try/catch here is a bug where this function is being called with type = storage-set and data=unknown here https://github.com/code-charity/youtube/blob/7e56c0c0005240da1bc2f9b5aa2a31e527410eeb/js%26css/satus.js#LL1004C1-L1004C45
|
bug 3 fix code-charity/youtube#1676 Still no idea why this functionality is there (why call extension.attributes() every time some option is changed?) :) but at least now its working as it was intended. |
|
just answered in #1634 |
mostlikely, includes some unfinished plans worth noticing. |
If you really want smaller js files (meaningless in case of menu for an extension) you can always minify the release package. Mixing naming conventions just makes code less readable. It adds noise for no gain whatsoever. This code doesnt live in a hot loop of some performance sensitive function, its extension menu - gets executed only when user wants to change options.
1 "need 1ms since JS executes faster than firefox storage" Patch comment is not entirely accurate, settimeout is not a proper fix for race conditions. What is happening here is using async storage function (chrome.storage.local.set in onclick event) and expecting it to take immediate action (satus.storage.get('transcript')). settimeout will help in that case, but not the way one might expect. Its not that you need to wait some magic number of milliseconds for slow storage, its emptying event loop so async functions can complete The problem here is how Satus gui library handles clicking on elements in separate event. Here Appearance/Sidebar/Transcript element has two onclick handlers simultaneously (what I mentioned earlier as "2. Too many verbose click listeners") Im thinking on ways to rework whole thing into something less convoluted. 2 nextSibling.click() is fragile code. Its meant to target "To the side! (No page margin)" and will break next time someone decides to move options around. Better to call by name. |
yes, besides it could be an unlimited ordered collection, when a build script could generally include removal of unused functions. One original thought/reason for Satus was to keep different extension features & GUI maintainable efficiently. Thank you again @raszpl. Looking forward / excited. You probably already solved something else pending since #1439 🤩 |
sorry, the cause was human eyes, not cpu. See here. (The idea there was just to make collaborated code as short as possible. To reduce our (contributor's) time it takes to read it. Increasing cognitive efficency, decreasing overhead. (Underscores are considered overhead by a majority of JS developers. (Yet not for translators maybe. Thats why one could maybe reason to have both. But we dont need to )
👍 good info. (just a hotfix & the intentional UX advantage (250ms delay) could rather be animated.)
🥳🎉 *hyperventilates*
👍 just to make sure you saw the current way this before possibly implementing it well. (Sometimes instead of "check" i should say "btw, just incase...) |
(we agree) the following is bloated to read&remember
Same information, just shortest & logically ordered Optionally another 1 character shorter&tidier for humans (if adhering/phrasing a html UI-templating-Syntax ) (- And whle considering that we can assess/define why&how Satus might potentially be used combined with the predominant JS libs |
Everything is overhead when performance is considered, but here we shouldnt care about absolute optimal code speed because this is not a critical function of this code. This code already works same way on 1GHz Atom laptop as it does on 4GHz desktop to human perception.
Function names and labels arent bloat, there is no point making them smaller for the sake of making them smaller. On the other hand using two naming conventions at the same time is iffy. Finally mixing two naming conventions is bad
with GUI section name matching storage variable name and being used directly as lookup to locale.json. This might require some code changes to https://github.com/code-charity/youtube/blob/ee0de83adb8bc5b5385c9e0ae298a1595648575f/js%26css/satus.js#LL802C12-L802C12 here is one example where someone renamed GUI section without reason btw what are tags ? |
Sorry, while the thread #1211 about codec & dom is pinned, #1634 wasn't meant about computers, only humans.
Humans count/quantify work. If a project will be X% shorter, without decreasing readbility, then editors will be Y% faster & happier. Even 1% matters with many users (+ planning for years, welcoming contributors, ...)
No opinion, didnt start this in our code nor the world!
just has the point of being distiguishable (nearly equally?)
The mentioned point was, the average developer on github. (+the global trend, as around 43% of code on github seems to use camelCase but it is increasing since 2004 in global search interest too. We can repeat & filter GitHub by recent years, so that we assumably see camelCase as the bigger half in all recent code(>50%). (While in javascript it is around 94% allover already. Which is ~30% of all code and also more considering recent years & NPMs )
Consider the shortest versions i mentioned - Only these chars are required, when to be written by humans efficiently (+ most of all GUI templates /html start with mentioning GUI element types before their labels=values) (Not saying we should bother before important bugs 😅 & more urgent /interesting things. Just noting down this topic at all, here in this repo. ) **2. Currently we only have names with underscore for values in GUI, this also appear when there is no translation. Since Users might be less used to camelCase. - i also thought of removing that /keeping one naming convention only. (We can always improve translation & locales later still. While our project might outgrow the rigid extension locales structure anytime like this:
(Can rename old storage names @update-installation in background.js) |
Do you have any links/references to literature on this subject? Im not familiar with the concept. Iv been taught to make code readable and fast, not smaller by reducing size of variables. Why is checkbox/switch .dataset.value a string ('true') while .storage.value a boolean? both represent same data and both should be boolean. What is the relationship between
I see enabling 1 will disable 2, enabling 2 will disable 1, but enabling 3 will disable 1 and enable 2?? I dont understand :) optimize_codec_for_hardware_acceleration needs a list of GPUs with hardware video acceleration capabilities. |
(As of now our code is *mostly using camelCase which is popular among [JS-]developers)
Just a big topic yet (should be a discussion-thread, not an issue)
If #1211 is done well, we might save the average user 3 minutes + $0.2 in electricity per year. just relevant on scale (+ the project is growing). Might also be able to save them some seconds per year if we werent bound to JS.
mmm 🤔 - "editable is the new readable" (- this curriculum literature doesn't seem to be written yet (zero search results!!) - we'll have to start writing it.) ( justification for our PhD-topic: https://trends.google.com/trends/explore?date=all&q=editable,readable,expandable,enhanceable ) White spaces are "cheap readablity" - at the expense of time. One more test: According to this camelCase makes ~ Also, kinda predictably we appear first here: |
Dont know!! BTW here is a slightly related Brainstorming: code-charity/youtube#1685 .. also since you analysed shortcuts issues earlier! :D ( code-charity/youtube#1565 - just sharing my latest thought-process for the project - hopefully not flooding you, but just adding some interesting /innovative perspective. extra motivation. Hopefully we can share some work once /based on special skills/experience (mine isn't JS 🤫😆just yet). ...
Yay, let's go
|
so far my favorite
1 is very ambitious, difficult and fragile. YT changes the page often. I also really dislike convoluted heavy YT dynamic DOM with all those moving parts and everything done with javascript. Layout from before the 2020 change was mostly html, now everything is client side and slow :(((( 2 is ready, needs a list of GPUs with supported codecs.
great :) so I can change it after verifying everything works?
so autoPip should disable 1 and force enable 2? |
hi, are you on Discord? ( https://discord.gg/aHpjrhf )
👍👍
😅
yes, (you might saw 😳 hackademix/noscript#291) (might start with Firefox & offering mobile youtube on desktop. (Also always wanted to bring the desktop sibling of "show desktop site"(mobile browser) as a single-click standalone extension "show mobile site" (no popup menu, just a checkup as extension icon, remembering per sub domain))
|
👍♡ |
1. Sep-2021 : 105kb JS + 22kb CSS
2. Now it is more CSS, less JS. Yet unfinished. This goes in hand with all known bugs:
( what we use live is from ImprovedTube 3.945 August 2022) - None of the bugs appeared before.
(+ 2.1. just removed an old color-picker code, without reviewing changes: f416701 )
8 bugs introduced in the live version: #3
history manager has a version from May 2021 with the mark up working! ( & <textarea> ?)
so we just got to compare this too.
( text markup also works in https://github.com/code-charity/ultimate-REGEX-extension/blob/master/satus.js from september 2021, but there it is minified ...)
More:
satus July18 from ImprovedTube Beta 3.1001.zip
( Inbetween, still almost the same as current / 2023):
( 2. Jan-2022 87kb JS + 37kb CSS Jan2022.zip )
Finally: [oct2022 but again MINIFIED unfortunately.zip] (https://github.com/code-for-charity/SATUS/files/11045240/oct2022.but.MINIFIED.zip) - possibly could also have any good edit, but yet we need an automated way to compared, despite minified. how?
The text was updated successfully, but these errors were encountered: