I've never wrote an article for anything before so please be gentle with me.

Why we made JavaScript

When I first discovered JavaScript, it was called JScript and was as a part of Classic ASP web pages, being as likely to be replaced with VBScript as used. The Web was a pretty boring affair - with mostly text and large, garishly coloured graphics - if any at all. JavaScript was a gimmick - and as far as I could tell - it was unable to do the stuff I needed it to. Coming from a desktop background, my first Windows coding was to create Excel macros in VBA (Visual Basic for Applications). It was hard for me to understand the world of the Web. I was looking outwards from the server-side towards the client-side and pondering over the futility of being limited to not being able to access anything except what the server-side code allowed you to have.

The strengths of JavaScript were far from being realised. It would take half a decade until 2005 before I would begin to see what some of the fuss was about - and the same time again before I really began to understand what it was all about.

Once the notion of the DOM existed, and could be manipulated, then JavaScript grew in power and ability.

My JavaScript

So I didn't go straight into plain JavaScript or ECMAScript or whatever you want to call it. My experience was to make the mistake that many new developers make. I would waste a large portion of my time learning a framework. Just as many teenagers are entering the job market now for front-end developers with React skills that are expertly honed through many personal projects - so too I started with jQuery. Indeed I believed for a while that jQuery was JavaScript. It would be about 18 months into my dev career that I realised the notion of a library. It was another year before I determined that I should master JavaScript instead of just jQuery if I didn't want to end up like many of the AS-400 developers out there on the job boards - with lots of experience and able to earn huge salaries - but only when they managed to get one of the handful of contracts that they were having to fight for against other equally skilled but ultimately lazy, dogmatic developers who had all refused to learn new skills and make sure they were competitive in the modern job market.

As someone once advised me - Software Engineers should aim to be Jack of All Trades - but the Master of One (or two or so). The point is that you need to have a good general knowledge and be an all-rounder - but with one or two main skills that earn you the money.
This means that you can cope with situations such as your main bread-winning skills becoming redundant. When the current trend for React as a SPA framework dies away - perhaps as far as 2030 - there will be those who float and those who drown. If you have mastered the basics of your trade - HTML, CSS and ECMAScript - as well as some of the design paradigms like OOP / OOD, SOLID, etc. then you will have a core set of transferable job skills for use with other frameworks.

If you've managed to get by because you are a React ninja - and know the framework inside and out but have never bothered with any of that uncool, boring stuff because you never needed to and were making so much money that you couldn't be bothered - then you will reap what you sow. I've seen it so many times with other developers, as well as experiencing it myself when the fad that was jQuery fell from favour, so I know that we have a duty as developers to keep our skills updated to reflect market needs rather than simply because we enjoy something. That hobbyist attitude earned a lot of money for many autodidactic self-taught coders, but ultimately you need to maintain a common language and quality assurance approach if you want to work with other developers. I've despaired a few times when I've tried to explain to other developers that they are wrong about something, but they are arguing with me. I seem like the dinosaur to them - with weird value systems that they cannot relate to - whilst I grow infinitely more frustrated with their arrogance as they state the subjective as the definitive.

In fact the other day, I had outsourced a piece of work to an 18 year old guy from Venezuela. He has potential and so I asked him to make a few CSS and HTML fixes. I expected to get the same document but with some extra classes in it. My expectation was to load his document alongside my original - and see the differences. I use a tool called Beyond Compare - and it's a bit like DiffMerge or TortoiseDiff - in that it highlights the differences in files. This sort of visualisation of what has changed in a document is a vital part of development. What I got back was a document that showed every single line with changes!! There were new lines inserted all over the show, and even the indentation had gone from spaces to tabs.

No problem I thought - I'll explain this to the guy and he'll rectify the problem. When I told him that he shouldn't prettify/beautify documents when he is working on a document that he is not creating as a new document - he starts to say that I am wrong. He tells me that I should realise that prettifying a document is essential and normal - and that he did nothing wrong. I literally couldn't believe what I was hearing. I asked him if he'd worked with other developers like this before. He said "yes and they've had no problems".

The fact is that we have all done this before. We've all had to learn that when we do changes, our pull requests must be atomic and easy to read. If the PR doesn't show clearly just the essential changes made, then it will be rejected.
Looking back, I should have used GIT instead of mailing him the file. I assumed that he had the same views as me. Instead he didn't. His mistake was to be arrogant and presume he knew more about this fact than me. He didn't ask me to explain why he had done something wrong. He only came up with excuses rather than logical reasons.
So now I have paid this guy to do work for me in order to save time - only to realise that I now have to revert the formatting in order to see exactly what he has changed. It will take me almost as long to discover the essential changes - rather than those aesthetic ones he chose to add.

Uses of legacy skills and the fun of DOM manipulation

So one of the things I find jQuery most useful for is quick and easy customisation of a web page. My habit is to use the Chrome extension jQuery Injector so that I can run jQuery on any page I want. Now I can hide or show elements according to any logic I want.

A practical demonstration of why jQuery is still useful

So one of my habits is to spend a lot of time on YouTube. I have a real penchant for anything to do with science, technology, development, space or the paranormal. I watch a lot of videos. Since working from home as a developer, I find that I leave YouTube videos playing on a television in the background. They are constantly distracting me from doing what I am supposed to do, but I love this way of working. I learn stuff constantly, and use it to ensure my knowledge is up to date. The only problem is knowing what videos I have watched and those I haven't. YouTube doesn't support many options for this. It doesn't care if you have already watched a video. It wants you to just keep watching.

So we have to do what we need to in order to keep on top of our viewing history. YouTube will cache a list of videos you have already watched - and show you a red line underneath all videos you have watched. On top of this, I always ensure that I rate videos I watch. A thumbs-up or down ensures I can quickly skip a video I've watched.

When I view the list of suggested videos on the right-hand side, I want to only see those videos I've not watched already. The way I do this is to hide those videos that have a red line on the bottom of them. This red line indicates the last position watched of that particular video. A full red line indicates that the whole video has been watched. A bar 1/10th across indicates I've watched 10% of the video.
This is the only DOM information available to us when we are looking at a list of videos in YouTube. I used to believe this line was cached at a browser level, but it applies across YouTube and is saved against your account. YouTube knows where you reached on every one of your History videos. We can use this to our advantage.

How to only show unwatched YouTube videos

Here are the steps to remove all watched videos from a list of videos in YouTube (suggested viewing, channel list, etc).

1. Open up Chrome browser
2. Install jQuery Injector
3. Go to YouTube and ensure you are signed in
4. Go to a channel you are subscribed to and has a mixture of watched and unwatched videos
5. F12 to open the Console window.
6. Run jQuery injector (right click and select) so the page loads a script tag including the jQuery library in the page. You should see some messages in the console window stating something akin to jQuery(//code.jquery.com/jquery-3.5.0.min.js) loaded
7. To double check, enter console.log(jQuery().jquery); You should see the version of jQuery available to you 8. In another tab, navigate to the script that I made. I saved it as a GitHub Gist. These are useful snippets, not quite as good as Pastebin because Gists lack the number of views so you cannot be aware of how many people are looking at your code snippet, but they do have the version control history that GitHub offers. 9. Paste the script into the console window. You should see the videos with a red line on them disappear. This causes the lazy loading to kick in as though you had scrolled the page down, and the places where the hidden videos once were, are now filled with new content.

// example data
var selector = '.ytd-thumbnail-overlay-resume-playback-renderer'; // CSS selector for red bar indicating video has been watched
var exampleUrl = 'https://www.youtube.com/channel/UCN64HIrZNqFQYZ2BuyY-4zg'; // example URL for text
var jQueryInjectorExtension = 'https://chrome.google.com/webstore/detail/jquery-injector/ekkjohcjbjcjjifokpingdbdlfekjcgi?hl=en'; // url for chrome extension to inject jQuery into page for code below to run

$(selector)
  .parent()  // ytd-thumbnail-overlay-resume-playback-renderer.style-scope.ytd-thumbnail
  .parent()  // div#overlays.style-scope.ytd-thumbnail
  .parent()  // a#thumbnail.yt-simple-endpoint.inline-block.style-scope.ytd-thumbnail
  .parent()  // ytd-thumbnail.style-scope.ytd-grid-video-renderer
  .parent()  // div#dismissable.style-scope.ytd-grid-video-renderer
  .parent()  // ytd-grid-video-renderer.style-scope.yt-horizontal-list-renderer
  .hide();

Future ideas

I would like to make this into a Chrome extension. If someone wants to do this, I'd appreciate a credit. That's all I ask.
The fact is - jQuery has some very useful features. It only needs a single library to give you all this control over the DOM. Sure - it's not as popular as the new SPA frameworks - but it does do the job correctly. It's very polished and still maintained.

Any feedback would be welcomed.