Syntactic Sugar, Declarative and First Class Citizens? What does that even mean?

Monday. Monday. Monday.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS web development treats coming in hot. Here is Wes, Barracuda,

Boss, and Scott

key.

Welcome to Syntax.

In this Monday hasty treat, we're gonna be describing some JavaScript things, some JavaScript sayings, some jargon, some stuff that you may have heard before and just wondering, what is that? What's that thing? I've heard these words around here, but people are just tossing them out. Like, everybody knows what they they mean. So JavaScript buzzwords explained what does that even mean. But before we get into that, we're gonna be talking about some buzz companies. And by buzz, I mean, not not ones that are just fly by night here. These are incredible, awesome, amazing companies doing awesome stuff. So one of which is Sentry, and the other one is FreshBooks.

Now Sentry is the perfect place to see all of your errors and exceptions happening in your application, track bugs and performance across all your different services, whether that's your API or UI or anything else. Sentry has you covered because their APIs work with all the tools you know and love. Not only that, but they allow you to create custom dashboards to get alerts, To get, connections to the tools like GitHub issues so that you can track and fix your bugs. You can attach them to specific developers so that way they can get fixed. And you could make sure they get fixed by attaching those issues to release numbers and build numbers as well. So if you wanna give Century a try. Check it out at century.i0.

Use the coupon code at tasty treat, all lowercase and all one word. Is one of those services that Wes and I have been using for a long time and absolutely love.

We're also sponsored by FreshBooks.

FreshBooks is a cloud accounting solution for your business. They have billing and payments all in one place. Everything is organized and easy to track.

The professional invoices, online payments, automated payment reminders.

FreshBooks makes it easy for you and for your clients. Check it out atfreshbooks.comforward/ syntax. That's gonna get you a 30 day free trial.

No credit card required. Thank you, FreshBooks, for sponsoring.

Alright. Let's get on into it. Basically, this was a show where I like, I think about back To, like, when I was first learning JavaScript and people would say these types of things, and I would be like, okay, But what does that even mean? Yeah. Right. And and people would throw it around. And these are more like, like sayings or piece things in the language of versus, I guess they are buzzwords, but we'll have a whole show on buzzwords as well. So first one we have here is everything in JavaScript is an object.

So in JavaScript, you have objects, but then they say everything is an object.

Like, what does so am I an object?

And am I? So what they mean by that is that Obviously, in JavaScript, we have objects, meaning you open up your curly brackets, you can put properties in there, you can modify those after the fact.

However, if you look at any of the other types inside of JavaScript, like what other types do we have? We have strings, We have numbers. We have booleans.

All of those things here. Let me let me give you a little example. So Open up your your dev tools and go ahead and say, const age is equal to a100 And then say age.

Name is equal to string of Wes.

So now if you type in age, you get a 100. If you type age. Name, You get Wes.

So what that means is that, even types that are not objects, like numbers, You can still put properties on that value, and more importantly, probably those things can still have methods and functionality inside of them. So for example, if you take age, which is a number, you can say dot to fixed or to local string or to precision.

And those methods are inside of the number object, Allowing us to have that kind of like nice access to it. So putting properties on things that are not objects, sometimes handy.

Putting methods on things that are not objects. Very handy.

Yeah. Next one here is x is just syntactic sugar.

This is a a thing that you hear all the time about different things in JavaScript just being sugar or syntactic sugar. You often you you'll hear it just shorten to sugar many times. What does this mean? It it's basically what you're getting is a nicer, more human readable syntax for the same things that you'd be doing in a maybe not even always more complex way, but sometimes just an uglier way, so to say. And, I guess beauty is in the eye of the beholder here because some people there there's definitely, like, a a push when people use JavaScript classes to say, JavaScript classes are just syntactic sugar because they're not doing anything necessarily any different, than you can do with creating objects, from prototypes already.

However, It's just a nicer, more friendly syntax. And not only that, it's a syntax that people are used to from other object oriented programming interfaces. So, it's taking a thing that everybody kind of did a certain way already and say, oh, you can also do it this way in JavaScript as well, Using this class syntax. So some people say, I don't want syntax sugar. I don't want these abstractions over, syntax they already know how to do. I already know how to do it the normal way, so I don't need this syntactic sugar. But me, personally, You know, I'm a fan of sugar in many ways. You know? It we should be evident by my usage of Svelte because something like the dollar sign in Svelte syntactic sugar to reference a subscription.

You use the dollar sign in front of your variable, and then you can access the properties in a subscription Instead of subscribing or pulling out those values individually from that observable. So, you know, me, I I like syntactic sugar. But, again, it's just little flourishes or syntax changes in the code to make it easier

for humans to read or write without necessarily changing how the computer interprets this thing. Yeah, I'm trying to think, like, what else is syntactic sugar that we've got in JavaScript recently. And, when we got backticks For template strings, that's just syntactic sugar over, the ability to Close a string and concatenate a variable, and then open that string again.

Shorthand methods. So if you have a method in An object or class. You can just like if the method was, get age, you can just type get age, open close parenthesis, open close Curly brackets, and that is allowing you to describe a function rather than saying get age property is colon function get age.

It's just just a bit shorter. Syntactic sugar. That's that's one that gets thrown around. And and generally, syntactic sugar, because they're not adding features.

That stuff can be compiled with Babble, or any of these other things to

the old version, the unsugared version of it. Yeah. Which may or may not be, you know, more performant or, you know, less Works in more browsers. Worse in more browsers. Yep. Works in more server side. Yeah. I I just found this, Stack Overflow post here. I'm gonna link it to the show notes. It says, no classes are not just syntactic sugar of the prototypal pattern. So, since I said that they were moments ago, I wanna go ahead and link this blog post too. It has some reading for distinctly why classes are not syntactical sugar, but I have seen many other people, with their viewpoints saying that they are. So I think that's an argument that people are having. Here's the other side to that argument that they're not just syntax sugar.

Features that are impossible to implement without the class syntax, the internal home object property of static class methods point to the class constructor.

Okay.

We're gonna we're gonna the, job we're gonna need a JavaScript jargon episode for that sentence.

Next one we have here is functions are first class citizens in JavaScript. So this is something that gets thrown around a lot.

And this is particularly hard to understand if JavaScript Which is your 1st language that you are learning, which is the case for a lot of people when they're the JavaScript is usually the first language that a lot of people learn. So What they mean by that is that functions in JavaScript can be passed around like any other value in JavaScript like a string, like a number, meaning that functions can be stored in variables.

Functions can be put inside of objects, like methods.

Functions can be passed into other functions, like a callback function.

Functions can be composed upon each other. So because functions are values, They can be passed around to other functions and stored in values, etcetera, etcetera. So that's what they mean by saying they are first class citizens. They our values in themselves.

Next one we have is just object literal.

What that means is that Sometimes when you create an object, like, let's say let's give date, for example.

To create a new date object, you have to say new, Capital d, date, open close parenthesis. And what that does is it creates a new date object. However, if you are just creating An object that is like like a const podcast equals open close curly brackets.

That, where you're explicitly just putting it in the open close curly brackets. That's the literal part where you're not using a constructor To create a new version of it, you're simply just literally making a new one. So that's that's the idea here is that you have object literal With open close curly brackets.

You have string literal, like Scott just said.

Why? Because if you wanted to, you could say const name equals new, capital s, string,

and in quotes. Inside of string, you can put your name, Wes. No one does that because you can use string literal where you just say const name equals Wes. Cool. Let's go on to this one is you get tossed around all the time, declarative or imperative. And and frequently, you'll hear it in maybe, like, docs will say a declarative way to do this or anything like that.

People would say, okay.

Yeah. Sure. Whatever.

But declarative versus imperative is kind of the difference between step by step instructions versus, like, a structural output of this thing. So If you look at, like, React code, React code has, like, a a template.

And that template is if you're defining your actions, you're declaring them in the template as a means of programming them rather than saying step by step, create this div, then add this text to this div, then add that div to the page. You're saying, here's a structure. Here's here I'm declaring the shape of this stuff, and it's just going to work. It's just going to put it onto the page by declaring its structure rather than necessarily writing the individual step by steps. You could think of it as like the difference between, again, instructions on how to how to how to build a thing, verse just declaring that this thing kind of exists. Right? You you're declaring it exists or you're using it as its a individual, structure, essentially.

Yeah. I always like to just to think about the difference between creating, let's say, h two tag with a class of title and the text of Wes. Mhmm.

An h two tag in HTML, that is declarative, meaning that you simply just open your bracket, type h two, give it a class of title, and put Wes in between it and close it. That's very declarative.

Imperative would be how you create it in JavaScript, not in JSX. We have obviously we have lots of declarative in, templating languages. But if you're just doing it in straight vanilla JavaScript, you'd say, uh-uh, const heading equals document dot create element h2.

H, and then you would say heading dot class list.

Addtitle and then you would say heading.

That is declarative. I've I've written the instructions out, versus oh, sorry. Yeah. Imperative. Yes. Imperatives. Oh, my gosh. That is imperative where, with HD, I simply just declared it totally. Yeah. Again, imperative step by step attractions.

That's that's the one that you gotta to know that that was the easiest way to describe that. If you remember that. I like that a lot. So that is the buzzwords that we have here. I've got a list of, I don't know, probably 40 more, but these are ones in JavaScript that gets thrown around a lot.

And especially, like, if you're at a conference and somebody starts talking to you about why they like something, you can get that sort of gulp.

And I've certainly been there many times where you're like, oh, like, especially you you get a lot of people who are almost, like, aggressive. Like, oh, I don't like that.

Imperative approach to creating this is is silly. And you're just like, oh my gosh. I don't know what that means.

Absolutely not. Me neither. Who would use such a thing, you know? And, or if you're in a job interview or something like that. So these things are not as scary as the names that make them up to be. You just have to sort of remember what's behind it. Totally.

Alright. That's it. Thank you so much for tuning in, and we will catch you on

Wednesday,

wet day. It was

Head on over to syntax.fm for a full archive of all of our shows, And don't forget to subscribe in your podcast player or drop a review if you like this show.