DEV Community: Gaurang

ORMs: A Solution Looking for a Problem?

Gaurang — Sun, 06 Jul 2025 10:13:53 +0000

Introduction
My Initial Reaction - "These People are Mad!!"
Then Came Sequelize... And Then Mongoose
We Think It's Just Mapping
The Reality Without ORMs
- Raw SQL Everywhere
- Conditional Joins Get Messy
- Transactions And Multi-Step Logic
- Input Validation And SQL Injection Risks
Lessons from Real Projects
- Changing Column Names
- Environment-Specific Schema Hack
What I've come to realize
- When you try to build your own mini-ORM
- The "ORM but still Raw SQL" Anti-Pattern
- Not Perfect, But Worth It
- The Real Value
Summary

Introduction

When I first got into web development during my college days, the process was refreshingly straightforward. I would set up a PHP backend, execute my SQL queries using mysqli_query, and that was it - no models, no layers, just raw queries and the data I needed.

$conn = mysqli_connect("localhost", "root", "", "mydb");
$result = mysqli_query($conn, "SELECT * FROM users WHERE id = 1");

Then I was introduced to Hibernate ORM in Java. Later, Sequelize ORM in Node.js. And eventually, Mongoose ODM with MongoDB. Suddenly, everything was an object, everything had a schema, and everything required a model definition.

For those unfamiliar, ORM (Object Relational Mapping) and ODM (Object Document Mapping) tools let you interact with your database using objects in your programming language instead of writing raw SQL or database commands. ORMs are typically used with relational databases like MySQL or PostgreSQL, while ODMs are used with document databases like MongoDB. So instead of crafting a SQL SELECT statement, you call something like User.findAll() or User.save() in your code, and the ORM or ODM library handles the database part under the hood.

My Initial Reaction: These People Are Mad!!

I vividly remember my initial reaction while learning about Hibernate ORM during a Java crash course at my first job: "WHHHATT?! These Java people are MAD!" Why does everything need to be a class, a model, or a POJO object? If I can retrieve my data with a one-line SQL query, why must I now split that across three files and define models, relationships, and repositories just to achieve the same result?

It felt like some kind of object-worship cult. SQL a perfectly capable language was suddenly not allowed to sit next to Java. No, no. We must now jump through a flaming hoop of entity files and framework magic just to avoid writing SQL directly.

Then Came Sequelize... And Then Mongoose

When I switched to Node.js, we used Sequelize ORM. Same story - more models, more boilerplate, more time spent reading docs just to figure out how to define a basic relationship between entities.

Even after working with Sequelize for years, I would still have to go back to their documentation on associations to understand how to use hasOne, belongsTo, and through. Every. Single. Time.

Then came MongoDB and the Mongoose ODM. And my confusion reached a whole new level. MongoDB is supposed to be schema-less, right? And JavaScript isn't even a typed language. So why the heck are we defining schemas?

People often say that ORMs make it easy to switch between relational databases - like swapping MySQL for PostgreSQL - because they abstract away the underlying database. Fair enough. But in the case of MongoDB, what exactly am I switching to? Sure, other document databases exist but Mongoose is tightly coupled to MongoDB, so the whole "you can switch databases" argument kind of falls apart here.

And let's be real - no one's casually swapping out their database on a Tuesday afternoon. Even if you did want to, it's rarely seamless. You can't just unplug Postgres and plug in MySQL and expect things to work because "we use an ORM". If someone has actually done that flawlessly, please message me - I need to see this miracle firsthand.

Out of a mix of curiosity and a bit of rebellion, I once wrote a quick script for a one-off task that just updated some data in MongoDB. I just used the native MongoDB Node.js client — the same driver Mongoose uses under the hood — with no models, no schema validation, nothing. And it worked. Which left me thinking: if this gets the job done, why go through all the extra steps with Mongoose and its overhead?

People also say that with an ORM, developers don't need to learn SQL - they can just stick to the programming language they already know. But here's the catch: you still have to learn how to use the ORM! And most of them have their own conventions, syntax, and rules. You didn't really avoid learning something new - you just traded SQL for something else. Sometimes, something even more confusing.

In fact, I've lost count of how many times I had a perfectly valid SQL query - maybe something I got from a colleague or wrote for debugging - and then had to spend extra time figuring out how to express that same logic using the ORMs syntax. Sometimes it's straightforward, but other times it feels like translating from English to Klingon.

We Think It's Just Mapping

I came across a line - maybe in a MongoDB blog or a talk (I honestly can't recall the exact source) - that really struck a chord and got me thinking:

"MongoDB is schema-less. But your data sure follows some schema."

That line really made me pause. Just because MongoDB doesn't enforce a schema doesn't mean your app doesn't need one. Without some kind of structure, things quickly spiral into chaos - making the code harder to understand, maintain, and trust.

And that's where tools like ORMs and ODMs come in. The phrase Object Relational Mapping or Object Document Mapping sounds so harmless. Just a mapping. No big deal.

But we often lose context for why that mapping matters.

The Reality Without ORMs

Let's imagine a production-grade app built entirely without ORMs or ODMs.

Raw SQL Everywhere

Your queries end up scattered throughout the codebase - sometimes written inline alongside business logic, sometimes tucked away in helper functions. If your team is organized, maybe there's a dedicated file or folder just for SQL strings. But even then, they're just raw strings - meaning the compiler, linter, or even your IDEs IntelliSense can't catch errors, offer suggestions, or help you refactor them safely.

And that's the real problem: if there's any mistake in one of those strings - a wrong column name, a missing comma, ORDER BY before WHERE - you don't know until the query actually runs.

And if the query is buried in a rarely-used API endpoint? That bug could sit unnoticed for months. Then one day, someone calls that API, and boom - SQL error in production.

Now imagine someone renames a column or changes a data type in the DB. Good luck finding every instance of that column across your codebase. Miss one, and you'll find out the hard way.

Conditional Joins Get Messy

Let's say you're building an API to fetch employee details. If the employee is an intern, include the university_address table. If they're a manager, include the office_address table. Both have similar schemas, but they're still separate tables - so your joins and logic must adapt accordingly.

You now have two options:

Option 1: Write separate SQL queries for each case. This often results in duplicated logic - like repeating the same SELECT, WHERE, ORDER BY clauses or shared joins - across multiple queries.
Option 2: Dynamically build the query with string concatenation. That reduces redundancy, but now no one knows what the final query looks like without running the code.

Now imagine handling 68 optional joins like this. Yikes!

Transactions and Multi-Step Logic

Now imagine you need a transaction: create an employee, then insert into employee_address, and based on role, insert into either manager, intern, or director.

Without an ORM, you're manually building a query block like this:

BEGIN;
INSERT INTO employee (name, role) VALUES ('John Doe', 'manager');
INSERT INTO employee_address (employee_id, address) VALUES (LAST_INSERT_ID(), '123 Office St');
INSERT INTO manager (employee_id, department) VALUES (LAST_INSERT_ID(), 'Engineering');
COMMIT;

Now imagine you have to add logic to conditionally insert into intern or director instead of manager, handle rollbacks, and construct this dynamically in code using string concatenation - things get messy fast.

In the previous section, we saw how conditional joins can complicate a single query. Now imagine chaining multiple such conditionally-executed queries into a single transaction. It becomes more difficult to read, understand or even predict what the final query will look like.

Input Validation and SQL Injection Risks

When you build queries by stitching strings together - especially with values coming from API requests - things can get dangerous fast. You have to be extremely cautious about validating and sanitizing every input, or you risk exposing your app to SQL injection attacks. ORMs take care of this for you by using parameter binding and escaping inputs safely by default. That means one less thing to worry about every time you write a query; and a big step toward keeping your APIs secure.

Lessons From Real Projects

Here are two real work experiences that I've faced.

Changing Column Names

At work, we sometimes had to rename DB columns. With JPQL, all I had to do was update the field name in the entity class. Done. The app might throw a few syntax errors on startup, but once fixed, everything stays consistent.

With native queries? Total pain. Every single query using that column had to be updated. And that could be in hundreds! Miss one, and it quietly fails later when someone happens to hit that endpoint.

Environment-Specific Schema Hack

Once, our client didn't want to set up a separate database instance for pre-prod environment. Instead, they asked us to create a different database schema in the same instance.

Now, Spring Boot allows us to configure a custom strategy to set the schema name. But it only applies to the JPQL queries - the ones that are ORM-based. And since most of our queries were native, we had to create a Java file with the schema names, exclude it from Git, and manually place a different version on each environment's server. We also had to update all our queries to use the schema name from the Java file.

It worked. But it was fragile, ugly, and easily avoidable if we had relied more on ORM features.

What I've come to realize

I used to think that ORMs were just bloated frameworks trying to make simple things harder. But over time, I realized they're actually solving the problems you don't even know you'll have - until its too late.

🛠 When You Try to Build Your Own Mini ORM

Let's be honest - if you're going to pull out query strings, schema names, and column names into separate files, and then write logic to stitch strings together based on conditions... aren't you basically building your own mini ORM? You're solving the exact problems that ORMs are designed to handle.

Only now, its more error-prone, less generic, and tightly coupled to your project. ORMs already do this - and they do it better, more reliably, and in a way that works across projects and teams.

🚨 The ORM But Still Raw SQL Anti-Pattern

Imagine you buy an expensive bed for your cat… and it still sleeps in a cardboard box.
Or you visit a doctor, get prescribed medicine… and then never finish the course.
Or you buy nice clothes, only to leave them unworn in the closet.

Frustrating, right?

That’s exactly what it’s like when a project includes an ORM — but developers still write most of the queries in raw SQL. You're adding the overhead, but not reaping any of the benefits.

I've seen codebases where an ORM was technically in place, but nearly all queries were still written natively. In that case, you're getting the worst of both worlds - extra boilerplate from the ORM, and all the risks of raw SQL.

To be clear, most ORMs do let you run raw queries — and that’s by design. It’s meant as a fallback, for when you have a complex SQL query that the ORM syntax can’t express easily. But that’s a backup plan, not the main plan. If you find yourself reaching for raw queries by default, you’re not really using the ORM — you’re just working around it.

A lot of times, teams stick with raw queries because learning the ORM feels like extra work. Or they were told to use it, so they did - but without really getting why it matters. And in the end, they miss out on everything the ORM was supposed to help with.

If you're using an ORM, native queries should be your last resort. The more you rely on raw queries, the more you defeat the purpose of using an ORM in the first place.

As your project grows, you’ll eventually run into a moment where you think,
“We already have the ORM. This would’ve been trivial if we just used it properly.”
But by then, the ORM feels useless — not because it didn’t work, but because we never used it the way it was meant to be used. The tool had the power to help — and yet we couldn't tap into it when it mattered most.

🧩 Not Perfect, But Worth It

Sure, they aren't perfect. Sometimes the queries these ORMs generate are messy. Sometimes they feel overkill for basic stuff. Sometimes, they get in the way. But they solve real problems. They handle transactions, conditional logic, rollbacks, query sanitization - all in your apps native language. You write clean logic. It handles the mess behind the scenes.

🧱 The Real Value

They're not just "mappers". They're your defense against chaos that give you:

🔒 Safer queries
🔧 Easier maintenance
🔄 Smoother schema changes
🔁 Better handling of relationships, conditional logic, and transactions

It's not about being able to switch databases or not having to learn SQL. It's about building something that wont fall apart when things get complicated.

Summary

ORMs and ODMs can feel like unnecessary overhead in small projects or one-off scripts - and in these cases, skipping them is perfectly fine. But as your codebase grows, raw queries introduce real risks: scattered queries, fragile string concatenation, and painful schema changes. ORMs and ODMs bring structure, safety, and consistency that scale with your application.

This article isn't about always using ORMs - its about understanding why they matter.

You can get things done without them - but when things get complex, you'll be glad you have them.

P.S. This turned out to be a long one - so if you made it all the way to the end, thank you! 🙌 I hope it gave you something to think about. If you have any questions or thoughts, feel free to leave a comment below. And if you found it helpful, a like or share would really mean a lot! 😊

[Node.js] How to Use Promises in a Callback-based Codebase

Gaurang — Sun, 01 Jun 2025 05:58:21 +0000

Hi! I'm Gaurang. I’ve worked extensively with Node.js in the past, and during that time, I spent a lot of effort wrangling with different async patterns — callbacks, promises, and async/await. This article is part of my series, My guide to getting through the maze of callbacks, promises, and async-await, where I share lessons learned and best practices for writing asynchronous code in Node.js.

This article assumes you’re familiar with basic Node.js concepts, especially asynchronous programming constructs like callbacks, promises, and async/await.

Converting a Promise-based Function to Use Callbacks
Prefer Then-chaining over nesting

Converting a Promise-based Function to Use Callbacks

Often, you’ll find yourself working in older codebases where asynchronous functions are written using the callback pattern. Node.js also offers a built-in way to convert a Promise-returning function into a callback-based one using util.callbackify().

Personally, I believe we should avoid writing new callbacks whenever possible. Even in a callback-heavy codebase, it's often worth introducing promises or async/await for better readability and maintainability.
I’ve spent years digging through callback-infested codebases, and I’ll say it plainly: callbacks are obsolete. They had their time, but that time is over. Stop writing them. Let them die.

Use this only when absolutely necessary — like when you're deep in a legacy callback jungle and need to drop in a Promise-based function without rewriting everything around it.

Prefer Then-chaining over nesting

It's common to see people misuse promises by nesting .then() calls instead of chaining them. This leads to "Promise hell", which is structurally similar to "callback hell."

Callbacks are difficult to work with primarily because of their deeply nested structure. Promises were introduced to address this by enabling a more linear, manageable code flow.

Of course, code with then-chaining may not be as readable and intuitive as synchronous code or code written with async-await. But it is more manageable than code with nested thens.

For a deeper dive into why Promise hell is best avoided — and how to write cleaner promise chains — check out these excellent articles:

Please don't nest promises

Basti Ortiz ・ Jan 6 '20

#javascript #node #programming #tips

How to escape Promise Hell. Unlike Callback Hell, Promise Hell is… | by Ronald Chen | Medium

Ronald Chen ・ Dec 15, 2018 ・
Medium

Keep in mind that it’s not just .then() chains you need to keep clean — don’t nest callback-based functions inside a .then() either. This is a common mistake that defeats the purpose of using Promises in the first place.

If you’re already using Promises, don’t go back to callbacks mid-way. Promises are designed to give you a linear, manageable control flow — and the moment you reintroduce nested callbacks, you throw that benefit away. Whether you’re nesting callbacks or .then() blocks, the result is the same: harder-to-read code.

Instead, convert the callback-based function into a Promise using any of the methods discussed in my previous article "Using callback-based functions when the rest of the code uses Promises" and keep your chain linear.

Notice that readFile2CB is a callback-based function. If you nest it (as shown in the bad-code example), any code that relies on content2 or results must go inside that nested block. Over time, this leads to deeply indented, harder-to-read code — exactly the kind of mess Promises were created to prevent.

Once you start using Promises, commit to the pattern. Nesting defeats the purpose. Whether you’re nesting .then() blocks or stuffing callbacks inside them, you’re trading away clarity and maintainability — the very reasons Promises exist.

If you're stuck in a callback-heavy codebase, I feel your pain. Use these patterns sparingly, but push for modern async functions where you can — your future self (and your teammates) will thank you.

I've put a lot of work into this article. And I hope that it has been helpful. If you have any questions, please feel free to leave a comment below. I'd really appreciate it if you could like and share the article! 😊

[Node.js] Using callback-based functions when the rest of the code uses Promises

Gaurang — Sun, 21 May 2023 12:08:58 +0000

Hey!

My name is Gaurang and I've been working with Node.js for the past 5 years. This article is part of the "My Guide to Getting through the Maze of Callbacks and Promises" series. It's a 3-part series where I talk about writing asynchronous code with Node.js.

The articles are intermediate-level and it is expected that the reader already has basic familiarity with Node.js syntax and the constructs related to asynchronous programming in it. Such as callbacks, promises, and async-await.

Introduction
Using util.promisify
Creating a new Promise
Create a Promise/callback dual-behaviour wrapper
Conclusion
Footnote

Introduction

Promises were introduced in JavaScript in 2015 - just 8 years back from the date of writing this article. Async-await was introduced in 2017 - just 6 years back. That was not a very long time ago. (At least not enough to eradicate the use of callbacks 😢)

As a working professional, you often need to work with legacy code. So as a JavaScript/Node.js developer, God forbid, you may have to work with callbacks at some point. And I'm assuming that you've had enough exposure to callbacks to understand the general dread that they bring.

It takes time to get a hang of writing code with callbacks. For those without prior experience with asynchronous programming, it is no different than bullfighting for the first time. For this reason, I believe they try to stick to the sync version of async functions. If you've read my previous article in the series, you would know that this approach is more damaging than it is helpful.

My personal opinion is that the best way to deal with callback-based functions is to convert them into promise-returning ones.

Suppose, you're working on a Node.js-based project. You created new modules (it could be APIs, controllers, utility services, etc.); everything using promises and async-await. However, there are some legacy functions written using the callback approach. You need to call one such function but don't want to give birth to a callback hell.

There are 3 ways of going ahead with this.

Use util.promisify (My favourite)
Create a new promise.
Create a smart wrapper that can get you either a callback or a Promise based on your requirement

Using `util.promisify`

A lot of people don't know about this gem that was introduced in Node.js version 8. If the legacy callback-based function uses the standard error-first callback style and the callback is the last argument, you can create a promise-returning function with minimal code using util.promisify.

You have to be careful using it with functions that belong to a class/object though.

If you're new to the bind function and are not sure what the object context is, here are a few great resources that may help:

One of the best things about util.promisify is that it works flawlessly with Node.js native library methods such as functions belonging to modules: fs, child_process, etc. You can use it to promisify setTimeout as well.

Creating a new Promise

If the callback-based function doesn't follow proper conventions. Or for some reason, util.promisify doesn't work for you, you can always create a custom new Promise.

You can move the Promise-creation to a separate function if doing it inline looks shabby.

Note: Here, promisifiedAsyncFunction does not use async-await. But, it returns a Promise. So, we have to use await in the main function while calling promisifiedAsyncFunction

If the callback-based function belongs to a class/object, you'll need to take care of the context.

Create a Promise/callback dual-behaviour wrapper

If you have access to the source code of the original callback-based function. And the authority to modify it, you can create a wrapper around it. This wrapper will work as a callback-based function if a callback is provided. If not, it'll return a Promise.

This dual-behaviour wrapper lets you work with Promises in new code that you write. Without disturbing the old code where the function is expected to work with a callback. Thus, it provides Promise support with backward compatibility for callback-based legacy code.

Previously, if the module exported the callbackBasedAsyncFunc function, now it can export the dualBehaviourWrapper.

// Previously
module.exports.callbackBasedAsyncFunc = callbackBasedAsyncFunc;

// Now
module.exports.callbackBasedAsyncFunc = dualBehaviourWrapper;

Thus, with minimal modification, you can add Promise support to a legacy module. And all the other existing modules, that are calling callbackBasedAsyncFunc by passing a callback, remain unaffected. Win-win!

You might have noticed that a lot of popular NPM libraries give similar dual-behaviour support for their functions where they use a callback if it is passed, and return a Promise if a callback is not passed. Their implementation may be different though. For example, mocha.js

Conclusion

Overall, handling callback-based functions when the rest of your code uses promises can be a bit tricky. However, by following the tips in this article, you can make the process much easier. With a little practice, you'll be handling callback-based functions like a pro in no time!

I've put a lot of work into this article. And I hope that it has been helpful. If you have any questions, please feel free to leave a comment below.
I'd really appreciate it if you could like and share the article! 😊

Footnote

fs version 10 introduced Promises API which has promise-based versions of functions. Have a look at the documentation. So you don't need to struggle with callbacks or manually convert fs functions to Promise-based ones.

[Node.js] Why using sync versions of async functions is bad.

Gaurang — Sun, 05 Mar 2023 15:08:14 +0000

Hi!
My name is Gaurang and I've been working with Node.js for the past 5 years.
This article is part of the "My guide to getting through the maze of callbacks and promises" series. It's a 3-part series where I talk about writing asynchronous code with Node.js.

Sync of Async what?
What's wrong with using sync versions of async functions?
Conclusion

Sync of Async what?

Before I go ahead and beef about synchronous functions, I should briefly describe synchronous as well as asynchronous functions.

Many Node.js packages provide synchronous alternatives of their asynchronous functions.
For example, the fs package has fs.readFile (which works asynchronously) and fs.readFileSync (which works synchronously).

The working of fs.readFileSync is similar to traditional functions.
Your program calls the method and waits for the file to be read. Once the file is completely read, it returns the contents. The program then resumes execution of the rest of the code.

Now reading a file is a slow I/O operation that could take a few seconds.
So when our program calls the asynchronous fs.readFile method, it does not wait for the method to read the entire file and return the contents. Our program moves ahead with the execution of the rest of the code immediately; while fs.readFile continues with the reading task in parallel.

If there's any code you want to execute after the file contents have been read, you need to wrap the code in a function and pass that function to fs.readFile as a callback function.
fs.readFile will call the callback function as soon as the file contents have been read.
This way of writing code is an engineering choice made by the creators of JavaScript/Node.js that allows it to be extremely fast despite being single-threaded.

Here's a sample script demonstrating the difference between synchronous and asynchronous programming in JavaScript.

What's wrong with using sync versions of async functions?

I often come across codebases where callbacks, promises, and async-await have been mixed together. Turning the code into a hotchpotch.
I sympathize with the people that have to work with such codebases.
Understanding callbacks and promises is difficult. Writing code with callbacks is difficult. Understanding the difference between synchronous and asynchronous functions is difficult.

The advent of async-await has made writing code in JavaScript fairly straightforward. And so, most people learning JavaScript today do not know what a pain it used to be when using callbacks was the primary method of writing code. As a result, they often lack experience in handling callbacks.

People often retreat to synchronous versions of library methods because they're more convenient. E.g. fs.readFileSync, fs.writeFileSync, fs.copyFileSync, child_process.execSync, etc.
In my opinion is one of the worst things to do to your project.

People generally opt for Node.js due to its reputation for fast network and I/O operations. However, it's crucial not to overlook the fundamental reason behind this efficiency: Node.js's single-threaded, asynchronous execution model! Utilizing synchronous versions of I/O and network operations can significantly impair your application's performance compared to counterparts developed in alternative languages.

Asynchronous functions are designed to be non-blocking and to avoid delays. As Node.js is single-threaded, just one long-running synchronous (blocking) task is enough to degrade the performance of the entire application. Using synchronous versions of asynchronous functions may seem like an easy solution at first, but it is the devil in disguise. It can cause delays all over the application; leading to frustration for developers and users alike.

Of course, if you're writing a small independent one-time script, it may not matter much. But in large production-level applications, this is going to cause unnecessary bottlenecks.

Here's a short demo of how a synchronous method call affects the rest of the application.

This script starts a barebones Node.js server that has three APIs.

GET /quick-api
GET /slow-sync-api
GET /slow-async-api

The quick-api API is supposed to return a response immediately.
But, if you call quick-api after calling slow-sync-api, it does not return until slow-sync-api returns. This is because Node.js is single-threaded. And slow-sync-api calls a synchronous method that does not let the main thread do anything else till its execution is complete. It blocks all other requests.
However, if you call quick-api after slow-async-api, the quick-api works as expected. This is because slow-async-api does not block the main thread till its execution is complete. The work of the asynchronous function is deferred to a worker thread and the main thread waits for the execution to complete. Meanwhile, the main thread is free to fulfil other requests.

Conclusion

Asynchronous execution is integral to JavaScript. So, you'll find asynchronous functions everywhere. Transitioning from a traditional synchronous mindset to an asynchronous one takes some adjustment.

However, using the synchronous versions of asynchronous functions is a bad practice. It can lead to unexpected behavior and performance bottlenecks. When performing asynchronous operations, it's best to use the asynchronous version of functions whenever possible. This will help you avoid any potential problems and ensure that your code is as efficient as possible.

Might I introduce you to my friend TypeScript?

Gaurang — Sun, 03 May 2020 11:04:24 +0000

The lead-up
Why interfaces in JavaScript make no sense
Might I introduce you to my friend Typescript?
Do I really need it though?
Conclusion

The lead-up

A few days back, I wrote an article explaining the concept of interfaces in Java (or object-oriented programming in general). In the process, I also debunked a popular myth that I found to exist among Java novices.
I was glad to find that it was so well received. (Thanks all of you awesome people! You rock!! :D )
I want to address this particular comment though.

Richard Andrews • Mar 23 '20

Great read. Love the analogies. But I'm a javascript developer and there is no support for interfaces in javascript currently. How would I create a contract for other developers to follow?

My answer to this (the short one) is "You can't. Nope. No. Nada. Zilch. Naught". You don't have interfaces in JavaScript.
And I don't believe there exists any other way to enforce method contracts in JavaScript the way you do in Java with the help of interfaces.

Why interfaces in JavaScript make no sense

With the help of interfaces, you define three things in Java:

What methods should compulsory exist
The input of these methods - how many parameters they will take and what shall be the data-type of each
The output of these methods - what shall be the data-type of the returned value

When you're talking about having interfaces in JavaScript, you're probably only thinking about point 1. But, what about points 2 and 3?


    
function dummyMethod(definedParam1, definedParam2){
    // arguments is a special object that exists inside every JavaScript function.
    // It contains all the input-parameters passed to the function.
    console.log(arguments)
}

dummyMethod("a", "b");
dummyMethod();
dummyMethod("a", "b", "c", "d", "e");

You can see that the function dummyMethod is defined to take exactly 2 parameters as input.
But, regardless of whether I pass less parameters or more, the function takes them without complaining.

Not only does JavaScript lack the kind of type-checking that happens in Java. But also, there's no policing on the number of arguments of a function.
Furthermore, JavaScript has no notion of 'return type of a function'.

For a language like Java which is statically typed, it makes sense to have interfaces. There, things break if methods are called with the wrong parameters.
But JavaScript follows duck-typing; which is considered to be the antithesis to interfaces.

Nov 5 '16

214

Simple Explanation

What is duck typing?

“If it walks like a duck and quacks like a.... ” - YES, but what does that mean??!

Short answer: We're interested in what "objects" can do, rather than what they are.

Let's unpack it with an example:

See below for further…

Open Full Answer

Nov 10 '15

Consider you are designing a simple function which gets an object of type Bird and calls its walk() method. There are two approaches you can think of:

This is my function, and I must be sure that it only accepts the Bird type or the code will not compile. If…

Open Full Answer

Might I introduce you to my friend Typescript?

TypeScript is really just JavaScript + types. Or as they call it, the typed super-set of JavaScript.
So, remember how you write int total, boolean isEmpty, String name in Java/C++. Yeah, Typescript is basically JavaScript with all that.

TypeScript Tutorial: A step-by-step guide to learn TypeScript

Amanda Fawcett for Educative ・ Feb 17 '20

#typescript #javascript #beginners #webdev

TypeScript doesn't let you pass more parameters to a function, or less, than what has been defined.
It also doesn't let you pass parameters of the wrong type.

// Source: https://www.typescriptlang.org/docs/handbook/functions.html
function buildName(firstName: string, lastName: string) {
    return firstName + " " + lastName;
}

let result1 = buildName("Bob");                  // error, too few parameters
let result2 = buildName("Bob", "Adams", "Sr.");  // error, too many parameters
let result3 = buildName("Bob", "Adams");         // ah, just right

Now that we've introduced types to JavaScript, it makes lot more sense to have interfaces. Undoubtedly, TypeScript has them.

// Source: https://devblogs.microsoft.com/typescript/walkthrough-interfaces/
interface Greetable {
    greet(message: string): void;
}

function helloEnglish(g: Greetable) {
    g.greet('Hello there!'); // OK
    g.greet(42); // Not OK -- 42 is not a string
    g.greep('Hi'); // Not OK -- 'greep' is not a member of 'Greetable'
}

Note that the type system of TypeScript is like an add-on over JavaScript. It is not a separate language.
A script written in TypeScript is not runnable on its own.
When you run the compiler over your .ts file, it gets converted to a normal JavaScript file without types.
You can even check out their playground and see it live how TypeScript gets converted to JavaScript. Check out their examples. It's fun! :D

Do I really need this though?

If you're an indie developer, who has spent considerable time working with vanilla JS, you might've grown fond of the type-less flexibility, and smartness of the language to dynamically infer the type of variables. Without bothering you, so that you can focus on writing your logic.

You might be wondering whether this overhead of declaring types is really worth it or is just an unnecessarily glorified self-infliction.
Maybe it's part of some grand propaganda conjured by Microsoft, spread by Java/C++ cult-followers, and backed by those pretentious developers who grill you for not following a certain coding standard, or ask a random language-quirk related question in interview and judge the candidate critically for not knowing the answer.

Well... Your suspicions might as well be true. I have no proofs to tell you otherwise. ¯\_(ツ)_/¯
But, here's the thing. Just by looking at the name, you can't tell if total is a Number or String. You'll have to trace it back to where it's defined to know that. If it's a value being passed from another function, you'll need to trace it back there as well.
The flexibility of JavaScript might feel like a boon when you're writing your software ground-up. But it feels like a curse when you're receiving a knowledge-transfer (KT) session from another developer.
Larger the codebase and larger the number of people that have worked on it, the more difficult it is to understand it.

Also, while writing your own feature, you'd obviously want your code to be resilient to the mistakes of previous code. So, you can't trust it. And you'll need to deliberately cast it total = Number(total).
If you get a Nan, you can handle it accordingly.
Imagine if yours is an e-commerce website with the user-base of lakhs. You miss this said case and your code goes to production just before a major sale. A user clicks on checkout and boom! Server crashed!

Forgive me if the scenario sounds a little presumptuous. But, at the very least, you must agree that it is plausible.
Just Google "common JavaScript mistakes". Most results will list at least one mistake that is related to types.
Specifically, the ones related to + operator and strict/loose comparison or type-coercion.

Consider this tweet:
// Detect dark theme var iframe = document.getElementById('tweet-1161012147884707840-194'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1161012147884707840&theme=dark" }
Confused?
Here, + "a" turns into NaN (Not a Number. Yes, that's a thing in JavaScript) because + acts as the unary plus operator that tries to cast any value to a number. And "a" is literally not a number.
Thus, "b" + "a" + + "a" + "a" becomes "ba" + NaN + "a".
Now, the NaN gets cast to a string and "ba" + NaN + "a" transforms to "baNaNa".
Convert it to lowercase and that's how you get "banana".


    
console.log(("b" + "a" + + "a" + "a").toLowerCase());
console.log(+"a");
console.log("ba" + NaN + "a");
console.log("baNaNa".toLowerCase());

With a type system in place, you just immediately know whether a variable is a string or a number or something else altogether. (Who knows.. It could be an object, for heaven's sake!)
And say, if you're assigning a string to a number variable, the error will be caught immediately at compile time.

"I completely understand that if you're a single person writing a large JavaScript application where you know exactly what every object is. And you've made it all. And it's beautiful. And it's fast. And you can change it into any other thing that you want, because you know everything about it in your head, right?

But once you start programming larger apps in teams. Y'know, we just find that teams want to have the ability to agree upon [that] in between these two modules, we have to follow a contract. And they want to have things that can validate that they're adhering to the contract. Y'know, you can't just like run into each others offices and like compare code all the time.

You want to have some sort of agreed upon way that you write this down. And you also want, when new people come in, something that tells you a bit about what this 100-1000 line codebase does. How am I supposed to understand what this paramteter x is. I don't know. I don't know x. Tell me! With an annotation, right?"

— Anders Hejlsberg, What is TypeScript and why with Anders Hejlsberg [13:30]

Here's another cool thing.
If you use Microsoft VS Code, and you've been using its IntelliSense features (code-completion, parameter info, member list, etc.), they are powered by TypeScript.

Conclusion

Even with the absence of types and interfaces, I've seen great software written by people in vanilla JavaScript; mostly at startups with small teams though.
So, if vanilla-JS is your thing, there's nothing wrong in using it.

But, if you're working on larger projects, or/and you're bothered by the lack of interfaces in JavaScript (and by extension, lack of types), you should consider using TypeScript.
It'll definitely increase your productivity and your team's.

Do you go back to edit your published articles?

Gaurang — Thu, 09 Apr 2020 03:27:35 +0000

Hey Dev's!

So I've been wondering. I often spend days to write an article.
'Cause I never feel the article is complete and ready to be published.
Does the content make sense? Is it relatable? Did I spend all this time just rambling?
Maybe there's a wrong assumption? Wrong fact? Did I make a googie?
Maybe it's not relevant to other people? Maybe it's bland? Maybe I should add a diagram? Or an example?

When I feel that the article is decent enough and I've gotten tired of editing it, I quickly publish it before I can change my mind.
And being the self-obsessed person that I am, I often come back to reread them.
And often I feel like, maybe I could add reference to that article that I recently read. That quote. Maybe this Codepen.
Maybe active voice would've sounded better than passive here.

Once it gets into my mind, it bothers me that something is amiss in my article. And I edit it.
So yeah, here's my question.

Do you guys do it too? Do you edit your articles if you find something to add/change in it?
Or once it's published, you don't touch it again at all? Like, religiously. Add comments instead maybe?
Or add new stuff with a new "Edited" section.
Or store your ideas till you have enough of them to make another independent article?
"You're crazy Gaurang. Nobody thinks about their articles so much. Here, have a cookie 🍪"

PS. I took more than half a day to post this question

Do you really understand interfaces?

Gaurang — Sun, 15 Mar 2020 14:52:38 +0000

The lead-up

When I was learning Java in college, I did not understand the use for interfaces.
You can't define functions inside an interface. You can only declare them. You have to have a class implement the interface to define it's functions and then use them.
That's crazy! Pretty worthless piece of crap I would think. I can just write my classes and their functions normally. Why would I declare them in one place and define in another.
I don't even need to declare them. Just write my functions normally in a class. It's totally redundant.

Confused and curious, I asked my teacher why I would ever require to implement an interface.
Almost immediately, she said that interfaces let you achieve multiple inheritance, while normal classes don't - the textbook answer on the difference between classes and interfaces.
And I was like, so? Even if my class can implement multiple interfaces at once, none of them would contain function definitions.
They would all be pretty useless. I can just drop them all and write my class without implementing them. Be it single or multiple, what advantage do I get by using interfaces?
My teacher did not have an answer to that.

With the lack of a proper answer, me and most (if not all) of my friends resigned ourselves to accept that interfaces are some kind of mysterious artifacts. That, given the right incantation, would help us manipulate the space-time continuum, rip through the fabric of Java ecosystem and use multiple inheritance - the fruit that is wrongly forbidden from us.

Meanwhile, we gave the same answer during our engineering vivas that my teacher gave me. And wrote the same in our written exams.
Something felt off though. And I could never digest this.
It wasn't until later, when I dabbled with Android that I really learnt the purpose of interfaces - as a contract which lets you to enforce that, the classes you work with, exhibit certain behavior.

I still come across people whose primary understanding of interfaces is something that allows multiple inheritance in Java.
And that is so ridiculous - saying that interfaces support multiple inheritance while classes don't, when I ask you what's the difference between the two.
It's like saying that the difference between a dog and a horse is that a dog barks while a horse neighs.
While that is indeed true, you must understand that dogs and horses are fundamentally different animals!
If your understanding of a horse is that of a dog that neighs. Then boy! You're going to have a wild time in a farm!

Deadly Diamond of Death

First off, lets understand why multiple inheritance is not allowed in Java.

Consider there's a class 'Animals'. All animals makeNoise().
We derive two child classes from this class - 'Horses' and 'Dogs'. Both of them override the makeNoise() behavior.
Horses makeNoise() by neighing. Dogs makeNoise() by barking.
Now suppose, for whatever godforsaken reason, a mad scientist decides to mix up the genes of Horses and Dogs together, and make a new species of Animals - Horgs.
When the Horgs makeNoise(), will they bark? Or will they neigh?
This is the infamous diamond problem (aka Deadly Diamond of Death) in object-oriented programming.

Java doesn't support multiple inheritance with classes simply because inheriting multiple classes together is problematic.
If a class inherits multiple other classes, and these classes contain functions with the same signature, there arises an ambiguity - when I call the said function with an instance of the inheriting (derived) class, how should it behave?
Out of the many function definitions coming from multiple inherited classes, which should be considered?
And how do I control which definition is used when?

C++ tries to handle the Diamond problem using virtual inheritance and scope resolution.
I'm not really a C++ person. And I don't understand how virtual inheritance works.
But, from what I understand, it requires prior knowledge that a certain function may get involved in multiple inheritance. And it requires to be specially handled.
Now that feels weird to me. I did not find many articles on the topic. So, maybe not many people use it. But, please do recommend me any good material on the topic if you have any.

How interfaces solve the diamond problem?

They don't.
Like I said, they're not a mechanism to allow multiple inheritance. It's just that since interfaces don't have method definitions, they don't have the diamond problem.
That is why you're allowed to implement multiple interfaces. That's all.
But the notion that, the use of interfaces is to enable multiple inheritance, is wrong and far from the truth.

The idea behind interfaces

Consider you're a king. You have a beautiful daughter who has reached the age for marriage.
A lot of princes' from the neighboring nations are eager to marry your daughter. But, you have some basic criteria in mind that they should fulfill before they could be considered to marry your daughter.

The Prince should be able to fight. 'cause that's a necessary skill to have for a prince
The Prince should like reading books. 'cause books contain knowledge. And you'd want your son-in-law to be well-educated and wise.
The Prince should be able to speak Klingon. 'cause that's the sign of a superior man.

You write these requirements down on a big banner and place it above the castle gate.
If a Prince comes and satisfies all these conditions, the gatekeeper awards him a 'Badass Prince' badge and sends him in.
If, however, the prince doesn't meet these requirements, the gatekeeper of the castle won't even allow him inside.

Now, this is exactly the idea behind interfaces.
The banner with the requirements on it is an interface for a 'Badass Prince'. And by enforcing those requirements on the prospective Prince, you're essentially requiring them to implement the 'Badass Prince' interface.
Thus stating, that if a Prince is not a 'Badass Prince' (as defined by your interface), they're not eligible to marry your daughter.

The practical use of interfaces while writing software

If you know a class implements an interface, then you know that class contains concrete implementations of the methods declared in that interface, and you are guaranteed to be able to invoke these methods safely.
— StackOverflow answer

Often, different teams work together to develop a product. They may work on different features or segments that are integrated together to form the final product.
In such a case, it is obvious that there will be certain inter-dependencies within the teams.

Say for example, we're building an e-commerce website. One team is developing the 'Add-to-cart' feature (the process before checkout). And another team is working on the online-payment system (the process after checkout).
We definitely can't make the online-payments-team wait and idle till the cart-team has finished and tested their feature.

But then, if both the teams start working on their features in parallel, how do we ensure that we'll be able to integrate the online-payments with the cart? In the end, both the features should come together to form the final product, right?
For example, the online-payments team needs the cart to be cleared on successful payment. But, since the cart is not ready yet, how would the payments-team do that? What function should they call? What parameters should they pass to it? What if the cart team doesn't implement such a function at all? And instead, you have to write logic to remove every product from the cart individually?

To mitigate such problems, both the teams must brainstorm about the technical requirements of their own features and realize the inter-dependencies. Once that is done, both the teams can design appropriate interfaces.
For example, the teams decide that on checkout, the cart-system will provide a MyCart object to the payments-system. This MyCart class must implement the Cart interface that has the following methods:

1. void addProduct(Product product)
2. Product removeProduct(integer productId)
3. List<Product> getProductsFromCart()
4. boolean emptyCart()

If object provided by the cart-system does not come from a class that has implemented the Cart interface, then the payments-system will throw an Exception.

if(!(myCart instanceof Cart)){
    throw new Exception("Expected an instance of Cart");
}

Due to the principle of abstraction in object oriented programming, the payments-team does not need to know how the emptyCart method works. They just need to know:

that it exists
that it is intended to do what they want (clear all products in the cart)
how to call it (what parameters to pass and what to expect in return).

Out of these, interfaces take care of points 1 and 3. Point 2 is left to the human intellect.

Basically, by asking the cart-team to implement the Cart interface, the payments-team says,

"Hey cart-team,
We are not concerned about the logic and implementation on your side.
But, we require certain functionality to be present in the object that you pass to us. And we require it in a very specific manner (with so and so name, so and so parameters, so and so value returned).
Please implement these exactly as specified so that we can just plug your cart-system into our payment-system. And we can have a seamless integration."

This was just a simple example of when an interface is used. There might be more. But, I hope it helps you to understand what an important role the interfaces play in software development.
If you can think of more examples, please let me know in the comments.

In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information.
...
An interface is thus a type definition; anywhere an object can be exchanged (for example, in a function or method call) the type of the object to be exchanged can be defined in terms of one of its implemented interfaces or base-classes rather than specifying the specific class.
— Wikipedia

Also, a lot of people relate interfaces with legal contracts. This is because interfaces are based on mutual agreement between two parties; on how one party could use the services of another.
You meet the requirements in the contract. And you shall enjoy our uninterrupted services.
You fall short on the terms of the contract, we shall no longer serve you.

A contract is like a promise between people. It is an understanding, a deal between two or more people or organizations to do certain things.
— Arts + Law article

To conclude..

Multiple inheritance is problematic.
Java novices often wrongly associate interfaces with multiple inheritance. That's not what they are for.
An interface is actually a pretty powerful construct that lets you define the requirements of your software component. It also lets you enforce that other software components, that interact with yours, meet those requirements.

Official Oracle documentation

Oracle has provided some really awesome documentation on interfaces. So, please check out the following links and look around.

The odyssey of asynchronous JavaScript

Gaurang — Wed, 30 Oct 2019 16:34:08 +0000

The lead-up
Events, event-handlers and callbacks
- Issue with callbacks
Promises
Co-routines
- Generators
- Co-routines
Async/await

The lead-up

When I was learning JavaScript (about 1-2 years back), my mentor had me go through it step-by-step. So, first I spent some time to get comfortable with callbacks. Then I jumped onto Promises. And then, after months, I started using Async-await.

Due to this reason, I was exposed to a number of flow-control methods and practises that evolved around JavaScript; which I would've missed otherwise - simply because of the fact that I wasn't part of that generation.

Just like how our grandparents complain about how easy our generation has it due to the existence of internet, mobiles, electronic devices, etc. I strongly believe that in the next 2-3 years, we'll complain about how easy the JS-newcomers have it since they do not have to deal with callback-hell and all the other struggles of the "pre-Promise" era. To them, it'll probably just be a textbook paragraph on the history of JavaScript that no one really cares about; except for the compulsory 1 mark question that is asked from it.

When I was in college, I had no idea what 'asynchronous' meant. Coming from the world of C++, PHP, and Java, the word 'asynchronous' was completely alien to me. I had vague understanding of multi-threading in Java and I dreaded it. I've come a long way from there! 😌

My intention of writing this article is simple.
It is my humble attempt to immortalize the evolution of writing in JavaScript before it's too late and forgotten; in a way that even non-JS people can appreciate it. Even if they don't completely understand the specifics, as they're not familiar with JavaScript constructs, I'm trying to keep it so that they can at least get the general idea.
Yet, if something doesn't make sense, or you want to talk more about it, feel free to reach out.

Events, event-handlers and callbacks.

This is from the pre-historic times.
If you have enough experience, you must've definitely come across event-driven systems - Visual Basic, OnClickListener() in Android, onchange behavior in HTML, etc.
Since node is primarily an event-based runtime environment, all it had initially was events and event-handlers.
Event-handlers are just functions that are triggered once a certain event is fired/emitted. Just like the onChange behaviour in HTML.

Simply put, it means something that occurs after an unknown amount of time, so don't expect immediate results.

For example, "Mom, can I have five dollars?"

Putting my hand out for money is me expecting her to immediately respond by giving me money (synchronous).

Realistically, she will look at me for a moment or two, and then decide to respond when she wants to (asynchronous).

— Kai (StackOverflow)

Due to the asynchronous nature of JS, the system wouldn't wait while, say, you get some data from a database (It was really difficult to wrap my head around and get used to this initially).

However, events enable you to put your work on hold when Node.js realises that it is an async task you're performing; and then lets you resume your work when the task has completed and data is available.

In JavaScript, functions can be passed as arguments to other functions and functions can return functions. Such functions are called higher-order functions - similar to how a person who manages other people under him is considered to be at a higher level or position.
Thus, a pattern emerged where a function will be passed as the last parameter to an asynchronous function; called a callback function.
Under the hood, this function would become the event-handler for the concerned event.

Issue with callbacks.

There are hardly any practical applications that may not involve async operations.
The advantage of using Node.js is that time-consuming async operations don't affect the performance of your server. The server won't hold off (or starve) one request till another one is completely processed and its response is sent.
As soon as Node.js realizes that an async operation is to be performed, it'll delegate a worker process to handle the operation and immediately start processing the next request. This gives a terrific boost to the speed of the system.
If your server is getting a lot of requests, and each request requires some async operation (say, database queries), this turns out to be significantly efficient.

However, this efficiency came at a great cost. Writing industry-grade applications with just events, event-handlers and callbacks is not easy.
Callback-hell is the biggest problem with callbacks that leads to decreased code-extensibility, reusability and manageability.

Coming from the object-oriented background of Java, I found it very difficult to get used to writing code involving callbacks - how you have to split the code into a separate function, the callback function.
The struggle was real during that time.

Frustrated by writing asynchronous code with callbacks, developers started finding creative ways to write better, cleaner code.
For example, we used to use async.io at my workplace. It has utility methods like async.series(), async.parallel(), async.waterfall(), etc.
async.waterfall() is the most interesting one according to me. It lets you chain async functions together so that one function's output is the next function's input - kind of like the human centipede but with functions. 😅

Promises

Promises were introduced in ES6 (2015). Until then, people only had callbacks.
Promises were the next step from callbacks. A major step that brought a revolution in the way we worked with Node.js. Consider it the industrial revolution of JavaScript.

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.
— MDN web docs

A promise is really just a wrapper around callbacks. An ingenious wrapper where we make a shift from using functions for storing the next code to using an object.
The next function to call (the callback), instead of passing it into a function, we attach it to an object - the promise object.
This object is then responsible to pass the callback function as an event handler to the concerned event.

You can instantiate a promise object from any callback based function. Thus, you can always go from a function-based approach to an object-based one.

The significance of this is that your code turns from nested blocks of callbacks to a linear chain of .then-ables.

It is lot more easy to make modifications to your code when it is written in linear sequential manner (the very reason we love synchronous code) than when it is written in nested blocks.
Your code instantly becomes readable, predictable and 200x more manageable.

Read this article for more information on Promises:

Master the JavaScript Interview: What is a Promise? | by Eric Elliott | JavaScript Scene | Medium

Eric Elliott ・ Aug 24, 2021 ・
Medium

If the Promise object sounded like magic, and you are interested in understanding its internal working, you might be interested in this article.

Co-routines

Generators

Generators were introduced in ES6 (2015) along with promises. But, I believe not many people know about them or use them often.
They are functions that return generator objects.
A generator object is an iterator.
An iterator is anything that implements the iterator protocol.

The iterator protocol says that an object can be called an iterator if it has the next() method that is supposed to do a very specific job; get the next value of iteration/sequence. If you're familiar with Scanner in Java, it's an Iterator (Although it breaks Java design priniciples)


    
//Simplest example of a custom iterator
function myIterator(){
    let a = 0;
    return {next: function(){return a++}}
}
let it = myIterator();
console.log(it.next());
console.log(it.next());
console.log(it.next());

So, a generator object is basically an object that has this next() method
And generator functions are just functions that return generator objects. If you've ever used xrange() in Python 2.x, that's literally a generator.
A very good example for generators will be a Fibonacci generator.

Read the Mozilla docs for more information on generators and iterators.
Also, this in-detail post on generators on Medium:

A Simple Guide to Understanding Javascript (ES6) Generators | by Rajesh Babu | DailyJS | Medium

Rajesh Babu ・ Mar 29, 2023 ・
Medium

Co-routines

Now that we know what generators are, we make coroutines simply by adding promises to the mix.

Please note that the code has started looking very similar to its synchronous equivalent. It just needs some supplementary part.
To take care of that, people came up with a few coroutine libraries such as CO.

This part might have been pretty difficult to wrap your head around. It is pretty convoluted. But you might want to read this article if you're interested:

Modern Javascript and Asynchronous Programming: Generators/Yield vs. Async/Await | by Sergio Valverde | Frontend Weekly | Medium

Sergio Valverde ・ Nov 9, 2018 ・
Medium

Async/await

Soon, in ES8 (2017), async-await was announced and that made writing coroutines redundant.
Co-routines died out before they could become a thing. Many people today probably don’t even know about them.

Async-await is just a wrapper around Promises. And again, a promise is just a wrapper around callbacks. So, in reality, promises and async-await are all just glamour. Under the skin, it's still callbacks everywhere!
And yet, JS code now looks so clean, intuitive and manageable, that it's orgasmic!
6 years back, nobody would've imagined we could write such clean code in JavaScript.

This code looks exactly similar to the synchronous equivalent. And I’m awe-struck when I think about how much we hated callbacks, and how much we love structure that it led us from callbacks to async-await.
I'm mesmerized by the transitions that happened around Node.js in such short span of time and I needed to talk about it.

Now, the code looks really simple. Write your code using functions and when you're going to perform an async task, just use the async and await keywords. Anybody can easily write asynchronous code in JavaScript now.
But some times, things don't work as expected. Things that look simple and straight-forward often give unexpected results. And without enough understanding of the problem and the inherent system, one can go nuts in the process of debugging such errors.
Happened with me once.
// Detect dark theme var iframe = document.getElementById('tweet-1120390303440044033-173'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1120390303440044033&theme=dark" } // Detect dark theme var iframe = document.getElementById('tweet-1120390582239682560-458'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1120390582239682560&theme=dark" }
My mentor probably understood that well. And that is why, he set me up on this journey to find and feel the true essence of Node.js.

JS-veterans, if you find any inconsistencies in this piece, or would like to add more. Or simply want to talk, feel free to comment or DM me.
JS-newbies and JS-virgins, I hope I've sparked an interest for the JS community in your minds. Feel free to reach out in case of any doubts.

DEV Community: Gaurang

ORMs: A Solution Looking for a Problem?

Table of Contents

Introduction

My Initial Reaction: These People Are Mad!!

Then Came Sequelize... And Then Mongoose

We Think It's Just Mapping

The Reality Without ORMs

Raw SQL Everywhere

Conditional Joins Get Messy

Transactions and Multi-Step Logic

Input Validation and SQL Injection Risks

Lessons From Real Projects

Changing Column Names

Environment-Specific Schema Hack

What I've come to realize

🛠 When You Try to Build Your Own Mini ORM

🚨 The ORM But Still Raw SQL Anti-Pattern

🧩 Not Perfect, But Worth It

🧱 The Real Value

Summary

[Node.js] How to Use Promises in a Callback-based Codebase

Table of Contents

Converting a Promise-based Function to Use Callbacks

Prefer Then-chaining over nesting

Please don't nest promises

Basti Ortiz ・ Jan 6 '20

How to escape Promise Hell. Unlike Callback Hell, Promise Hell is… | by Ronald Chen | Medium

Ronald Chen ・ Dec 15, 2018 ・ Medium

[Node.js] Using callback-based functions when the rest of the code uses Promises

Table of Contents

Introduction

Using util.promisify

Creating a new Promise

Create a Promise/callback dual-behaviour wrapper

Conclusion

Footnote

[Node.js] Why using sync versions of async functions is bad.

Table of Contents

Sync of Async what?

What's wrong with using sync versions of async functions?

Conclusion

Might I introduce you to my friend TypeScript?

Table of Contents

The lead-up

Why interfaces in JavaScript make no sense

Simple Explanation

What is duck typing?

Might I introduce you to my friend Typescript?

TypeScript Tutorial: A step-by-step guide to learn TypeScript

Amanda Fawcett for Educative ・ Feb 17 '20

Do I really need this though?

Conclusion

Do you go back to edit your published articles?

Do you really understand interfaces?

Table of Contents:

The lead-up

Deadly Diamond of Death

How interfaces solve the diamond problem?

The idea behind interfaces

The practical use of interfaces while writing software

To conclude..

Official Oracle documentation

The odyssey of asynchronous JavaScript

Table of Contents

The lead-up

Events, event-handlers and callbacks.

Issue with callbacks.

Promises

Master the JavaScript Interview: What is a Promise? | by Eric Elliott | JavaScript Scene | Medium

Eric Elliott ・ Aug 24, 2021 ・ Medium

Co-routines

Generators

A Simple Guide to Understanding Javascript (ES6) Generators | by Rajesh Babu | DailyJS | Medium

Rajesh Babu ・ Mar 29, 2023 ・ Medium

Co-routines

Modern Javascript and Asynchronous Programming: Generators/Yield vs. Async/Await | by Sergio Valverde | Frontend Weekly | Medium

Sergio Valverde ・ Nov 9, 2018 ・ Medium

Async/await

Ronald Chen ・ Dec 15, 2018 ・
Medium

Using `util.promisify`

Eric Elliott ・ Aug 24, 2021 ・
Medium

Rajesh Babu ・ Mar 29, 2023 ・
Medium

Sergio Valverde ・ Nov 9, 2018 ・
Medium