Posts - Coding Beauty

These coding themes are incredible

By Tari Ibaba / Last updated on October 2, 2024

10 breathtaking themes to upgrade your dev quality of life and coding enjoyment.

1. Night Owl

Night Owl is here for all your late-night coding drills.

Easy on the eyes with a cool color palette:

Sit in a dark room and code all night long.

And there’s a different variant, for those who hate the italics:

And when the morning comes around again:

No italics:

2. Atom One Theme

My absolute favorite.

The signature color scheme from the Atom editor that GitHub killed.

I find dark themes annoying in the day with bright light all around me — so thankfully this also has a light counterpart.

3. GitHub Theme

Speaking of GitHub: Their official theme for VS Code:

Look familiar? No? How about this:

Reduce the font size and change it to Consolas and you have a perfect replica of the theme at github.com.

4. One Dark Pro

The biggest difference from Atom One Dark is the variable color.

It’s got a vibrant yellow compared to the gray of the former.

Essentially all the rainbow colors now — can’t get much more colorful than that.

Especially when you sprinkle bracket pair colorization.

And One Dark Pro also has some nice variants you may want to try: Check out One Dark Pro Mix.

It’s got a slightly darker background with a pleasant bold color for the function blue.

No light theme though.

5. Monokai

A visually stunning theme with strikingly vibrant colors and excellent readability.

Look at the alluring contrast between the green and the pink, and the purple too. All with a nice brownish background.

There’s also Monokai Pro for a lesser contrast and a more sophisticated feel.

The extension also comes with a beautiful file icon theme with multiple variants:

6. Dracula Theme

Dark and dramatic — that’s Dracula.

It’s a purple-centric theme with a mysterious vibe.

Not surprising it doesn’t have a light theme — that’s Dracula.

7. Material Theme

A popular theme packed with sleek, modern colors.

Comes with gorgeous color variants, like Material Theme Ocean:

Material Theme also has its own icon set:

8. Quiet Light

Minimalistic theme with a clean interface:

Purple purple purple.

9. Winter Is Coming

Lovely night-friendly theme cool blue hues:

If you’re not a big fan of the dark blue background, then dark black should help.

And it’s only fitting for it to have a light counterpart — it’s Winter after all.

10. Visual Studio Theme

For those with Visual Studio nostalgia.

Instantly recognizable with the blue variables and red strings.

Final thoughts

There’s a theme here for every developer’s taste – all clear and breathtaking to upgrade your coding experience.

Whether you prefer dark modes for late-night coding or bright themes for daytime clarity, the right theme can make all the difference in how comfortable and productive you are as you work.

Explore these options, find the one that resonates with your style, and take your coding sessions to the next level.

Interviewer: You are clueless about for loops😂

By Tari Ibaba / Last updated on October 2, 2024

Interviewer: What does func() print in this code?

const arr = [1, 2, 3, 4];

for (let i = 0; i < arr.length; i++) {
  func(arr[i]);
  arr.splice(0, 1);
}

function func(item) {
  console.log(item);
}

A huge grin appeared on Jimmy’s face.

After all the many rounds of interviews he’d finally gotten to this last question, and it was easier than he ever thought it would be.

Get this right and the job was assured.

“It prints 1, 2, 3, and 4”, he confidently proclaimed.

Unfortunately this turned out to be a huge mistake, and the interview was ended immediately.

“But how?! What else would it print? I got it correctly!”, He fumed at the interviewer.

“No, you didn’t. Your foundation of JavaScript is clearly not solid enough”.

“Okay okay wait, I get it now — splice() mutates the array on every iteration right?

I see it now! I forgot that element indexes change when you remove elements.

Let me work this out:”

iter 1: [1, 2, 3, 4], index: 0, print: 1
iter 2: [2, 3, 4], index: 1, print: 3
iter 3: [3, 4], index: 2, print: undefined
iter 4: [4], index: 3, print: undefined

“Oh so it really prints 1, 3, undefined, and undefined”. He looked up in desperate reassurance.

It was the interviewer’s turn to grin.

“Wrong again”.

Alright, enough of this nonsense.

“What the hell is wrong with you?”, He boomed as he shot up from his seat.

“I’ve worked my ass off for your stupid company and I haven’t even gotten the job!

And now you’re giving me this simple question for what? To insult my intelligence? Test my confidence? You think I don’t how splice() works? Or for loops, like what do you take me for?”

“You think I give a damn about your useless organization? You think I gave up my $200K job at Google for this crap…”, the ranting and raving went on and on…

The interviewer’s smile never wavered as the candidate continued his tirade, his words increasingly filled with frustration. He stood, clenching and unclenching his fists, the tension palpable.

“I don’t need this! I’ve mastered JavaScript, built complex applications, and solved problems you couldn’t even comprehend. And now this? A trick question? Who even writes code like that in production? This is absurd!”

The interviewer calmly leaned back in his chair and crossed his arms, still maintaining that infuriating, knowing smile.

“Are you finished?”, the interviewer asked after a long pause, the candidate breathing heavily.

Jimmy glared at him, his heart racing, his fists clenched, ready for another volley. But the interviewer’s calm demeanor somehow doused the fire in his chest.

“My friend, the issue is not with splice() or how the loop behaves.

The core of the problem lies in how you’re thinking about the array’s length in the for loop”

“What the hell are you talking about?” he sat back down.

“Let me show you”, he came closer to Jimmy’s laptop.

const arr = [1, 2, 3, 4];

for (let i = 0; i < arr.length; i++) {
  console.log('here');
  arr.splice(0, 1);
}

“Do you see how many times the loop ran?”

“Wait… wha… how are there only 2 iterations?”, Jimmy couldn’t believe his eyes.

“You see what I said about you lacking a fundamental understanding of JavaScript? You are clueless about for loops”

“Don’t you realize that the length property is recalculated every time the loop runs?”

Jimmy’s face flushed as the realization sank in.

“So I hope you can see what really happens in the code:”

const arr = [1, 2, 3, 4];

for (let i = 0; i < arr.length; i++) {
  func(arr[i]);
  arr.splice(0, 1);
}

function func(item) {
  console.log(item);
}

It prints just 1 and 3:

“People like you are so used to looping to a constant number. You didn’t even consider the possibility that arr.length could change, like here again:”

let n = 10;
for (let i = 0; i < n; i++) {
  console.log(n--);
}

Jimmy nodded slowly, his anger replaced by quiet contemplation.

“I should have seen it”.

“We all have rough moments. Take this as a chance to reflect and improve.”

Jimmy shook his hand, humbled. This interview was still over so he rose up to leave.

“Alright, so um… do I still get the job?”

The interviewer burst into a hysterical feat of laughter.

“Don’t push it my man”.

The 5 most transformative JavaScript features from ES11

By Tari Ibaba / Last updated on September 25, 2024

JavaScript has come a long way in the past 10 years with brand new feature upgrades in each one.

Let’s take a look at the 5 most significant features that arrived in ES11; and see the ones you missed.

1. Modularization on the fly: Dynamic `import`s

ES11 was the awesome year when import could now act as function, like require().

An async function.

Keeping imports at the top level was no longer a must; We could now easily resolve the module’s name at compile time.

Loading modules optionally and only when needed for high-flying performance…

async function asyncFunc() {
  if (condition) {
    const giganticModule = await import('./gigantic-module');
  }
}

Loading modules based on user or variable input…

import minimist from 'minimist';

const argv = minimist(process.argv.slice(2));

viewModule(argv.name);

async function viewModule(name) {
  const module = await import(name);
  console.log(Object.keys(module));
}

It’s also great for using ES modules that no longer support require():

// ❌ require() of ES modules is not supported
const chalk = require('chalk');
console.log(chalk.blue('Coding Beauty'));

(async () => {
  // ✅ Runs successfully
  const chalk = (await import('chalk')).default;
  console.log(chalk.blue('Coding Beauty'));
})();

2. Promise.allSettled()

But we already had Promise.all() to wait for all the Promises in a list to resolve?

const responses = await Promise.all([
  fetch(endpoint1),
  fetch(endpoint2),
]);

So what was the point of this, right?

But no, allSettled() turns out to be quite different from all().

Promise.all(): If even a single Promise in the list fails, everything fails.

But you see the problem: We’d have no idea if one failed and which succeeded.

What if you want to retry the failed errors until they do succeed? You’re stuck.

Until you turn to Promise.allSettled():

❌ Before ES11:

// ❌ Promise.all()
async function fetchData() {
  const apiUrl = 'api.tariibaba.com';
  const endpoint1 = `${apiUrl}/route1`;
  const endpoint2 = `${apiUrl}/route2`;

  try {
    const responses = await Promise.all([
      fetch(endpoint1),
      fetch(endpoint2),
    ]);
  } catch (err) {
    // ❌ Which failed & which succeeded? We have no idea
    console.log(`error: ${err}`);
  }
  // ...
}

✅ After ES11:

Promise.allSettled(): Wait for every Promise to fail or resolve.

// ✅ Promise.allSettled()
async function fetchData() {
  const apiUrl = 'api.tariibaba.com';

  const endpoint1 = `${apiUrl}/route1`;
  const endpoint2 = `${apiUrl}/route2`;

  try {
    const promises = await Promise.allSettled([
      fetch(endpoint1),
      fetch(endpoint2),
    ]);
    const succeeded = promises.filter(
      (promise) => promise.status === 'fulfilled'
    );
    const failed = promises.filter(
      (promise) => promise.status === 'rejected'
    );
    // ✅ now retry failed API requests until succeeded?
  } catch (err) {
    // We don't need this anymore!
    console.log(`error: ${err}`);
  }
  // ...
}

3. Optional chaining

?. is all over the place now but it all started from ES11.

We’ve been checking vars for null since the dawn of time but it gets pretty cumbersome when we’re null-checking nested properties.

❌ Before ES11:

const a = {
  b: {
    c: {
      d: {
        site: 'codingbeautydev.com',
        name: null,
      },
    },
  },
};

// ❌ Must check every property for null
if (a && a.b && a.b.c && a.b.c && a.b.c.d.site) {
  console.log(a.b.c.d.site);
}

✅ After ES11:

With the optional chaining operator:

// `?.` auto-checks every property for null

// if any prop in the chain is null, short-circuit
// and return null
if (a?.b?.c?.d?.site) {
  console.log(a.b.c.d.site);
}

4. Nullish coalescing

?? was one of the most impactful JavaScript additions.

A powerful to set a variable to a default value and use it at the same time.

❌ Before ES11:

We repeat the variable unnecessarily:

console.log(str1 ? str1 : 'codingbeautydev.com'); // coding is cool

console.log(str2 ? str2 : 'codingbeautydev.com'); // codingbeautydev.com

✅ After ES12:

?? keeps things clean and readable:

const str1 = 'coding is cool';

const str2 = null;

console.log(str1 ?? 'codingbeautydev.com'); // coding is cool

console.log(str2 ?? 'codingbeautydev.com'); // codingbeautydev.com

It coalesces.

Left and right combine to form a non-null whole:

5. Go big or go home: Big Ints

The name BigInt gives it away: loading up on humongous integer values:

const bigInt =
  240389470239846028947208942742089724204872042n;

const bigInt2 = BigInt(
  '34028974029641089471947861048917649816048962'
);

console.log(typeof bigInt);
console.log(bigInt);

console.log(typeof bigInt2);
console.log(bigInt2);

console.log(bigInt * bigInt2);

Because normal integers can’t:

// ✖️ Stored as double
const normalInt = 240389470239846028947208942742089724204872042;

const normalInt2 = 34028974029641089471947861048917649816048962;

console.log(typeof normalInt);
console.log(normalInt);

console.log(typeof normalInt2);
console.log(normalInt2);

// ✖️ Precision lost
console.log(normalInt * normalInt2);

Final thoughts

These are the juicy new JavaScript features that arrived in the ES12.

Use them to boost your productivity as a developer and write cleaner code with greater conciseness, expressiveness and clarity.

Nobody wants to use these HTML tags 😭

By Tari Ibaba / Last updated on September 25, 2024

Trust me, you can do MUCH better than <div> <a> and <p>.

Living images, built-in dialogs, a href hacking…

There’s a whole lot of sophisticated tags to discover.

1. `progress` and `meter`

So first there’s progress – your typical drama-free progress bar.

You set a value and max for gradation — pretty straightforward.

<label for="file"
  >Downloading knowledge into evil AI</label
>
<progress id="file" value="0" max="100">32%</progress>

But then there’s meter — also known as progress on a rampage:

<label for="energy">energy levels after 🍉🍌🍇</label>

<meter
  id="energy"
  min="0"
  max="100"
  low="25"
  high="75"
  optimum="80"
  value="50"
/>

2. `dfn`

dfn — for anything we’re gonna define in the page:

<div>
  <dfn>Mellifluous</dfn> sounds are smooth, musical🎶,
  and pleasant to hear
</div>

And the definition must be inside the dfn‘s parent tag, or else…

Or else nothing — just a semantic rule you can happily disregard.

3. `dialog`

New native HTML dialogs!

<dialog id="dialog">
  ⚡Lighting strikes the earth 44 times every second!
</dialog>

<button>Something interesting</button>

const dialog = document.getElementById('dialog');
const button = document.querySelector('button');
button.addEventListener('click', () => {
  dialog.showModal();
});

Stay open from the get-go:

<!-- btw setting open to "false" won't do anything -->
<dialog id="dialog" open>
  😻 Cats have over 30 different muscles just in their
  ears, allowing them to swivel them in all directions.
</dialog>

Built-in support for closing:

<dialog id="dialog" open>
  Your free trial is over! Subscribe for as low as $5
  billion per month
  <form method="dialog">
    <button>Get lost</button>
  </form>
</dialog>

And powerful, flexible customization letting you create wonderful UIs like this:

4. `map` and `area`

<map> and <area> — powerful combo to create clickable areas in images:

<img
  src="workplace.jpg"
  alt="Workplace"
  usemap="#workmap"
  width="400"
  height="379"
/>
<map name="workmap">
  <area
    shape="rect"
    coords="34,44,270,350"
    alt="Computer"
    href="computer.html"
  />
  <area
    shape="rect"
    coords="290,172,333,250"
    alt="Phone"
    href="phone.html"
  />
  <area
    shape="circle"
    coords="337,300,44"
    alt="Cup of coffee"
    href="coffee.html"
  />
</map>

We call clickable images like these image maps.

5. `bdo`

Super cryptic acronym here, what does it do?

This 👇

<!-- dir = direction -->
<!-- rtl = right-to-left -->
<bdo dir="rtl">
  🥺🥰but when I saw you I felt something I never felt...
</bdo>

That’s why it stands for: bi-directional override.

6. `base`

So you know how relative URLs normally work right? 👇

<body>
  <a href="/blog/javascript-functional-try-catch"
    >This is how functional try-catch transforms your
    JavaScript code
  </a>
</body>

The <a>‘s use the page’s domain to get the full URL they’ll navigate you to:

But what happens when you create a foundational <base> in the HTML?

<head>
  <!-- ✅ <base> tag -->
  <base href="https://www.codingbeautydev.com" />
  <title>codingbeautydev.com</title>
</head>

<body>
  <a href="/blog/javascript-functional-try-catch"
    >This is how functional try-catch transforms your
    JavaScript code
  </a>
</body>

Now they all use the hardcoded value in the <base>‘s href to get the full URL:

Frameworks like Angular and Flutter Web use it too:

7. `time`

For dates and times:

My Journal
<br/><br/>
<time>2:36pm</time> -- I asked her if she wanted to
grab a cup of coffee with me
<br />
<time>3:50pm</time> -- Still dealing with the brutal
rejection

No fancy visuals but it means a lot to search engines.

With time they better understand the dates in your page and produce smarter results.

Especially with the datetime attribute:

<time datetime="2025-01-07">AI singularity</time> is
coming sooner than you think!

8. `hgroup`

<hgroup> is all about family.

It tells the entire world that a heading tag and some content below are related:

<hgroup>
  <h1>Maybe this is the end, but if we go out...</h1>
  <p>We go out together</p>
</hgroup>

Family sticks together:

9. `kbd`

Represents keyboard inputs:

Over 30 years professional experience with
StackOverflow specializing in
<kbd>Ctrl + C</kbd> and <kbd>Ctrl + V</kbd>

And speaking of StackOverflow, <kbd> has a nice styling there and other StackExchange sites.

10. `cite`

Indicates the title of a book, song, movie, or some other creative work:

One thing I love about <cite>Wednesday</cite> is how
Wednesday doesn't care about fitting in

Final thoughts

So these are 10 of the least known and utilized tags in HTML.

Quite useful in various situations despite their low usage.

5 overlooked ways to make $5000/m online as a programmer

By Tari Ibaba / Last updated on September 23, 2024

Developers are turning code into cash on the internet every day.

Just look at Pieter Levels, a developer making over $300,000 per month from his laptop.

He’s just one of many who combined ingenuity and skill to create tremendous value through the internet.

If you’ve been coding for a while, you can also provide value with your knowledge in several ways.

1. SaaS: Build it once, sell it forever

This is how Pieter makes most of his money.

It’s the holy grail of online income.

Build it once and sell it forever. It’s as passive as it gets.

The hard part is, what are you building? What problem are you solving?

Ideas are not a dime a dozen. Good ideas are rare.

And how do you find good SAAS ideas?

Look into your life.

What are some problems you face regularly online or offline, and can software solve them?

Uber started because the founders found themselves stuck in Paris with no way to find a taxi.

React, Polymer JS, and many other dev tools came about because the existing alternatives just weren’t good enough.

2. Freelancing the right way

I love freelancing.

It’s packed with new and exciting opportunities with unlimited earning potential.

One minute you’re building a sleek landing page for a startup; the next, you’re diving into an AI project for a company on the other side of the world.

But please don’t make the same mistake I did.

I used to spend hours cold-emailing strangers and applying to random low-quality job listings.

I thought it was all a numbers game.

But it was a complete and utter waste of time.

I stopped cold applying and focused on building your network instead. Warm.

I meet new people from people already in my network on WhatsApp and my email contacts.

These people ended up either becoming clients or referring me to clients.

An even faster way was by joining exclusive freelance networks.

In the networks I’m in I get offered at least 3 new freelancing opportunities every single day.

I could have saved all the time and energy spent on the above — but less control and hard to find and get into legit ones.

3. Create “content”

Every line of code you write has a story behind it. Let’s hear it.

Let’s hear how — tools and techniques.

Let’s hear why — your motivations, thought processes, and breakthroughs.

Don’t just throw your knowledge out there; it’s about storytelling.

Share your discoveries, ideas, and opinions; share what you’re passionate about.

And content doesn’t only mean posting on social media or blogging.

“Content” also includes your portfolio — on GitHub and more.

So it also means creating significant projects in your niche and talking about them.

The point of all this is to broaden your reach.

You either end up earning directly on the platform (like YouTube), or you greatly boost your visibility and attract great opportunities.

4. Coaching: Teach what you know

Nothing beats interactive and personalized learning from another human.

Someone who’s been there done that. They’ve seen it all, they know all the tips and tricks and pitfalls.

If you’ve been coding for more than a few years, this is you. You are the one.

Turn your knowledge into an income stream by teaching others.

And it doesn’t even have to be online. Look into your life.

When I was in uni there were tons of my coursemates who needed someone to guide them on learning coding and the other CS topics.

That was a serious opportunity.

Especially as I was one of the few who had already been coding for quite some time.

5. Patreon and GitHub Sponsors: Rally a community

Donations? Lol

How can anyone make any real money from donations?!

Until you hear of how Caleb Porzio makes over $100K/year from nothing but those same donations🤯

That’s the magic of Patreon and GitHub Sponsors.

By offering exclusive perks—like priority issue responses, educational guides on the project, or early access to your latest builds—you can turn your most devoted fans into your sponsors.

You can even sell advertising space, just like Vuetify does:

It’s not just about code anymore—it’s about building a community around your work, a tribe that’s willing to keep you going.

Final thoughts

Making money online as a programmer is about turning your skills into something bigger than yourself.

Whether you’re a freelancer battling through client projects or a creator gathering an audience, the key is the same: know your value, share it, and let the internet do the rest.

This new JavaScript operator is an absolute game changer

By Tari Ibaba / Last updated on September 17, 2024

With the new safe assignment ?= operator you’ll stop writing code like this:

// ❌ Before:

// ❌ Deep nesting of try-catch for different errors

async function fetchData() {
  try {
    const response = await fetch('https://api.codingbeautydev.com/docs');
    try {
      const data = await response.json();
      return data;
    } catch (parseError) {
      console.error(parseError);
    }
  } catch (networkError) {
    console.error(networkError);
  }
}

And start writing code like this:

// ✅ After:

async function fetchData() {
  const [networkError, response] ?= await fetch('https://codingbeautydev.com');
  
  if (networkError) return console.error(networkError);
  
  const [parseError, data] ?= await response.json();
  
  if (parseError) return console.error(parseError);
  
  return data;
}

We’ve completely eradicated the deep nesting. The code is far more readable and cleaner.

Instead of getting the error in the clunky catch block:

async function doStuff() {
  try {
    const data = await func('codingbeautydev.com');
  } catch (error) {
    console.error(error);
  }
}

Now we do everything in just one line.

Instead of failing loudly and proudly, ?= tells the error to shut up and let us decide what do with it.

// ✅ if there's error: `err` has value, `data` is null
// ✅ no error: `err` is null, `data has value
async function doStuff() {
  const [err, data] ?= await func('codingbeautydev.com');
}

We can tell it to get lost:

async function doStuff() {
  // 👇 it's as good as gone here
  const [, data] ?= await func('codingbeautydev.com');
  // ...
}

We can announce it to the world and keep things moving:

async function doStuff() {
  const [err, data] ?= await func('codingbeautydev.com');
  if (err) {
    console.error(err);
  }
  // ...
}

Or we can stop immediately:

// `err` is null if there's no error
async function doStuff() {
  const [err, data] ?= await func('codingbeautydev.com');
  if (err) return;
}

Which makes it such a powerful tool for creating guard clauses:

// ✅ avoid nested try-catch
// ✅ avoid nested ifs
function processFile() {
  const filename = 'codingbeautydev.com.txt';

  const [err, jsonStr] ?= fs.readFileSync(filename, 'utf-8');
  if (readErr) {
    return;
  }

  const [jsonErr, json] ?= JSON.parse(jsonStr);
  if (jsonErr) {
    return;
  }

  const awards = json.awards.length;
  console.log(`🏅Total awards: ${awards}`);
}

And here’s one of the very best things about this new operator.

There are several instances where we want a value that depends on whether or not there’s an exception.

Normally you’ll use a mutable var outside the scope for error-free access:

function writeTransactionsToFile(transactions) {
  // ❌ mutable var
  let writeStatus;

  try {
    fs.writeFileSync(
      'codingbeautydev.com.txt',
      transactions
    );
    writeStatus = 'success';
  } catch (error) {
    writeStatus = 'error';
  }
  // do something with writeStatus...
}

But this can be frustrating, especially when you’re trying to have immutable code and the var was already const before the time came to add try-catch.

You’d have to wrap it try, then remove the const, then make a let declaration outside the try, then re-assign again in the catch…

But now with ?=:

function writeTransactionsToFile(transactions) {
  const [err, data] ?= fs.writeFileSync(
    'codingbeautydev.com.txt',
    transactions
  )
  const writeStatus = err ? 'error' : 'success'
  // // do something with writeStatus...
}

We maintain our immutability and the code is now much more intuitive. Once again we’ve eradicated all nesting.

How does it work?

The new ?= operator calls the Symbol.result method internally.

So when we do this:

const [err, result] ?= func('codingbeautydev.com');

This is what’s actually happening:

// it's an assignment now
const [err, result] = func[Symbol.result](
  'codingbeautydev.com'
);

So you know what this means right?

It means we can make this work with ANY object that implements Symbol.result:

function doStuff() {
  return {
    [Symbol.result]() {
      return [new Error("Nope"), null];
    },
  };
}

const [error, result] ?= doStuff();

But of course you can throw as always:

function doStuff() {
  throw new Error('Nope');
}

const [error, result] ?= doStuff();

And one cool thing it does: if result has its own Symbol.result method, then ?= drills down recursively:

function doStuff() {
  return {
    [Symbol.result](str) {
      console.log(str);
      return [
        null,
        {
          [Symbol.result]() {
            return [new Error('WTH happened?'), null];
          }
        }
      ];
    }
  }
}

const [error, result] ?= doStuff('codingbeautydev.com');

You can also use the object directly instead of returning from a function:

const obj = {
  [Symbol.result]() {
    return [new Error('Nope'), null];
  },
};

const [error, result] ?= obj;

Although, where would this make any sense in practice?

As we saw earlier, ?= is versatile enough to fit in seamlessly with both normal and awaited functions.

const [error, data] ?= fs.readFileSync('file.txt', 'utf8');

const [error, data] ?= await fs.readFile('file.txt', 'utf8');

using

?= also works with the using keyboard to automatically clean up resources after use.

❌ Before:

try {
  using resource = getResource();
} catch (err) {
  // ...
}

✅ After:

using [err, resource] ?= getResource();

How to use it now

While we wait for ?= to become natively integrated into JavaScript, we can start it now with this polyfill:

But you can’t use it directly — you’ll need Symbol.result:

import 'polyfill.js';

const [error, data] = fs
  .readFileSync('codingbeautydev.com.txt', 'utf-8')
  [Symbol.result]();

Final thoughts

JavaScript error handling just got much more readable and intuitive with the new safe assignment operator (?=).

Use it to write cleaner and more predictable code.

OpenAI’s new o1 model changes EVERYTHING

By Tari Ibaba / Last updated on September 18, 2024

OpenAI just launched a new model (“o1”) and it’s HUGE.

Before now there’d been a lot of mystery about an upcoming “Strawberry” model, subtly hinted at by Sal Altman in a cryptic tweet last month.

The isn’t just another version of GPT. This is something completely different.

OpenAI designed it to excel in tasks that require deeper reasoning—things like solving multi-step problems, writing intricate code (bad news for devs?), and even handling advanced math.

It doesn’t just predict the next word. It’s been trained to “think”.

But didn’t AI models already do this? Not quite.

o1 is different because it’s been trained using reinforcement learning. A training approach that lets the model learn from its mistakes, getting better over time at reasoning through complex tasks.

How good is it?

OpenAI tested o1 on International Mathematics Olympiad problems and results were jaw-dropping: o1 correctly solved 83% of them.

And how many was last year’s all-powerful GPT-4 able to solve?

13%.

Literally 13 — imagine how bad GPT-3 would have been? You know that wowed us all in 2022. That’s not just an improvement—it’s a massive leap.

Also massive enough to make it as intelligent as Physics and Chemistry PhD students in benchmark tests — incredible.

The price tag

Here’s where things get a bit tricky.

If you’re looking to use o1 through the API, be ready to pay.

The cost is $15 per million input tokens and $60 per million output tokens. Compare that to GPT-4’s $5 and $15, and you can see the difference.

For large scale apps with tons of users this adds up much quickly.

Is it worth it? Well that depends.

o1 is slower when handling simple tasks. So if you just want to know the capital of Spain then it’s a overkill. There’s no thinking there, just basic memory retrieval.

GPT-4 is still more efficient for everyday queries with moderate complexity.

How does it work?

What really makes o1 stand out is how it thinks through problems.

Instead of just spitting out answers, it explains its reasoning step by step. It’s like watching someone carefully work through a tough math problem, showing their process as they go.

OpenAI ran a demo where o1 solved a logic puzzle involving the ages of a prince and princess.

The model broke down the puzzle in real time, walking through the logic in a way that felt almost human. It didn’t just give the answer—it explained how it got there. This “chain of thought” approach gives o1 a serious edge when tackling complex challenges.

It’s kind of like an LLM agent, break down goals into sub-goals, possibly doing some internal multi-prompting.

Or like AutoGPT (lol) — you know that overhyped stuff no one talks about anymore.

But it’s not perfect. When you ask it simple questions, it can overthink things. For instance, ask it where oak trees grow in America, and you might get an entire essay. o1 is built for depth, not speed.

And of course it can get the chain of thought wrong — like in this popular code cracking problem.

Where o1 shines

o1 opens up new possibilities in fields like science, coding, and advanced problem-solving.

OpenAI mentioned it’s especially useful for scientific research—like generating formulas for quantum physics or solving tricky coding challenges.

In coding competitions like Codeforces, o1 performed in the 89th percentile. That’s impressive, given these contests aren’t just about writing code—they demand serious problem-solving skills.

Even in everyday tasks, o1 proves its value when complexity is high.

I saw this interesting instance where someone asked o1 to help plan a Thanksgiving dinner for 11 people with only two ovens. The model didn’t just give a recipe; it created a detailed cooking schedule, even suggesting renting an extra oven to make the day easier. That’s the kind of thinking it brings to the table.

Worth the hype?

o1 won’t replace GPT-4 for most day-to-day tasks. It’s slower, pricier, and can be overkill for simple queries. But when you’ve got a problem that needs serious brainpower—whether it’s writing complex code or solving advanced math problems—o1 is unmatched.

It probably won’t be your go-to for everything, but it’s a powerful tool for those moments when you need something that thinks, not just computes.

So, what do you think? Is o1 something you’ll be using, or are you sticking with GPT-4 for now?

These coding fonts are incredible

By Tari Ibaba / Last updated on October 2, 2024

Why do many devs keep using that boring Consolas font?

VS Code thinks it’s the best but there are so many better font options out there for you.

Here are 10 stunning fonts to spice up your coding game and upgrade your developer quality of life.

1. Fira Code

It’s extremely popular and for good reason.

This was where I first discovered the magic of ligatures.

Ligatures — those gorgeous character combos that naturalize your code.

It’s legible, open source and free to use.

Made by Mozilla (but hosted in the GitHub repo of some “tonsky” guy?)

2. Fantasque Sans Mono

An elegant font to bring out the joy in your workspace.

We used to call it Comic Sans Neue Mono because of the similarity to Comic Sans and Helvetica Neue.

3. Roboto Mono

100% chance you’ve seen a Roboto font somewhere.

YouTube, Android, Material Design… this is Google’s baby.

So this is Roboto for coding.

You’ll see it all over the place in Google Dev Docs too — Android Dev, Firebase, GCP…

4. Anonymous Pro

Made specifically for coding with excellent readability — thanks to consistent spacing and clear character descriptions.

It reminds me of the Monospace font in that Notepad++ editor I used in the past (underwhelming compared to VS Code ofc).

5. Cascadia Code

Fira Code was great but I found the characters too tall.

So I switched to this beauty that I’ve been with ever since.

Supports ligatures too:

6. Noto Sans Mono

Clean and modern font that renders perfectly across multiple screen sizes and languages.

Open-sourced and free to use.

7. JetBrains Mono

The lovely font you’ll find in WebStorm, IntelliJ and every other IDE from Jetbrains.

8. Comic Neue

It’s a comic-inspired coding font with an energetic appearance.

It may give you a certain feeling of casualness in your coding (for better or worse).

9. Pixelify Sans

The chunky, pixelated letter forms give you the nostalgia of all those old video games from the past.

10. Victor Mono

Clean and minimalist with excellent readability and gracefully cursive italics.

There’s a font here for every developer’s taste – all clear and breathtaking to upgrade your coding experience.

Don’t waste your time reading docs

By Tari Ibaba / Last updated on September 11, 2024

I was hopelessly pouring through coding books hoping for the knowledge to stick to my brain.

Reading and re-reading C++ books so I wouldn’t “forget” important string functions.

Memorizing huge swaths of random C# classes and methods (like seriously?)

But eventually I realized what a stupid waste of time this was.

I should never have paid so much attention to these random APIs and docs.

I should have focused on action.

I should have focused on general essential concepts instead of obsessing with specifics of ever-changing languages and frameworks.

Why waste so much time on API specifics when you can easily look it up on Google?

Most of the knowledge docs give only matter on a need-to-know basis.

When I need it, I will search for it and be on my way.

And eventually it will stick to my brain after I search and use it enough times — which is why action is so important — you’ll have far greater efficiency and retention when you learn by doing rather than memorizing random facts.

Look, I don’t really need to know how to loop through an array in PHP or JavaScript or whatever beforehand.

But I need to understand iteration as a coding construct and how I can use it to solve problems.

Problem solving. Isn’t that what computing is all about?

If you’re new to coding and learning say Python, your goal is NOT to become a Python expert.

Your goal is to learn how to think like a computer.

This isn’t about Python.

You learned about Python variables so you can use data storage to solve problems.

You’ll learn about Python arrays and dictionaries so you can structure data effectively to solve problems.

You’ll learn about if statements so you can make dynamic decisions for all the different scenarios a problem may bring.

So you see you learn the tool not for the tool’s sake but for why it exists in the first place.

Now you can effortlessly swap out one tool for another.

New languages can be learned on the fly: Dart, PHP, C#, whatever.

Even “weird” languages like Lisp only take a bit of familiarization to figure out:

I’m sure you can tell what this does if you’ve been coding for a while

When you look at a new problem your mind computerizes it easily.

What are the inputs and outputs? And what’s the best to represent them for efficient storage and retrieval?

What sequence of transformations are needed to act on the data and inputs to get our desired result?

What are the conditions that alter the pathways through the sequence?

How do we break the data and the transformations into more manageable units at different levels of abstraction?

All this you can do without even writing a single line of code.

And that’s the thing — coding isn’t the typing. The typing is actually more of a passive activity.

The real coding was the thinking you did by asking all the questions the above to design the solution.

Once the solution has been fleshed out, implementation is a no-brainer, whether it’s C++, PHP, Dart or JavaScript.

Stop writing code comments

By Tari Ibaba / Last updated on September 7, 2024

Most comments are actually a sign of bad code.

In the vast majority of cases developers use comments to explain terribly written code desperately in need of refactor.

But good code should explain itself. It should tell the full story.

❌ Before:

You did too much in one go and you know it — so you drop in a bad comment to explain yourself:

// Check if user can watch video
if (
  !user.isBanned &&
  user.pricing === 'premium' &&
  user.isSubscribedTo(channel)
) {
  console.log('Playing video');
}

// codingbeautydev.com

✅ After:

Now you take things step-by-step, creating a clear and descriptive variable before using it:

Comment gone.

const canUserWatchVideo =
  !user.isBanned &&
  user.pricing === 'premium' &&
  user.isSubscribedTo(channel);

if (canUserWatchVideo) {
  console.log('Playing video');
}

// codingbeautydev.com

You see now the variable is here mainly for readability purposes rather than storing data. It’s a cosmetic variable rather than a functional one.

✅ Or even better, you abstract the logic away into a function:

if (canUserWatchVideo(user, channel)) {
  console.log('Playing video');
}

function canUserWatchVideo(user, channel) {
  return (
    !user.isBanned &&
    user.pricing === 'premium' &&
    user.isSubscribedTo(channel)
  );
}

// codingbeautydev.com

Or maybe it could have been in the class itself:

if (user.canWatchVideo(channel)) {
  console.log('Playing video');
}

class User {
  canWatchVideo(channel) {
    return (
      !this.isBanned &&
      this.pricing === 'premium' &&
      isSubscribedTo(channel)
    );
  }
}

// codingbeautydev.com

Whichever one you choose, they all have one thing in common: breaking down complex code into descriptive, nameable, self-explanatory steps eradicating the need for comments.

When you write comments you defeat the point of having expressive, high-level languages. There is almost always a better way.

You give yourself something more to think about; you must update the comment whenever you update the code. You must make sure the comment and the code it refers to stay with each other throughout the lifetime of the codebase.

And what happens when you forget to do these? You bring unnecessary confusion to your future self and fellow developers.

Why not just let the code do all the talking? Let code be the single source of truth.

Your var names are terrible

❌ Before: Lazy variable naming so now you’re using comments to cover it up:

// Calculate volume using length, width, and height
function calculate(x, y, z) {
  return x * y * z;
}

calculate(10, 20, 30);

// codingbeautydev.com

✅ After: Self-explanatory variables:

function calculate(length, width, height) {
  return length * width * height;
}

calculate(10, 20, 30);

// codingbeautydev.com

✅ Even better, you rename the function too:

function calculateVolume(length, width, height) {
  return length * width * height;
}

calculateVolume(10, 20, 30);

// codingbeautydev.com

✅ And yet another upgrade: Named arguments

function calculateVolume({ length, width, height }) {
  return length * width * height;
}

calculateVolume({ length: 10, width: 20, height: 30 });

// codingbeautydev.com

Do you see how we’ve completely exterminated comments?

Like just imagine if the comment was still there:

// Calculate volume using length, width, and height
function calculateVolume({ length, width, height }) {
  return length * width * height;
}

You can see how pointless this comment is now?

Oh but yet again, we have developers writing tons of redundant comments just like that.

I think beginners are especially prone to this, as they’re still forming the “mental model” needed to intuitively understand raw code.

So they comment practically everything, giving us pseudocoded code:

// Initialize num to 1
let num = 1;

// Print value of num to the console
console.log(`num is ${num})`;

But after coding for a bit, the redundancy of this becomes clear and laughable, worthy of r/ProgrammerHumor.

Delete commented out code

They’re ugly and wishy-washy.

You did it because you were scared you’ll need it in the future and have to start all over from scratch.

You should have used Git.

Okay you’re already using Git — well you shouldn’t have written such terrible commit messages. You should have committed regularly.

You knew that if you deleted the code, it’ll be hell to go through your vaguely written commits to find where it last existed in the codebase.

Comments worth writing?

1. TODO comments

Perfect for code tasks in highly specific part of the codebase.

Instead of creating a project task saying: “come up with something better than the for loop in counter/index.js line 2”

You just add a TODO comment there — all the context is already there

2. Public APIs

One reason people love Flutter is the amazingly extensive documentation — both online and offline:

These all came from the massive amount of comments in the codebase:

3. Why did I do this?

Sometimes you need to explain why code is a certain way from a bigger-picture perspective.

Like a warning:

// Keep it at 10 or else the server will crash in v18.6.0
const param = 10;

Or check out this from React’s source code:

Yeah it’s pretty damn tough to put that gigantic explanation into code form. Here comments do make sense.

Final thoughts

Always look for ways to show intent directly in code before pulling out those forward slashes.

Comments give you something else to think about and in most cases you actually need a refactoring.

Let code lead.

1. Night Owl

2. Atom One Theme

3. GitHub Theme

4. One Dark Pro

5. Monokai

6. Dracula Theme

7. Material Theme

8. Quiet Light

9. Winter Is Coming

10. Visual Studio Theme

Final thoughts

1. Modularization on the fly: Dynamic imports

2. Promise.allSettled()

3. Optional chaining

4. Nullish coalescing

5. Go big or go home: Big Ints

Final thoughts

1. progress and meter

2. dfn

3. dialog

4. map and area

5. bdo

6. base

7. time

8. hgroup

9. kbd

10. cite

Final thoughts

1. SaaS: Build it once, sell it forever

2. Freelancing the right way

3. Create “content”

4. Coaching: Teach what you know

5. Patreon and GitHub Sponsors: Rally a community

Final thoughts

How does it work?

using

How to use it now

Final thoughts

The price tag

How does it work?

Where o1 shines

Worth the hype?

1. Fira Code

2. Fantasque Sans Mono

3. Roboto Mono

4. Anonymous Pro

5. Cascadia Code

6. Noto Sans Mono

7. JetBrains Mono

8. Comic Neue

9. Pixelify Sans

10. Victor Mono

Your var names are terrible

Delete commented out code

Comments worth writing?

1. TODO comments

2. Public APIs

3. Why did I do this?

Final thoughts

1. Modularization on the fly: Dynamic `import`s

1. `progress` and `meter`

2. `dfn`

3. `dialog`

4. `map` and `area`

5. `bdo`

6. `base`

7. `time`

8. `hgroup`

9. `kbd`

10. `cite`