DEV Community: Mr Abdullah

Linus Trovalds ~ Founder of Linus and GIT

Mr Abdullah — Wed, 26 Aug 2026 12:20:14 +0000

A brilliant engineer who could have become a billionaire, built a trillion-dollar company, and chased every measure of commercial success.

But instead, Linus Torvalds chose something different: independence, flexibility, reliability, and the empowerment of people to build.

He didn’t just create technology. He helped shape a culture where software could remain open, collaborative, and adaptable by engineering rather than ownership.

His brilliance results Linux and Git are more than extraordinary pieces of software, these are reminders that some of the greatest impact comes not from controlling what you build, but from giving others the freedom to build on it.

_And honestly, I don’t even know how he makes his money. 😄
_

Render Infrastructure Incident? Multiple Backend Services Returning 502 and 503 Errors

Mr Abdullah — Thu, 20 Aug 2026 18:06:56 +0000

TL;DR

August 20, 2026

Today, I ran into a problem with multiple backend services hosted on Render.

At first, I assumed one of my applications had failed.

Then I checked another service.

The same thing happened.

I checked another account.

Again, the backend was unavailable.

After checking multiple Render accounts and multiple services, the pattern became difficult to explain as an application-level problem. The services were separate backend applications, but they were experiencing similar availability problems.

The main errors I encountered were 502 Bad Gateway and 503 Service Unavailable.

That raised a bigger question:

Is there an infrastructure-level problem affecting Render services?

What I Observed

The important part of this situation is that I did not encounter the problem with only one application.

I checked multiple Render accounts and multiple services.

The services were primarily backend APIs, and the affected applications were not all part of the same codebase.

The common factor was the hosting platform: Render.

The symptoms included requests failing with responses such as:

502 Bad Gateway

and:

503 Service Unavailable

When the same failure appears across unrelated backend services, it is worth investigating the hosting layer before immediately changing application code.

This does not prove that Render's entire infrastructure was down. It does, however, make a platform-side issue a reasonable possibility when independent services fail at approximately the same time.

Why 502 and 503 Matter

A 502 Bad Gateway generally means that a gateway or proxy could not successfully communicate with the upstream service.

Render's own troubleshooting documentation lists several possible causes for a 502, including a service not listening correctly, connection problems, timeouts, and worker termination.

A 503 Service Unavailable means that the requested service was not available to handle the request.

There are many possible reasons for a 503, so the status code alone cannot tell us whether the problem is inside the application or inside the hosting platform.

That distinction is important.

A single application's 502 does not automatically mean Render is having an outage.

But if multiple unrelated applications begin returning gateway or availability errors at roughly the same time, the investigation should move beyond a single application's source code.

The Interesting Part: Multiple Backend Services

This is the part that caught my attention.

Suppose I have one Express API running on Render and suddenly receive:

502 Bad Gateway

The first things I would normally check are:

Is the Node.js process running?
Did the application crash?
Is the application listening on 0.0.0.0?
Is it using the correct PORT?
Did the latest deployment fail?
Are database connections failing?
Is the service running out of memory?
Are requests timing out?
Did an environment variable change?

These are normal application-level checks.

But now imagine the following:

Service A → 502
Service B → 503
Service C → 502
Service D → 503
Service E → unavailable

And these services:

belong to different projects,
use different repositories,
have different application logic,
are deployed separately,
and are accessed through different service URLs.

At that point, repeatedly changing application code would not be my first move.

The shared dependency becomes the hosting platform.

Render's Architecture Matters Here

Render web services run as containerized service instances on Render infrastructure.

For public web services, Render's infrastructure receives the incoming HTTP request and forwards it to the service. Render documents that web services must listen on 0.0.0.0 and that the default PORT is 10000.

That means a request to an API is not simply:

Client
  ↓
Node.js application

There is infrastructure between the client and the application.

Conceptually, it looks more like:

Client
   ↓
Internet
   ↓
Render networking / edge
   ↓
Render service
   ↓
Application process
   ↓
Database / external services

If something fails between these layers, the client may see a gateway or availability error even though the application code itself has not changed.

That is why distinguishing application failures from infrastructure failures matters.

But There Is an Important Caveat

A 502 does not automatically mean Render's infrastructure is broken.

Render's own documentation explicitly lists application-side causes for 502 responses.

For example, a service may fail to bind to the correct host or port. Node.js services can also encounter connection resets or timeout problems. Worker processes can terminate unexpectedly.

So the correct conclusion is not:

"I received a 502, therefore Render is down."

That conclusion would be too strong.

A better approach is:

"Multiple independent services are failing at the same time, so a platform-level or shared infrastructure problem should be investigated alongside application-level causes."

That distinction is important for anyone writing about production infrastructure.

Free Services Add Another Variable

Another detail worth mentioning is Render's free web service behavior.

Render documents that free web services spin down after 15 minutes of inactivity and start again when they receive a new incoming request.

Therefore, a slow first request or startup-related behavior should not automatically be interpreted as an infrastructure outage.

However, that explanation becomes less convincing when several unrelated services repeatedly fail rather than simply taking longer to start.

The pattern matters.

How I Would Investigate This

When several backend services fail simultaneously, I would avoid immediately redeploying everything.

Instead, I would compare the services.

1. Check the service logs

Look for:

Application crash
Database connection failure
Out of memory
Worker timeout
SIGTERM
SIGKILL
Connection reset
Port binding failure

If the application is completely healthy in its runtime logs but external requests are failing, that provides useful evidence.

2. Check deployment history

Look at the Render Events page.

Ask:

Did a deployment happen immediately before the failure?
Did several services deploy automatically?
Did builds fail?
Did services restart?
Did the service become unavailable without a deployment?

If nothing changed in the applications, the investigation should move toward the infrastructure layer.

3. Test independent services

This is one of the most useful tests.

For example:

API A → unavailable
API B → unavailable
API C → unavailable

If these APIs are completely independent, compare their behavior.

The more unrelated services that fail at the same time, the stronger the evidence becomes that the problem is not isolated to one application.

4. Check Render's status page

Render maintains a public status page covering components such as:

Dashboard
Platform API
REST API
Web Services
Builds and Deploys
PostgreSQL
Redis
regional infrastructure
Free Tier Web Services

The status page should be checked before making major production changes.

At the time of writing, the status information available to me does not show an officially confirmed active August 20 infrastructure outage.

That is an important distinction from my own observations.

Why Status Pages Don't Always Tell the Whole Story

A status page is useful, but developers should not treat it as the only source of truth.

There can be a period between:

Problem begins
      ↓
Users notice failures
      ↓
Engineering investigates
      ↓
Incident is identified
      ↓
Status page is updated

There can also be partial failures.

For example, one region or one infrastructure component may experience problems while the overall platform remains classified as operational.

Render has previously documented incidents involving specific infrastructure components or regions. Its incident history includes, for example, an Oregon service disruption in July 2026 where Render reported that some services could become unreachable or experience failed requests.

This is why looking at the actual behavior of affected services is still important.

What Developers Should Not Do During a Possible Platform Incident

One common mistake during infrastructure incidents is changing too many things at once.

For example:

Change environment variables
↓
Redeploy
↓
Change database configuration
↓
Change Node.js version
↓
Change dependencies
↓
Restart service

If the actual problem is outside the application, these changes do not solve the underlying issue.

They can also make later debugging harder because the original state has been changed.

When several unrelated services fail simultaneously, preserving evidence is often more useful than immediately modifying everything.

A Simple Mental Model

When debugging a production failure, I like to divide the problem into three layers.

Layer 1: Application

Node.js
Express
FastAPI
Django
Database client
Business logic

Layer 2: Service Runtime

Container
Process
Port
CPU
Memory
Health checks
Instance lifecycle

Layer 3: Platform

Networking
Load balancing
Routing
Regional infrastructure
Platform control plane
Underlying providers

If one application fails, start at Layer 1.

If many independent applications fail at approximately the same time, investigate Layers 2 and 3 as well.

Render Health Checks Are Another Piece of the Puzzle

Render performs health checks on running web services and private services.

According to Render's documentation, these checks are used to identify unresponsive instances and determine whether an instance is ready to receive traffic.

For HTTP health checks, the service needs to respond with a 2xx or 3xx status within the configured health-check requirements.

If an instance repeatedly fails health checks, Render can stop routing traffic to that instance and eventually restart it.

That means a service can become temporarily unavailable because of an application problem, a resource problem, or an infrastructure problem.

Again, the status code alone is not enough.

My Observation From August 20, 2026

The reason I am writing about this incident is not because one API failed.

It is because I observed failures across multiple backend services.

I checked multiple accounts and multiple services hosted on Render, and the affected services were independent backend applications.

The repeated appearance of 502 and 503 responses made the situation look different from a normal application bug.

I cannot independently confirm that Render's entire infrastructure crashed.

I also would not describe every 502 or 503 as proof of a Render outage.

But the pattern was significant enough to warrant checking the hosting platform before assuming that every backend application had suddenly developed an unrelated problem at the same time.

That is the part developers should pay attention to.

What This Means for Production Systems

This is also a useful reminder about hosting dependencies.

A backend may have:

GitHub
   ↓
Render
   ↓
Node.js
   ↓
MongoDB
   ↓
External APIs

Even if your source code is correct, your application still depends on infrastructure outside your repository.

A production system is not only the code you wrote.

It is the complete chain that allows a request to travel from a user to your application and back again.

When one shared dependency fails, multiple otherwise healthy applications can appear broken at the same time.

Final Thoughts

The most useful lesson from today's Render issue is not simply "Render was down."

The more accurate lesson is about failure diagnosis.

When one service fails, investigate the service.

When many independent services fail at the same time, investigate the common infrastructure.

Check application logs.

Check deployment events.

Check regional behavior.

Check the platform status page.

Compare unrelated services.

And most importantly, do not immediately assume that the application code is responsible just because the browser displays a 502 or 503.

At the time of writing, Render's public status page does not show an officially confirmed active August 20 outage, so the observations described in this article should be understood as a developer's field observation rather than a confirmed Render incident.

If Render later publishes an official incident report for this event, that report should be used to establish the actual root cause.

For developers running production APIs, this is a good reminder that monitoring should cover more than application errors.

Your application can be healthy.

Your database can be healthy.

Your latest deployment can be healthy.

And the request can still fail somewhere in the infrastructure between the client and your application.

That is why understanding the entire request path matters.

Abdullah Shayed
Software Developer

Resources

Render Status Page
Official platform status and incident information.
Render Incident History
Previous Render incidents and their resolutions.
Render Troubleshooting Your Deploy
Render's documentation for common 502, 500, and deployment-related failures.
Render Web Services Documentation
Information about Render web services, ports, networking, and request handling.
Render Health Checks
How Render checks service instances and handles unhealthy instances.
Render Service Types
Overview of Render web services, workers, cron jobs, private services, and other service types.

~ (Abdullah Shayed)

Check It

Mr Abdullah — Tue, 18 Aug 2026 15:42:59 +0000

Mr Abdullah

Aug 15

Python Functions, Arguments & Scope: The Details That Start to Matter

#ai #python #devops #programming

20 min read

Python Functions, Arguments & Scope: The Details That Start to Matter

Mr Abdullah — Sat, 15 Aug 2026 07:16:14 +0000

Python's function syntax looks simple until you start writing reusable libraries, decorators, callbacks, configurable utilities, or APIs. Then small choices around arguments, unpacking, scope, and closures start affecting readability and behavior.

This part focuses on the pieces that sit underneath everyday function calls: *args, **kwargs, positional-only and keyword-only parameters, unpacking, LEGB scope, closures, lambda, and the functional tools map(), filter(), and reduce(). These features are closely related rather than isolated tricks.

Part 1 — Functions, Arguments & Scope

1. `*args` and `**kwargs`

What It Is

A Python function normally declares a fixed number of parameters:

def create_user(name, email):
    ...

That is usually the right design. The function tells its caller exactly what information it expects.

Sometimes, however, the number of positional or keyword arguments is not fixed. That's where *args and **kwargs become useful.

*args collects additional positional arguments into a tuple.

**kwargs collects additional keyword arguments into a dictionary.

The important point is that these are not special argument types. They are syntax for packing multiple arguments into a parameter.

def inspect_arguments(*args, **kwargs):
    print(args)
    print(kwargs)

Calling:

inspect_arguments(10, 20, 30, name="Abu", active=True)

produces:

(10, 20, 30)
{'name': 'Abu', 'active': True}

The positional arguments were packed into a tuple, while the keyword arguments were packed into a dictionary.

This becomes particularly useful when writing wrappers, callbacks, decorators, adapters, or functions whose API intentionally accepts an open-ended collection of arguments.

Syntax

def function_name(*args, **kwargs):
    ...

args is simply a conventional name. Python does not require it.

This is equally valid:

def function_name(*values, **options):
    ...

The * tells Python to collect remaining positional arguments.

The ** tells Python to collect remaining keyword arguments.

How It Works

Consider:

def log_values(*args):
    print(args)

When you call:

log_values("error", 404, "/users")

Python effectively packs those positional arguments into:

("error", 404, "/users")

The function receives one local variable named args, and that variable refers to a tuple.

Likewise:

def configure(**kwargs):
    print(kwargs)

Calling:

configure(host="localhost", port=8000, debug=True)

gives:

{
    "host": "localhost",
    "port": 8000,
    "debug": True
}

A useful mental model is:

multiple positional arguments
        ↓
      *args
        ↓
      tuple

multiple keyword arguments
        ↓
    **kwargs
        ↓
     dict

The reverse operation is called unpacking, which becomes important when calling another function.

Real-World Example

Suppose you have a logging utility that adds contextual information to an event:

def log_event(event_name, *messages, **metadata):
    ...

The caller can provide any number of message fragments and arbitrary metadata.

That can be useful for infrastructure utilities, adapters, or generic framework code where the function deliberately does not want to prescribe every possible value.

Handwritten Python Code

from datetime import datetime


def log_event(event_name, *messages, **metadata):
    timestamp = datetime.now().isoformat(timespec="seconds")

    print(f"[{timestamp}] {event_name}")

    for message in messages:
        print(f"  - {message}")

    for key, value in metadata.items():
        print(f"  {key}: {value}")


log_event(
    "user_login",
    "Authentication successful",
    "Session created",
    user_id=42,
    method="password",
    ip_address="192.168.1.10",
)

Output

[2026-08-09T13:00:00] user_login
  - Authentication successful
  - Session created
  user_id: 42
  method: password
  ip_address: 192.168.1.10

The exact timestamp will depend on when the program runs.

Common Mistakes

Mistake 1: Assuming `args` is a list

def process(*args):
    args.append("new")

This fails because args is a tuple.

If you actually need a mutable collection:

def process(*args):
    values = list(args)
    values.append("new")

Mistake 2: Using `*args` when the API has a known shape

This:

def calculate_total(*values):
    ...

may be appropriate for a mathematical aggregation.

But if your function always needs exactly:

price
quantity
tax

then this is clearer:

def calculate_total(price, quantity, tax):
    ...

A flexible function is not automatically a better function.

Mistake 3: Treating `**kwargs` as an excuse to skip API design

This:

def create_user(**kwargs):
    ...

looks flexible, but it also hides the function's contract.

A caller can now pass:

create_user(
    nmae="Abu",
    emial="user@example.com",
)

and the typo may survive until much later.

Explicit parameters provide better readability and often better tooling support.

When to Use It

Use *args when:

the number of positional values is intentionally variable
you're building wrappers or adapters
you're forwarding positional arguments
you're implementing APIs such as aggregation utilities

Use **kwargs when:

optional named settings are genuinely open-ended
you're forwarding keyword arguments
you're writing decorators or framework-level utilities
a function intentionally accepts arbitrary configuration

When NOT to Use It

Avoid *args or **kwargs when the function's expected inputs are known.

Prefer:

def send_email(recipient, subject, body):
    ...

over:

def send_email(**kwargs):
    ...

The second version pushes responsibility for discovering the API onto the caller.

That usually makes code harder to understand and validate.

Developer Notes

*args and **kwargs also matter when forwarding arguments:

def wrapper(*args, **kwargs):
    return target(*args, **kwargs)

Here the first function receives arguments by packing them and then immediately unpacks them when calling target.

This pattern appears frequently in decorators.

Also remember that *args and **kwargs are just conventional names. The syntax is what matters:

def example(*values, **options):
    ...

Short Takeaway

*args collects extra positional arguments into a tuple. **kwargs collects extra keyword arguments into a dictionary.

Use them when variable argument counts are part of the function's actual design. Don't use them merely to make a function look flexible.

2. Positional-Only `/` and Keyword-Only `*` Arguments

What It Is

Python allows a function to control how callers are allowed to pass arguments.

Consider:

def create_user(name, age):
    ...

Both of these calls work:

create_user("Abu", 25)
create_user(name="Abu", age=25)

Sometimes an API should not permit both forms.

Python provides two special markers:

marks the end of positional-only parameters.

marks the beginning of keyword-only parameters.

For example:

def connect(host, port, /, *, timeout=10):
    ...

Here:

host must be positional
port must be positional
timeout must be passed by keyword

So this works:

connect("localhost", 8000, timeout=5)

but this does not:

connect(host="localhost", port=8000, timeout=5)

Syntax

Positional-only:

def function(value, /):
    ...

Keyword-only:

def function(*, value):
    ...

Both together:

def function(first, second, /, third, *, fourth, fifth=None):
    ...

The categories become:

first, second
    ↓
positional-only

third
    ↓
positional or keyword

fourth, fifth
    ↓
keyword-only

How It Works

The / and * markers do not create variables.

They define the calling convention of the function.

Consider:

def resize(width, height, /, *, quality=80):
    ...

This is intentional API design.

The caller writes:

resize(1920, 1080, quality=90)

The dimensions are positional, while quality is explicitly named.

That distinction can make calls easier to read:

resize(1920, 1080, quality=90)

is clearer than:

resize(1920, 1080, 90)

because the name quality tells the reader what 90 represents.

Real-World Example

Suppose you are designing a function for HTTP requests:

def request(method, url, /, *, timeout=10, retries=3):
    ...

The request method and URL form the core identity of the operation.

The optional configuration values are named because their meaning matters at the call site.

Handwritten Python Code

def create_request(method, url, /, *, timeout=10, retries=3):
    return {
        "method": method.upper(),
        "url": url,
        "timeout": timeout,
        "retries": retries,
    }


request = create_request(
    "get",
    "https://example.com/users",
    timeout=5,
    retries=2,
)

print(request)

Output

{'method': 'GET', 'url': 'https://example.com/users', 'timeout': 5, 'retries': 2}

This API prevents ambiguous calls such as:

create_request("get", "https://example.com/users", 5, 2)

The configuration must be named.

Common Mistakes

Mistake 1: Forgetting what `/` means

def add(a, b, /):
    return a + b

This is invalid:

add(a=10, b=20)

because both parameters are positional-only.

Mistake 2: Assuming `*` means variable arguments

Compare:

def example(*args):
    ...

with:

def example(*, timeout):
    ...

They have completely different meanings.

The first collects positional arguments.

The second makes following parameters keyword-only.

Mistake 3: Making everything keyword-only

You can technically write:

def process(*, name, email, age, country, phone):
    ...

but that does not automatically make the API better.

For some APIs, positional arguments are natural and readable. Restrictions should have a reason.

When to Use It

Use positional-only parameters when:

parameter names are implementation details
you want freedom to rename parameters later
positional calling is the natural API
you're designing a library with a carefully controlled public interface

Use keyword-only parameters when:

an argument is optional configuration
the value's meaning is not obvious from the value alone
you want calls to be self-documenting
several optional arguments could otherwise be confused

When NOT to Use It

Don't add / and * just because advanced Python allows it.

For small internal functions, ordinary parameters are often sufficient:

def calculate_area(width, height):
    return width * height

API restrictions are most useful when they communicate a real design decision.

Developer Notes

These markers become especially valuable in libraries.

If callers are allowed to use:

process(data, timeout=5)

you can later rename data internally without necessarily breaking callers who never depended on its keyword name.

Likewise, keyword-only arguments can prevent accidental argument swaps:

send_email(
    recipient,
    subject,
    body,
    cc="manager@example.com",
    urgent=True,
)

The named configuration is much easier to review.

Short Takeaway

/ controls positional-only parameters. * controls keyword-only parameters.

They are not syntax tricks. They are tools for designing a function's public calling convention.

3. Unpacking

What It Is

Unpacking is the opposite side of argument packing.

Python lets you take values from an iterable or mapping and distribute them into variables or function arguments.

For example:

numbers = [10, 20, 30]

first, second, third = numbers

The iterable is unpacked into three variables.

The same idea works when calling functions:

values = [10, 20, 30]

print(*values)

Here *values means:

Take the elements inside values and pass them as separate positional arguments.

For dictionaries:

options = {
    "sep": "-",
    "end": "!\n",
}

print("Python", "rocks", **options)

**options passes dictionary entries as keyword arguments.

Syntax

Sequence unpacking:

first, second = values

Positional argument unpacking:

function(*values)

Keyword argument unpacking:

function(**mapping)

Extended unpacking:

first, *middle, last = values

How It Works

Consider:

def calculate_total(price, quantity, tax):
    return price * quantity * (1 + tax)


values = [100, 2, 0.10]

calculate_total(*values)

The call behaves as though you had written:

calculate_total(100, 2, 0.10)

The * does not change the function's parameters. It changes how the caller supplies the values.

For dictionaries:

def connect(host, port, timeout):
    ...


config = {
    "host": "localhost",
    "port": 8000,
    "timeout": 5,
}

connect(**config)

This is equivalent to:

connect(
    host="localhost",
    port=8000,
    timeout=5,
)

Real-World Example

Configuration-driven applications often have a dictionary containing options:

database_config = {
    "host": "localhost",
    "port": 5432,
    "timeout": 10,
}

A function can receive those settings without manually repeating every key:

connect_database(**database_config)

That is useful when the dictionary and function signature intentionally have matching keys.

Handwritten Python Code

def create_connection(host, port, *, timeout=10, ssl=True):
    return {
        "host": host,
        "port": port,
        "timeout": timeout,
        "ssl": ssl,
    }


connection_config = {
    "host": "db.internal",
    "port": 5432,
    "timeout": 5,
    "ssl": True,
}

connection = create_connection(**connection_config)

print(connection)

Output

{'host': 'db.internal', 'port': 5432, 'timeout': 5, 'ssl': True}

You can also unpack while constructing collections:

default_headers = {
    "Accept": "application/json",
}

auth_headers = {
    "Authorization": "Bearer token",
}

headers = {
    **default_headers,
    **auth_headers,
}

Common Mistakes

Mistake 1: Using `*` with a non-iterable

number = 10

print(*number)

This raises:

TypeError

because an integer is not iterable.

Mistake 2: Passing unexpected dictionary keys

def connect(host, port):
    ...


config = {
    "host": "localhost",
    "port": 8000,
    "debug": True,
}

connect(**config)

This fails because connect() does not accept debug.

Unpacking does not magically adapt an incompatible mapping to a function signature.

Mistake 3: Confusing unpacking with copying

result = [*values]

does create a new list containing the elements, but:

function(*values)

is about supplying function arguments.

The same syntax has different consequences depending on context.

When to Use It

Unpacking is useful for:

forwarding arguments
passing configuration dictionaries
combining collections
assigning multiple values
handling structured return values
writing wrappers and adapters

When NOT to Use It

Avoid excessive unpacking when it hides where values are coming from.

This:

process(*get_values())

can be less readable than:

values = get_values()
process(values[0], values[1], values[2])

if the argument meanings matter and are not obvious.

Shorter syntax is not automatically clearer syntax.

Developer Notes

Extended unpacking is especially useful:

first, *remaining = values

For example:

command, *arguments = ["git", "commit", "-m", "message"]

produces:

command = "git"
arguments = ["commit", "-m", "message"]

The starred target receives the remaining values as a list.

This is useful when parsing command structures, processing records, or separating a first element from the rest.

Short Takeaway

Unpacking lets you distribute values from collections into variables or function arguments.

* handles positional unpacking, while ** handles keyword unpacking. The feature is particularly useful when passing structured configuration or forwarding arguments.

4. Scope and LEGB

What It Is

Scope determines where a name can be found.

Consider:

name = "global"


def greet():
    name = "local"
    print(name)


greet()

The function prints:

local

The reason is not that Python randomly prefers one variable over another. Python follows a defined name-resolution process commonly described as LEGB:

L → Local
E → Enclosing
G → Global
B → Built-in

When Python evaluates a name, it searches these namespaces in that order.

Understanding LEGB becomes essential once you work with nested functions, closures, decorators, comprehensions, modules, and callbacks.

Syntax

There is no special LEGB syntax.

The important constructs are:

global variable_name

and:

nonlocal variable_name

These change how assignments to names are interpreted.

How It Works

Consider:

message = "global"


def outer():
    message = "enclosing"

    def inner():
        message = "local"
        print(message)

    inner()


outer()

The result is:

local

Inside inner(), Python finds message immediately in the local namespace.

Remove the local variable:

message = "global"


def outer():
    message = "enclosing"

    def inner():
        print(message)

    inner()


outer()

Now Python searches:

Local namespace of inner
Enclosing namespace of outer
Global namespace
Built-ins

It finds "enclosing".

If outer() did not define message, Python would continue to the module's global namespace.

If the global variable did not exist either, Python would finally search built-ins.

For example:

def example():
    print(len([1, 2, 3]))

len is not local or enclosing or global. Python finds it in the built-in namespace.

`global`

Consider:

counter = 0


def increment():
    counter += 1

This raises an error.

Why?

Because assignment makes counter local to increment() unless told otherwise.

Python treats:

counter += 1

as an operation involving assignment.

If you genuinely want to modify the module-level variable:

counter = 0


def increment():
    global counter
    counter += 1

Now Python knows that counter refers to the global name.

`nonlocal`

nonlocal is different.

It refers to a variable in an enclosing function scope.

def create_counter():
    count = 0

    def increment():
        nonlocal count
        count += 1
        return count

    return increment

Here count belongs to create_counter(), not the module.

The inner function can modify that enclosing variable because of nonlocal.

Real-World Example

A useful application is a small stateful callback:

def create_request_counter():
    count = 0

    def record_request():
        nonlocal count
        count += 1
        return count

    return record_request

The returned function remembers the state.

Handwritten Python Code

def create_request_counter():
    count = 0

    def record_request():
        nonlocal count
        count += 1
        return count

    return record_request


counter = create_request_counter()

print(counter())
print(counter())
print(counter())

Output

1
2
3

The variable count remains alive because the nested function retains access to its enclosing scope.

That leads directly to closures.

Common Mistakes

Mistake 1: Expecting assignment to modify an outer variable

def outer():
    value = 10

    def inner():
        value = 20

    inner()
    print(value)

Output:

The assignment created a new local value inside inner().

It did not modify the enclosing variable.

Mistake 2: Using `global` as a general state-management solution

Global mutable state can make dependencies difficult to track.

This:

global cache

may solve an immediate problem while creating a larger maintenance problem.

Mistake 3: Forgetting that built-ins are names too

You can accidentally shadow built-ins:

list = [1, 2, 3]

Now:

list("abc")

does not call the built-in list() function.

The global name list is found first.

When to Use It

Understanding LEGB is useful whenever you work with:

nested functions
callbacks
closures
decorators
modules
configuration
comprehensions
variable shadowing

nonlocal can be appropriate for tightly encapsulated state inside a closure.

global has legitimate uses, but it should usually be a deliberate design decision rather than the default way to share state.

When NOT to Use It

Avoid relying on deeply nested scope chains to make code work.

If a function depends on five names from surrounding scopes, understanding the function may require reading several layers of code.

Often, explicit parameters are clearer:

def calculate_total(price, tax):
    return price * (1 + tax)

rather than relying on:

tax = 0.10

from some distant outer scope.

Developer Notes

A subtle but important point: scope and lifetime are related but not identical concepts.

A local variable normally disappears from direct access after its function returns. But an object referenced by a closure can remain reachable because another function still holds a reference to it.

That is why this works:

counter = create_request_counter()

even though create_request_counter() has already returned.

The nested function keeps access to its enclosing environment.

Short Takeaway

LEGB describes Python's name lookup order: Local, Enclosing, Global, Built-in.

Most scope bugs become much easier to diagnose once you stop thinking of variables as floating around globally and start thinking in terms of namespaces and name resolution.

5. Closures

What It Is

A closure occurs when a nested function retains access to variables from its enclosing scope after the enclosing function has returned.

For example:

def make_multiplier(factor):
    def multiply(number):
        return number * factor

    return multiply

The returned function still knows what factor was.

double = make_multiplier(2)

print(double(10))

Output:

make_multiplier() has already finished executing, but multiply() still has access to factor.

That retained environment is the important part of a closure.

Syntax

There is no special closure keyword.

The basic pattern is:

def outer(value):
    def inner():
        return value

    return inner

The inner function references a variable from the enclosing function.

How It Works

Consider:

def make_prefix(prefix):
    def add_prefix(text):
        return prefix + text

    return add_prefix

When:

add_log_prefix = make_prefix("[LOG] ")

print(add_log_prefix("Server started"))

is executed, the inner function needs prefix.

Python therefore retains the necessary enclosing state so the function can access it later.

Conceptually:

make_prefix("[LOG] ")
        │
        ├── prefix = "[LOG] "
        │
        └── returns add_prefix
                    │
                    └── remembers prefix

This is one of the mechanisms behind many decorators and factory functions.

Real-World Example

Suppose you need validators with different limits.

Instead of duplicating functions:

def validate_short_name(name):
    return len(name) <= 20


def validate_long_name(name):
    return len(name) <= 100

you can create a validator factory:

def create_length_validator(max_length):
    def validate(value):
        return len(value) <= max_length

    return validate

Now:

validate_username = create_length_validator(20)
validate_description = create_length_validator(500)

Each returned function remembers its own limit.

Handwritten Python Code

def create_length_validator(max_length):
    def validate(value):
        if not isinstance(value, str):
            return False

        return len(value) <= max_length

    return validate


validate_username = create_length_validator(20)
validate_title = create_length_validator(80)

print(validate_username("developer"))
print(validate_username("a" * 25))
print(validate_title("Python Functions"))

Output

True
False
True

Common Mistakes

Mistake 1: Confusing a closure with simply nesting a function

Nesting alone is not enough.

The inner function must retain and use information from its enclosing scope.

Mistake 2: Forgetting `nonlocal` when modifying captured state

This does not modify the outer variable:

def create_counter():
    count = 0

    def increment():
        count += 1
        return count

    return increment

Use:

def create_counter():
    count = 0

    def increment():
        nonlocal count
        count += 1
        return count

    return increment

Mistake 3: Creating closures inside loops without understanding late binding

Consider:

functions = []

for number in range(3):
    functions.append(lambda: number)

print([function() for function in functions])

The result is:

[2, 2, 2]

The lambdas don't capture three independent snapshots of number. They refer to the same loop variable, whose final value is 2.

One common solution is to bind the current value as a default argument:

functions = []

for number in range(3):
    functions.append(lambda number=number: number)

Now:

[0, 1, 2]

This distinction matters when creating callbacks dynamically.

When to Use It

Closures are useful for:

function factories
encapsulated state
decorators
callbacks
configurable behavior
small stateful utilities

When NOT to Use It

Don't create a closure when a simple class would make the state and behavior easier to understand.

For example, if an object needs ten pieces of mutable state and several methods, a class is generally clearer than a deeply nested closure.

Closures work particularly well for small, focused pieces of state.

Developer Notes

Closures are closely connected to decorators.

A decorator often looks like:

def decorator(function):
    def wrapper(*args, **kwargs):
        ...
        return function(*args, **kwargs)

    return wrapper

wrapper retains access to function.

That is a closure.

So understanding closures makes decorators much less mysterious.

Short Takeaway

A closure is a function that retains access to variables from its enclosing scope.

It is useful for creating small, configurable functions and encapsulating state without introducing a full class.

6. `lambda`

What It Is

A lambda creates a small anonymous function expression.

For example:

square = lambda number: number * number

is roughly equivalent to:

def square(number):
    return number * number

The major difference is that a lambda is an expression, while def creates a named function using a statement.

Lambdas are most useful when a small function is needed temporarily, especially as an argument to another function.

Syntax

lambda parameter: expression

Multiple parameters are allowed:

lambda x, y: x + y

The result of the expression becomes the return value.

You cannot write ordinary statements such as:

lambda x:
    print(x)
    return x

A lambda is intentionally limited to a single expression.

How It Works

Consider sorting records by a specific field:

users = [
    {"name": "Mina", "age": 31},
    {"name": "Abu", "age": 24},
    {"name": "Rafi", "age": 28},
]

users.sort(key=lambda user: user["age"])

The lambda receives each user and returns the value used for sorting.

There is no reason to create a separate globally named function if the behavior is only needed at that point.

Real-World Example

Sorting API results by response time is a realistic example:

responses = [
    {"endpoint": "/users", "duration": 320},
    {"endpoint": "/orders", "duration": 120},
    {"endpoint": "/products", "duration": 210},
]

You can sort them directly:

responses.sort(key=lambda response: response["duration"])

The lambda expresses the sorting key right where it is used.

Handwritten Python Code

users = [
    {"name": "Mina", "age": 31},
    {"name": "Abu", "age": 24},
    {"name": "Rafi", "age": 28},
]

users.sort(key=lambda user: user["age"])

for user in users:
    print(user["name"], user["age"])

Output

Abu 24
Rafi 28
Mina 31

Common Mistakes

Mistake 1: Writing complicated lambdas

This:

process = lambda user: (
    user["active"]
    and user["role"] in {"admin", "editor"}
    and user["age"] >= 18
)

may technically work, but if the logic needs explanation, a named function is usually clearer:

def can_edit(user):
    return (
        user["active"]
        and user["role"] in {"admin", "editor"}
        and user["age"] >= 18
    )

Mistake 2: Using lambda just because it is shorter

Short code is not necessarily better code.

If naming the operation makes the code easier to understand, use def.

Mistake 3: Expecting multiple statements

A lambda cannot contain ordinary statements such as for, try, or return.

It is intended for small expressions.

When to Use It

Lambdas are useful for:

sorting keys
small callbacks
simple transformations
short predicates
APIs that expect a callable

When NOT to Use It

Use def when:

the function has meaningful business logic
the expression is difficult to read
you need multiple statements
the function deserves a descriptive name
you need documentation or type annotations that would be clearer on a named function

For example:

users.sort(key=lambda user: user["created_at"])

is fine.

But:

users.sort(key=lambda user: calculate_complex_business_rule(user))

may indicate that the logic belongs in a named function.

Developer Notes

A lambda is still a normal Python function object.

For example:

operation = lambda x: x * 2

print(operation(5))
print(type(operation))

The output includes:

10
<class 'function'>

The important distinction is mostly about syntax, naming, and how the function is used.

Short Takeaway

Use lambda for small, local expressions where a named function would add unnecessary ceremony.

Once the logic becomes difficult to understand at a glance, give it a name with def.

7. `map()`, `filter()`, and `reduce()`

What It Is

map(), filter(), and reduce() are functional programming tools that operate on sequences or other iterables.

Their basic ideas are:

map()
    transform each item

filter()
    keep items that satisfy a condition

reduce()
    combine multiple items into one result

They are related, but they solve different problems.

A common beginner mistake is to use all three simply because they are available.

Python often has a clearer alternative in comprehensions or ordinary loops.

The important skill is choosing the clearest expression of the operation.

`map()`

map() applies a function to every item in an iterable.

map(function, iterable)

For example:

numbers = [1, 2, 3, 4]

result = map(lambda number: number * 2, numbers)

In modern Python, map() returns an iterator rather than a list.

To materialize the values:

list(result)

`filter()`

filter() keeps items for which a predicate returns a truthy value.

filter(function, iterable)

Example:

numbers = [1, 2, 3, 4, 5]

result = filter(lambda number: number % 2 == 0, numbers)

Again, filter() returns an iterator.

`reduce()`

reduce() repeatedly combines items and eventually produces one value.

It lives in functools:

from functools import reduce

For example:

numbers = [1, 2, 3, 4]

total = reduce(lambda left, right: left + right, numbers)

The operation proceeds conceptually as:

1 + 2 → 3
3 + 3 → 6
6 + 4 → 10

The final result is:

How It Works

Consider:

numbers = [10, 20, 30]

doubled = map(lambda value: value * 2, numbers)

The map object does not immediately contain a new list.

It produces values as iteration requests them.

That means:

for value in doubled:
    print(value)

will retrieve the mapped values during iteration.

This lazy behavior can be useful when processing large streams of data because you don't necessarily need to construct an intermediate list.

`map()` vs Comprehension

These are both valid:

result = list(map(lambda x: x * 2, numbers))

and:

result = [x * 2 for x in numbers]

The comprehension is often easier to read because the transformation is directly visible.

Compare:

list(map(lambda user: user["email"], users))

with:

[user["email"] for user in users]

The second version is often the more idiomatic Python expression.

`filter()` vs Comprehension

Likewise:

active_users = list(
    filter(lambda user: user["active"], users)
)

can often be written more clearly as:

active_users = [
    user for user in users
    if user["active"]
]

The choice should be based on readability rather than blindly following one style.

Real-World Example

Suppose an API returns transaction records:

transactions = [
    {"amount": 120, "status": "completed"},
    {"amount": 50, "status": "failed"},
    {"amount": 200, "status": "completed"},
]

You might want to:

keep completed transactions
extract their amounts
calculate the total

This creates a natural relationship between filtering, mapping, and reduction.

Handwritten Python Code

from functools import reduce


transactions = [
    {"amount": 120, "status": "completed"},
    {"amount": 50, "status": "failed"},
    {"amount": 200, "status": "completed"},
]

completed = filter(
    lambda transaction: transaction["status"] == "completed",
    transactions,
)

amounts = map(
    lambda transaction: transaction["amount"],
    completed,
)

total = reduce(
    lambda left, right: left + right,
    amounts,
    0,
)

print(f"Completed transaction total: {total}")

Output

Completed transaction total: 320

Notice that the operations are lazy until the values are consumed by reduce().

A More Pythonic Alternative

The same task can often be expressed more directly:

transactions = [
    {"amount": 120, "status": "completed"},
    {"amount": 50, "status": "failed"},
    {"amount": 200, "status": "completed"},
]

total = sum(
    transaction["amount"]
    for transaction in transactions
    if transaction["status"] == "completed"
)

print(f"Completed transaction total: {total}")

Output:

Completed transaction total: 320

For this particular problem, sum() plus a generator expression communicates the intent more directly than filter() → map() → reduce().

That is an important Python lesson: having a functional tool available does not mean it is the best tool for every functional-looking problem.

Common Mistakes

Mistake 1: Assuming `map()` returns a list

result = map(lambda x: x * 2, [1, 2, 3])

print(result)

You get a map object representation, not:

[2, 4, 6]

If you need a list:

result = list(map(lambda x: x * 2, [1, 2, 3]))

Mistake 2: Consuming an iterator twice

values = map(lambda x: x * 2, [1, 2, 3])

print(list(values))
print(list(values))

The second result is empty because the iterator has already been exhausted.

Output:

[2, 4, 6]
[]

If the values need to be traversed repeatedly, materialize them into a collection.

Mistake 3: Using `reduce()` when a named built-in expresses the operation

For a total:

reduce(lambda a, b: a + b, numbers, 0)

is usually less clear than:

sum(numbers)

Likewise, don't reach for reduce() when max(), min(), sum(), or another specialized operation already expresses the intent.

Mistake 4: Building unreadable functional pipelines

This:

list(
    map(
        lambda x: transform(x),
        filter(
            lambda x: condition(x),
            values,
        ),
    )
)

may be correct but difficult to maintain.

A comprehension or explicit loop may communicate the same logic better.

When to Use `map()`

map() can make sense when:

you already have a named transformation function
you want lazy transformation
multiple iterables need to be processed together
the functional form reads naturally

For example:

emails = map(normalize_email, raw_emails)

can be perfectly readable.

When to Use `filter()`

filter() can be appropriate when:

you already have a named predicate
lazy filtering is useful
the operation reads naturally in functional form

For simple conditions, comprehensions are often clearer:

active = [user for user in users if user["active"]]

When to Use `reduce()`

Use reduce() when the operation genuinely represents repeated pairwise combination and there isn't a clearer specialized function.

Examples can include certain aggregation or functional pipelines where the reduction operation is naturally expressed as a binary function.

But don't use it merely because you can.

When NOT to Use Them

Avoid functional constructs when they make straightforward Python harder to read.

Compare:

result = list(
    map(lambda x: x * 2, numbers)
)

with:

result = [x * 2 for x in numbers]

The comprehension is usually easier for a Python developer to scan.

Likewise, use:

sum(values)

instead of:

reduce(lambda a, b: a + b, values, 0)

when summation is all you need.

Developer Notes

There is an important connection between these tools and Python's iterator model.

map() and filter() are lazy iterators.

That means they can process values without immediately creating a complete output list.

For example:

large_dataset = get_large_dataset()

processed = map(normalize_record, large_dataset)

If get_large_dataset() itself produces values incrementally, this can form a pipeline where records are processed one at a time.

That can reduce unnecessary intermediate storage.

But laziness is not automatically a performance win. If you immediately write:

list(map(normalize_record, large_dataset))

you have deliberately materialized the result into memory.

The real advantage depends on how the resulting iterator is consumed.

Short Takeaway

map() transforms values, filter() selects values, and reduce() combines values into one result.

They are useful tools, but Python's comprehensions, generator expressions, sum(), any(), all(), and other built-ins often express the same intent more clearly. Good Python is not about using the most sophisticated-looking construct; it is about choosing the clearest one.

Part 1 — Connecting the Concepts

These features become much easier to understand when viewed as one system.

Function arguments can move through several stages:

function parameters
       ↓
positional / keyword arguments
       ↓
*args / **kwargs
       ↓
unpacking
       ↓
forwarding to another function

Scope provides the environment in which those functions resolve names:

Local
  ↓
Enclosing
  ↓
Global
  ↓
Built-in

Closures combine functions with that enclosing scope:

outer()
  │
  ├── local state
  │
  └── inner function
          ↓
     retains access
     to enclosing state

Then lambda, map(), filter(), and reduce() provide different ways to treat functions as values and compose operations around iterables.

A practical progression looks like this:

functions
   ↓
arguments
   ↓
*args / **kwargs
   ↓
unpacking
   ↓
scope
   ↓
closures
   ↓
lambda
   ↓
map / filter / reduce

The important shift is that these features stop being isolated pieces of syntax. They become tools for controlling data flow, function behavior, and state.

When you understand why a function receives its arguments the way it does, where Python looks for a name, why a nested function can remember a value, and when a functional pipeline is clearer than a loop, you're no longer just memorizing Python syntax. You're starting to reason about Python code the way you would when reviewing or designing it.

TypeScript Just Got Rewritten in Go — And Your 7-Minute Build Is About to Take 45 Seconds

Mr Abdullah — Fri, 10 Jul 2026 06:52:57 +0000

TypeScript Just Freaked Up

Why TypeScript 7.0 is the biggest infrastructure change in the language's history, even though it doesn't add a single new keyword.

If you've spent the last few years watching your tsc --noEmit spinner while your coffee goes cold, TypeScript 7.0 is the release you've been waiting for without knowing it. Released on July 8, 2026, it isn't a feature update. It's a foundation swap the entire compiler and language server, ported from a self-hosted TypeScript codebase into native Go.

That distinction matters more than it sounds. TypeScript has always compiled itself: the tool that type-checks your code was written in the same language it checks. That self-hosting was elegant, but it also capped how fast the compiler could ever be, because JavaScript engines were never built for the kind of CPU-bound, single-threaded grinding a large-scale type-checker demands. TypeScript 7.0 breaks that ceiling by leaving JavaScript entirely for the compiler's internals, while your code, your .ts files, and your day-to-day workflow stay exactly the same.

The headline number is 8x to 12x faster full builds, achieved through native code execution and, for the first time, real shared-memory multithreading something the old architecture simply couldn't do. But the more interesting story is in the details: how the team pulled off a rewrite of this scale without breaking a decade of existing type-checking behavior, and what it took to get some of the biggest engineering orgs in the industry to trust it in production before the ink was even dry.

This wasn't a rewrite from a blank page, either. The Go codebase was ported line-by-line in structure and logic from the existing implementation, not reimagined from scratch which is precisely why teams with multi-million-line codebases could adopt early betas without their type-checking suddenly behaving differently. The team spent over a year validating this parity against a test suite built up across ten years of the language's evolution, plus pre-release testing inside real production codebases at Bloomberg, Canva, Figma, Google, Notion, Slack, Vercel, and Microsoft itself.

The tradeoff, at least for now: TypeScript 7.0 ships without a programmatic API. If your tooling reaches into the compiler directly think typescript-eslint or custom build plugins you'll need to keep TypeScript 6.0 installed alongside 7.0 for a while. The team built a compatibility package specifically to make that coexistence painless, which tells you they were thinking about ecosystem disruption as seriously as they were thinking about raw speed.

What's Releases New

A native Go compiler with the same semantics. The type-checking logic is structurally identical to 6.0 same rules, same edge cases, same errors just running as compiled native code instead of JavaScript on Node.

Shared-memory multithreading. This is the real unlock. TypeScript 7.0 spins up multiple type-checker workers that split your codebase and check it in parallel, using a new --checkers flag to control how many. Default is 4 workers; on a beefier CI machine, bumping it to 8 squeezes out even more speed, at the cost of more memory.

A dramatically more stable language server. Anyone who's had VS Code's TS server hang or crash on a large monorepo will care about this one: failing language server commands dropped by over 80%, and crashes dropped by over 60%, compared to TypeScript 6.0.

A side-by-side compatibility path. The new @typescript/typescript6 package ships a tsc6 binary and re-exports the old API, so tools that still need programmatic access to TypeScript 6.0 aren't left stranded while the ecosystem catches up.

LSP-native editor tooling. The TypeScript Native Preview extension runs on the Language Server Protocol, meaning the same performance gains show up not just in VS Code but in any LSP-compatible editor and even in tools like Copilot CLI.

Developers Opinion

The reaction has been loud, and mostly celebratory, but not without some sharp technical debate.

The performance numbers aren't just marketing copy they're showing up in production. Slack's engineering team reported that TypeScript 7 cut their CI type-checking time from roughly 7.5 minutes down to 1.25 minutes, and eliminated 40% of their merge queue wait time. Their local development experience had reportedly degraded to "almost unusable" under TypeScript 6 at their codebase's scale, forcing engineers to lean on CI instead of their own editor TypeScript 7 apparently made local type-checking viable again.

On community threads, the more technical debate isn't about speed nobody's arguing with 10x it's about the philosophical shift of moving away from self-hosting. One frequently echoed point: self-hosted compilers put evolutionary pressure on a language to become good at writing compilers, which isn't necessarily the same as being good at being used. Others pointed to Rust-based tooling rewrites elsewhere in the JS ecosystem (Astral's ruff and uv being the most cited comparison) as evidence that this migration pattern dropping the source language for something faster at systems-level work is becoming a broader trend, not a one-off.

There's also a practical thread worth flagging for teams mid-migration: editor integrations that still reference the old preview binary name (tsgo) need a small amount of manual reconciliation if you're running package managers like mise alongside project-local TypeScript installs. Minor, but worth knowing before you flip the switch on a team-wide upgrade.

New releases Matters for Developers

CI pipelines that currently gate merges on type-checking will see the most dramatic wins this is where Slack's 6x improvement came from.
Large monorepos where the language server used to choke get real local type-checking back, instead of developers disabling it and hoping CI catches problems.
Teams on CPU-heavy build servers can tune --checkers upward to trade memory for even more speed, which matters for larger CI runners.
Editor experience improves for everyone, immediately, just by installing the extension no code changes required, since semantics haven't shifted.
Anything depending on the compiler API (linters, codegen tools, custom build steps) should hold off on a hard cutover until 7.1 ships the new API, and lean on the 6.0 compatibility package in the meantime.

Feature Impact at a Glance

Conclusion: And My Take, After 5+ Years Building Production TypeScript

I've lost real hours of my life to a spinning TS server on a large Next.js monorepo, watching a laptop fan spin up just to tell me I forgot a semicolon three files deep. So I'll say this plainly: this is the release that finally treats build performance as a first-class product concern, not an afterthought fixed by "just add more skipLibCheck."

What I respect most isn't the 10x number vendors throw around big multipliers all the time. It's that the team chose fidelity over reinvention. A rewrite that changed type-checking behavior even slightly would have been a nightmare for every team with a decade of accumulated // @ts-ignore compromises. Porting the logic, not just the language, is the harder and more disciplined engineering choice, and it's the reason companies with multi-million-line codebases could trust it in production before most of us even heard about it.

The missing API is the one real friction point right now. If your team leans on typescript-eslint or custom compiler plugins, budget a little time for the 6.0/7.0 coexistence dance rather than assuming a clean drop-in upgrade it isn't one, yet. That said, for the vast majority of teams just running tsc in CI and using the language server in the editor, this is close to a free upgrade: same code, same errors, dramatically less waiting.

My honest recommendation: install the Native Preview extension today, let your team feel the editor speed difference for a week, then schedule the CI migration once you've confirmed your critical tooling has a 7.0-compatible path. The wait for a fast, stable TypeScript compiler is over the only real decision left is how quickly your team gets out of the queue.

Source: Popular sources covering TypeScript 7.0

Microsoft DevBlogs (official) https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
Thurrott.com https://www.thurrott.com/dev/338669/typescript-7-0-is-here
InfoWorld https://www.infoworld.com/article/4194567/revving-up-microsofts-10x-faster-typescript-7.html
Visual Studio Magazine https://visualstudiomagazine.com/articles/2026/07/08/typescript-7-arrives-to-rock-vs-code-with-go-powered-speed.aspx
Analytics India Magazine https://analyticsindiamag.com/ai-news/microsofts-new-typescript-7-promises-812x-faster-builds-with-native-go-compiler
Lobsters (community discussion) https://lobste.rs/s/txmyod/announcing_typescript_7_0
daily.dev https://daily.dev/posts/announcing-typescript-7-0-leoc6kxvq
X / Twitter (official TypeScript account) https://x.com/typescript/status/2074892178745327926

Connect With me

🚀 What's New in Next.js 15? (A Smooth Developer Experience Ahead!)

Mr Abdullah — Sun, 13 Jul 2025 17:24:31 +0000

Hey Devs! Big news — Next.js 15 is finally here, and it's bringing a wave of powerful improvements to modern web development. Whether you’re building sleek SPAs or robust server-rendered apps, this release is packed with developer-first features. From enhanced routing and React 19 support to a more stable app directory and flexible data fetching — Next.js 15 continues to push the edge of performance and DX (developer experience). Let's break it down.

🧠 What’s Good in Next.js 15?
Let’s explore the most important updates in a smooth and understandable way — with clear examples.

1. ⚛️ Full Support for React 19 (with Actions!)
One of the most exciting updates in Next.js 15 is official support for React 19, including React Actions, which simplify form handling, server actions, and more.

✅ Example: Server Action (React 19 style)
1)

// app/actions.js
'use server'

export async function submitData(formData) {
  const name = formData.get("name");
  // Save to DB or process
  console.log("User name is:", name);
}

// app/page.js
<form action={submitData}>
  <input type="text" name="name" />
  <button type="submit">Send</button>
</form>

Why it’s cool:

No need for API route boilerplate.
Works natively with serverless architecture.

2. 🧭 Enhanced Routing with Stable App Router
The App Router is now stable and the default going forward! This makes it easier to use layouts, nested routing, loading UI, error boundaries, and more.

✅ Example: Nested Layouts
1)

app/
├─ layout.js
├─ page.js
├─ dashboard/
│  ├─ layout.js
│  ├─ page.js

// app/layout.js
export default function RootLayout({ children }) {
  return (
    <html>
      <body>{children}</body>
    </html>
  );
}

// app/dashboard/page.js
export default function DashboardPage() {
  return <h2>Welcome to Dashboard</h2>;
}

Why it’s cool:

Build complex UIs with ease.
Shared layouts reduce re-renders.
More control over UX/UI structure.

3. 🛠️ New next/after for Client-Side Effects
Next.js 15 introduces next/after — a new lifecycle hook that ensures effects run only after paint, improving interactivity timing and user-perceived performance.

'use client';
import { afterPaint } from 'next/after';

afterPaint(() => {
  console.log('App fully painted!');
});

Why it’s cool:

Useful for analytics, tracking, or animations.
Makes hydration smoother and less janky.

4. 🌍 Middleware Enhancements with cookies().set()
Now you can mutate cookies directly inside middleware — perfect for A/B testing, localization, authentication, etc.

// middleware.js
import { cookies } from 'next/headers';

export function middleware(request) {
  cookies().set('user-location', 'USA', { path: '/' });
  return NextResponse.next();
}

Why it’s cool:

Dynamic control over session data.
Easier redirect logic based on cookies.

5. 🧪 Turbopack Progress + Performance Boost
While still marked as experimental, Turbopack is getting closer to replacing Webpack — promising faster local dev, hot reloads, and smaller builds.

 # Enable Turbopack
 next dev --turbo

Why it’s cool:

Built in Rust = lightning fast.
Designed to scale with large apps.

6. 🐞 Better Error Overlays and Logs
Next.js 15 improves the developer experience with clearer error overlays, better stack traces, and React Server Component error reporting.

Why it’s cool:

Faster debugging.
Cleaner error boundaries.
Enhanced DevTools support.

7. 🔍 Metadata Improvements for SEO
Next.js 15 makes metadata handling even cleaner and dynamic — especially great for programmatically updating SEO tags.

export const metadata = {
  title: 'My Page',
  description: 'This is a cool page!',
};

export async function generateMetadata({ params }) {
  const data = await getData(params.id);
  return {
    title: data.name,
    description: data.summary,
  };
}

🎁 Final Thoughts — Why Upgrade to Next.js 15?

If you're already using Next.js 13 or 14, upgrading to v15 is mostly smooth. It aligns with React 19, gives you stable App Router power, improved dev speed, and lets you use cutting-edge features like React Actions and Turbopack. It's not just a framework update — it's a performance + productivity boost.

🧩 TL;DR — What’s New in Next.js 15?

✅ React 19 Support — Full support for Actions and new APIs

🚀 App Router — Stable with better nested layouts

🔄 afterPaint() — Post-render client-side hook

🍪 Cookie Mutations in Middleware — Great for auth/localization

⚡ Turbopack (Faster Builds) — Dev mode speed improvement

🐞 Dev UX — Better error overlays & logs

🔍 SEO Metadata — Cleaner, dynamic page-level metadata

Feel free to share this with your dev team or drop a ⭐️ on the Next.js GitHub repo if you're hyped about these features!

Let’s build better, faster, and smarter with Next.js 15.

**
📚 References**
For all updates, docs, and release notes, check out the official resources:

📄 Next.js Documentation

🧪 React 19 (RC) Features

🧵 Next.js GitHub Repository

🧰 App Router Docs

🔬 Turbopack (Experimental)

How does work React Awesomework Next.Js ?

Mr Abdullah — Fri, 16 May 2025 17:46:27 +0000

As a Developer why you must learn NEXT.JS ?

In the fast-evolving world of web development, frameworks and libraries come and go, but some stand out by offering a combination of power, flexibility, and simplicity. Next.js is one such framework. Built on top of React, it enables developers to create highly performant and scalable web applications with ease. In this article, we'll dive into the basics of Next.js and its key features, helping you get started on your journey.

What is Next.js?

Next.js is a React framework developed by Vercel. It’s designed to simplify the process of building server-rendered and statically generated React applications. With features like built-in routing, server-side rendering (SSR), and static site generation (SSG), Next.js helps developers create fast, SEO-friendly websites.

Why need Use Next.js as a web developer?

1. Server-Side Rendering (SSR): Automatically renders pages on the server, improving SEO and initial load times.
2. Static Site Generation (SSG): Pre-renders pages at build time, delivering ultra-fast performance.
3. API Routes: Create backend API endpoints directly within the application*. It's for small web app.
4. Image Optimization: Automatically optimizes images for performance.
5. Built-in CSS and Sass Support: Style your app seamlessly.
6. Module CSS : Next.js supports CSS Modules, a feature that allows you to write scoped and reusable CSS for your components. By naming your CSS files with a .module.css extension, styles are automatically scoped to the component, preventing clashes with other styles in your application.
7. File-based Routing: Simple and intuitive routing based on the file system.

Next.js simplifies the development process by providing tools and features that streamline both frontend and backend workflows. Whether you're building a simple blog or a complex web app, Next.js is a powerful choice. Start exploring Next.js today and unlock its potential to create blazing-fast, SEO-friendly applications.

So developers, you finally know about Next.js. Then you start with Next.js to build up your development experience💪🏻.

HappyCoding

Next.Js

JavaScript

🚀 Node.js v24 is Here – What's New, What's Hot, and Why You Should Care

Mr Abdullah — Wed, 07 May 2025 17:44:08 +0000

Node.js just dropped its v24 release, and it's not just a version bump — it's a big leap toward a faster, smarter, and more modern JavaScript runtime for backend developers. Whether you're building APIs, working on full-stack apps, or experimenting with serverless, Node.js 24 brings several updates worth knowing.

Let’s break it down! 👇

🧩 1. npm v11 Comes Built-in

Yes, the latest Node ships with npm v11, and it brings some serious improvements:

🔄 Faster package installations
🔒 Better security scanning for vulnerabilities
📦 Improved dependency resolution

No more dealing with flaky node_modules — this is smoother and smarter.

⚙️ 2. Upgraded V8 Engine to v13.6

Node v24 now runs on V8 13.6, which means:

🚀 Even better JavaScript performance
✨ Support for newer ECMAScript features
🧠 Memory optimization under the hood

This also helps keep Node aligned with modern browser JS engines like Chrome.

🌐 3. New `URLPattern` API

Originally part of the web platform, the URLPattern API is now available in Node.js:

const pattern = new URLPattern({ pathname: '/blog/:slug' });
console.log(pattern.test('https://example.com/blog/hello-node'));

Use cases:

🚦 Route matching
🔧 Middleware filtering
🧼 Cleaner code in frameworks

It’s one more step towards making the server feel like the browser.

⚡ 4. Undici v7 Update – HTTP Gets a Power Boost

Node.js uses Undici as its core HTTP client, and v24 brings an updated version (v7). You get:

🌍 Improved HTTP/1.1 and HTTP/2 support
🚀 More stable, faster fetch()
📦 Less need for third-party HTTP libraries like axios

For most use cases, fetch is now just as reliable and faster than ever.

🪓 5. Legacy APIs Deprecated – Time to Modernize!

Node.js v24 is cleaning house:

❌ Deprecated old modules and functions (like certain crypto, fs, and util methods)
🔄 Encourages using Promises, async/await, and modern ES modules

👉 Check the full changelog to see what needs updating in your codebase.

🎯 Why Should You Upgrade?

Here’s the deal:

⚡ Better performance out of the box
✅ Built-in modern features like fetch, URLPattern, AbortSignal
🔐 Security improvements
🚫 Less boilerplate and fewer dependencies needed

If you're already using Node 18 or 20, the shift to 24 should be smooth. Just make sure your dependencies support it.

🛠️ Quick Setup

Using nvm (Node Version Manager):

nvm install 24
nvm use 24

And you're good to go!

✨ Final Thoughts

Node.js v24 is a strong step forward — it blends web platform APIs with the power of backend development, trims the fat of legacy features, and pushes developers toward a cleaner, more modern codebase.

If you're building for the future, Node.js 24 should be your default.

Have you tried v24 yet? What feature excites you most?

💬 Let’s talk in the comments.
🧑‍💻 Follow for more backend tips and JS deep dives!
🔁 Repost if your code smells like require() but dreams in import.

How to Start Web Development as a Beginner 🚀 — Part I (Frontend)

Mr Abdullah — Sat, 19 Apr 2025 19:20:01 +0000

📖 How to Start Frontend Web Development — A Beginner Friendly Guide (with Code Examples!) 🚀

Hey everyone 👋, If you’ve been thinking about learning web development but aren’t sure how to start, this guide is for you. I’ll not only explain what to learn — but also show you real code examples so you can practice right away.

So, let’s roll!

📌 What is Web Development?
Web Development means creating websites or web applications that people can use through a browser like Chrome, Firefox, or Safari.

There are three major types:

1) Frontend Development: Frontend development focuses on the visual and interactive parts of a website or web application. It involves creating the layout, design, and user interface that users directly interact with. Common technologies used in frontend development include HTML, CSS, and JavaScript. Popular frameworks and libraries like React, Vue, and Next.js make building dynamic user interfaces easier. Frontend developers also ensure that websites are responsive, meaning they look good on all devices. Additionally, they work on optimizing website performance and enhancing user experience.

2) Backend Development: Backend development deals with the server-side logic and databases of a web application. It ensures that data flows smoothly between the server, database, and client-side interface. Backend developers typically work with languages like Node.js, Python, PHP, or Java. They are responsible for creating APIs, handling authentication, and managing server operations. Security, scalability, and performance are critical aspects of backend development. Backend developers also integrate third-party services and manage data storage systems like MongoDB, MySQL, or PostgreSQL.

3) Full-Stack Development: Full-stack development covers both frontend and backend tasks in a web project. A full-stack developer can build user interfaces, manage databases, and create server-side logic. This role requires knowledge of both client-side and server-side technologies, allowing developers to handle entire projects independently or within a team.

Before start web development you must know that is which web development stack you'll start . Because , there are many types of web development stacks. These are : ->

1️⃣ MERN Stack
The MERN stack includes MongoDB, Express.js, React.js, and Node.js. It’s a JavaScript-based full-stack solution perfect for building modern web apps. Developers love it for fast development, flexibility, and a huge open-source community.

2️⃣ MEAN Stack
MEAN consists of MongoDB, Express.js, Angular, and Node.js. It’s also JavaScript-based but uses Angular for a structured, component-based frontend. This stack is great for large, scalable, and enterprise-grade web applications.

3️⃣ LAMP Stack

The LAMP stack includes Linux, Apache, MySQL, and PHP. It’s one of the oldest and most reliable stacks for hosting dynamic websites and apps. LAMP is valued for its affordability, security, and wide hosting support.

4️⃣ JAM Stack

JAM stands for JavaScript, APIs, and Markup. It focuses on decoupling the frontend and backend, often using static site generators like Next.js, Gatsby, or Nuxt.js. It’s known for fast, secure, and scalable website development.

5️⃣ Django Stack

This stack uses Django (Python) as the backend, typically paired with PostgreSQL and frontend tools like HTML, CSS, and JavaScript. Django provides a high level of security, built-in features, and a rapid development workflow. It’s ideal for scalable and feature-rich web apps.

6️⃣ Ruby on Rails Stack

Ruby on Rails stack pairs Ruby on Rails with databases like PostgreSQL or MySQL, and standard frontend technologies. It prioritizes convention over configuration, simplifying development workflows. Popular with startups and MVP builders for its rapid prototyping capability.

7️⃣ PERN Stack

PERN combines PostgreSQL, Express.js, React.js, and Node.js. It’s like MERN but uses PostgreSQL, a powerful open-source relational database. Great for apps needing structured, relational data with _React’s _component-driven frontend.

8️⃣ Serverless Stack (SST)

This stack uses cloud services like AWS Lambda, API Gateway, DynamoDB, and frontend frameworks like React or Next.js. It eliminates server management and scales applications automatically. Best for lightweight, scalable, and cost-efficient apps.

9️⃣ Vue + Node Stack

This stack uses Vue.js for the frontend and Node.js with Express.js for the backend. Vue is known for its simplicity, flexibility, and gentle learning curve, making it beginner-friendly yet powerful. Combined with Node, it’s great for modern, fast, and interactive web apps.

In these I exampled to you some of web development stack. Now decision is yours's which stack you start a as a beginner . In my suggestion you'll try to start MERN stack web development . Because , it's easy to learn & high value in market .

Now , in this article I'll discuss to you MERN stack web development . MERN stack means basically M for MongoDB , E for Express.js , R for React.js _ , N for _Node.js . MERN stack is a fully furnished web development stack . Like React.js for frontend & Node.js, Express.js and also MongoDB for backend . In this article I'll focuses on Frontend.

📌 The Core Frontend Technologies

Frontend web development is like the part of a car you can see, touch, and experience while driving.

*👉 HTML is like the car’s body structure *— it decides where the seats, steering, doors, and dashboard go, shaping the layout.

👉 CSS is the car’s paint, decoration, and style — it handles the color, design, rim style, dashboard look, and interior feel.

👉 JavaScript is the car’s engine and controls — when you press a button to turn on the headlights, honk the horn, or open a sunroof, JavaScript makes those dynamic actions happen.

👉 Responsive Design is like the adjustable seats and mirrors — it ensures your car feels good whether you’re driving in the city, highway, or off-road (meaning the website looks good on any screen size).

👉 The DOM (Document Object Model) is the car’s control panel — it lets you control the lights, AC, and music system anytime while driving, just like JavaScript can change HTML elements instantly.👉 Performance Optimization is like improving the car’s mileage, speed, and smoothness — making sure your website runs fast, uses fewer resources, and feels smooth to the user.

👉 Browser Compatibility is making sure the car can run on any kind of road — so your website looks and works properly on any browser like Chrome, Firefox, or Safari.

Let’s now talk about the core tools you need to start:

📝 I. HTML — Structure of the Website
HTML (HyperText Markup Language) is the skeleton of every webpage. HTML is the standard language for creating webpages. It structures the content on a page using elements like headings, paragraphs, images, and links. Every website on the internet uses HTML as the foundation of its content.

✅ Example:

<!DOCTYPE html>
<html>
  <head>
    <title>My First Webpage</title>
  </head>
  <body>
    <h1>Welcome to My Website!</h1>
    <p>This is a simple paragraph explaining my page.</p>
    <img src="https://via.placeholder.com/150" alt="Sample Image">
    <a href="https://www.google.com">Visit Google</a>
  </body>
</html>

Explanation:

<!DOCTYPE html> declares this as an HTML5 document.
wraps the entire page.
contains meta info like the page title.
holds everything visible to the user: headings, paragraphs, images, and links.

know more about HTML : ->

1)HTML Tutorial

2) HTML Tutorial | GeeksforGeeks

🎨 II. CSS — Styling the Website
CSS (Cascading Style Sheets) controls how everything looks — colors, layouts, fonts, and responsiveness.CSS is used to style the appearance of HTML content. It controls how elements look on a page, including colors, fonts, layouts, and animations. With CSS, developers can create responsive and visually appealing websites.

✅ Example:

<style>
  body {
    background-color: #f0f0f0;
    font-family: Arial, sans-serif;
  }

  h1 {
    color: #333;
    text-align: center;
  }

  p {
    padding: 10px;
    font-size: 18px;
  }
</style>

Explanation:

body sets the background and font for the whole page.
h1 makes the heading color dark and centers it.
p adds space around the paragraph and increases its font size.

know more about CSS : ->

1)CSS Tutorial

2)CSS Tutorials - CSS: Cascading Style Sheets | MDN

⚙️ III. JavaScript — Making It Interactive

📌 What is JavaScript (JS)?

JavaScript is a high-level, interpreted programming language mainly used to add interactivity and dynamic behavior to websites. Where HTML structures a page, and CSS styles it — JavaScript makes it alive. JavaScript is a powerful programming language used to add interactivity to websites. It allows developers to create dynamic features like sliders, popups, form validation, and animations. JavaScript can work on both the frontend (in browsers) and the backend (using tools like Node.js).

✅ It can:

Show popup alerts
Handle form validation
Create animations
Control content without refreshing the page
And even work on servers now (thanks to Node.js)

✅ Example:

<button onclick="sayHello()">Click Me!</button>

<script>
  function sayHello() {
    alert("Hello, welcome to my website!");
  }
</script>

Explanation:

creates a clickable button.
onclick runs a function when clicked.
alert() shows a popup message

📌2 ways to See JavaScript Output:

1) On a Webpage (Browser Console)

You can write JavaScript in:
1)An HTML file using script tags
2)Or directly inside the browser console

📖 Example: JS Inside HTML File:


<!DOCTYPE html>
<html>
<head>
  <title>JS Output Example</title>
</head>
<body>

<h1>Hello from HTML</h1>

<script>
  console.log("Hello, this is JS in the browser console!");
  alert("Hello User!");
  document.write("This text is from JS inside HTML.");
</script>

</body>
</html>

📌 How to See Output:

Open this HTML file in any browser .
Press F12 or Ctrl + Shift + I (Inspect)
Go to Console Tab ✅ You’ll see:

Hello, this is JS in the browser console!

And an alert box will also appear.

2) Running JavaScript in CMD / PowerShell (Without Browser)

⚠️ Problem:

By default, browsers have JavaScript engines (like Chrome’s V8), but your computer’s CMD or PowerShell doesn’t understand JS directly.

✅ Solution: Install Node.js

Node.js is a JavaScript runtime built on Chrome’s V8 engine. It allows you to run JavaScript code outside the browser — directly from your terminal.

📖 How to Install Node.js

👉 Download and install from : Nodejs.org
👉 Open CMD or PowerShell 👉 Type:

node -v

If installed properly, it’ll show you the version number. Like --> v20.16.0

📖 Example: JS File in CMD / PowerShell

✅ Create a file hello.js
console.log("Hello from Node.js!");

✅ Run it in CMD / PowerShell:
node hello.js
Output:

Hello from Node.js!

📌 Why We Need Node.js for JavaScript Outside Browser .?

👉 Browsers have built-in JavaScript engines (like V8 in Chrome) to run JS on web pages
👉 But command line and server environments don’t have this by default
👉 Node.js adds that runtime environment to your computer, so JS can run like other languages (Python, Java, C, etc.) directly from terminal

_know more JavaScript : _
1)JavaScript Tutorial
2)The Modern JavaScript Tutorial

IV. Responsive Design Basics ->
Nowadays, your website must look good on mobiles and tablets too. That’s where Media Queries and layout systems like Flexbox and Grid help.

✅ Flexbox Example:

<style>
  .container {
    display: flex;
    justify-content: space-around;
  }

  .box {
    width: 100px;
    height: 100px;
    background-color: steelblue;
    color: white;
    text-align: center;
    line-height: 100px;
  }
</style>

<div class="container">
  <div class="box">One</div>
  <div class="box">Two</div>
  <div class="box">Three</div>
</div>

Explanation:

display: flex enables Flexbox.
justify-content: space-around distributes the boxes evenly.
Each .box is styled with color, size, and centered text.

✅ Media Query Example:

@media (max-width: 600px) {
  .container {
    flex-direction: column;
  }
}

Now on mobile screens, the boxes stack vertically instead of staying side-by-side.

V. Optional: Learn a CSS Framework
Once you’re comfortable with CSS, you can try frameworks like:

Tailwind CSS (utility-first, modern)
Bootstrap (classic, easy to start)

Example with Bootstrap:

<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css">

<button class="btn btn-primary">Click Me</button>

This renders a nicely styled blue button without writing custom CSS.

Tailwind CSS & Bootstrap docs: ->

1) Bootstrap · The most popular HTML, CSS, and JS library in the world.

2)Tailwind CSS - Rapidly build modern websites without ever leaving your HTML.

⚙️VI. Version Control: Git & GitHub

📌 What is Git?

Git is a version control system (VCS) — it keeps track of all changes made to your project files over time.

✅ With Git, you can:

Save multiple versions of your code (called commits)
Revert to any previous version if something breaks
Work on different features separately using branches
Merge those branches when features are ready
Collaborate with others without messing up each other's code
In short — Git is a time machine for your code.

📌 What is GitHub?

GitHub is a cloud-based hosting service for Git repositories. Think of it as Facebook for your code — where:

You can store your Git-tracked projects online
Share your projects with others
Collaborate with developers worldwide
Manage open-source contributions
Showcase your work to recruiters or clients
✅ Git is the tool.
✅ GitHub is the online storage and collaboration platform built on top of it.

📌 Why Do We Need Git & GitHub?

i) Track Changes : See exactly who changed what, when, and why
ii) Restore Old Versions : Go back to any earlier version if needed
iii) Branching : Try new ideas without affecting the main project
iv) Collaboration : Multiple developers can work on the same project easily
v) Backup & Portfolio : Keep your code safe online, accessible anytime, anywhere
vi) Deploy & Integrate : Host open-source projects, connect with CI/CD pipelines, deploy

Basic Git Commands:

git init # Start a new repository
git add . # Stage changes
git commit -m "Initial commit"
git remote add origin
git push -u origin main

know more about GIT & GITHUB : ->

1)Git Tutorial

2)GitHub Docs

⚛️VII. JavaScript Library: React.js
If you wanna to make more interactive your website, React is the more important for a website frontend more interactive after learn HTML, CSS, JS. So, ready to go knowing about React.js.

📌 What is React?
React is a JavaScript library (not a framework) for building user interfaces (UIs), especially single-page applications (SPAs).

✅ It makes websites super fast and interactive by using something called the virtual DOM, which updates only the necessary parts of a web page — not the whole page.

📌 What is Vite? Why use it with React?

Vite is a next-generation front-end build tool that’s faster and lighter than Create React App (CRA).

Why Vite?

Instant dev server start
Fast hot module replacement (HMR)
Smaller final build
Simple and clean project structure

React + Vite = 🚀 Modern React development with speed and simplicity.

📌 How to Initialize a React Project with Vite

👉 Step 1️⃣ : Open your terminal (CMD / PowerShell)
👉 Step 2️⃣ : Run this command:

npm create vite@latest my-react-app -- --template react

Or with Yarn :

yarn create vite my-react-app --template react

👉 Step 3️⃣ : Go inside your project folder

cd my-react-app

👉 Step 4️⃣ : Install dependencies

npm install

👉 Step 5️⃣ : Start the development server

npm run dev

✅ Your React site is now running locally at [http://localhost:5173/](http://localhost:5173/)

📌 2 Strong React Example (with Code)

📖 Example 1: write Hello World in React.js

import React from 'react'

function App() {
  return (
    <div>
      <h1>Hello World</h1>
      <button>Click Me</button>
    </div>
  )
}

export default App

📖 Example 2: Simple Counter App
A classic React example using state.

import { useState } from 'react'

function App() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => setCount(count - 1)}>Decrement</button>
    </div>
  )
}

export default App

know more about React + Vite ->
1)Getting Started | Vite
2)Quick Start – React
3)React-Router

📌 Final Thoughts
If you’ve read till here — thank you, you’re already ahead of most beginners out there. Starting your frontend web development journey isn’t about knowing everything at once. It’s about taking small, steady steps, building projects, and having fun along the way.

Frontend Web Development isn’t just about code — it’s about creating experiences for people. It can be tough at first, but with consistency, curiosity, and practice, you’ll master it.

So all of learner people, in this article I tried to discuss about of web development & share basics thought of frontend development. In my suggestion If you'll start web development step by step , I hope you'll learn web development smoothly .

*Start with small steps. Don’t chase all things at once. Learn. Build. Share. Repeat.
*
And that’s a wrap for Part I! But a website isn’t just what you see — there’s a whole world happening behind the scenes. In the next part, we’ll dive deep into Backend Development and explore how servers, databases, and APIs work together to power your web apps.

Stay tuned, it’s going to be exciting! 🚀

Happy Coding 💻💪🏻

If you want to get updated about related . Please follow me :- Abdullah Shayed

DEV Community: Mr Abdullah

Linus Trovalds ~ Founder of Linus and GIT

Render Infrastructure Incident? Multiple Backend Services Returning 502 and 503 Errors

What I Observed

Why 502 and 503 Matter

The Interesting Part: Multiple Backend Services

Render's Architecture Matters Here

But There Is an Important Caveat

Free Services Add Another Variable

How I Would Investigate This

1. Check the service logs

2. Check deployment history

3. Test independent services

4. Check Render's status page

Why Status Pages Don't Always Tell the Whole Story

What Developers Should Not Do During a Possible Platform Incident

A Simple Mental Model

Layer 1: Application

Layer 2: Service Runtime

Layer 3: Platform

Render Health Checks Are Another Piece of the Puzzle

My Observation From August 20, 2026

What This Means for Production Systems

Final Thoughts

Resources

Check It

Python Functions, Arguments & Scope: The Details That Start to Matter

Python Functions, Arguments & Scope: The Details That Start to Matter

Part 1 — Functions, Arguments & Scope

1. *args and **kwargs

What It Is

Syntax

How It Works

Real-World Example

Handwritten Python Code

Output

Common Mistakes

Mistake 1: Assuming args is a list

Mistake 2: Using *args when the API has a known shape

Mistake 3: Treating **kwargs as an excuse to skip API design

When to Use It

When NOT to Use It

Developer Notes

Short Takeaway

2. Positional-Only / and Keyword-Only * Arguments

What It Is

Syntax

How It Works

Real-World Example

Handwritten Python Code

Output

Common Mistakes

Mistake 1: Forgetting what / means

Mistake 2: Assuming * means variable arguments

Mistake 3: Making everything keyword-only

When to Use It

When NOT to Use It

Developer Notes

Short Takeaway

3. Unpacking

What It Is

Syntax

How It Works

Real-World Example

Handwritten Python Code

Output

Common Mistakes

Mistake 1: Using * with a non-iterable

Mistake 2: Passing unexpected dictionary keys

Mistake 3: Confusing unpacking with copying

When to Use It

When NOT to Use It

Developer Notes

Short Takeaway

4. Scope and LEGB

What It Is

Syntax

How It Works

global

nonlocal

1. `*args` and `**kwargs`

Mistake 1: Assuming `args` is a list

Mistake 2: Using `*args` when the API has a known shape

Mistake 3: Treating `**kwargs` as an excuse to skip API design

2. Positional-Only `/` and Keyword-Only `*` Arguments

Mistake 1: Forgetting what `/` means

Mistake 2: Assuming `*` means variable arguments

Mistake 1: Using `*` with a non-iterable

`global`

`nonlocal`

Mistake 2: Using `global` as a general state-management solution

Mistake 2: Forgetting `nonlocal` when modifying captured state

6. `lambda`

7. `map()`, `filter()`, and `reduce()`

`map()`

`filter()`

`reduce()`

`map()` vs Comprehension

`filter()` vs Comprehension

Mistake 1: Assuming `map()` returns a list

Mistake 3: Using `reduce()` when a named built-in expresses the operation

When to Use `map()`

When to Use `filter()`

When to Use `reduce()`