Forem: Matheus Julidori

WIll AI really replace devs?

Matheus Julidori — Wed, 18 Jun 2025 12:52:13 +0000

TL;DR:

AI isn't replacing skilled developers; it's a powerful tool that augments their work, enabling higher-level problem-solving rather than substituting deep understanding..

The "programming bubble" burst: Many developers, especially those from rapid bootcamps, often lack the foundational depth needed for complex problem-solving, making them vulnerable in a maturing market.

AI growth faces inherent limits: Current AI, particularly LLMs, operates within computational and data constraints. Its progress follows an "S-curve," not infinite exponential growth, and widespread quantum computing is still far off.

True builders will thrive: Developers who possess deep computer science fundamentals, understand how to build robust systems, and can critically assess AI-generated code will find their roles elevated and secured. "Vibe coding" is a dead end.

Filter the noise: Much of the sensationalist news about AI's disruptive power is fueled by the "hype cycle" and commercial interests, not necessarily by objective reality. Critical thinking is paramount.

AI and the Dev Job Market: Separating Hype from Reality in an Evolving Landscape

The conversation around Artificial Intelligence (AI) consistently circles back to a pressing question for professionals across industries: "Will AI take my job?" For software developers, this inquiry holds particular weight, especially with the rapid proliferation of sophisticated AI tools like Large Language Models (LLMs) and advanced code generation with Copilot, Cursor, Claude and others. But a closer, more nuanced look—informed by technology experts and the fundamental realities of computational limits—paints a picture far less apocalyptic and much more collaborative than popular narratives often suggest.

Recent surveys reinforce this. According to Gartner's 2024 survey on AI in software development, less than 30% of organizations have integrated generative AI tools into production workflows. Similarly, the 2024 Stack Overflow Developer Survey found that while over 70% of developers experiment with AI tools like Copilot, only 23% trust them for mission-critical production code.

The consensus among those deeply entrenched in the field is increasingly clear: AI is poised to be an incredibly powerful augmentative tool for developers, not a wholesale replacement. The crucial differentiator for future job security won't be whether you use AI, but how you use it—and, more importantly, your foundational understanding of the underlying systems you're building. This distinction is critical in a rapidly maturing tech landscape.

The Problem with Current Devs: The "Programming Bubble" Fallout

For over a decade, the global "Learn to Code" movement, that was supported by many companies and governments, catalyzed a massive influx of new talent into the software development industry after high-profile events like President Obama writing a line of code to promote computer science education, coding bootcamps and intensive online courses proliferated, often promising rapid entry into high-paying tech jobs with minimal time investment. The Inter-American Development Bank (IDB), for example, highlighted how these bootcamps often provide "high-quality technical training updated to technological dynamics, relevant to the market and at relatively accessible costs,"1 effectively addressing a portion of the tech talent shortage. Reports from organizations like SALT also show high employer satisfaction with bootcamp graduates.

However, a significant side effect of this rapid expansion was the emergence of "Framework-First Developers". These individuals, sometimes lacking a traditional computer science background, might develop proficiency in specific frameworks or libraries but often miss the deeper, foundational knowledge of algorithms, data structures, system architecture, and robust problem-solving principles.

When the tech market experienced a significant downturn from late 2022 into 2024—often called the "tech bubble burst" — coinciding with widespread layoffs, these less deeply skilled roles became particularly vulnerable. Data from Lemon.io indicates a decline in demand for software developers, with the percentage of processed leads converting to onboarded hires dropping sharply from 1.49% in 2022 to just 0.31% in 2024. Despite overall projected market growth (the U.S. Bureau of Labor Statistics still projects a 17.9% growth for software developers from 2023 to 2033), the market has certainly tightened, increasing the demand for more robust and adaptable skill sets.

This downturn wasn’t just about AI-driven disruption. It also reflected a broader macroeconomic correction: rising interest rates, the end of the low-interest "ZIRP" era, and a sharp pullback in venture capital funding forced many companies to shift focus from growth at all costs to profitability. As a result, non-essential, lower-skilled developer roles became a primary target for cost-cutting, especially in large tech firms.

The Reality of AI: Beyond Infinite Exponential Hype

Much of the public discourse around AI's future is fueled by a simplified, often sensationalized view of its capabilities. The idea of an unstoppable, purely exponential growth curve leading directly to an imminent Artificial General Intelligence (AGI) that will render human intellect obsolete — and lead to an inevitable scenario of the world succumbing to a Skynet-like AI — is compelling, but scientifically questionable.

As technology commentator Fábio Akita explains, AI's progress is better understood through the lens of an "S-curve" of technological adoption—a concept famously illustrated by Gartner's Hype Cycle. This cycle features a "Technology Trigger," followed by a "Peak of Inflated Expectations," then a "Trough of Disillusionment," before potentially reaching a "Slope of Enlightenment" and a "Plateau of Productivity". More or less the same as the Bitcoin/Crypto hype from 2017-2022. Many believe we're currently in or past the peak of inflated expectations for Generative AI, moving towards a more realistic understanding of its limitations.
Current Large Language Models (LLMs) like ChatGPT, while impressive, are fundamentally sophisticated pattern-matching and auto-completion systems. As ProjectPro highlights, LLMs have several key limitations:

Hallucinations and Inaccuracies: They can generate misleading or entirely false information.
Limited Knowledge Update: Their knowledge is static after initial training; they can't acquire new information dynamically without retraining.
Lack of Long-Term Memory: LLMs struggle to maintain context over extended conversations.
Struggles with Complex Reasoning: They operate based on statistical probabilities in training data, not true understanding or common sense.

Furthermore, the physical limits of computation pose significant barriers. While theoretical limits like Landauer's principle (the minimum energy required to erase a bit of information) are far from being reached by current hardware, the massive computational power (GPUs) and vast datasets that fueled recent AI breakthroughs are becoming increasingly saturated. Akita notes that publicly available internet data, crucial for training these models, is largely exhausted. Furthermore, energy consumption is becoming a growing environmental and economic concern for LLM deployment at scale, as the sheer energy consumption required to train and run these massive models also presents a growing challenge.
According to Business Energy UK, ChatGPT’s energy consumption is significant — its daily compute load is estimated to equal the annual power usage of the Empire State Building over one and a half years.

Even the much-hyped quantum computing, often cited as the next leap, is far from a general-purpose solution. As "The Quantum Insider" and Microtime explain, significant challenges remain:

Qubit Decoherence and Error Correction: Qubits are extremely fragile and susceptible to environmental interference, requiring complex error correction techniques that are not yet practical for large-scale systems.
Scalability Issues: Building quantum computers with millions of stable qubits is beyond current capabilities.
High Costs and Specialization: Quantum computers are immensely expensive and designed for very specific, complex tasks (like drug discovery or materials science), not to replace traditional CPUs or GPUs for everyday computing or general software development.

The Future of Devs: Built on True Understanding, Not Just "Vibe Code"

Given the realities of AI's capabilities and limitations, what does the future truly hold for software developers? The consensus is that roles will evolve, with a clear emphasis on deeper understanding and higher-order thinking. As Salesforce suggests, developers are "moving up the stack," shifting from purely technical implementation to more strategic responsibilities.

AI tools are already proving invaluable in augmenting developer productivity. Developers themselves echo this evolving role. A GitHub Copilot user study reports that while 56% of developers say Copilot makes them faster, only 23% rely on it for logic-heavy, business-critical code. This highlights that AI currently excels at boilerplate and repetitive tasks, but human oversight remains essential for complex problem-solving. What can AI do?

Code Generation: Modern AI-powered tools like GitHub Copilot, Cursor AI, and Tabnine can generate boilerplate code, suggest entire functions, and even build small modules from natural language prompts. This significantly accelerates development by automating repetitive coding tasks and reducing context-switching. Tools like Visual Studio IntelliCode and JetBrains AI Assistant further enhance developer productivity with context-aware,in-IDE code completions and intelligent suggestions tailored to the project’s coding patterns.
Debugging and Error Detection: AI can analyze code patterns, predict potential runtime errors, and offer contextual suggestions for fixes, streamlining the often time-consuming debugging process. SonarQube, with AI enhancements, helps detect bugs and vulnerabilities early.
Testing Automation: AI-driven tools like Testim, mabl, and Functionize can automatically generate, execute, and maintain test cases, drastically reducing manual QA effort. AI security tools like GitHub CodeQL and Snyk Code AI help identify vulnerabilities in code before deployment. For UI testing, platforms like Applitools Eyes use Visual AI to detect UI regressions and layout inconsistencies across devices and browsers.
Documentation and Code Reviews: AI tools like GitHub Copilot for Pull Requests, Amazon CodeGuru Reviewer, and SonarQube AI now assist in automated code reviews, flagging style inconsistencies, performance anti-patterns, and potential security issues. For documentation, platforms like Mintlify and Swimm.io can generate or suggest documentation snippets directly from source code, making it easier to maintain up-to-date developer docs. Additionally, tools like DeepCode (now integrated into Snyk Code AI) provide AI-driven static code analysis, helping developers catch vulnerabilities early in the development cycle.

Where AI Development Tools Are Headed Next

Looking forward, AI's role in software development will evolve beyond code completion and bug detection. Early experiments like GitHub Copilot Workspace, Google’s Gemini Code Assistant, and Anthropic’s Claude agents hint at AI tools that will soon assist with autonomous pull request generation, architectural planning, and even test suite creation based on system diagrams or product specs.

However, this augmentation doesn't negate the need for human expertise. As a panel of experts on the Le Wagon blog emphasized, the "typing part" of coding may be commoditized, but the "orchestrating, reviewing, and translating ideas into architecture" becomes paramount. Developers will need to:

Master AI Tools: Learn how to prompt effectively, debug AI-generated code, and integrate AI into their workflow.
Don't Skip the Fundamentals: A strong grasp of computer science fundamentals is crucial to identify "smelly" or unscalable code, regardless of whether it's human or AI-generated. You can ask AI to build something, but "only a developer can tell if it'll break with a million users."
Embrace a Product Mindset: Focus on clearly defining what _ needs to be built and the underlying business logic, not just _how to code it.
Develop Strategic Thinking: Shift towards system design, context management, and long-term planning, taking on a supervisory role over AI agents.

While "prompt engineering" has emerged as a hot skill in the early stages of AI adoption, most experts agree it's a temporary gap. As LLMs become more context-aware and interfaces improve, the real long-term value for developers will lie in system design, architecture decisions, and critical reasoning—not memorizing prompt tricks. The ability to understand the business problem, frame it correctly, and supervise AI-generated output will far outweigh knowing specific prompt syntax.

New hybrid roles like AI evaluators, prompt engineers, and AI agent designers are emerging, requiring a blend of technical and critical thinking skills. The future belongs to those who adapt, continuously learn, and leverage AI as an intellectual amplifier—not a crutch.

Final Thoughts: Don't Worry, Most News Is Exaggerated Because They Need to Sell

It's absolutely essential to approach news about AI's transformative and disruptive power with a critical eye. Much of the sensationalism is a natural byproduct of the "Peak of Inflated Expectations" phase of the technology hype cycle. Media outlets thrive on dramatic narratives, and companies involved in AI often benefit from amplifying their capabilities to attract investment and talent.

Furthermore, the rapid spread of misinformation, including "deepfakes" and biased AI algorithms, raises significant ethical concerns that demand scrutiny, as discussed by IESE Blog and MDPI. This creates an environment where exaggerated claims can quickly gain traction.

For developers, the ethical implications go beyond fake news and misinformation. Engineering teams will increasingly need to assess the long-term maintainability, fairness, and bias in AI-generated code, especially as AI tools start making architectural or logic-level decisions. Critical review and ethical responsibility will become as important as technical correctness.

While AI is undeniably changing the landscape, the goal of much of the news and public statements is often to "sell" a vision—be it a product, a company, or simply clicks. Developers who understand the genuine capabilities and limitations of AI, focus on cultivating deep problem-solving skills, and commit to continuous learning will not only secure their place but also lead the way in integrating these powerful tools responsibly and effectively into the future of software development.

💬 Are you already integrating AI tools into your development workflow? What's your experience?
📬 Share this with your team if you're debating the real impact of AI on developer careers.
👉 Follow me @matheusjulidori for more in-depth discussions on tech trends and practical development insights.

npm vs Yarn vs pnpm: The Great Package Manager Race (And We Have a Winner!)

Matheus Julidori — Tue, 17 Jun 2025 13:00:00 +0000

TL;DR:

npm is the default Node.js manager, functional but with notable performance and dependency management limitations.

Yarn, once the faster challenger, now often struggles to keep pace with modern demands and has growing complexity.

pnpm is the clear winner: blazing fast, incredibly disk-efficient, and solves long-standing dependency issues with clever engineering.

If you prioritize performance, integrity, and robust dependency control for your projects – pnpm is the indisputable path forward.

Why Package Managers Matter (And Why Your Choice is Crucial)

As JavaScript developers, package managers are the backbone of our projects, handling everything from installing and updating to removing third-party libraries. But with so many options, the choice isn't trivial. I've worked with all of them, and the impact of selecting the right tool on development experience (DX), build times, and even disk space is enormous.

The three most popular contenders in the Node.js ecosystem are:

npm (the long-standing default, bundled with Node.js)
Yarn (Meta's challenger, born to fix npm's early woes)
pnpm (the modern, highly efficient, and increasingly dominant approach)

Let's break down why your package manager choice today should likely lead you to pnpm.

npm: The Established Default (But Showing Its Age)

Released in 2010, npm (Node Package Manager) remains the official, pre-installed package manager for Node.js. It's the most widely used, and its sheer ubiquity makes it a familiar starting point for many.

✅ Pros:
- Zero Setup: Comes bundled with Node.js, making it instantly available.
- Vast Ecosystem & Community: Benefits from years of widespread adoption, leading to extensive documentation, countless packages, and a massive community.
- Simple CLI & Stable Updates: Its command-line interface is straightforward, and updates are generally non-breaking.
❌ Cons:
- Performance Bottleneck: Slower installs, especially for large projects or monorepos, due to its flat node_modules structure and sequential package fetching.
- "Phantom" Dependencies: The flat node_modules can hide implicit dependencies, leading to packages appearing to work even if they aren't explicitly declared in your package.json. This can cause hard-to-debug issues when migrating projects.
- Storage Inefficiency: Often results in significant duplication of packages across multiple projects, bloating disk storage unnecessarily.

Yarn: The Former Challenger (Now Facing its Own Challenges)

Introduced in 2016 by Meta (Facebook), Yarn emerged to directly address npm's early pain points: speed, deterministic installs (via yarn.lock), and security. It certainly improved the DX significantly for a time.

✅ Pros:
- Improved Speed (over old npm): Offered noticeably faster installs compared to legacy npm versions.
- Deterministic Installs: Introduced yarn.lock for consistent installs across environments.
- Workspaces: Pioneered native support for monorepos, a feature later adopted by npm and pnpm.
- Plug'n'Play (PnP) Module Resolution: An innovative (though controversial) approach to radically restructure node_modules, aiming for even faster installs and stricter dependency trees.
❌ Cons:
- Slower & Heavier than pnpm: Despite its initial speed advantage, Yarn often can't match pnpm's efficiency in modern benchmarks.
- Increased Complexity (Yarn 2+): The introduction of Yarn 2 (Berry) brought significant breaking changes and a steeper learning curve with its PnP mode, alienating some users and tools.
- Tooling Compatibility Issues: PnP mode, while efficient, can sometimes lead to compatibility problems with certain tooling that expects the traditional node_modules structure.
- Declining Open-Source Popularity: While still strong in Meta's internal ecosystem, its overall momentum in the wider open-source community has lessened compared to pnpm's rise.

pnpm: The Undisputed Modern Winner

pnpm is rapidly gaining traction, and for incredibly compelling reasons. Its core innovation lies in its unique approach: symlinks + content-addressable storage. This isn't just a minor improvement; it's a fundamental shift that addresses the root causes of many package manager inefficiencies.

Instead of duplicating packages for every project, pnpm stores a single, immutable copy of each package in a global content-addressable store on your disk. When you install a package in a project, pnpm simply creates a symlink to that central store. This engineering elegance translates directly into tangible benefits for developers.

✅ Pros:
- Blazing Fast Installs: Consistently outperforms both npm and Yarn in install speeds due to its symlinking strategy and avoidance of redundant downloads.
- Massive Disk Space Savings: Stores packages only once, saving gigabytes of disk space, especially beneficial for multiple projects or large monorepos.
- Strict Dependency Management: By default, it creates a stricter node_modules structure via symlinks, preventing "phantom" dependencies and ensuring your project only accesses packages explicitly declared in package.json. This leads to fewer elusive bugs.
- Native Monorepo Support (pnpm workspaces): Offers first-class support for monorepos, providing an intuitive and efficient way to manage multiple packages within a single repository.
- Fully Compatible: Works seamlessly with the npm registry and npm scripts, making the transition remarkably smooth for most projects.
❌ Cons:
- Different node_modules Structure: While mostly beneficial, its non-flat node_modules structure (due to symlinks) can, in rare edge cases, cause compatibility issues with extremely legacy tools that expect the traditional npm layout. (These cases are becoming rarer as tools adapt).
- Not Pre-installed: Unlike npm, you need to install pnpm globally once. (A minor inconvenience for significant long-term gains).

🔍 Feature Comparison: Why pnpm Leads

Feature	npm	Yarn	pnpm
Install Speed	🟡 Average	🟡 Good	🟢 Excellent
Disk Usage	🔴 High	🟡 Medium	🟢 Low
Workspace Support	🟢 Native	🟢 Native	🟢 Native
Strict Dependency Tree	🔴 No	🟡 Optional	🟢 Yes
Community Support	🟢 Huge	🟢 Large	🟢 Growing
Plug'n'Play Support	🔴 No	🟢 Yes	🔴 No (doesn't need it)
Default `node_modules`	Flat	Flat	Symlinked

When Should You Use Each? (My Final Recommendation)

Choosing the right package manager can significantly impact your development workflow. Here’s how I'd recommend approaching your decision:

You’re new and want absolute simplicity to get started: Go with npm. It's pre-installed, and its commands are straightforward.
You’re in a project deeply embedded in Meta's ecosystem or older Yarn v1 setups: You might stick with Yarn for compatibility.
In any other case: pnpm is your ultimate choice. It's truly the best modern option for most JavaScript projects today. It is an absolute masterpiece when it comes to performance, development experience (DX), disk efficiency, and clean installs.

Final Thoughts: It's Time for a Smarter Approach

The JavaScript world is constantly evolving, and so should our tooling. If you're still using npm or Yarn out of sheer habit or because "that's what everyone uses," now is the ideal time to give pnpm a serious try.

The benefits are not just hype – they are foundational improvements in how we manage dependencies:

Noticeably faster CI builds and local installs.
Dramatically less disk space used on your machine and build servers.
Fewer weird, elusive bugs caused by implicit or "phantom" dependencies.
A cleaner, more predictable dependency graph.

It's clear to me: pnpm isn't just another package manager; it's a smarter, more efficient engineering solution for the challenges of modern JavaScript development. Make the switch and feel the difference.

💬 Are you using pnpm already? If not — what’s holding you back?
📬 Share this with your team if you’re considering a package manager switch.
👉 Follow me @matheusjulidori for more hands-on dev content.

Still Drowning in API Choices? My Battle-Tested Guide to REST, GraphQL & gRPC

Matheus Julidori — Thu, 12 Jun 2025 14:30:12 +0000

TL;DR:

REST is the seasoned veteran: simple, widely understood, and a go-to for most standard web applications needing robust CRUD (Create, Read, Update, Delete) operations.

GraphQL is the client's best friend: it empowers frontends with incredible flexibility to fetch exactly the data they need, making it a game-changer for complex UIs and data-intensive applications.

gRPC is the performance powerhouse: blazing fast and incredibly efficient, it's tailor-made for high-throughput internal microservices and critical real-time systems.

The takeaway? There’s no single "best" choice. Each comes with its own set of trade-offs. Your decision should always be guided by your specific use case, performance requirements, your team's expertise, and your existing infrastructure.

When I first dipped my toes into the vast ocean of API design, I'll confess, it felt a bit like navigating a labyrinth. Back in 2020, as a junior developer trying to become a backend specialist, I spent countless days trying to grasp the nuances of REST, GraphQL, and gRPC, poring over documentation, watching tutorials, reading articles, and wrestling with code. For a long time, the pieces just didn't click into place. But then, something shifted. I realized the best way to truly understand these concepts, beyond just memorizing definitions, was to try and teach them myself. That meant diving even deeper, dissecting their architectures, and really internalizing why each exists and where it shines. This article is the fruit of that journey – my attempt to distill years of learning into something clear, practical, and genuinely helpful.

Article Index

1. Understanding the Fundamentals:
- What is REST? (Representational State Transfer)
- What is GraphQL? (The Client-Driven Query Language)
- What is gRPC? (The High-Performance RPC Framework)
2. Deep Dive into Design Choices:
- Pros & Cons Comparison: A side-by-side look at the advantages and disadvantages.
- When Should You Use Each? Matching the right tool to the right problem.
3. Practical Considerations:
- Performance & Scalability: How each style handles load and growth.
- Hosting & Deployment: Where and how to run your APIs.
- Community and Ecosystem: The support network behind each style.
- Tooling, Languages & Frameworks: The ecosystem supporting each.
4. Final Thoughts: My takeaways and advice for your API journey.

What is REST? The Enduring Standard

From my early days exploring web development, REST (Representational State Transfer) quickly became a foundational concept. It’s not a protocol or a framework, but rather an architectural style that has truly stood the test of time since its introduction by Roy Fielding in his 2000 doctoral dissertation. Think of it as the bedrock of how a vast majority of web services communicate.

At its heart, REST leverages the very principles of the web itself. It’s all about managing resources – which could be anything from a user profile to a product in an e-commerce store – identified by unique URLs. To interact with these resources, REST uses the familiar workhorses of the internet: standard HTTP methods like GET (to retrieve), POST (to create), PUT (to update), and DELETE (to remove). This simple mapping makes it incredibly intuitive once you grasp the core idea.

Main Features & Core Concepts:

Resource-Based: Everything is treated as a resource, addressable via a unique URL. For me, understanding that a URL wasn't just a path, but the identifier of a specific thing, was a key "aha!" moment.
Stateless Operations: Each request from a client to a server must contain all the information needed to understand the request. The server doesn't store any client context between requests. This makes REST APIs incredibly scalable.
Uses Standard HTTP Verbs: Relying on GET, POST, PUT, DELETE (and sometimes PATCH) means you're speaking the native language of the web.
Responses Typically in JSON (or XML): While not strictly enforced by the style, JSON has become the de facto standard for human-readable and machine-parseable data exchange, though XML was common in earlier days.
Cacheable: Resources can be cached by clients or intermediaries, improving performance.
Flexible & Language-Agnostic: Because it builds on HTTP, REST isn't tied to any specific programming language or framework. This is one of its biggest strengths, allowing diverse systems to communicate seamlessly.

What is GraphQL? The Client-Driven Query Language

After working with REST for a while, I often found myself frustrated by the "over-fetching" or "under-fetching" problem – getting too much data (and making my app work harder) or not enough (leading to multiple, waterfall requests). Being mainly a backend developer, I still remember the pain of seeing a React page reload 6 times because I didn't know how to avoid reloading them after each one of the 6 API requests I needed to make to fetch all the data. Then I encountered GraphQL, and it felt like a revelation, especially coming from a frontend perspective. Developed by Facebook and open-sourced in 2015, GraphQL isn't just another API style; it's a powerful query language for your API that completely shifts the control dynamic.

My "aha!" moment with GraphQL came when I understood its core promise: it empowers clients to ask for exactly what they need, no more, no less. Instead of the server dictating the data structure for a given endpoint (as in REST), the client specifies the shape of the data it expects. This means you typically interact with a GraphQL API through a single endpoint, sending a flexible query and receiving a predictable, structured response tailor-made for your specific view or component. It's like ordering a custom meal instead of picking from a fixed menu!

Main Features & Why They Matter:

Strongly Typed Schema: This is the backbone of GraphQL. The server defines a clear, strongly typed schema that describes all possible data types and operations (queries, mutations, subscriptions). For me, this was a huge confidence booster – knowing exactly what data I could ask for and what shape it would come in.
Clients Define Data Shape: This is GraphQL's superpower. Your frontend application sends a query that precisely outlines the data it requires. This directly addresses the over-fetching (getting fields you don't need) and under-fetching (needing multiple requests to get related data) issues common with REST.
Single Endpoint for All Operations: Unlike REST's many resource-specific URLs, a GraphQL API typically exposes just one endpoint (e.g., /graphql). All queries and mutations go through this single URL, with the schema determining the logic on the backend.
Avoids Over-fetching and Under-fetching: As mentioned, this is one of its primary benefits, leading to more efficient data transfer and often simpler client-side logic.
Great for Frontend-Heavy Apps: Because clients have such granular control, GraphQL is particularly well-suited for complex single-page applications (SPAs) or mobile apps that need to fetch diverse, nested data for various UI components.
Strong Introspection and Tooling: Tools like GraphQL Playground or GraphiQL leverage the schema to provide auto-completion, real-time error checking, and easy API exploration. This significantly flattens the learning curve once you grasp the basics.
Versionless APIs: Since clients request specific fields, adding new fields to the backend doesn't break existing clients, and deprecating old fields can be handled gracefully within the schema, simplifying API versioning.

What is gRPC? The Performance Powerhouse for Microservices

While REST and GraphQL are excellent for many scenarios, especially those involving frontend clients, there's another player that truly shines when raw performance and efficiency are paramount: gRPC (gRPC Remote Procedure Call). I remember first trying to grapple with gRPC early in my career. I got a job that I wasn't even a bit prepared for, working on a Web3 blockchain stack. It was incredibly hard to understand, being nothing like REST. I was let go from that role, and it wasn't until about 4 months ago that I truly grasped its full potential. Created by Google, gRPC is an open-source RPC (Remote Procedure Call) framework designed from the ground up for speed.

The magic behind gRPC's incredible efficiency lies in a couple of key technologies. First, it leverages HTTP/2 for its transport layer, which enables features like multiplexing (multiple requests over a single connection) and header compression. Second, and perhaps most crucially, it uses Protocol Buffers (protobuf) for data serialization. Unlike JSON, which is human-readable, protobuf serializes data into a compact, binary format. This combination makes gRPC truly "blazing fast" and incredibly efficient, especially for inter-service communication where every millisecond and byte counts.

Main Features & Why It's a Game-Changer:

Binary Protocol via HTTP/2: This is the foundation of its speed. HTTP/2 offers significant performance benefits over HTTP/1.1, and the binary nature of Protobuf payloads means much smaller message sizes compared to text-based formats like JSON or XML.
Contract-First API (via .proto files): With gRPC, you define your service interface and the structure of your messages using .proto files. From these definitions, gRPC generates client and server code in numerous languages. This "contract-first" approach ensures strict typing and consistency across your services, which I found invaluable for maintaining large, distributed systems.
Supports Streaming and Real-time: gRPC natively supports different types of streaming (unary, server streaming, client streaming, and bi-directional streaming). This makes it incredibly powerful for real-time applications, live updates, or long-lived connections – scenarios where traditional REST falls short.
Strong Client-Server Typing: Because code is generated from .proto definitions, both client and server automatically get strongly typed objects and methods. This significantly reduces runtime errors and makes development more robust, a massive benefit in complex backend architectures.
Extremely Fast and Compact: This is gRPC's headline feature. Its efficiency is unmatched for inter-service communication, making it ideal for the backbone of large microservice architectures.
Language-Agnostic with Robust Tooling: Despite its complexity, gRPC provides excellent tooling and supports code generation for a wide array of programming languages, allowing polyglot microservice environments to communicate seamlessly.

Pros & Cons: A Side-by-Side Comparison

Now that we've explored each API style individually, let's lay out their strengths and weaknesses side-by-side. This table distills the core trade-offs I've encountered, helping you quickly identify which style aligns best with your project's priorities.

Feature	REST	GraphQL	gRPC
Maturity & Adoption	High: Battle-tested, oldest, vast community.	Medium: Growing rapidly, strong modern ecosystem.	Medium: Gaining traction, especially in enterprise.
Learning Curve	Low: Simple, intuitive, builds on HTTP basics.	Medium: New concepts (schema, queries, resolvers).	High: Binary protocols, `.proto` files, code generation.
Flexibility	Low (Client-side): Fixed responses, over/under-fetching.	High (Client-side): Client defines data shape.	Medium (Server-side): Strict contracts, but powerful streaming.
Data Fetching	Fixed payloads, often requires multiple requests.	Precise data fetching in a single request.	Extremely efficient binary payloads.
Schema Required	No (by default): Less strict, less predictable.	Yes: Strongly typed schema for validation.	Yes: `.proto` files define contracts.
Performance	Medium: Text-based JSON, multiple requests.	Medium: Efficient fetching, but complex queries can be heavy.	Very High: Binary, HTTP/2, ideal for high-throughput.
Human Readability	Excellent: JSON is clear, URLs are semantic.	Excellent: Queries are readable JSON-like syntax.	Poor: Binary format, requires tooling to inspect.
Caching	Easy: Leverages HTTP caching mechanisms.	Difficult: Single endpoint, complex queries.	Difficult: Binary, streaming nature.
Browser Support	Native: Works seamlessly in all browsers.	Native: Standard HTTP POST.	Partial: Often needs `gRPC-Web` proxy.
Tooling & Ecosystem	Excellent: Mature, vast libraries, debug tools.	Excellent: Strong tools (Playground), active community.	Good: Code generation, but debugging tools less common.
Versioning	Can be challenging (e.g., `/v1/`, `/v2/`).	More flexible (add fields, deprecate gracefully).	Strong typing aids compatibility.
Complexity	Simple to start, scales well for common CRUD.	More backend complexity for resolvers.	Higher initial setup, more specialized knowledge.

When Should You Use Each? Choosing Your API Style

With the landscape of API styles clearer, the practical question becomes: "Which one should I pick for my project?" Based on my journey through these architectures, I've found that the best choice almost always hinges on your specific use case, team expertise, and performance demands. Here's a breakdown of common scenarios and the API style that typically shines brightest.

Use Case	Best Pick	My Reasoning / Why It Shines Here
Public-Facing API for Standard CRUD	REST	Simplicity & Broad Adoption: REST is the most universally understood and easiest to get started with. For typical operations like fetching lists of resources, creating new ones, or simple updates, its straightforward HTTP mapping is hard to beat. Its maturity means vast tooling and community support.
Mobile or SPA with Complex UIs	GraphQL	Client Empowerment & Efficiency: When your frontend needs to fetch diverse, nested, or highly specific data for multiple UI components, GraphQL prevents the dreaded over/under-fetching. It gives frontend developers unparalleled control, leading to fewer requests and a smoother user experience.
Internal Microservices Communication	gRPC	Blazing Fast & Efficient: For communication between services within your backend system, where low latency and high throughput are critical, gRPC is the clear winner. Its binary nature and HTTP/2 foundation make it exceptionally performant, ideal for the demanding backbone of a microservice architecture.
Real-time or Streaming Services	gRPC	Native Streaming Support: If your application requires real-time updates, bi-directional communication, or long-lived connections (e.g., chat applications, live dashboards, IoT data streams), gRPC's built-in streaming capabilities are a game-changer.
Strong Schema Enforcement Needed	GraphQL / gRPC	Contract-First Design: Both provide a strong contract (schema for GraphQL, `.proto` files for gRPC) that enforces data types and structures. This is invaluable for preventing bugs and ensuring consistency in large, distributed teams or complex applications.
Team Unfamiliar with Schema Tools	REST	Lower Learning Curve: If your team is new to API development or lacks experience with schema definition languages and code generation, REST's familiarity with HTTP methods and JSON payloads makes it a much gentler entry point.
High-Performance, Low-Latency Systems	gRPC	Optimized for Speed: For scenarios where every millisecond counts, such as critical backend services, financial trading systems, or IoT sensor data ingestion, gRPC's binary protocol and HTTP/2 optimizations deliver unmatched speed and efficiency.

Performance & Scalability & Hosting & Deployment

Beyond features and use cases, the practical realities of how your API performs under load and where it lives are paramount. My journey has shown me that while an API style might be perfect on paper, its real-world implications for performance, scalability, and deployment can make or break a project. Let's look at these critical factors.

Performance & Scalability

When it comes to how your API handles traffic and grows with your application, each style presents distinct characteristics.

REST:
- Performance: REST is generally reliable, but because it relies on text-based JSON (which can be verbose) and often requires multiple round trips for complex data, it might not be the most performant choice for low-bandwidth environments or scenarios demanding extreme speed. Each GET request, for instance, comes with standard HTTP overhead.
- Scalability: Highly scalable due to its stateless nature. You can easily distribute requests across many servers, and caching mechanisms (thanks to HTTP standards) significantly reduce server load.
GraphQL:
- Performance: GraphQL can be incredibly efficient in terms of data fetched per request, drastically reducing "over-fetching." However, performance can degrade if complex queries are poorly optimized on the backend, as a single query can potentially trigger many database lookups. It's efficient data-wise, but needs careful implementation for computation-wise efficiency.
- Scalability: Scalable, but the single endpoint means you need robust backend infrastructure to handle complex query parsing and resolution efficiently. Caching can also be trickier than with REST, as queries are dynamic.
gRPC:
- Performance: This is where gRPC truly shines. With its binary Protocol Buffers and HTTP/2 underlying transport, it offers unparalleled speed and efficiency. Message sizes are significantly smaller, and HTTP/2 features like multiplexing mean fewer connections and less overhead. It's built for high-throughput, low-latency scenarios.
- Scalability: Extremely scalable. Its design is perfect for internal microservice communication where efficiency across many services is key. The lightweight nature of messages and efficient connection handling make it ideal for massive distributed systems.

Hosting & Deployment Options

Bringing your chosen API style to life requires careful consideration of where and how it will be hosted. Each has its own ecosystem and requirements.

REST:
- Hosting: Extremely versatile. REST APIs can be hosted virtually anywhere you can run a web server. Whether it's a simple Node.js Express app, a Django REST Framework project, a Ruby on Rails API, or a Spring Boot service, standard HTTP servers are all you need.
- Deployment: Easy to deploy to common cloud platforms like Heroku, AWS EC2/Lambda, Google Cloud Run, Vercel (for serverless functions), or even a basic VPS. Its ubiquity makes deployment straightforward.
GraphQL:
- Hosting: Requires a GraphQL server implementation (e.g., Apollo Server for Node.js, Graphene for Python, Hasura for instant GraphQL APIs). While these are backend services, they still run on standard web servers.
- Deployment: Can be deployed to the same platforms as REST APIs (AWS, GCP, Azure, Vercel, etc.), as they typically run over HTTP POST. The main difference is the specific server-side library or framework you'll use.
gRPC:
- Hosting: Has more specific requirements due to its reliance on HTTP/2. It needs an HTTP/2-enabled server and environment. While many modern languages and frameworks have excellent gRPC libraries (Go, Node.js, Java, Rust, Python's grpcio), you need to ensure your hosting environment properly supports HTTP/2.
- Deployment: Often best suited for cloud environments that provide robust HTTP/2 support, such as Kubernetes clusters, AWS ECS/EKS, or Google Cloud Platform's offerings. For browser clients, remember you might need a gRPC-Web proxy to handle the translation, adding a layer to your deployment architecture.

Community and Ecosystem: The Support Network Behind Each Style

When you're making a significant architectural decision, it's not just about the technical specs; it's also about the human factor. How vibrant is the community? How extensive are the learning resources? How mature is the tooling? These questions are incredibly important for long-term project success and team productivity. My journey has shown me that a robust ecosystem can make all the difference, providing the support you need when you inevitably hit a challenge. Let's explore the community landscape for each API style.

REST: The Ubiquitous Veteran

For anyone starting in web development, REST is almost certainly the first API style you encounter. Its deep roots mean it has an unparalleled support system.

Maturity & Pervasiveness: REST has been the reigning champion since the early 2000s, making it incredibly mature and deeply embedded in almost every web framework. Think out-of-the-box support in Express (Node.js), Django/Flask (Python), Spring Boot (Java), Rails (Ruby), Laravel (PHP), and countless others. It's truly everywhere.
Learning Resources: The sheer volume of tutorials, blog posts, books, courses, and Stack Overflow answers related to REST is immense. If you have a question, chances are someone has already asked and answered it. It's also integrated into most API documentation tools like Swagger/OpenAPI, making discovery straightforward.
Community Size: Enormous and incredibly diverse. REST is often the default developers learn first, creating a massive pool of talent and a strong presence in both large enterprises and agile indie projects.
Verdict: Excellent community, extensive tooling, and a highly stable job market. You're rarely alone when working with REST.

GraphQL: The Rising Star with a Dedicated Following

Since its open-sourcing by Facebook in 2015, GraphQL has rapidly carved out its niche, particularly with frontend-focused teams who quickly embraced its client-centric approach.

Maturity & Adoption: While younger than REST, GraphQL has matured rapidly and gained significant traction. It's not just a trend; it's widely adopted by tech giants like GitHub, Shopify, and Netflix for critical parts of their infrastructure.
Ecosystem & Resources: GraphQL boasts a rich and rapidly evolving ecosystem. Projects like Apollo (with its client and server libraries), Relay, and GraphQL Yoga lead the way. Developers also benefit from fantastic tooling like GraphiQL and GraphQL Playground, which leverage its introspection features to provide an interactive API exploration experience.
Community: Strong, vibrant, and growing, especially among frontend developers working with modern frameworks like React, Vue, and for mobile applications. You'll find a wealth of libraries and support in languages like JavaScript/TypeScript, Python, Go, and Ruby. While its penetration might be slightly less in traditional, purely backend-focused environments compared to REST, its momentum is undeniable.
Verdict: A modern, active community with great momentum, innovative tooling, and a growing presence in the job market.

gRPC: The Cloud-Native Workhorse

gRPC, also released by Google in 2015, has a different, more specialized trajectory. It's the silent workhorse behind many high-performance, cloud-native systems.

Maturity & Adoption: gRPC has achieved significant adoption within infrastructure-level and microservice-heavy environments. It's a cornerstone in projects built on technologies like Kubernetes, Istio, and Envoy, indicating its reliability for demanding internal systems.
Ecosystem & Resources: Google provides robust, official support across a wide array of languages, including Go, Java, C++, Rust, Python, and Node.js. The documentation for these official libraries is generally solid. However, you'll find fewer high-level "how-to" tutorials aimed at traditional web developers, as its focus is often on backend-to-backend communication. Integrations with frontend tooling are also less common (often requiring gRPC-Web as a bridge).
Community: While smaller and more niche than REST or GraphQL, the gRPC community is incredibly strong and dedicated within specific domains, particularly among infrastructure, DevOps, and cloud-native circles. It's less common for public-facing web APIs but a staple in enterprise SaaS and highly performant internal systems.
Verdict: Highly respected and established in the backend/cloud-native world, but remains a niche player compared to REST and GraphQL in the broader web development landscape.

TL;DR Comparison Table: Community & Ecosystem at a Glance

Category	REST	GraphQL	gRPC
Community Size	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Learning Resources	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Ecosystem Tooling	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Popular Industries	All (General Web)	Web/Mobile (Frontend-heavy)	Cloud-native/Microservices/IoT
Beginner Friendly	✅ (Very)	Medium	❌ (Steep Learning Curve)

Tooling, Languages & Frameworks: Bringing Your API to Life

One of the most important considerations when choosing an API style is how well it integrates with your existing tech stack and the tools your team is comfortable with. My experience has taught me that the robustness of an ecosystem can heavily influence development speed and long-term maintainability. Here's a snapshot of some common technologies and their support across REST, GraphQL, and gRPC.

Tech	REST (Common Frameworks/Libraries)	GraphQL (Common Servers/Libraries)	gRPC (Common Libraries)
Node.js	Express, Fastify, Koa, NestJS	Apollo Server, Yoga, GraphQL.js, Nexus	`@grpc/grpc-js` (official Node.js)
Python	Flask, Django REST Framework, FastAPI, Falcon	Graphene, Ariadne, strawberry	`grpcio`, `protobuf`
Go	`net/http`, Gin, Echo, Fiber	`gqlgen`, `graphql-go`, `graphql-server`	`google.golang.org/grpc` (official)
Java	Spring Boot (Spring Web), JAX-RS (Jersey)	`graphql-java`, Spring for GraphQL	`grpc-java` (official)
Rust	Actix Web, Rocket, Axum	`async-graphql`, `juniper`	`tonic`, `grpc-rs`
C# (.NET)	ASP.NET Core Web API	Hot Chocolate, GraphQL.NET	`Grpc.Core`, `Grpc.Net.Client`
PHP	Laravel, Symfony (API Platform)	`webonyx/graphql-php`, Lighthouse	`grpc/grpc` (PECL extension)
Ruby	Rails (Rails API Mode), Sinatra	`graphql-ruby`	`grpc`

Final Thoughts: Beyond the Hype, Towards Pragmatism

If there's one overarching lesson I've taken from my deep dive into REST, GraphQL, and gRPC, it's this: choosing the right API style isn’t about which is newest, flashiest, or currently trending on social media. It's profoundly about understanding what your project truly needs, the specific problems you're trying to solve, and the existing expertise and comfort level of your team.

REST is your reliable, battle-tested workhorse. It's stable, incredibly easy to get started with, and perfect for a vast majority of common web scenarios where simplicity and broad compatibility are key. Don't underestimate its enduring power.
GraphQL is your modern power tool for client-driven development. It genuinely empowers frontend teams, streamlines data fetching, and simplifies data management in complex user interfaces. It's a fundamental shift that, once mastered, can significantly boost developer efficiency.
gRPC is your high-performance engine for internal systems. It's the precision instrument for microservices, real-time communication, and any use case where raw speed, efficiency, and strong contracts are non-negotiable.

My journey through these architectures has repeatedly shown me that you don't have to pick just one and stick with it forever. In fact, many successful, modern systems are wonderfully pragmatic, adopting a hybrid approach. You might see a public-facing REST API externally, providing broad access; a powerful GraphQL layer for complex frontend clients, giving them tailored data access; and hyper-efficient gRPC internally for blazing-fast service-to-service communication within the backend.

The most valuable advice I can offer, born from personal experience, is to be pragmatic and curious. Explore each option. Learn its strengths and its limitations. Don't let hype dictate your choices. Instead, let your product's unique requirements, your team's capabilities, and your ultimate goals guide your decision.

💬 Which API style do you use the most? Have you tried mixing them in a hybrid system? Share your experiences in the comments below!

📬 If this post helped you unravel the complexities of API design, consider sharing it with your dev circle!

👉 Follow me @matheusjulidori for more practical insights like this every week!

Is Node.js Dying? Meet the Technologies That Promise to Replace It

Matheus Julidori — Wed, 04 Jun 2025 17:42:14 +0000

TL;DR:

Node.js is still alive and well — but newer runtimes like Deno and Bun are shaking things up.

Bun is super fast, modern, and comes with built-in tools (bundler, test runner, package manager).

Deno focuses on security, native TypeScript support, and cleaner module handling.

Node.js has the biggest community and ecosystem — it’s not going anywhere anytime soon.

Don’t panic or migrate everything. Learn, experiment, and be ready for what the future brings.

Article Index

What is Node.js?
What is Bun?
What is Deno?
Pros and Cons
When to Use Each?
Recent Node.js Updates
Is Node.js Dying?
Final Thoughts

For over a decade, Node.js has been the backbone of JavaScript on the server side. But new players have entered the game — and they're gaining traction fast. You’ve probably heard of them:

🦕 Deno
⚡ Bun

These technologies promise to be faster, more modern, and more secure. But is Node.js really on its way out?
Let’s dive deep into what each one brings to the table — and why there's no need to rush nor panic (yet 😉).

What is Node.js?

Node.js was released in 2009 by Ryan Dahl. It brought JavaScript to the backend world by allowing devs to run JavaScript code outside of the browser, making it possible to use the same language across the full stack. It’s built on the V8 engine (the same used by Chrome) and is known for its event-driven, non-blocking I/O model, which made it ideal for building scalable applications, especially APIs and real-time services like chat apps.

Main ideas behind Node.js:

JavaScript everywhere
Fast and lightweight I/O
Huge package ecosystem via npm

What is Bun?

Bun is the newest kid on the block — developed by Jarred Sumner and released in 2022.

It’s a runtime built from scratch in Zig (a low-level language focused on performance), and its goal is to be a drop-in replacement for Node.js — but faster and more integrated.

Main ideas behind Bun:

Extremely fast startup and execution
Built-in bundler, test runner, and package manager
Node.js-compatible API

Bun is not just a runtime — it's an all-in-one toolkit. No need for separate tools like Webpack, Jest, or even npm.

What is Deno?

Deno was released in 2020, by none other than… Ryan Dahl — yes, the same creator of Node.js. The name is kind of a spoiler of that, since is just Node written with it's syllables inverted (No de -> de No).

After years of Node.js dominating the market, Dahl wanted to revisit some of its design decisions — especially security, module handling, and dependency management. He pointed out that NodeJS had become too complex overtime, with many third-party dependencies and bad package management, as well as very concerning security risks.

Main ideas behind Deno:

Secure by default (no file or network access unless explicitly allowed)
Built-in TypeScript support
Uses modern ES Modules instead of require()
No node_modules — uses URLs to import modules

Deno is essentially Ryan Dahl’s “second try” at building a server-side JS runtime — fixing what he saw as Node.js’ biggest flaws.

Pros and Cons

Let's talk about some of the pros and cons of each techs, because, of course, as with everything in programming, each tool has its pros and cons — and the best choice depends on your needs.

Node.js

Pros:

Mature, stable, and well-supported
Massive ecosystem (npm)
Tons of tutorials, tools, jobs, and community support
Cross-platform and widely adopted

Cons:

Lack of native TypeScript support (partially resolved).
Slower performance compared to Bun
Requires extra tools for bundling, testing, etc.
APIs are insecure by default (unrestricted access to the system).

Bun

Pros:

Blazing fast (both in dev and production)
Native bundler, transpiler, and package manager
Built-in test runner
Node.js-compatible (mostly)

Cons:

Still very new. Bun is evolving fast — so don’t be surprised if some things break or change as it matures (a bit like the Python 2 → 3 transition, though Bun is a runtime, not a language spec).
Smaller community and ecosystem
Some Node.js features/packages may not work as expected

Deno

Pros:

Secure by default
Native TypeScript support
No need for package managers (URL-based imports)
Modern and clean standard library

Cons:

Not fully compatible with Node.js or npm
Smaller ecosystem
May have a steeper learning curve for devs used to Node.js

Feature	Node.js	Bun	Deno
Released	2009	2022	2020
Creator	Ryan Dahl	Jarred Sumner	Ryan Dahl
Language	JavaScript	JavaScript	TypeScript/JS
Built with	C++	Zig	Rust
TypeScript support	Via tooling	Partial	Native
Security	Low	Medium	High
Performance	Good	Excellent	Good
Tooling built-in	No	Yes	Partial
Node/npm compatible	Yes	Mostly	Not fully

So… When Should You Use Each?

Use case	Best pick
Large enterprise apps	Node.js
Need for speed + modern tooling	Bun
Highly secure and modular projects	Deno
Learning backend for the first time	Node.js or Deno (TypeScript helps)

Each runtime has its own purpose. If you’re starting from scratch and want modern DX and performance, Bun might be the sweet spot. If you need security and modularity, Deno shines.
But if you’re working in a company, or on a codebase with 100s of dependencies — Node.js is still the king.

Have in mind that those are just some of the scenarios I analyzed. For instance, you might not even have a choice on "legacy" projects, since they already have NodeJS implemented (Jeez, it feels weird to call NodeJS legacy). But if you are building your own project from scratch, maybe it's time to experiment on those two and see for yourself how they feel.

Recent Node.js Updates

Despite the critiques that sparked the creation of Deno and Bun, Node.js hasn’t stood still. It has evolved significantly in recent years:

Improved TypeScript Support

While Node doesn’t compile TypeScript natively like Deno, it now has official support for custom ESM loaders. Tools like tsx and the node --loader tsx flag make it possible to run .ts files directly without manual compilation. This brings TypeScript much closer to a first-class experience in Node.js.

🔗 Official guide: Run TypeScript natively in Node.js

Security Policies

With the Security Policies, Node now allows developers to define manifest-based security rules to restrict module access and resource usage — a huge step forward for safer execution. This adds a crucial layer of protection for production systems.

🔗 Also see: Node.js Security Best Practices

Improved ESM/CommonJS Interoperability

Node’s support for ESModules has matured, and it’s now possible to use import and require more flexibly (although some edge cases still exist). The developer experience with ESM has improved a lot in recent LTS releases.

These changes show that Node.js is actively evolving in response to pressure from newer runtimes — and it’s doing a solid job staying relevant in the modern JavaScript ecosystem.

🔗 Full ESM documentation: ECMAScript Modules in Node.js

Is Node.js Dying?

Let’s calm things down: No, Node.js is not dying.
And even if it does slow down, it won’t happen overnight.

Remember:

PHP 5 is still around.
COBOL still powers banks.
Legacy tech doesn’t disappear — it fades over time as the ecosystem evolves.

Node.js has over a decade of momentum. Tons of companies and developers rely on it.
You won't wake up tomorrow and find it gone.

But — that doesn’t mean you should ignore Deno or Bun.
Learning new tools is good. Rewriting your entire stack for hype? Not so much.

Be curious. Experiment. But don’t panic.

Final Thoughts

If you're already using Node.js, you're still in good hands. Specially in enterprise environments, NodeJS is still king there.
But if you're starting something new — or just want to expand your skills — it's worth trying out Bun and Deno. Especially Bun, which is shaping up to be a serious contender.

Don’t rush to migrate all your projects. But do start learning, testing, and playing around. It's always good to have new knowledge added to your library.

💬 Have you tried Bun or Deno yet? Which one impressed you the most? What are your thoughts about it?

📬 If you enjoyed this article, consider sharing it with a fellow JS dev!

👉 Follow me @matheusjulidori for more posts like this!

Do you know how it works? - JS Closures

Matheus Julidori — Mon, 02 Jun 2025 15:07:30 +0000

TL;DR

A closure is when a function “remembers” variables from its outer scope.

This works even after the outer function has returned.

Closures are everywhere: in factory functions, private variables, event handlers, and more.

If you understand how scopes work, you already understand 90% of closures.

Introduction

"Closures are scary."

If you’ve been in the JavaScript world long enough, you’ve probably heard this sentence (or thought it).

There’s a certain mystique around closures — like they’re black magic or some abstract wizardry.

But here’s the truth:

If you understand scopes, closures are a breeze.

What Is a Closure?

According to MDN:

“A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function.”

See, that was easy, see y'all next week...
Just kiding. Let's dive deeper on what that sentence means

The apartment

Imagine a function is an apartment.

Inside this apartment, you’ve got furniture (let, const, and var), and maybe a roommate (another function declared inside it).

Now imagine that, after many happy years living together, sharing everything, one day the main tenant moves out (the outer function finishes executing)... but the roommate stays... and somehow still has access to all the furniture, even though the main tenant, the one that has all the furniture's, is long gone.

That roommate is your closure.

The furniture? That’s the variables from the outer scope.

Magic? No. It’s just JavaScript doing its thing.

Example: Accessing Outer Variables

function outerFunction() {
    const message = "I'm from the outer scope!";

    function innerFunction() {
        console.log(message);
    }

    return innerFunction;
}

const closureExample = outerFunction();
closureExample(); // "I'm from the outer scope!"

Even though outerFunction() is done executing, innerFunction() still has access to message.
That’s a closure.

Function Factory

Remember HOFs? Well, one of the examples we used there actually makes a good use of closures. I'm gonna use a similar example here, but shorter and easier to visualize.

function makeMultiplier(multiplier) {
    return function (number) {
        return number * multiplier;
    };
}

const double = makeMultiplier(2);
const triple = makeMultiplier(3);

console.log(double(5)); // 10
console.log(triple(5)); // 15

In this example, I use the function factory makeMultiplier(multiplier) to return a new function that receives a variable number. The catch is that each returned function remembers the multiplier it was created with.
This is a closure in action — capturing external variables into a private, persistent scope.

Use Case: Private Variables

Another use case for closures is to create a private state in a function.

function secretHolder(secret) {
    return {
        getSecret() {
            return secret;
        },
        setSecret(newSecret) {
            secret = newSecret;
        },
    };
}

const mySecret = secretHolder("I love JavaScript");

console.log(mySecret.getSecret()); // I love JavaScript
mySecret.setSecret("I once said Java is the best");
console.log(mySecret.getSecret()); // I once said Java is the best

You can't access the variable secret directly — only through the returned methods. That's a closure keeping your data safe. Yes, it's very similar to private variables, more on that at the end of the article

So, What’s a Closure Really?

A closure happens any time a function uses variables from its outer scope, even after that scope has finished.

It’s not a special kind of function. It’s just a function with memory. And the best is that you may be using closures for a long time without even noticing, because JS does it on its own.

Why Use Closures?

Encapsulate and protect internal state
Create configurable functions (factories, currying)
Simulate private variables and methods
Prevent global pollution
Maintain context across function calls

Classes private variables vs Closures private state

Well, there is not much to explain here. They both work similarly, but the historical context may be of more use here.

For years, JavaScript had no true private fields. If you wanted to hide internal state, you’d use closures. Closures are here since the beginning (ES3), and they use logic (function scopes and returned methods) to make something private. The problem is that, with some tricks (reflection) and abuses, you could access those variables.

As of ES2022, JavaScript introduced the # prefix inside classes. They are a new way of truly making something private. The protection is language-enforced(syntax-level), so there is no way of accessing it.

But that does not mean using closures to make something private is "old school bad behavior). It is still very much welcome to do it, specially in specific use cases that may work well with OOP-style encapsulation (Factories, modules, encapsulation in functional style, etc)

Just to make it easier to visualize, here is an example of a function-style encapsulation vs an OOP-style encapsulation:

Function-style (closures)

function createCounter() {
    let count = 0;

    return {
        increment() {
            count++;
        },
        getValue() {
            return count;
        },
    };
}

OOP-style (class with #prefix):

class Counter {
    #count = 0;

    increment() {
        this.#count++;
    }

    getValue() {
        return this.#count;
    }
}

Wrapping Up

Closures might sound complex at first — but they’re just a natural result of how scope and functions interact in JavaScript.

If you can understand who sees what, and when, you can understand closures.

Absolutely! Here’s a concise and friendly message you can include near the end of your post (or as a standalone update) to explain the shift in pace and your exciting plans:

⚡ Quick Message!

It’s been about 10 weeks since I started this series — and honestly, it’s been a blast.
Sharing what I know (and learning in the process) has been super rewarding.

That said… writing weekly is no joke. It takes a lot of time and energy to deliver something valuable and clear every single week.

So here’s the plan:
👉 I’m still going to write — but maybe not every week. I want to focus on delivering content that’s thoughtful and well-planned.

I’m also working on turning this content into a full YouTube series — a complete guide for new devs, from scratch:

Programming logic and fundamentals (probably using C++ or some other low-level programming language)
Then JavaScript, OOP, and web development
Build up to advanced topics, and fullstack development

Think of it as a complete guide — from “What’s a variable?” to “Here’s how to build real-world applications without using AI and Vibe Coding that will break your app due to security and bad code.”

And I'd love your support on this project. It may take a while for it to really start and get a consistency on posts, but if you want to support me, start by subscribing to my channel.

Thanks for following along so far. I appreciate all the support, messages, and comments. You are the reason I keep doing this, and I hope you stick with me on this next chapter too! 😊🙌

Let’s keep learning — together. 💻📚🎥

💬 Got a clever use case for closures? Or a bug caused by one?
Drop it in the comments — I’d love to hear about it.

📬 If you're enjoying this series, save it or share it with a fellow JS dev. Let’s keep learning together!

👉 Follow me @matheusjulidori for more content on JavaScript and web development!

🎥 And subscribe to my YouTube channel to catch the next chapter — from the very beginning.

Do you know how it works? - JS Scopes

Matheus Julidori — Mon, 26 May 2025 13:30:32 +0000

TL;DR

Every variable or function in JavaScript lives inside a scope — global, function, or block.

Global scope is accessible everywhere.

Function scope is created by functions (var, let, and const declared inside a function).

Block scope is defined by blocks like if, for, and while — but only applies to let and const.

A child scope (inner) has access to its parent scope, but not the other way around.

var is function-scoped and should be avoided in modern JS — prefer let and const.

Scopes are temporary — once a function finishes running, everything inside its scope disappears.

Understanding scope is crucial to avoid weird bugs and prepare for concepts like closures (next episode!).

Introduction

Every piece of code in JavaScript lives inside something we call a scope.

Scopes define what can be accessed, where, and for how long.

Think of scopes as environments. Each environment has its own variables and functions.

Some environments can access values from others based on a few rules. Others have shorter lifespans.

And on top of that, we have the difference between var, let, and const.

Scopes in Practice

We have two main types of scope in JavaScript:

Global scope: accessible everywhere
Local scope: created inside functions or blocks

Let’s first understand what it means to be in the global scope. It's pretty simple: everyone can see you.
For now, don’t worry about const, let, and var. Let’s focus just on scope.

var varGlobal = "I'm global";

function scope1(){
    var var1 = "I only exist in scope 1"
    console.log("Scope 1");
    console.log("var1: " + var1);
    console.log("varGlobal: " + varGlobal);
}

function scope2(){
    var var2 = "I only exist in scope 2"
    console.log("Scope 2");
    console.log("var2: " + var2);
    console.log("varGlobal: " + varGlobal);
}

scope1();
scope2();

Note that both functions can access varGlobal, because it was defined in what we call the global scope — it isn’t wrapped in any function, it's in the root of the script execution.

Now, local scope can be “split” into two types: function scope and block scope.

Function scope is created by functions. Block scope is defined (not created — careful with that wording) by code blocks like if, for, and while.

const and let have block scope, meaning they only exist within the block they were declared in.
var has function scope, meaning it exists throughout the entire function and cannot be redeclared within it.

It’s important to note: blocks do NOT create scope on their own — this will become clearer shortly.

Let’s take a look at local scopes in action:

function main(){
    console.log("------------------Scope: main------------------");
    const num1 = 3;
    const num2 = 4;
    let res = 0;
    console.log("calcPower: " + calcPower);
    console.log("num1: " + num1);
    console.log("num2: " + num2);
    console.log("res: " + res);
    //console.log("calcSum: " + calcSum);
    res = calcPower(num1,num2);
    console.log("------------------Scope: main------------------");
    console.log("res after execution: " + res);
}

function calcPower(a,b){
    console.log("------------------Scope: calcPower------------------");
    // console.log("res: " + res);
    // console.log("num1: " + num1); 
    let res = 1;
    console.log("res: " + res);
    console.log("a: " + a);
    console.log("b: " + b);
    console.log('------------------"Scope": for loop------------------');
    for(let i = 0;i<b;i++){
        res *= a;
        console.log("i: " + i);
        console.log("res: " + res);
        console.log("a: " + a);
        console.log("b: " + b);
    }
    //console.log("i: " + i);
    function printAfterLoop(){
        console.log("------------------Scope: printAfterLoop------------------");
        console.log("res: " + res);
        //console.log("i: " + i);
    }
    printAfterLoop();
    return res;
}

function otherScope(){
    // Many other things happening
    function calcSum(a,b){
        return a + b;
    }
    // Many other things happening
}

main();

Now look closely — you’ll notice I left some console.log() lines commented out. Let’s analyze the execution output and what would happen if we uncommented some of them. I’ll explain the naming conventions I’m using further down.

'------------------Scope: main------------------'
`calculaPotencia: f calculaPotencia()`
'num1: 3'
'num2: 4'
'res: 0'
'------------------Scope: calculaPotencia------------------'
'res: 1'
'a: 3'
'b: 4'
'------------------"Scope": for loop------------------'
'i: 0'
'res: 3'
'a: 3'
'b: 4'
'i: 1'
'res: 9'
'a: 3'
'b: 4'
'i: 2'
'res: 27'
'a: 3'
'b: 4'
'i: 3'
'res: 81'
'a: 3'
'b: 4'
'------------------Scope: printAfterLoop------------------'
'res: 81'
'------------------Scope: main------------------'
'res after execution: 81'

Let’s break this down:

The main() function’s scope knows about num1, num2, res, and the calcPower() function because the first three are declared within main(), and calcPower() is declared in the global scope.
If we uncomment console.log("calcSum: " + calcSum);, we’ll get an error — because calcSum() was declared inside otherScope() and isn’t visible to main().
The calcPower() function knows about a, b, and res, since they are all declared within its own function scope.
If you uncomment console.log("res: " + res); in calcPower(), it will throw an error — because res from main() is not visible inside calcPower() (they're two different res variables).
The same applies to num1 — it only exists inside main(). The variable a holds a copy of the value of num1 passed as an argument — same value, different variable.
The for loop block "knows" everything from its parent (calcPower()), including a, b, and res.
But the parent scope cannot access i, because i was declared using let inside the for loop — it only exists there.
The nested printAfterLoop() function also has access to res, a, and b because it's declared within the calcPower() scope.
But printAfterLoop() does not have access to i, because i only exists in the for loop — sibling scopes don’t share values.
Finally, the res value from calcPower() is returned and assigned to the res variable in main() — because the result was returned and assigned explicitly. It’s a copy of the value, just like when main() passed num1 and num2 to a and b.

Before you correct me on the comment, yes, I'm going to talk about the deliberate mistake I made when I said that the for loop has a scope, don't crucify me.

Initial Conclusions

From all this, we can extract a few key rules:

An inner scope knows everything from its outer scope (parent). If you have function A inside B inside C — A has access to C.
A scope doesn’t know about sibling scopes or nested ones it doesn't contain. If you have functions A and B in the same scope, and C inside A — A doesn't know B or C scope's.
Everyone knows what’s in the global scope.
Function A can call function B if they are declared in the same scope.
Function A can call function B if B was declared inside A.
Function A cannot call function B if B lives in a scope A doesn’t have access to.

Additional info:

A scope exists while the function that defines it is executing. After that, it disappears.
A variable or function declaration only lives as long as the scope that contains it. Once the scope is gone — so is the declaration.

`var`, `let`, and `const`

Before anyone comes for me — yes, I said blocks define scopes. But they don’t. Let me clarify.

“But Matheus, didn’t we just see that i doesn’t exist outside the for loop?”
Yes, but that behavior comes from let, not the for block.

Since ES6 (2015), JavaScript introduced three ways to declare variables: var, let, and const.

Here's how they differ:

`var`	`let`	`const`
Lives through the entire function it’s declared in	Lives within the block it’s declared in	Lives within the block it’s declared in
Can be reassigned manually	Can be reassigned manually	Cannot be reassigned manually

So why did i not exist outside the loop in our earlier example?
Because it was declared with let inside a block — and let is block-scoped.

Want proof?

function example() {
    for (var i = 0; i <= 10; i++) {
        console.log(i);
    }
    console.log("i outside the loop: " + i); // 10
}

The i variable still exists outside the loop, because var has function scope, not block scope.

Now, why did I refer to blocks as “scopes” earlier?
Well — in modern JS, you’re not supposed to use var anymore. It’s discouraged due to unpredictability in complex blocks.

Since we mostly use let and const today, which are block-scoped, it’s kind of okay to think of blocks as scopes — at least for learning purposes.

And one last thing — when I said const can’t be changed manually, I meant you can’t reassign a new value to it.
That doesn’t mean its contents can’t change.

const arr = [];

arr = [5]; // ❌ Not allowed — reassignment

arr.push(5); // ✅ Allowed — value changed, but the reference is still the same

Conclusion

Scopes in JavaScript are foundational and can be hard to visualize and understand at first — but with practice, they become second nature.

The key is to understand who knows what and when values disappear.

Next up, we’re finally going to talk about about one of the most powerful (and misunderstood) topics in JS: Closures.

I’ve been holding off on that topic because it requires a solid understanding of scopes and other topics — which we now have.
See you in the next episode of Do You Know How It Works?

💬 Got a scope-related bug story?
Drop it in the comments — I’d love to hear how you debugged it!

📬 If you're enjoying this series, save it or share it with a fellow JS dev. Let’s grow together!

👉 Follow me @matheusjulidori for the next episodes of Do You Know How It Works?

🎥 Subscribe to my YouTube channel to be the first ones to watch my new project as soon as it is released!

Do you know how it works? - Higher Order Functions (HOFs)

Matheus Julidori — Mon, 19 May 2025 17:46:43 +0000

TL;DR:

Higher-Order Functions (HOFs) are functions that receive or return other functions.

They’re key to functional programming, widely used in React, map(), filter(), and more.

They help abstract repetitive logic, making your code cleaner, testable, and elegant.

Classic examples: setTimeout, Array.map(), Array.filter(), function factories.

Introduction

Higher-Order Functions (HOFs), or First-Class Functions, became a hot topic in JavaScript over the last few years — largely thanks to functional programming principles and React.

But despite the intimidating name, HOFs are actually pretty simple. They can be defined as:

Functions that takes one (or more) functions as parameters, or
Functions that return another function

But what’s the point of passing a function as a parameter? Going deeper: why even pass parameters to a function at all? What’s the use?

Parameters in Functions

Function parameters play a crucial role. Functions that receive parameters usually either perform some action with that value or transform it.

For example, take a binary search function, which receives an array of elements and a target value to search for:

function binarySearch(array, value) {
    let left = 0;
    let right = array.length - 1;

    while (left <= right) {
        const mid = left + Math.floor((right - left) / 2);

        if (array[mid] === value) {
            return mid;
        } else if (array[mid] < value) {
            left = mid + 1;
        } else {
            right = mid - 1;
        }
    }

    return -1;
}

const numbers = [1, 3, 5, 7, 9, 11, 13, 15];
console.log(binarySearch(numbers, 7));  // 3
console.log(binarySearch(numbers, 10)); // -1

The function needs the target value to know what to look for, and the array to know where to look and what index to return.

But sometimes, passing primitive values like numbers, arrays, or strings isn’t enough. In more complex cases, the logic itself needs to be passed as a function.

Functions as Parameters

A perfect example of a function that needs another function is setTimeout(). This function executes an action after a delay. But it needs to know what to execute — which is why we pass it a function.

Think of it like calling your ISP and following the steps to reset your modem:

Turn it off
Wait 5 seconds
Turn it back on

const modem = {
    on: true,
    toggle() {
        this.on = !this.on;
        console.log(this.on);
    },
};

// Turn off the modem
modem.toggle();
// Turn it back on after 5000ms (5s)
setTimeout(modem.toggle, 5000);

Passing a number alone wouldn’t be enough for setTimeout() — it needs a function to execute after the time delay.

Other common examples include Array.map() and Array.filter().

If you, like me, learned programming in a language with no functional programming (or sometimes not even OOP — shoutout to the C devs, I do not miss that), you probably ignored these functions and wrote loops instead:

let numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
let lessThan4 = [];
let j = 0;

for (let i = 0; i < numbers.length; i++) {
    if (numbers[i] < 4) {
        lessThan4[j] = numbers[i];
        j++;
    }
}

But when you need to chain multiple steps, this quickly becomes messy and unreadable. Suppose we want to filter even numbers less than 4, then multiply them by 2:

let numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
let lessThan4 = [];
let j = 0;

// Filter < 4
for (let i = 0; i < numbers.length; i++) {
    if (numbers[i] < 4) {
        lessThan4[j] = numbers[i];
        j++;
    }
}

// Filter evens
let evens = [];
j = 0;

for (let i = 0; i < lessThan4.length; i++) {
    if (lessThan4[i] % 2 === 0) {
        evens[j] = lessThan4[i];
        j++;
    }
}

// Multiply by 2
let result = [];

for (let i = 0; i < evens.length; i++) {
    result[i] = evens[i] * 2;
}

console.log(result); // [4]

That’s a lot of logic for a simple transformation. With HOFs, we abstract all that into readable, functional chains using filter() and map():

let numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

let result = numbers
    .filter(n => n < 4)
    .filter(n => n % 2 === 0)
    .map(n => n * 2);

console.log(result); // [4]

And if the logic gets more complex or will be reused, you can define it in named functions and pass those:

let numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

let result = numbers
    .filter(lessThan4)
    .filter(isEven)
    .map(double);

function lessThan4(n) {
    return n < 4;
}

function isEven(n) {
    return n % 2 === 0;
}

function double(n) {
    return n * 2;
}

console.log(result); // [4]

This makes your code more readable, reusable, and testable. (Seriously — write tests. Your future self will thank you.)

Returning Functions

As I said earlier, functions that return other functions are also considered HOFs.

Let’s say you have multiple buttons, and each applies a different theme to the page (light, dark, high-contrast). But besides applying styles, you also want to:

Save the preference to localStorage
Log which theme was selected

<button onclick="applyLightTheme()">Light</button>
<button onclick="applyDarkTheme()">Dark</button>
<button onclick="applyHighContrastTheme()">High Contrast</button>

<script>
function applyLightTheme() {
    document.body.className = 'light';
    localStorage.setItem('theme', 'light');
    console.log('Theme: light');
}

function applyDarkTheme() {
    document.body.className = 'dark';
    localStorage.setItem('theme', 'dark');
    console.log('Theme: dark');
}

function applyHighContrastTheme() {
    document.body.className = 'contrast';
    localStorage.setItem('theme', 'contrast');
    console.log('Theme: contrast');
}
</script>

But the logic is repeating — and we don’t like repetition. So we use a Function Factory (not to be confused with Factory Functions 😄).

A function factory is a HOF — it builds and returns a function:

<button onclick="applyLightTheme()">Light</button>
<button onclick="applyDarkTheme()">Dark</button>
<button onclick="applyHighContrastTheme()">High Contrast</button>

<script>
function makeThemeApplier(themeName) {
    return function () {
        document.body.className = themeName;
        localStorage.setItem('theme', themeName);
        console.log(`Theme: ${themeName}`);
    };
}

const applyLightTheme = makeThemeApplier('light');
const applyDarkTheme = makeThemeApplier('dark');
const applyHighContrastTheme = makeThemeApplier('contrast');
</script>

The makeThemeApplier() function is a Higher-Order Function because it receives a value and returns a function that remembers that value (thanks to closures).

That’s the core power of HOFs:

“Give me a parameter, and I’ll give you back a function that uses it.”

And if you’re wondering what a closure is — don’t worry. That’s exactly what we’ll explore in the next episodes.

Recap

A Higher-Order Function:

Accepts a function as an argument, or
Returns a new function

They're everywhere: setTimeout(), map(), filter(), reduce()
They help you:

Abstract logic
Write cleaner code
Compose behavior

Enable powerful patterns like:

Function factories
Closures
Declarative pipelines

Perfeito! Aqui está seu post formatado para publicação no dev.to, com título, seções, marcação em markdown e preservando o estilo da série “Do You Know How It Works?”:

Wrapping Up

HOFs are a gateway to functional programming in JavaScript.
They help you write expressive, declarative, and clean code.

If you’ve ever wondered why map() and filter() feel so magical — it’s because they are.

But we’ve only scratched the surface.

Next up: JavaScript Scopes —
What exactly can your function “see”?
Let’s uncover the rules behind variable visibility, hoisting, and why sometimes things just don’t exist where you expect them to..

💬 Have a cool use case for HOFs?
Drop it in the comments — I’d love to learn how you’re using them in your projects!

📬 If you're enjoying this series, consider saving it or sharing it with a fellow JS dev. Let’s grow together!

👉 Follow me @matheusjulidori for the next episodes of Do You Know How It Works?

🎥 Subscribe to my YouTube channel to be the first ones to watch my new project as soon as it is released!

Do you know how it works? - JS Getters & Setters

Matheus Julidori — Wed, 14 May 2025 14:57:45 +0000

TL;DR

Getters and setters allow you to control access to class properties.

Setters are used to validate and sanitize data before it’s stored.

Getters are used to control how data is returned — sometimes hiding or formatting sensitive information.

It’s a way to encapsulate logic and protect internal state, especially when working with classes.

Intro

The question that could save your car from flying off at Eau Rouge: how do I protect my classes in JavaScript?

We’ve already walked through the power of this, constructor functions and classes, and one of the main reasons I use to justify classes was Security. As Uncle Ben once said (probably to a junior dev): "With great power comes great responsibility.". But although I said it is a good practice due to security reasons, there are still some basics to be taught about protecting your classes.

Back to my hyper-focus on F1, you wouldn’t want to give a junior engineer direct access to the core setup of a McLaren F1 car, would you?

In JavaScript, if you’re not careful, you’re doing exactly that — letting anyone read or change values inside your class without any kind of validation.

And that’s where getters and setters come in. They are special methods from classes that allow you to encapsulate and protect your data.

Protecting Inputs

Let’s say you’re building a class to represent a Formula 1 car. One of the critical parameters is the differential adjustment on throttle. Don’t worry if you don’t know what that is — just know this:

👉 It must be a number between 0 and 100.

But without validation, your class can be abused like this:

const mclaren = new F1Car();
mclaren.diffOnThrottle = "Invalid value";

That's like letting your cousin, who has never seen F1, adjust Lando Norris' setup for Monaco.

So instead, let’s protect it using private fields and setters:

class F1Car {
  #diffOnThrottle = 50; // private field

  set diffOnThrottle(value) {
    if (typeof value !== 'number' || value < 0 || value > 100) {
      throw new Error("Differential on throttle must be a number between 0 and 100.");
    }
    this.#diffOnThrottle = value;
  }
}

mclaren.diffOnThrottle = "Invalid value"; // Uncaught Error: Differential on throttle must be a number between 0 and 100.

mclaren.diffOnThrottle = 70 // Will work

Now, anytime someone tries to change the diff setup, the setter makes sure the value is valid. You’re no longer handing out the keys to the pit wall.

Controlling outputs

One thing you will notice now is that, if you try to console.log the value of the diffOnThrottle, it won't work.

console.log(this.diffOnThrottle) //undefined

This happens because we are using a private field (#) on our class.
Without a getter, trying to access mclaren.diffOnThrottle just gives you undefined, because the actual field is private (#diffOnThrottle). This means that only the class has access to it. In order to be able to see the value, we need to use getters.

class F1Car {
  #diffOnThrottle = 50; // private field

  set diffOnThrottle(value) {
    if (typeof value !== 'number' || value < 0 || value > 100) {
      throw new Error("Differential on throttle must be a number between 0 and 100.");
    }
    this.#diffOnThrottle = value;
  }

  get diffOnThrottle() {
    return `${this.#diffOnThrottle}%`;
  }
}

const mclaren = new F1Car();

console.log("Initial diff on throttle:", mclaren.diffOnThrottle);

mclaren.diffOnThrottle = 70 // 70

console.log("New diff on throttle:", mclaren.diffOnThrottle);

This way, not only you can choose what to expose from you classes by creating or not creating a getter for an attribute, but you can also define how the return value will be shown. For example, I could have my getter written like this:

  get diffOnThrottle() {
    return `Current Diff on Throttle: ${this.#diffOnThrottle}%`;
  }

So that every time I call the mclaren.diffOnThrottle, it will show as "Current Diff on Throttle: x", where X is the current value.

Bonus: Getters and Setters Without Classes?

You don’t need to use classes to have getters and setters — you can use Object.defineProperty() on plain objects too.

Here’s the same idea of protecting a field, but using a plain object instead of a class:

const sauber = {
  _fuel: 0,
};

Object.defineProperty(sauber, 'fuel', {
  get() {
    return `${this._fuel} liters`;
  },
  set(value) {
    if (typeof value !== 'number' || value < 0 || value > 110) {
      throw new Error("Fuel must be a number between 0 and 110 liters.");
    }
    this._fuel = value;
  },
});

sauber.fuel = 80;
console.log(sauber.fuel); // "80 liters"

sauber.fuel = "full"; // Error

This works the same way as in a class, but under the hood — more manual, but still useful when you don't want to write a class.

Another Bonus: Getters Can Compute Things Too

Setters usually validate or sanitize data, but getters can also do more than just return raw values — they can compute derived information.

For example, let’s say your car tracks how much fuel it has and how much it consumes per lap. You could create a getter that tells how many laps you can still run:

class F1Car {
  #fuel = 100; // liters
  #consumptionPerLap = 2.5; // liters per lap

  set fuel(value) {
    if (typeof value !== 'number' || value < 0 || value > 110) {
      throw new Error("Fuel must be a number between 0 and 110.");
    }
    this.#fuel = value;
  }

  set consumptionPerLap(value) {
    if (typeof value !== 'number' || value <= 0) {
      throw new Error("Consumption must be a positive number.");
    }
    this.#consumptionPerLap = value;
  }

  get remainingLaps() {
    return Math.floor(this.#fuel / this.#consumptionPerLap);
  }
}

const ferrari = new F1Car();
ferrari.fuel = 75;
ferrari.consumptionPerLap = 2.5;

console.log("Remaining laps:", ferrari.remainingLaps); // 30

So instead of exposing raw data, the getter gives you meaningful insight — kind of like telemetry dashboards in real F1 teams.

Recap

Setters let you validate, sanitize, or transform data before storing it.
Getters let you format, restrict, or compute values before returning them.
Both allow you to encapsulate logic inside your class — something every serious engineer (code or F1) should care about.
Protecting internal state is key to making your classes secure, predictable, and future-proof.

Wrapping up

When you're designing classes, think like an F1 engineer. Not everything should be adjustable by just anyone. Not everything should be visible to the public.

Encapsulation is not just about being "clean" — it's about building robust systems that don’t crash when someone types "banana" into a numeric field.

So... next time you're coding your class, ask yourself:
Am I building a well-guarded and projected McLaren, or a messy Sauber with an open fuel cap?

💬 Got a clever way of using getters or setters in your projects?
Have you ever saved a bug thanks to input validation or locked down your data like it was FIA telemetry?

Drop a comment — I’d love to see how you’re protecting your objects in the wild!

📬 Enjoying the series? Save it, share it with your dev squad, or that one friend who still assigns "banana" to numeric fields. 😅
Let’s keep leveling up together.

👉 Follow me @matheusjulidori for the next episodes of Do You Know How It Works?

🎥 Subscribe to my YouTube channel to be the first ones to watch my new project as soon as it is released!

Next up: Higher-Order Functions —
Why do we call map, filter, and reduce higher? And what makes a function worthy of the title?

Let’s break it down in plain JavaScript — and probably with another F1 analogy.

Do you know how it works? - The "this" keyword

Matheus Julidori — Mon, 05 May 2025 14:09:59 +0000

TL;DR:
In JavaScript, the value of this depends entirely on how a function is called, not where it was defined.
It can reference the global object (window/global), the calling object, undefined (in strict mode), or be explicitly bound using .bind(), .call(), or arrow functions.
In this post, we cover:

What this points to in different contexts: object methods, global scope, functions, classes, and callbacks

How this behaves differently in strict mode

The use of .bind() and .call() to control this explicitly

Why arrow functions can be lifesavers in callback scenarios

How this works with constructor functions and classes By the end, you’ll understand the most misunderstood keyword in JavaScript with clarity.

Introduction

The question that could bring world peace: "What is the value of this?"
If you’ve worked with JavaScript for a while, you’ve probably hit this dreaded error:

Cannot read property 'value' of undefined

If you haven’t seen it yet — don’t worry young padawan, your time will come. 😅

In this post, I’ll break down what this really is in JavaScript. Spoiler: it’s all about who’s calling the function — not where or how it’s written. We’ll explore this in object methods, top-level functions, strict mode, constructors, and even callback hell. Strap in — it’s going to clear up a lot.

In short, in JS, this points to the object that is executing the current function — in other words, the object that defines the execution context of that function.
Said like this, it may sound tricky to grasp, but let’s go through some practical examples.

`this` in the context of methods

We already know that when a function is part of an object, it’s called a method. In this scenario, it’s easy to deduce what object will be referenced by this, since the function is part of the object itself.

const car = {
  model: "MCL39",
  team: "McLaren",
  showThis() {
    console.log(this)
  }
}

car.showThis(); 
// Object { model: "MCL39", team: "McLaren", showThis: showThis() }

No big mystery here — this points to the object that called the function, which in this case is const car.

In most cases, you can figure this out by using the left-hand rule: the object to the left of the function invocation is usually the context.

`this` in the context of functions

Okay, but what if my function isn’t being called by an object? What if I’m not even inside a function? What is this then? Well, everything in JS is an object — everything.
So, if in your code, script, or app you’re using a function that isn’t part of an object you created, then it’s part of JS’s global object. This global object can be window in the browser or global in NodeJS.

Here’s an example:

console.log(this); // Window {...}

if (true) {
  console.log(this); // Window {...}
}

function aFunction() {
  console.log(this);
}
aFunction(); // Window {...}

In this case, we see three examples where the context is the same.

The first console.log(this) runs directly in the browser’s console — its execution context is the global window object.
The second one is inside an if() block — again, this points to window. This happens because blocks don’t define context. They define variable scope, but not object context. In the end, it’s just another block belonging to the global object.
The third one is inside the aFunction() function, but it’s being invoked directly in the console, by the browser’s window. So, its context is also window.

To reinforce what we said earlier: as a general rule — with a few exceptions we’ll cover later — the context of this belongs to whoever is calling the function.
We can prove this by checking the window object:

console.log(this);
/*
Window {
  aFunction(): function aFunction()
}
*/

window.aFunction(); // Window {...}

Notice that the window object contains the aFunction() we defined. That’s because we created the function directly in the browser console, which defaults to the window context.

`this` and strict mode

If you’re using “strict mode”, the return will be undefined. Strict mode is a safeguard that prevents direct access to the global object through this. It’s used by default in React and Node environments, for example.

function aFunction() {
  'use strict';
  console.log(this);
}

const obj = {
  aFunction
}

obj.aFunction(); // Object {...}
aFunction();     // undefined

Here, we explicitly use strict mode inside the function. That way, the global object can’t be referenced through this.
But when we place the same function inside an object and call it through that object, this correctly references the object.
When we invoke the function directly in the console, we get undefined — because strict mode forbids access to the global object (window in this case).

But this can cause problems. What if we need to execute a function using an object we can’t modify?

Binding and `this`

Imagine I have my accelerate() function and I want it to be executed using my car object — but I don’t have permission to add the function directly to the object.
To solve this, there are some Function API methods that let us manually bind the object to the function’s this.

Let’s start with Function.bind():

const car = {
  speed: "250km/h"
}

function accelerate() {
  return `Accelerating at ${this.speed}`;
}

const boundFunction = accelerate.bind(car);
boundFunction(); // Accelerating at 250km/h

Function.bind() creates a new function whose this context is explicitly set to the object passed as parameter. This new function can then be stored and reused.

Now, what if the function receives arguments? There are two ways: you can pass the argument in the bind() call or call the bound function with arguments later.

const car = {
  speedKm: "250km/h",
  speedMi: "155mph"
}

function accelerate(isMPH) {
  return isMPH 
    ? `Accelerating at ${this.speedMi}`
    : `Accelerating at ${this.speedKm}`;
}

const boundWithArg = accelerate.bind(car, false);
const boundWithoutArg = accelerate.bind(car);

boundWithArg();             // Accelerating at 250km/h
boundWithoutArg(true);      // Accelerating at 155mph
boundWithoutArg(false);     // Accelerating at 250km/h

// If bind was used with a fixed argument
boundWithArg(true);         // Accelerating at 250km/h
boundWithArg(false);        // Accelerating at 250km/h

When you bind with an argument, that argument is fixed and can’t be changed later — so choose the method that fits your case best.

If you don’t need to reuse the function and just want to run it once, use Function.call():

const car = {
  speedKm: "250km/h",
  speedMi: "155mph"
}

function accelerate(isMPH) {
  return isMPH
    ? `Accelerating at ${this.speedMi}`
    : `Accelerating at ${this.speedKm}`;
}

accelerate.call(car, true); // Accelerating at 155mph

There’s not much difference between bind and call in this simple case — but these methods are much more powerful than shown here. This was just to explain the binding concept so we can better understand this.

`this` and constructors/classes

We already explored constructors and classes in a previous post — and you’ve probably noticed how frequently we use this inside them.

class Car {
  constructor(model, team) {
    this.model = model;
    this.team = team;
  }
}

Here’s a good opportunity to reinforce why this is so important. A class is instantiated with the new keyword. In that earlier post, I explained that the reason this exists inside a constructor is because the constructor “creates” a this context for the object. The example I used was:

function Pet(name, ownerName) {
  // const this = {};
  this.name = name;
  this.ownerName = ownerName;
  this.identify = () => {
    return `${this.name} belongs to ${this.ownerName}`;
  }
  // return this;
}

But now we can go further: when we use the new keyword, JavaScript automatically binds the this inside the constructor/class to the new object being created.

Back to our code:

class Car {
  constructor(model, team) {
    this.model = model;
    this.team = team;
  }
}

In this code, notice how the argument name and the class property name are the same. The this.model on the left refers to the instance’s property, while the model on the right is the constructor argument.

Also, when we instantiate an object from this class, this will refer to the new object:

class Car {
  constructor(model, team) {
    this.model = model;
    this.team = team;
  }

  showThis() {
    console.log(this);
  }
}

const car = new Car("MCL39", "McLaren");
car.showThis(); // Object { model: "MCL39", team: "McLaren" }

`this` and Callbacks

Let’s simulate the 200ms reaction time a racing driver has before pressing the throttle. We’ll use setTimeout() — which takes two parameters: a delay time and a function to run once that time has passed.

class Car {
  constructor(model, team) {
    this.model = model;
    this.team = team;
  }

  accelerate() {
    setTimeout(function() {
      console.log(`Accelerating at ${this.model}`);
    }, 200);
  }
}

const car = new Car("MCL39", "McLaren");
car.accelerate(); // Accelerating at undefined

Oops… this.model is undefined? Aren’t we inside the car object?

That’s the catch: we’re inside a callback function, which is just a regular function — and as explained earlier, in normal functions, this refers to the global object (or undefined in strict mode).
Let’s verify:

class Car {
  constructor(model, team) {
    this.model = model;
    this.team = team;
  }

  showThis() {
    setTimeout(function() {
      console.log(this);
    }, 200);
  }
}

const car = new Car("MCL39", "McLaren");
car.showThis(); // Window {...} or undefined

There are two ways to fix this:

Option 1: Explicit binding with `bind()`

class Car {
  constructor(model, team) {
    this.model = model;
    this.team = team;
  }

  accelerate() {
    setTimeout(function() {
      console.log(`Accelerating at ${this.model}`);
    }.bind(this), 200);
  }
}

const car = new Car("MCL39", "McLaren");
car.accelerate(); // Accelerating at MCL39

We’re explicitly binding the this context to the object when passing the function into setTimeout().

Option 2: Using an arrow function

class Car {
  constructor(model, team) {
    this.model = model;
    this.team = team;
  }

  accelerate() {
    setTimeout(() => {
      console.log(`Accelerating at ${this.model}`);
    }, 200);
  }
}

const car = new Car("MCL39", "McLaren");
car.accelerate(); // Accelerating at MCL39

Arrow functions don’t create their own this — they inherit it from the outer context, which in this case is the accelerate() method. That’s why this solution works so well.

For a deeper explanation of why this works and why I recommend arrow functions in this context, check the arrow functions post — it covers the nuance in detail.

Wrapping up

JavaScript’s this can be confusing, but with some practical rules and examples, you can master it:

this refers to the calling object in most cases
In strict mode, this is undefined unless explicitly bound
In global functions, it defaults to the global object (window/global)
Arrow functions don’t have their own this, they inherit it from the parent scope
.bind(), .call(), and .apply() give you explicit control over this

Knowing how to use this effectively will help you write more predictable, safer code — especially in modern frameworks like React or when designing your own reusable JavaScript modules.

💬 Have you ever been bitten by a confusing this bug?
Let me know in the comments — and let’s help each other write better JavaScript.

📬 And don’t forget: follow me @matheusjulidori for more hands-on JavaScript tips, patterns, and dev-friendly content, every week! Share this content with your peers if you enjoyed it!

👉 Follow me @matheusjulidori for the next episodes of Do You Know How It Works?

🎥 Subscribe to my YouTube channel to be the first ones to watch my new project as soon as it is released!

Do you know how it works? - Factory Functions vs Constructor Functions

Matheus Julidori — Mon, 28 Apr 2025 16:42:56 +0000

TL;DR:
Factory functions and constructor functions both solve the problem of object creation and code repetition, but they do it differently. Factory functions return objects explicitly and offer better flexibility and encapsulation (closures), while constructor functions use the new keyword and automatically set up prototypal inheritance, sharing methods across instances. In this post, we break down real-world examples, when to use each one, and why understanding both patterns makes your JavaScript code more powerful, scalable, and readable.

Introduction

In the previous post, we explored factory functions and constructor functions separately, learning how each helps eliminate code duplication.
Today, as promised, we’ll dive straight into a practical comparison between them — focusing almost entirely on code examples.
We’ll revisit our pet shop, explore both patterns side by side, and finally answer the million-dollar question:

👉 Which one should you use, and when?

If you enjoy learning by doing (and breaking things down step-by-step), this post was made for you.

Quick Recap

In this topic, we’ll take a much more practical approach. Almost everything will be explained using code. So, to start, let’s quickly recap what factory and constructor functions look like:

function carFactory(m) {
  return {
    model: m
  };
}

function Car(m) {
  // this = {}
  this.model = m;
  // return this
} // The commented code happens under the hood; you don't need to write it

const car1 = carFactory("McLaren");
const car2 = new Car("Sauber");

Factory Functions: Explicitly return an object with the parameters we pass. Invoked normally.

Constructor Functions: Invoked using the reserved word new, implicitly return the this = {} object. This action is called Object Instantiation. The object in question is an Instance of the constructor function.

The similarities are easy to see — both create a person object (or car in this case) and return it somehow.

But let’s focus on the differences. First, we’ll discuss factory functions, then constructor functions.

Factory Functions

function carFactory(m) {
  return {
    model: m,
    accelerate() {
      return `Accelerating a ${this.model}`;
    }
  };
}

const car1 = carFactory("McLaren");
const car2 = carFactory("Sauber");

console.log(car1);
/*
Object {
  model: "McLaren"
  accelerate: function accelerate()
  __proto__: Object {...}
}
*/

console.log(car2);
/*
Object {
  model: "Sauber"
  accelerate: function accelerate()
  __proto__: Object {...}
}
*/

car1.accelerate(); // Accelerating a McLaren
car2.accelerate(); // Accelerating a Sauber

Notice something important: where the accelerate() function is located.

It’s inside the object, alongside the model attribute.

At first glance, this doesn’t seem to matter much — both objects execute the function just fine.

But what happens if I modify that function?

car1.accelerate = function() {
  return `Accelerating a ${this.model} with all my strength!`;
};

car1.accelerate(); // Accelerating a McLaren with all my strength!
car2.accelerate(); // Accelerating a Sauber

Notice how only car1’s function changed. This tells us a few things:

car1.accelerate() and car2.accelerate() are not the same function in memory.

Every time carFactory() creates an object, it copies everything from inside the return into a new object. Each object gets its own copy of the function and attribute.
Since each object has its own copy, it consumes more memory.

With simple functions like this, it’s not a big deal. But at scale, memory consumption adds up.
Finally, it means that if I want to modify the function logic, I would need to modify it in every created object.

Conclusion:

Even though we’re creating objects and "inheriting" characteristics defined in the factory function, we’re not building an inheritance tree or hierarchy — we are merely copying characteristics.

Is that a bad thing? Not necessarily!

It has its advantages. But before we understand the advantages, let's look at the ways of solving it. First, the bad way (please, don't ever do this — seriously. I'm only showing it for didactic reasons).

Solution 1 — Terrible

If we look again at car1 and car2, we’ll see they are plain Objects. Meaning essentially they are pure instances of Object.

In theory, we could add a function to any __proto__ or prototype (some people already know where this is going, and they are not liking it at all).

car1.__proto__.floorIt = function() {
  return "Vrooooommmm";
};

car1.floorIt(); // Vrooooommmm
car2.floorIt(); // Vrooooommmm

Solved, right?

Yes — and now you’ve created a monster, a catastrophe.

Object.prototype === car1.__proto__; // true

See the problem?

If not, here it is:

const totallyNotACar = {};

totallyNotACar.floorIt(); // Vrooooommmm

Vrooooommmm.

Now everything can floor it. Seriously — everything:

window.floorIt(); // Vrooooommmm
const numbers = [1, 2, 3, 4];
numbers.floorIt(); // Vrooooommmm

Why does this happen?

Remember from the inheritance topic? Everything in JS is ultimately an Object.

And car1 was a pure Object — so modifying its prototype modified every Object’s prototype, and now everything can go Vrooooommmm

Solution 2 — Bad

The second solution is to create a custom __proto__ before building the factory function, and then assign it to every object created.

const prototypeCarFactory = {
  accelerate() {
    return `Accelerating a ${this.model} with all my strength!`;
  }
};

function carFactory(m) {
  return Object.create(prototypeCarFactory, {
    model: {
      value: m
    }
  });
}

const car1 = carFactory("McLaren");
const car2 = carFactory("Sauber");

car1.accelerate(); // Accelerating a McLaren with all my strength!
car2.accelerate(); // Accelerating a Sauber with all my strength!

console.log(car1);
/*
Object {
  model: "McLaren"
  __proto__: Object {...}
}
*/

console.log(car2);
/*
Object {
  model: "Sauber"
  __proto__: Object {...}
}
*/

console.log(car2.__proto__);
/*
Object {
  accelerate: function accelerate
  __proto__: Object {...}
}
*/

Now the accelerate() function is no longer inside the object itself, but inside its __proto__.

And __proto__ does not point directly to Object anymore.

If I modify car1.__proto__, it will reflect on car2.__proto__ — without affecting every object in the system.

Why are both of these solutions bad?

Because the beauty of factory functions is precisely in not having inheritance.

They favor simplicity and composition instead.

Now, let’s move on to constructor functions.

Constructor Functions

function Car(m) {
  this.model = m;
}

const car1 = new Car("McLaren");

console.log(car1);
/*
Object {
  model: "McLaren"
  __proto__: {
    constructor: function Car(m)
  }
}
*/

The created object is an instance of Car(), meaning its prototype is Car, not Object.

It directly inherits from Car.

In other words, all that messy workaround we needed in the factory to avoid pointing __proto__ to Object?

Here, it’s done automatically.

Every object already comes with its inheritance correctly set by default.

"Alright Matheus, so I should always use constructors, since they do everything factories do, and more?"

Hold your horses, young padawan.

Like I said before: each approach has its own advantages.

When Should You Use Which?

The choice between Factory Functions and Constructor Functions depends on what you’re aiming for in terms of inheritance, encapsulation, readability, flexibility, and even performance.

Let’s understand each case:

Use Factory Functions when...

1. You want encapsulation with closures

Factory functions allow you to create truly private variables using closures (if you don't know what they are, don't worry, we'll get there in the next topics), something constructors can't do easily (without hacks like Symbols or #private fields in ES2022+).

function bankAccount(initialBalance) {
  let balance = initialBalance;

  return {
    deposit(amount) {
      balance += amount;
    },
    withdraw(amount) {
      if (amount <= balance) balance -= amount;
    },
    currentBalance() {
      return balance;
    }
  };
}

const account = bankAccount(100);
account.deposit(50);
console.log(account.currentBalance()); // 150
console.log(account.balance); // undefined — balance is protected

2. You need more flexibility

You can easily return different kinds of objects, apply conditional logic, or change the object depending on parameters.

This allows for more dynamic object creation.

function createAnimal(type) {
  if (type === 'dog') {
    return { bark: () => 'Woof!' };
  } else if (type === 'cat') {
    return { meow: () => 'Meow!' };
  }
}

const dog = createAnimal('dog');
console.log(dog.bark()); // Woof!

3. You don't need an explicit inheritance chain

Factory functions create pure, independent objects.

This is perfect in simpler systems or more functional programming styles, where inheritance would just add unnecessary complexity.

It’s very similar to how structs work in C++.

4. You prefer composition over inheritance

Factory functions are excellent for object composition.

Instead of relying on a rigid inheritance structure, you combine behaviors.

This follows the principle: "Composition over inheritance".

const canFly = (name) => ({
  fly: () => `${name} is flying!`
});

const canSwim = (name) => ({
  swim: () => `${name} is swimming!`
});

function createDuck(name) {
  return {
    name,
    ...canFly(name),
    ...canSwim(name)
  };
}

const donald = createDuck("Donald");
donald.fly(); // Donald is flying!
donald.swim(); // Donald is swimming!

Use Constructor Functions when...

1. You want instances with prototypes and inheritance

Constructor functions automatically give you a prototype chain.

And if you want methods to be shared among all instances (rather than duplicated), constructors shine.

function Person(name) {
  this.name = name;
}

Person.prototype.speak = function() {
  return `Hi, my name is ${this.name}`;
};

const john = new Person("John");
console.log(john.speak()); // Hi, my name is John

2. You care about performance at large scale

Since methods live on the prototype, they are not copied for each new instance, saving memory.

// Every person shares the same method
console.log(john.speak === new Person("Maria").speak); // true

3. You are using classes or frameworks based on OOP

Some libraries (like older React with createClass, or certain prototype-oriented libraries) expect you to use constructors or classes.

Also, developers coming from Java, C#, or other OOP backgrounds will find this more natural.

Summary:

If you're working with simple objects without needing inheritance, and you want control or encapsulation → Use Factory Functions.
If you're building complex types that share many behaviors and you want memory efficiency → Use Constructor Functions.

Example

Remember the PetShop from the previous topic?

Back then, we built an HTML page that registered Pets and created petCards.

Over time, we noticed that Pets became more and more complex, needing to inherit shared behaviors.

But the Cards?

They remained simple — we just needed a small, standardized object to insert into the DOM.

What does this show us?

That in this case, it would be ideal to have Pets created with a constructor function and petCards created with a factory function.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Pet Registration</title>
  <style>
    body {
      font-family: sans-serif;
      padding: 20px;
      background-color: #f7f7f7;
    }

    form {
      margin-bottom: 20px;
      padding: 16px;
      background: white;
      border-radius: 8px;
      box-shadow: 0 2px 4px rgba(0,0,0,0.1);
      max-width: 400px;
    }

    label {
      display: block;
      margin-bottom: 8px;
      font-weight: bold;
    }

    input {
      width: 100%;
      padding: 8px;
      margin-bottom: 16px;
      border: 1px solid #ccc;
      border-radius: 4px;
    }

    button {
      padding: 10px 16px;
      background-color: #4CAF50;
      color: white;
      border: none;
      border-radius: 6px;
      cursor: pointer;
    }

    .card-pet {
      background: white;
      border: 2px solid #ccc;
      border-radius: 8px;
      padding: 12px;
      margin-bottom: 10px;
      max-width: 280px;
      box-shadow: 0 2px 4px rgba(0,0,0,0.1);
    }
  </style>
</head>
<body>

  <h1>Pet Registration</h1>

  <form id="form-pet">
    <label for="petName">Pet Name</label>
    <input type="text" id="petName" required>

    <label for="ownerName">Owner's Name</label>
    <input type="text" id="ownerName" required>

    <label for="species">Species</label>
    <input type="text" id="species" required>

    <button type="submit">Register Pet</button>
  </form>

  <div id="area-pets"></div>

  <script>
    function Pet(petName, ownerName, species) {
      let _petName = petName;
      let _ownerName = ownerName;
      let _species = species;

      this.identify = function() {
        return `The ${_species} ${_petName} belongs to ${_ownerName}`;
      };

      this.getData = function() {
        return { petName: _petName, ownerName: _ownerName, species: _species };
      };
    }

    function petCardFactory(pet) {
      const { petName, ownerName, species } = pet.getData();

      const card = document.createElement("div");
      card.className = "card-pet";

      const title = document.createElement("h3");
      title.textContent = petName;

      const speciesEl = document.createElement("p");
      speciesEl.textContent = `Species: ${species}`;

      const ownerEl = document.createElement("p");
      ownerEl.textContent = `Owner: ${ownerName}`;

      card.appendChild(title);
      card.appendChild(speciesEl);
      card.appendChild(ownerEl);

      return card;
    }

    // Form logic
    const form = document.getElementById("form-pet");

    form.addEventListener("submit", function(event) {
      event.preventDefault();

      const petName = document.getElementById("petName").value;
      const ownerName = document.getElementById("ownerName").value;
      const species = document.getElementById("species").value;

      const newPet = new Pet(petName, ownerName, species);
      document.getElementById("area-pets").appendChild(petCardFactory(newPet));

      form.reset();
    });

  </script>
</body>
</html>

Bonus: Class vs Constructor

ES6 introduced the class keyword in JavaScript.

I'll be straight to the point here, without too much sugarcoating:

Classes are EXACTLY the same thing as constructor functions.

They just use a cleaner syntax — but underneath, they still generate constructor functions.

So why didn’t we use class from the start?

Because I wanted you to understand the concept first — before seeing the syntax sugar.

From now on, whenever we use constructors, we’ll define them using the class syntax:

class Car {
  constructor(m) {
    this.model = m;
  }

  accelerate() {
    return `Accelerating a ${this.model}`;
  }
}

But be warned: there’s a lot more to classes in JavaScript (especially around inheritance, super, getters/setters, static properties, etc).

We’ll explore those topics later on!

Wrapping up

Both factory functions and constructor functions are powerful tools in a JavaScript developer’s toolkit.

Factory functions give you encapsulation, flexibility, and favor composition over inheritance.
Constructor functions (and classes) give you automatic inheritance, prototype efficiency, and a traditional OOP structure.

Choosing between them depends on your project's needs — whether you prioritize simplicity and modularity, or need robust hierarchies and performance across many instances.

Understanding both approaches makes you a more complete developer, ready to pick the right tool for the right job.

💬 What about you? Do you lean more toward factories, constructors, or mix both depending on the case?

Drop a comment — I’d love to hear how you apply this in your projects!

🚀 Next up: We'll explore what exactly this means in JavaScript — a topic that still trips up even experienced devs!

📬 And don’t forget: follow me @matheusjulidori for more hands-on JavaScript tips, patterns, and dev-friendly content, every week! Share this content with your peers if you enjoyed it!

🎥 Subscribe to my YouTube channel to be the first ones to watch my new project as soon as it is released!

Do you know how it works? - JavaScript Constructor Functions

Matheus Julidori — Tue, 22 Apr 2025 14:18:52 +0000

TL;DR:

Constructor functions in JavaScript are another way to create reusable object templates, much like factory functions. They use the new keyword and this to construct and return a new object automatically — no need for an explicit return. They help eliminate code duplication and improve consistency in your codebase. In this post, we revisit the pet shop example and compare constructor functions to factory functions to understand when and why to use them.

📌 Haven’t read Episode 3 yet?

Check out “Factory Functions — Do You Know How It Works?”

Introduction

If you’ve been following the series “Do You Know How It Works?”, you’ve seen that avoiding repetitive code is a major principle in writing clean JavaScript. Last week, we tackled factory functions as a way to solve that problem — and they worked beautifully for our pet shop scenario.

This week, we’re exploring another powerful (and older) JavaScript pattern: the constructor function. It looks a bit different, but at its core, it has the same mission — building reusable logic to avoid repetition. Constructor functions were the go-to before ES6 classes, and they’re still a foundational concept in the JavaScript ecosystem today.

Here is the full translation of your post, including the code, with no modifications to the original structure. Suggestions will follow below if needed.

Very similar to factory functions, a constructor function is also used to shape and build an object. They work a bit differently, but they follow the same core principle: eliminate code repetition.

In object-oriented languages, these functions are embedded within classes. They define how the class object will be built. But since JavaScript didn’t support classes for a long time and needed the same functionality, that’s where the name comes from. So, in a way, JS had constructors even before it had classes.

When we talked about factory functions, we used the pet shop example (If you haven't seen this post, read it first, we’ll omit some concepts here that were explained in it). To refresh your memory, we created a scenario where I want to register pets in my pet shop, along with information about their owners.

const pet1 = {
  name: "Katze",
  ownerName: "Matheus",
  identify() {
    return `${this.name} belongs to ${this.ownerName}`
  }
}

const pet2 = {
  name: "Hund",
  ownerName: "Pedro",
  identify() {
    return `${this.name} belongs to ${this.ownerName}`
  }
}

Every time I want to create an object, I’ll have to duplicate the code and the identify function. If you’re not already tired of hearing me say that duplicating code is horrible, go read the previous topics and you will be. (Seriously, read the previous posts — they cover very important concepts you should understand before diving into constructor functions.)

This problem was solved using factory functions, where we created a function that returned this object for us. This function could be called as many times as I wanted, just passing the name and ownerName parameters, and the function would take care of the repetitive part and return the object.

function petFactory(name, ownerName) {
  return {
    name,
    ownerName,
    identify() {
      return ` ${this.name} belongs to ${this.ownerName}`;
    }
  };
}

const pet1 = petFactory("Katze", "Matheus");

Another way to solve this is by using constructor functions, but unlike factory functions, constructors don’t directly return the created object. That’s where the magical new and this come in.

Constructor Functions in the Real World

Before jumping into code, let’s understand the concept. Imagine this scenario: It’s a sunny Sunday in Montreal. Exactly at 3 PM, the Canadian GP starts. Sauber (miraculously) gets an incredible start and is fighting at the front. Engineers and drivers need to stay in constant communication throughout the race to maintain their advantage. It’s a long race, and the engineers notice heavy rain is about to hit and need to tell Gabriel Bortoleto to pit for wet tires. Now imagine if every time they talked, they had to go through a whole dialogue:

“Hello Gabriel, how’s the race?”
“Hello Steven, going well, and over there?”
“All good here. We have an important message. Can we tell you?”
“Sure, what’s the info?”
“Well, we need you to box. Heavy rain is coming.”
“Okay, I’ll box next lap, just passed the pit entrance.”

You can draw two conclusions from this: First, if you’ve followed my content, you know I’m a big F1 fan. Second, this inefficient communication caused trouble for the team and driver. That’s why every team has protocols — a standard to eliminate unnecessary repetition and streamline action. With just one message, Bortoleto knows exactly what to do:

“Box box, heavy rain next lap.”
“Understood.”

The concept of factory functions, which we saw earlier, is basically the same: “Give me what’s necessary, and I’ll handle the rest.”

Constructor functions follow the same principle. We want to create a mold, a pattern for creating objects, so we don’t repeat what’s unnecessary — just pass the unique information for that object.

Constructor Functions in Code

Let’s reuse the example from earlier and create a constructor function to register pets in a pet shop.

function Pet(name, ownerName) {
  this.name = name;
  this.ownerName = ownerName;
  this.identify = () => {
    return `${this.name} belongs to ${this.ownerName}`;
  }
}

const pet1 = new Pet("Katze", "Matheus");

Let’s notice a few things:

A constructor function borrows the best practices of a class, so it should start with an uppercase letter.
Unlike a factory function, this function doesn’t return anything.

Focusing on point 2 — if it doesn’t return anything, how does JS know that pet1 should receive an object? That’s where the magic of new comes in. Under the hood, when the interpreter hits new, it automatically modifies how the Pet(name, ownerName) function behaves.

function Pet(name, ownerName) {
  // const this = {};
  this.name = name;
  this.ownerName = ownerName;
  this.identify = () => {
    return `${this.name} belongs to ${this.ownerName}`;
  }
  // return this;
}

The two commented lines are code we don’t see, but JS adds behind the scenes. this is a reserved keyword in JS that references the current execution context. In this case, it refers to the Pet object. In short, JS creates an object behind the scenes, assigns this to it, and automatically inherits from Object. (We’ve already covered inheritance in a previous post.)

Comparison

Transforming our previous factory function into a constructor function, we get:

function Pet(petName, ownerName, species) {
  let _petName = petName;
  let _ownerName = ownerName;
  let _species = species;

  this.identify = function() {
    return `The ${_species} ${_petName} belongs to ${_ownerName}`;
  };

  this.updateData = function(newName, newOwner, newSpecies, user) {
    if (user.role !== "admin") {
      console.warn("Permission denied: only admins can update pet data.");
      return;
    }
    _petName = newName;
    _ownerName = newOwner;
    _species = newSpecies;
  };

  this.getData = function() {
    return { petName: _petName, ownerName: _ownerName, species: _species };
  };
}

// Users
const admin = { name: "Matheus", role: "admin" };
const visitor = { name: "Pedro", role: "user" };

// Creating a pet instance using 'new'
const pet = new Pet("Katze", "Matheus", "Cat");

console.log(pet.identify()); // The Cat Katze belongs to Matheus

pet.updateData("Lion", "Matheus Julidori", "Feline", visitor); // Permission denied
console.log(pet.identify()); // The Cat Katze belongs to Matheus

pet.updateData("Feline", "Matheus Julidori", "Cat", admin); // Allowed
console.log(pet.identify()); // The Cat Feline belongs to Matheus Julidori

Again, all the problems we discussed about factory functions are solved here. And similarly, we can use this in a frontend application:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Pet Registration</title>
<style>
    body {
      font-family: sans-serif;
      padding: 20px;
      background-color: #f7f7f7;
    }

    form {
      margin-bottom: 20px;
      padding: 16px;
      background: white;
      border-radius: 8px;
      box-shadow: 0 2px 4px rgba(0,0,0,0.1);
      max-width: 400px;
    }

    label {
      display: block;
      margin-bottom: 8px;
      font-weight: bold;
    }

    input {
      width: 100%;
      padding: 8px;
      margin-bottom: 16px;
      border: 1px solid #ccc;
      border-radius: 4px;
    }

    button {
      padding: 10px 16px;
      background-color: #4CAF50;
      color: white;
      border: none;
      border-radius: 6px;
      cursor: pointer;
    }

    .card-pet {
      background: white;
      border: 2px solid #ccc;
      border-radius: 8px;
      padding: 12px;
      margin-bottom: 10px;
      max-width: 280px;
      box-shadow: 0 2px 4px rgba(0,0,0,0.1);
    }
  </style>
</head>
<body>

  <h1>Pet Registration</h1>

  <form id="form-pet">
    <label for="petName">Pet Name</label>
    <input type="text" id="petName" required>

    <label for="ownerName">Owner's Name</label>
    <input type="text" id="ownerName" required>

    <label for="species">Species</label>
    <input type="text" id="species" required>

    <button type="submit">Register Pet</button>
  </form>

  <div id="area-pets"></div>

  <script>
    function Pet(petName, ownerName, species) {
      let _petName = petName;
      let _ownerName = ownerName;
      let _species = species;

      this.identify = function() {
        return `The ${_species} ${_petName} belongs to ${_ownerName}`;
      };

      this.getData = function() {
        return { petName: _petName, ownerName: _ownerName, species: _species };
      };
    }

    function PetCard(pet) {
      const { petName, ownerName, species } = pet.getData();

      this.card = document.createElement("div");
      this.card.className = "card-pet";

      this.title = document.createElement("h3");
      this.title.textContent = petName;
      this.card.appendChild(this.title);

      this.speciesEl = document.createElement("p");
      this.speciesEl.textContent = `Species: ${species}`;
      this.card.appendChild(this.speciesEl);

      this.ownerEl = document.createElement("p");
      this.ownerEl.textContent = `Owner: ${ownerName}`;
      this.card.appendChild(this.ownerEl);
    }

    const form = document.getElementById("form-pet");

    form.addEventListener("submit", function(event) {
      event.preventDefault();

      const petName = document.getElementById("petName").value;
      const ownerName = document.getElementById("ownerName").value;
      const species = document.getElementById("species").value;

      const newPet = new Pet(petName, ownerName, species);
      const newPetCard = new PetCard(newPet);
      document.getElementById("area-pets").appendChild(newPetCard.card);

      form.reset();
    });
  </script>
</body>
</html>

So, we solved the same problem using two different approaches. But notice that, in this frontend case, some things became slightly more complex (perhaps unnecessarily) when using constructor functions instead of factory functions. And that leads us to the million-dollar question: “Which one should I use, and what’s the real difference between them?”

That’s exactly what we’ll cover in the next post, which will be entirely dedicated to answering that question.

Final Thoughts

Constructor functions are an essential piece of JavaScript's object construction toolbox. While factory functions offer more flexibility and control, constructor functions provide a more classical, OOP-inspired syntax that many developers coming from other languages will recognize.

They both solve the same core issues: code repetition, maintenance headaches, scalability, and structure. Whether you prefer new and this, or simple return statements in closures, understanding both patterns will help you write more robust, readable, and maintainable JavaScript.

Factory Function	Constructor Function
`return {}`	uses `this`
No `new` keyword	Requires `new`
More flexible	Familiar to OOP devs
Can be used as closures	Can use prototypes

💬 Have any thoughts, questions, or cool examples you've come across?

Drop a comment — I’d love to learn how you’re using this in your projects!

📬 If you're enjoying the series, consider bookmarking it or sharing with a fellow JS dev. Let’s grow together!

👉 Follow me @matheusjulidori for the next episodes of Do You Know How It Works?

🎥 Subscribe to my YouTube channel to be the first ones to watch my new project as soon as it is released!

Next up: We're finally answering the big question: Factory or Constructor — which one should you use, and when?

Don’t miss it.

Do you know how it works? - JavaScript Factory Functions

Matheus Julidori — Mon, 14 Apr 2025 13:07:33 +0000

TL;DR:

Factory Functions are functions that build and return objects based on input parameters — just like a real-world factory. Unlike creating objects manually, they solve key issues like code repetition, poor maintainability, lack of scalability, and unprotected data structures. In this post, we explore how Factory Functions work, what problems they solve, and how they can be used both on the backend and frontend to write clean, secure, and scalable code.

Introduction

What is a Factory Function, why do we need it, and where is it used? Is this just a fancy term for explaining a dry theory about something unnecessary — or is it a truly useful concept for JavaScript developers?

Welcome to Episode 3 of the “Do You Know How It Works?” series!

In this post, we’ll take a fun and practical approach to understanding Factory Functions — what they are, what problems they solve, and how they can seriously improve the way we structure our code. And don’t worry, this isn’t just theory — we’re going to build examples step-by-step and apply it in a real use case.

In short, factory functions are just functions that build something and return what was built. That “something” could be an object, another function — anything.

In this article, we’ll focus on objects as our primary example.

“But Matheus, if I want to build an object, I can just use const obj = {...} and move on, right?”

Sure — and sometimes that’ll be enough. But as your application grows, that approach can start causing problems. Especially when you're creating lots of similar objects across different places.

To show you what I mean, let’s build a pet registration system for a pet shop. Along the way, we’ll explore the issues that come up with the “manual” approach.

Problem 1 — Code Repetition

const pet1 = {
  name: "Katze",
  ownerName: "Matheus",
  identify() {
    return `${this.name} belongs to ${this.ownerName}`;
  }
};

const pet2 = {
  name: "Hund",
  ownerName: "Pedro",
  identify() {
    return `${this.name} belongs to ${this.ownerName}`;
  }
};

const pet3 = {
  name: "Vogel",
  ownerNme: "Miguel", // Typo here
  identify() {
    return `${this.name} belongs to ${this.ownerName}`;
  }
};

console.log(pet1.identify()); // Katze belongs to Matheus
console.log(pet2.identify()); // Hund belongs to Pedro
console.log(pet3.identify()); // Vogel belongs to undefined

Houston, we have the first problem: Code repetition.

If you’ve read the article about inheritance, you know where this is going: repeating logic is a practice practice considered terrible, condemnable, abominable, disastrous, horrible, catastrophic… as Cap would say:

In this example, we’re duplicating the structure of the object and its method for each new pet. Every time I had to create a new pet, I had to write the entire object and repeat the logic. In the programming world, having to repeat logic multiple times in your code will cause a huge delay and make you more prone to errors. Notice that in the third pet, the attribute representing the owner's name was written as ownerNme and not ownerName. Seems like a silly mistake, but trust me — from experience — after 5–6 hours of straight coding, finding a typo is harder than finding a logic error.

“But mate, if I use Copy+Paste, it’ll be quick to create the objects and I won’t mistype the attribute name.”

Don't use useful resources to justify badly written code.

In a large-scale codebase, you might not mistype the attribute, but copying and pasting 800 different pets won’t be fast at all, it’s absolute madness.

Problem 1: Repeting code.

Problem 2 — Maintainability

Let’s say I want to rename the name property to petName, for better readability. Here’s what happens:

const pet1 = {
  petName: "Katze",
  ownerName: "Matheus",
  identify() {
    return `${this.petName} belongs to ${this.ownerName}`;
  }
};

const pet2 = {
  petName: "Hund",
  ownerName: "Pedro",
  identify() {
    return `${this.petName} belongs to ${this.ownerName}`;
  }
};

const pet3 = {
  petName: "Vogel",
  ownerName: "Miguel",
  identify() {
    return `${this.petName} belongs to ${this.ownerName}`;
  }
};

console.log(pet1.identify()); // Katze belongs to Matheus
console.log(pet2.identify()); // Hund belongs to Pedro
console.log(pet3.identify()); // Vogel belongs to Miguel

And thus, the second problem is on our path: Maintaining the code.
When I wanted to edit the objects, I had to find and change the attribute in each of them, and once again, I was at risk of making a mistake. Also, in a large-scale codebase, you may have many of these objects scattered throughout the application, in dozens or hundreds of places.

“But Matheus, could just use find-and-replace in my IDE and change all name for petName.”

Don't use useful resources to justify badly written code.
Sure, your IDE may indeed find all the name and replace with petName, but what if other objects — like employees — also have a name property?
Congratulations, your employees now have ✨petNames✨.

Problem 2: Code is hard to maintain.

Problem 3 — Scalability

Still in this line of modifying the object, now I want to add another parameter to my pet: the animal’s species. To do this, I’ll modify the object again.

const pet1 = {
  petName: "Katze",
  ownerName: "Matheus",
  species: "Cat",
  identify() {
    return `The ${this.species} ${this.petName} belongs to ${this.ownerName}`;
  }
};

const pet2 = {
  petName: "Hund",
  ownerName: "Pedro",
  species: "Dog",
  identify() {
    return `The ${this.species} ${this.petName} belongs to ${this.ownerName}`;
  }
};

const pet3 = {
  petName: "Vogel",
  ownerName: "Miguel",
  species: "Bird",
  identify() {
    return `The ${this.species} ${this.petName} belongs to ${this.ownerName}`;
  }
};


console.log(pet1.identify()); // The cat Katze belongs to Matheus
console.log(pet2.identify()); // The dog Hund belongs to Pedro
console.log(pet3.identify()); // The bird Vogel belongs to Miguel

Shine on us, oh mighty third problem: Scalability.
Again, to add this attribute, I had to go through each object and also modify each function inside those objects. So, in order to add features to my code, I had to go on a hunting adventure to find all objects in my codebase, and risk breaking something in the process.
A huge amount of work that could be avoided.

“But I…”

Dude, don't even start. You already know what I’ll say. 😅

Problem 3: Hard to evolve code.

Problem 4 — Lack of Protection

Let’s say we’ve got everything working and our system is live. Then someone (or some code) changes object values like this:

pet1.ownerName = "Matheus Julidori";
pet2.ownerName = "Pedro Henrique";
pet3.petName = "Miguel S.";

console.log(pet1.identify()) // The Cat Katze belongs to Matheus Julidori
console.log(pet2.identify()) // The Dog Hund belongs to Pedro Henrique
console.log(pet3.identify()) // The Bird Miguel S. belongs to Miguel

He presents himself bringing tons of bugs: The dreaded fourth problem, lack of security.
The object’s elements are all mutable. I can change them however I want, whenever I want. Not just me, but anyone or anything in the system.
Now we’ve got inconsistent data — names with and without last names, pet names that were meant for owners, and no restrictions to prevent it.

Problem 4: No data protection.

Summary of the Problems

Code repetition
Hard to maintain
Difficult to scale
No data protection

And I didn’t even started on subject of testing. If these 4 aren’t enough reasons to want a better solution... I really hope we’re not on the same team 😅
And by a better solution, I mean design patterns, like Factory Functions

Factory Functions to the Rescue

Think of a car factory: raw materials go in, a complete car comes out (more or less, but you get the point)
Factory functions follow the same principle: they take input (parameters) and return a fully structured object.

Let’s refactor:

function petFactory(petName, ownerName, species) {
  return {
    petName,
    ownerName,
    species,
    identify() {
      return `The ${this.species} ${this.petName} belongs to ${this.ownerName}`;
    }
  };
}

const pet1 = petFactory("Katze", "Matheus", "Cat");
const pet2 = petFactory("Hund", "Pedro", "Dog");
const pet3 = petFactory("Vogel", "Miguel", "Bird");

console.log(pet1.identify()) // The Cat Katze belongs to Matheus
console.log(pet2.identify()) // The Dog Hund belongs to Pedro
console.log(pet3.identify()) // The Bird Vogel belongs to Miguel

We can already see that the code is cleaner, more organized and readable, and without tons of repeated stuff. Now all the logic lives in one single place. Cleaner, easier to maintain, and error-proof. But still, it lacks security.

Let’s Add Security

We can enhance our factory with private variables and controlled updates:

function petFactory(petName, ownerName, species) {
  let _petName = petName;
  let _ownerName = ownerName;
  let _species = species;

  return {
    identify() {
      return `The ${this._species} ${this._petName} belongs to ${this._ownerName}`;
    },
    update(newName, newOwner, newSpecies, user) {
      if (user.role !== "admin") {
        console.warn("Access denied: only admins can update pet data.");
        return;
      }
      this._petName = newName;
      this._ownerName = newOwner;
      this._species = newSpecies;
    },
    getData() {
      return { petName: this._petName, ownerName: this._ownerName, species: this._species };
    }
  };
}

// Users
const admin = { name: "Matheus", role: "admin" };
const visitor = { name: "Pedro", role: "user" };

// Creating pet
const pet = petFactory("Katze", "Matheus", "Cat");

console.log(pet.identify()); // The Cat Katze belongs to caretaker Matheus

pet.updateData("Lion", "Matheus Julidori", "Feline", visitor); // Permission denied
console.log(pet.identify()); // The Cat Katze belongs to caretaker Matheus

pet.updateData("Feline", "Matheus Julidori", "Cat", admin); // OK
console.log(pet.identify()); // The Cat Feline belongs to caretaker Matheus Julidori

In this example, we created the variables _petName, _ownerName, and _species inside the function. The value of these variables (attributes) isn’t exposed, nor are the attributes themselves, so I can't modify them using something like pet._ownerName = "someone". The only way to change them is by using the atualizarDados() function, which is protected. We simulated a user with permissions — only system admins can use the function to alter data. This way, we solved all four previously discussed problems.

in JS, prefixing an attribute with _ is a convention to indicate they are private properties. But be aware that this doesn't make them inaccessible if you return them in the object. However, in classes, there is the # symbol which makes the properties properly private.

Frontend Example: Building Cards with Factories

You can also use factory functions on the frontend to render data in a structured way.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Pet Registration</title>
  <style>
    body {
      font-family: sans-serif;
      padding: 20px;
      background-color: #f7f7f7;
    }

    form {
      margin-bottom: 20px;
      padding: 16px;
      background: white;
      border-radius: 8px;
      box-shadow: 0 2px 4px rgba(0,0,0,0.1);
      max-width: 400px;
    }

    label {
      display: block;
      margin-bottom: 8px;
      font-weight: bold;
    }

    input {
      width: 100%;
      padding: 8px;
      margin-bottom: 16px;
      border: 1px solid #ccc;
      border-radius: 4px;
    }

    button {
      padding: 10px 16px;
      background-color: #4CAF50;
      color: white;
      border: none;
      border-radius: 6px;
      cursor: pointer;
    }

    .card-pet {
      background: white;
      border: 2px solid #ccc;
      border-radius: 8px;
      padding: 12px;
      margin-bottom: 10px;
      max-width: 280px;
      box-shadow: 0 2px 4px rgba(0,0,0,0.1);
    }
  </style>
</head>
<body>

  <h1>Pet Registration</h1>

  <form id="form-pet">
    <label for="petName">Pet Name</label>
    <input type="text" id="petName" required>

    <label for="ownerName">Owner's Name</label>
    <input type="text" id="ownerName" required>

    <label for="species">Species</label>
    <input type="text" id="species" required>

    <button type="submit">Register Pet</button>
  </form>

  <div id="area-pets"></div>

  <script>
    function petFactory(petName, ownerName, species) {
      let _petName = petName;
      let _ownerName = ownerName;
      let _species = species;

      return {
        identificar() {
          return `The ${this._species} ${this._petName} belongs to ${this._ownerName}`;
        },
        getDados() {
          return {
            petName: this._petName,
            ownerName: this._ownerName,
            species: this._species
          };
        }
      };
    }

    function petCardFactory(pet) {
      const { petName, ownerName, species } = pet.getDados();

      const card = document.createElement("div");
      card.className = "card-pet";

      const title = document.createElement("h3");
      title.textContent = petName;

      const speciesEl = document.createElement("p");
      speciesEl.textContent = `Species: ${species}`;

      const ownerEl = document.createElement("p");
      ownerEl.textContent = `Owner: ${ownerName}`;

      card.appendChild(title);
      card.appendChild(speciesEl);
      card.appendChild(ownerEl);

      return card;
    }

    // Form logic
    const form = document.getElementById("form-pet");

    form.addEventListener("submit", function(event) {
      event.preventDefault();

      const petName = document.getElementById("petName").value;
      const ownerName = document.getElementById("ownerName").value;
      const species = document.getElementById("species").value;

      const newPet = petFactory(petName, ownerName, species);
      document.getElementById("area-pets").appendChild(petCardFactory(novoPet));

      form.reset();
    });
  </script>
</body>
</html>
}

In the script, we used 2 factory functions — one to create pets, and another to create cards and add them to the DOM.

Now you can dynamically build cards in the UI using structured, protected data.

Disclaimer: It’s not good practice to have factory functions manipulate other objects, so the logic to append the created card is not inside the factory. Otherwise, we’d be manipulating the DOM directly.

Factory Functions, Classes, and Constructors

By now you’ve probably noticed:

“This feels a lot like what we do with classes or constructor functions…”

And yes — they are very similar. And if you don't know what constructors and classes are, or which one should you use, don't worry, that’s exactly what we'll be covering in the next topics.

Wrapping Up

Factory functions aren’t just a theoretical concept — they’re a powerful and flexible pattern you can use in real-world JavaScript codebases. Whether you’re building domain models, encapsulating logic, protecting sensitive data, or simply organizing your code more efficiently, factory functions offer a clean and elegant solution.

They fix:

🔁 Code repetition
🛠️ Poor maintainability
📈 Scalability headaches
🔐 Lack of encapsulation

💬 Got a use case, tip, or question about factories?

Drop it in the comments — I’d love to talk more!

📬 And don’t forget: follow me @matheusjulidori for more hands-on JavaScript tips, patterns, and dev-friendly content, every week!

👉 Follow me @matheusjulidori for the next episodes of Do You Know How It Works?

🎥 Subscribe to my YouTube channel to be the first ones to watch my new project as soon as it is released!

Forem: Matheus Julidori

WIll AI really replace devs?

AI and the Dev Job Market: Separating Hype from Reality in an Evolving Landscape

The Problem with Current Devs: The "Programming Bubble" Fallout

The Reality of AI: Beyond Infinite Exponential Hype

The Future of Devs: Built on True Understanding, Not Just "Vibe Code"

Where AI Development Tools Are Headed Next

Final Thoughts: Don't Worry, Most News Is Exaggerated Because They Need to Sell

npm vs Yarn vs pnpm: The Great Package Manager Race (And We Have a Winner!)

Why Package Managers Matter (And Why Your Choice is Crucial)

npm: The Established Default (But Showing Its Age)

Yarn: The Former Challenger (Now Facing its Own Challenges)

pnpm: The Undisputed Modern Winner

🔍 Feature Comparison: Why pnpm Leads

When Should You Use Each? (My Final Recommendation)

Final Thoughts: It's Time for a Smarter Approach

Still Drowning in API Choices? My Battle-Tested Guide to REST, GraphQL & gRPC

Article Index

What is REST? The Enduring Standard

Main Features & Core Concepts:

What is GraphQL? The Client-Driven Query Language

Main Features & Why They Matter:

What is gRPC? The Performance Powerhouse for Microservices

Main Features & Why It's a Game-Changer:

Pros & Cons: A Side-by-Side Comparison

When Should You Use Each? Choosing Your API Style

Performance & Scalability & Hosting & Deployment

Performance & Scalability

Hosting & Deployment Options

Community and Ecosystem: The Support Network Behind Each Style

REST: The Ubiquitous Veteran

GraphQL: The Rising Star with a Dedicated Following

gRPC: The Cloud-Native Workhorse

TL;DR Comparison Table: Community & Ecosystem at a Glance

Tooling, Languages & Frameworks: Bringing Your API to Life

Final Thoughts: Beyond the Hype, Towards Pragmatism

Is Node.js Dying? Meet the Technologies That Promise to Replace It

Article Index

What is Node.js?

Main ideas behind Node.js:

What is Bun?

Main ideas behind Bun:

What is Deno?

Main ideas behind Deno:

Pros and Cons

Node.js

Bun

Deno

So… When Should You Use Each?

Recent Node.js Updates

Improved TypeScript Support

Security Policies

Improved ESM/CommonJS Interoperability

Is Node.js Dying?

Final Thoughts

Do you know how it works? - JS Closures

Introduction

What Is a Closure?

The apartment

Example: Accessing Outer Variables

Function Factory

Use Case: Private Variables

So, What’s a Closure Really?

Why Use Closures?

Classes private variables vs Closures private state

Wrapping Up

⚡ Quick Message!

Do you know how it works? - JS Scopes

Introduction

Scopes in Practice

Initial Conclusions

var, let, and const

Conclusion

Do you know how it works? - Higher Order Functions (HOFs)

Introduction

Parameters in Functions

Functions as Parameters

Returning Functions

Recap

Wrapping Up

`var`, `let`, and `const`

`this` in the context of methods

`this` in the context of functions

`this` and strict mode

Binding and `this`

`this` and constructors/classes

`this` and Callbacks

Option 1: Explicit binding with `bind()`