Now, I'm not saying that “determining the object bound to this” makes for the lightest possible reading, but there is some small comfort to be found here: now that we understand when that determination is made, we’re well equipped to understand the what—and that fortunately, that breaks down to only a handful of distinct use cases, all of which share one big caveat in the form of arrow functions.Global Binding (formerly "default binding")Any code outside of a defined function lives in the global execution context. Within the scope of the global execution context, this references globalThis—a property that itself references a JavaScript environment's global object. In a document in your browser, the global object is the window object:this;// result: Window {...}this === window;// result: trueglobalThis;// result: Window {...}this === globalThis;// result: trueSimple enough, if not especially useful outside the context of a function. Inside the context of a function declaration, you'll s

I know Alex, so I knew this wasn't going to be a slop supporting article. I don't want to spoil the article for you either, but the multiple redacted titles do a fantastic job of demonstrating historical hype cycles in the industry.Now what I'm not saying is AI is nailed-on to be yet another hype cycle that fizzles out. There's an inevitability that it will stick around. What I am saying though is you do not have to accept AI. I certainly don't.The point Alex makes well with a cheeky wink is you're not going to be "left behind" by not embracing AI, just like you weren't left behind by not embracing React for example. Sure React is very bedded in to the industry, but it's not required knowledge, quite like how web standards are.My advice is the same for each hype cycle this industry goes through: if you really need a job, you might have to hold your nose and get on the train, as it were. It's something that frustrates me endlessly with the tech industry. You definitely don't have to ful

I spent the first few years of my career regarding this as yet another aspect of my primarily hunch-driven approach to web development—which is to say, sometimes it felt like this might be what I wanted, but if so, it was for reasons I couldn't possibly begin to understand.I was occasionally right—to my very slim credit—but not because I knew why or anything. Now, after years of muddling through on vibes, trial and error, and squinting at Stack Overflow for as long as impending deadlines would allow, I think I've gotten a pretty good handle on this. I mean, give or take an emotional support console.log every so often; I'm only human.For me, the trouble was always that this is contextual, but that context isn't meaningful to us developers so much as it's meaningful to JavaScript. You and I are used to telling JavaScript what things are: this is the identifier we typed, where we typed it, scoped to the pair of brackets we typed around it, and it has the value we assigned to it.That's not

This is exactly the sort of thing I want to be reading right now. We often use Tailwind to generate only custom properties and utility classes.Up until v4 was released, Tailwind was purely JavaScript configured. We could quite easily rig up some design tokens and let it do the rest — it's how the Complete CSS system works under the hood.The newer version of Tailwind is more CSS-based though which I'm not feeling at all.I've got a real problem with a framework getting all in our CSS source code — especially one that completely changes in a major version. Really, we want to stick with tooling that generates CSS — utilities and custom properties — and stays as far away from our source code as possible. This is mainly for portability and scalability reasons — being deeply entwined with a framework makes it harder to move our CSS around when we need to. With that in mind, we're exploring different ways of generating this stuff, ongoing.This segues nicely to what Michelle is doing here. She'

Previously on Piccalilli, Sam Rose walked us through some real world uses of TypeScript's utility types. Today, I want to continue that line of thought and show you a few of TypeScript's advanced type manipulation features that I think will provide good bang for your buck.The objective of this article is to provide an overview of each feature, along with a overarching motivating example, so that you have a better awareness of what tools are at your disposal when you're creating types. Before I get into that, I want to provide a perspective on why you might want these features when they can be quite complicated.Some useful backgroundSometimes, it's easy to view types as merely "decorations" or conveniences that go on top of whatever JavaScript you're writing. I wont deny that you can get a lot done with that mindset! However, TypeScript's flexibility and power very much reward those who treat types as a first-class part of a program's design.Whenever we're writing software, we're always