DEV Community: nedajahanfar

Understanding WordPress Basics Before You Start

nedajahanfar — Thu, 08 Jan 2026 21:58:28 +0000

So you decided you want to create a website and put it on the internet.
Is the only way to do that by talking code to a computer?
No

Today we also have GUIs (graphical user interfaces) for this, and WordPress was made exactly for that reason.

Around 42–48% of all websites in the world are built with WordPress, which already tells you a lot about how powerful and accessible it is.

Content types in WordPress:

In WordPress, there are three main types of content you can give to a website:

1. Blog posts (Posts)

It also has a dedicated button in the WordPress dashboard.

It’s meant for:
blogs
articles
long text-based content
content that grows over time

Blog posts are usually managed and enhanced by blog-focused plugins.
One popular plugin used to extend content structures is JetEngine.

2.Pages (what you visually build)

Pages are more similar to what developers imagine when they think about structure.

They are:
visual layouts
sections + components
built using page builders

The most famous one is Elementor.

Pages have their own section in the dashboard, and you usually use them for:
Home
About
Services
Contact
Landing pages

Think of pages as designed layouts, not streams of content.

3. Custom Content Types (CCT / CPT)

This is where WordPress becomes more powerful.

Custom Content Types are structured content, similar to data stored in tables:
products
events
courses
team members
portfolio items

You can compare them to rows in a database table, where each item has fields (title, price, image, date, etc.).

They are not “pages” and not “blogs”, but reusable structured data.

Themes: the foundation of your site

When you create a site, the first thing you choose is a theme.

A theme decides:

typography
spacing
base layout
general visual rules

Some themes are very flexible, like Astra, which means:

easy to customize
works well with page builders
doesn’t lock you into a rigid structure

Other themes are more opinionated, meaning:
harder to modify
more constraints
faster setup but less freedom

Choose your theme wisely, because it affects everything that comes after.

Templates (often confused, very important)

After themes, we arrive at templates.

There are two types of templates:

1.Templates you create yourself

These are templates you build using Elementor (or another page builder).
They are basically reusable layouts.

2.Inserted / imported templates

These come from:
template kits
external libraries...

Important rule:
Once you create a page using a specific template, you can’t just switch the template.
You usually need to create a new page if you want a different structure.

Templates are basically sets of components, reused across pages.

Plugins (extra powers):

Plugins are how you add functionality to WordPress.

If you come from a coding background:
plugins are like libraries
they extend what WordPress can do

Too many plugins is not good:
slower site
conflicts
harder maintenance

Some very famous plugins:
WooCommerce → adds an entire e-commerce system
Elementor → visual page builder
Security plugins → protect your site
SEO plugins → help search engines understand your content

Each plugin adds power, but also responsibility.

Final thought?
WordPress lets you build websites without writing code, but understanding how it works makes a huge difference.

Episode 1: Arrays — The Hidden Logic Behind How Your Code Remembers

nedajahanfar — Sun, 09 Nov 2025 21:45:44 +0000

What Is an Array?

In short, an array is a sequence of values stored contiguously (back-to-back) in memory.
All values in the array must be of the same data type (e.g., integers, characters, etc.).

When an array is created, the computer allocates a continuous block of memory large enough for all its elements.
Unlike individual variables — which might be placed randomly in memory — array elements are stored side by side.

For example, an array of three integers will occupy 12 bytes in total (since an integer is typically 4 bytes), with the four bytes for each integer stored immediately next to the next.

Why Arrays Are Zero-Indexed

When an array is created, the computer:

Allocates a contiguous block of memory large enough for all elements.
Stores the address of the first element (called the base address).
The variable name (e.g., numbers) doesn’t hold all the elements — it only holds this starting address.

So when you write:

let numbers = [10, 20, 30];

The computer knows:

The base address (say, 0x1000) points to the first element (10).

Each integer takes 4 bytes.

Therefore:

numbers[0] → address 0x1000

numbers[1] → address 0x1004

numbers[2] → address 0x1008

This is why arrays start at index 0 —
to access any element, the computer uses the formula:

address = base_address + (index × size_of_each_element)

If indexing started at 1, every lookup would require an extra subtraction (index - 1) —
an unnecessary calculation. Zero-based indexing keeps memory access clean and direct.

When and Why to Use Arrays

Arrays are one of the most common choices for storing data — but when are they actually the best choice?

In general, there are four main operations you might want to perform on a dataset:

Insertion (adding a new item)

Deletion (removing an item)

Selection / Access (finding or reading an item)

Sorting (reordering items)

Let’s see how arrays handle each of these, both in the best and worst cases.

Deletion

It depends on where you delete from:

From the end: very efficient → O(1)
The computer simply forgets the last item — no need to move anything.

From the beginning or middle: slower → O(n)
Imagine removing the first book from a shelf — every other book needs to shift one position left to fill the empty spot.

So deleting the first element is the worst case since the program has to move n–1 items.

Insertion

Again, position matters:

Add to the end: easy → O(1)
The computer just adds one more element to the next empty slot.

Add to the beginning or middle: expensive → O(n)
All the other items need to shift one index to make room.

Selection (Accessing or Searching)

If you already know the index: instant → O(1)
Arrays shine here — the address formula lets you jump directly to any element.

If you don’t know the index: you must look through all items → O(n)

Sorting Is Special..

While most array operations have fixed theoretical costs defined by the structure itself
(e.g., deletion ≈ O(n), insertion ≈ O(n)), sorting is unique because your algorithm choice can change its Big O class entirely —
from O(n²) with simple methods like Bubble Sort to O(n log n) with smarter ones like Merge Sort.

For example:

Sorting an array with Bubble Sort → O(n²)
Sorting the same array with Merge Sort → O(n log n)
Here, the data is the same, but the algorithm changes the efficiency.

Why?
Because sorting isn’t an inherent feature of arrays — it’s an operation applied externally using an algorithm.
In contrast, operations like “add” or “access” are built into how arrays work.

LeetCode Example — Insertion in Arrays

Problem: LeetCode #1389 — Create Target Array in the Given Order

Task:
Given two arrays of integers, nums and index, create a target array following these rules:

Start with an empty array.

For each i, insert nums[i] at position index[i] inside the target array.

Repeat until all elements are processed.

It is guaranteed that all insertions will be valid.

As mentioned earlier, adding to the end of an array (like using .push() in JavaScript) is fast — O(1).
But inserting elements at random positions forces the computer to shift all other elements, which costs O(n) per insertion.

Since this problem requires doing that n times, the total cost becomes O(n²).

Step-by-Step Logic

When thinking through the solution:

Loop through the index array from start to end.

For each index i, find the corresponding number nums[i].

Insert nums[i] into the target array at position index[i].

If that position is already occupied, shift all following elements right.

Translating That Into Code:

function arrayMaker(index, nums) { let target = []; for (let i = 0; i < index.length; i++) { target.splice(index[i], 0, nums[i]); } return target; }

The .splice() method in JavaScript handles insertion directly.

It takes three arguments:

The index where to insert.

How many elements to delete (here, 0).

The new element to insert.

Example:

target.splice(2, 0, 5);

Inserts 5 at position 2, shifting everything after it to the right.

What We Learned

Inserting at the end of an array → O(1)

Inserting in the middle or beginning → O(n)

Doing this repeatedly → O(n²)

Arrays are great for reading and appending data,
but repeated insertions at random positions make them inefficient —
that’s where other data structures like linked lists come in.

Deletion Example — LeetCode #27

Problem: Remove Element

Given an integer array nums and a value val,
remove all occurrences of val in-place and return the new length of the array.

function removeElement(nums, val) { let k = 0; for (let i = 0; i < nums.length; i++) { if (nums[i] != val) { nums[k] = nums[i]; k++; } } return k; }

Explanation

We use two pointers:

i → reads each element

k → marks the position where the next valid element should go

If the current value isn’t equal to val, we copy it to nums[k] and move k forward.
This overwrites unwanted values as we go — deleting in-place without creating a new array.

Physical deletion (using .splice() or .slice() repeatedly) is not optimal,
because each deletion shifts all following elements one step left —
making it O(n²) when done multiple times.

Instead, overwriting valid elements keeps it O(n) and efficient.

LeetCode #1365 — Counting Smaller Numbers

Problem: How Many Numbers Are Smaller Than the Current Number

We return, for each number, how many others are smaller than it.

var smallerNumbersThanCurrent = function(nums) { let output = []; for (let i = 0; i < nums.length; i++) { let count = 0; for (let j = 0; j < nums.length; j++) { if (nums[i] > nums[j]) count++; } output[i] = count; } return output; };

Explanation

This approach compares each element with every other element.
If nums[i] > nums[j], we increase the counter.
The result shows how many numbers are smaller than each one.

This works fine for small arrays but is O(n²) in complexity.

We can reduce it to O(n log n) using sorting and mapping —

Now, let’s move to a different array problem that highlights another concept: selection.

LeetCode #448 — Find All Numbers Disappeared in an Array

Step 1 — Brute Force

Compare each number against all possible values 1..n.
Works, but too slow → O(n²).

Step 2 — Smarter (Using a Set)

function missingNums(nums) { let max = nums.length; let fullArray = Array.from({ length: max }, (_, i) => i + 1); let set = new Set(nums); let missing = fullArray.filter(num => !set.has(num)); return missing; }
How it works:

Array.from({ length: max }, (_, i) => i + 1) creates [1, 2, 3, ..., n].

new Set(nums) removes duplicates and enables O(1) lookups.

.filter() keeps only numbers missing from the Set.

Time: O(n)
Space: O(n)

Step 3 — Can You Still Do It Better?

Well, yes — you can make this even more efficient,
reduce the time complexity, and avoid using extra space.

Let’s see how

`function DisappearedNums(nums) {
let target = [];

for (let i = 0; i < nums.length; i++) {
let index = Math.abs(nums[i]) - 1;
if (nums[index] > 0) {
nums[index] = -nums[index];
}
}

for (let i = 0; i < nums.length; i++) {
if (nums[i] > 0) {
target.push(i + 1);
}
}

return target;
}`

What’s Happening Here?

Imagine you have a classroom full of students and want to see who’s absent.
Each student goes and marks their seat to show they attended.
Because arrays are zero-based, each student marks the seat at value - 1.

At the end, we check which seats remain unmarked (still positive) —
those correspond to the absent students.

This approach cleverly uses the same array as its own tracker,
so no extra arrays or Sets are needed.

Time Complexity: O(n)
Space Complexity: O(1)

This is one of the most efficient ways to solve the problem.
It shows how the right data structure, combined with the right algorithm,
can dramatically improve performance :)

Everything You Need to Know to Start Your Way as a Programmer

nedajahanfar — Wed, 05 Nov 2025 18:10:44 +0000

Finding Your Starting Point:

Finding a solid way to start programming can feel overwhelming.
You get lost in definitions, frameworks, and tutorials — and it’s hard to know where to begin.

But if we strip everything down to the most important foundation, one concept stands above all others: the algorithm.

What Is an Algorithm?

An algorithm is simply a set of steps used to solve a problem or create something.
It’s the sequence of actions you take to reach a result.

You use algorithms every day — even outside coding.

Making coffee: boil water → add coffee → pour → stir
Sorting your books: compare titles → arrange alphabetically

That’s all an algorithm is — a structured way to reach a goal.

What Makes a “Good” Algorithm?

_Not all algorithms are equal.
_Some take more time or use more memory than others.

A good algorithm is one that:

Solves the problem correctly
Uses the least possible time
Uses the least possible space

So how can we measure that?
That’s where Big O Notation comes in.

Big O Notation — Measuring Efficiency:

Big O tells us how the performance of an algorithm changes as the input grows.
It focuses on the worst-case scenario: how long (or how much memory) your code might take for n elements.

Here are the most common types:

O(1) => Constant => Always takes the same time, no matter the input size. (Best case!)

O(log n) => Logarithmic =>Still very efficient — time increases slowly as input grows.

O(n) => Linear => Time grows in proportion to input size.

O(n²) => Quadratic => Much slower — time grows dramatically as input increases.

Think of it like this:

Searching in a sorted list (binary search) → O(log n)
Looping through every item once → O(n)
Double nested loops → O(n²)

Algorithms and Data Structures:

Algorithms work on data — but the way we store and organize that data matters too.
That’s where data structures come in.

Different data structures (arrays, stacks, queues, linked lists, trees, etc.) are optimized for different operations.
For example:

Searching through an array might take O(n)
Searching through a hash table can be O(1)

Choosing the right structure can dramatically change performance.

What’s Next?

In this series, we’ll explore:
The most important data structures
Their time and space complexities (Big O)
Real LeetCode problems related to each topic
Pseudocode examples to understand how they work

By the end, you’ll not only know what each structure does — you’ll know when and why to use it.

What Is a Memory Leak?

nedajahanfar — Tue, 04 Nov 2025 09:41:29 +0000

Anything that runs on your computer or phone needs memory to work.
On a computer, we have two main types of memory:

RAM (Random Access Memory) – temporary, fast, used while apps are running.
Hard drive (or SSD) – permanent storage for files and apps.

When your RAM gets full, your system may start using the hard drive as slower “virtual memory.”
On mobile devices, it’s similar — there’s RAM (for running apps) and internal storage or memory card (for saving files).

How Memory Works in Apps:

When you open an app, it loads images, data, and resources into RAM so it can run quickly.
In an ideal world, when you close the app — or move from one screen to another — it should free up the memory it used, since it no longer needs that data.

But that’s not always the case...

What Is a Memory Leak?

Imagine you invite a friend to stay at your house for one night — but she decides to live in your room forever.
That’s what a memory leak is.

The app borrowed some memory temporarily, but instead of letting it go, it keeps holding onto it even when it’s no longer needed.

Over time, the app’s memory usage keeps growing.
Eventually:

The app becomes slower

The phone heats up

Or it crashes with “out of memory” errors

Why It Happens

Memory leaks usually occur when developers forget to:

Remove event listeners

Clear timers or intervals

Release references to images, arrays, or objects no longer needed

For example:

useEffect(() => { const interval = setInterval(fetchData, 5000); return () => clearInterval(interval); // cleanup to prevent leaks }, []);

Or when large objects are kept in memory:

const bigImage = loadImage('banner.png'); // ... app closes, but bigImage is still referenced somewhere

How Developers Prevent It:

Developers use profiling tools to detect leaks — like:

Android Studio Profiler

LeakCanary

Flipper (React Native)

They also:

Clean up listeners and intervals in useEffect

Release images and cache data properly

Move heavy data to the server, not the client app

In Short:
A memory leak is when an app refuses to let go of the memory it once borrowed.

Astro: A Different Kind of Web Framework

nedajahanfar — Fri, 22 Aug 2025 19:46:05 +0000

Astro first appeared in 2021 as a new kind of frontend framework, built with a very specific goal: giving developers complete control over how their websites are rendered.

Unlike many frameworks that push you into either SSR (server-side rendering) or CSR (client-side rendering / SPA), Astro lets you mix and match. This flexibility makes it especially powerful for content-heavy sites—think blogs, documentation, e-commerce catalogs—where most of the page is static but certain parts (like search bars, filters, or comments) still need to be dynamic.

The Island Architecture:
Astro’s secret sauce is what it calls “Island Architecture.”
Most of your site is rendered on the server by default (fast, SEO-friendly, lightweight).

But individual “islands” (small, interactive components) can be hydrated on the client only when needed.

This means you can have a mostly static site with a React search bar, a Vue shopping cart, and maybe a SolidJS widget—all living together on the same page.

Framework Flexibility:
Astro is framework-agnostic. You can use React, Vue, Svelte, Solid, Preact, Lit, or just plain HTML/JS. Or mix them all. That’s why Astro is often called a flexible framework: it doesn’t lock you in.
Each component you write can be given a client: directive to control when (and if) it loads on the browser:

client:load → load immediately.

client:visible → load only when it comes into view.

client:idle → wait until the browser is idle.

client:only="react" → load only in React, ignoring server-side rendering.

If you don’t specify anything, Astro takes a server-first approach—it behaves like SSR, sending down plain HTML without extra JavaScript.

File-Based Routing:

Astro also keeps things simple with file-based routing:
Put your pages inside the src/pages folder.
A file like about.astro becomes /about.
A folder with index.astro maps to /foldername.
Bracketed names (like [slug].astro) handle dynamic routes.

Inside each .astro file, the structure is straightforward:
Frontmatter (the top script block) → where you do imports and API calls.
Markup (HTML) → the actual page structure.
Style → scoped to that page or component.
Script → optional client-side JavaScript.

This encourages clean separation of logic and design.

Analogy :))

Think of Astro like building a theme park:

Most rides (pages) are already built and ready (static content rendered on the server).
But a few attractions (interactive islands) only start running when visitors walk up to them (hydrated when needed).
You, the architect, decide which rides are permanent and which ones only spin up when someone presses the button.

Everything You Need to Know About Web Rendering

nedajahanfar — Sun, 29 Jun 2025 07:30:39 +0000

How do we see the code we write show up on our screens?
What turns raw data and logic into buttons we can tap, pages we can scroll, and animations we can feel?

This process is called rendering, rendering is the process of transforming data and code into HTML that an end-user can see and interact with. This crucial step can happen in a few different places:

On the server: Where the website's data and logic live.
In the browser: On the user's device.

It can also be done all at once or partially, and each approach comes with its own trade-offs concerning user experience, performance, and developer experience.Now, let's explore the 10 rendering patterns for web apps:

Static Website:
Imagine you're preparing for a big event and need to send out invitations. With a static website, you create all your invitations (web pages) in advance, print them out, and then have them ready to hand over whenever someone asks for one. These pre-made pages are then uploaded as simple files to a storage space in the cloud, and a domain name points to them.
•
How it works: All web pages are put together upfront and uploaded as fixed, static files.
•
Analogy: It's like having a stack of pre-printed brochures for your business. When a customer walks in, you just hand them a brochure. You don't print a new one every time someone asks; it's already done.
•
Pros:
Works great, even today.
Simple to manage.
Low-cost hosting.
•
Cons:
Not ideal for websites where data changes frequently.
Only suitable for very basic websites without a lot of interactivity or dynamic content.
Frameworks: Hugo, 11t, and Jekyll.

Best for: Personal blogs, portfolios, documentation sites, marketing landing pages that rarely change.

Multi-Page Applications (MPA):
Think of a bustling custom bakery. Every time a customer places an order for a cake (representing a page request), the baker (the server) dynamically bakes a fresh cake from scratch based on that specific order, putting together the ingredients (HTML and data) right then and there. If you click on a new link, it's like ordering a completely new, freshly baked cake, leading to a full-page reload.
•
How it works: HTML and data are assembled dynamically on a server whenever a browser sends a request. The appearance of the website can change as the underlying data changes.
•
Analogy: Visiting amazon.com is a classic example. Every time you click a link, you get a new, dynamically generated page from their servers, like ordering a completely new dish at a restaurant where each order is prepared fresh.
•
Pros:
Handles dynamic data effectively.
Many of the biggest web apps still use this approach.
•
Cons:
The "full page reload" on every URL can feel "clunky" compared to smoother app experiences.
Can take at least a few hundred milliseconds or more for the page to render.
•
Frameworks/CMS: Ruby on Rails, Django, Laravel, and WordPress.

Best for: Large traditional websites like e-commerce (Amazon), forums, corporate portals.

Single Page Application (SPA):
Imagine an art studio with a single, large, blank canvas. When you enter, the artist (JavaScript) immediately starts painting the entire scene directly onto that one canvas, pulling in details and colors as needed. If you want to see a different scene, the artist doesn't get a new canvas; they simply paint over or adjust the existing one, making the transitions feel very smooth and instantaneous, all happening within that one "page" in the studio.
•
How it works: All user interface (UI) rendering occurs within the user's browser. It starts with one basic HTML page as a "shell," then JavaScript executes to render the UI and fetch any necessary data. Even with multiple "routes" or sections, these are updated by JavaScript in the browser, not by pointing to a new server page.
•
Analogy: Think of an interactive map application. You open it once, and then you can zoom, pan, search for locations, and get directions—all without the page ever reloading. All interactions happen seamlessly within that single map view.
•
Pros:
Feels instantaneous to the end user.
•
Cons:
Requires a large JavaScript bundle, which can make the initial page load quite slow.
Search engines, even today, struggle to understand content on dynamic routes, which is bad for SEO (Search Engine Optimization) or sharing content on social media.
•
Frameworks: AngularJS and React.

Best for: Web apps with rich interactivity—dashboards, chats, to-do apps, calendars.

Server-Side Rendering (SSR):
This is like a hybrid newspaper delivery service. The very first time you request the newspaper (the initial page load), a complete physical paper is printed and delivered directly to your door (the server renders everything dynamically). After that initial delivery, any subsequent updates, interactive elements, or navigation within the digital version of the newspaper are handled by a small, interactive app on your phone (client-side JavaScript takes over), giving you a smooth, app-like experience without needing a new physical paper for every small change.
•
How it works: HTML and data are rendered on the server for the initial page load. After this, client-side JavaScript "hydrates" the page, allowing it to function like a Single Page Application (SPA). It's a "best of both worlds" approach aiming for good initial load performance and a smooth interactive experience afterward.
•
Analogy: Imagine a restaurant that pre-cooks the main dish for efficiency (server-side render) so it's ready quickly when you sit down. But once it's served, you can add sauces, garnishes, and interact with the meal yourself (client-side JavaScript takes over) without sending it back to the kitchen.
•
Pros:
Offers the "best of both worlds" by providing a fast initial page load from the server while still enabling an app-like SPA experience afterward.
Likely the most popular rendering strategy today.
•
Cons:
Requires an actual server to run, which costs money.
On the initial page load, the app might feel "frozen" while the JavaScript is still executing to "take over" the rendering process (hydration).
•
Frameworks: Next.js, Nuxt, and SvelteKit (often called meta frameworks).

Best for: News sites, blogs, SaaS apps that need fast first paint + dynamic content.

Static Site Generation (SSG):
Think of a highly organized, pre-made meal service. All your meals (web pages) are cooked and perfectly packaged (rendered as HTML) in advance at a central kitchen (during the "build" process). When you order one, it's just delivered directly to you from this pre-made stock. But once you have it, you can heat it up, add sauces, or customize it within your own kitchen (JavaScript hydrates after the initial page load to add interactivity).
•
How it works: All HTML is rendered in advance, similar to static websites. However, like SSR, it then "hydrates" to JavaScript after the initial page load to provide an app-like experience. Websites using this approach are often called Jamstack sites.
•
Analogy: Building a LEGO set. All the pieces (HTML) are manufactured and sorted beforehand. When you get the box, everything is ready. You assemble the basic structure (initial static page), and then you can add motors or interactive elements to make parts move (hydration with JavaScript).
•
Pros:
Combines the simplicity and low-cost hosting of a static site with the app-like experience of an SPA.
•
Cons:
You have to redeploy your entire site whenever the underlying data changes.
Similar to SSR, the app might feel "frozen" during the initial page load while JavaScript executes for hydration.
•
Frameworks: Typically built by the same meta frameworks as SSR, such as Next.js, Nuxt, and SvelteKit.

Best for: Blogs, documentation, small e-commerce catalogs with infrequent updates.

Incremental Static Regeneration (ISR):
Imagine a very popular coffee shop that pre-brews large batches of coffee (like a static site). Most of the time, they just pour from what's already made (the cached content), which is incredibly fast. But, if a certain amount of time passes, or a specific ingredient runs out (cache invalidation rules), they don't shut down the whole shop; they automatically brew a new fresh batch for just that specific type of coffee (rebuild individual pages on the fly). This allows them to handle new data without a full "shop closure" (server deployment).
•
How it works: You deploy a static site, but individual pages can be rebuilt on the fly on your server when their cache is invalidated based on specific rules (e.g., after a certain amount of time). This provides a way to handle dynamic data without needing a full server deployment like SSR.
•
Analogy: A library with a main collection (static site) that's mostly unchanging. But for popular new releases or books with frequent updates, the librarian (the server process) can automatically get and update just those specific books periodically or when new editions are released, without having to reorganize the entire library.
•
Pros:
Offers the "best of both worlds" between SSG and SSR.
Allows handling dynamic data without a full server deployment.
Extremely fast due to permanent caching on a CDN (Content Delivery Network) for most requests.
•
Cons:
More complex to set up on your own.
You'll likely need a hosting provider that supports it out-of-the-box, like Vercel.
Still involves hydration, which can make the app feel "frozen" initially.
•
Frameworks: Started in Next.js.

Best for: Sites with lots of pages that need periodic updates, like blogs with comments or product catalogs with occasional price updates.

Partial Hydration:
Consider a vast, interactive museum exhibition. Instead of powering up every single exhibit at once when you walk in, which would take ages, the museum powers up the main entrance and the most important, visible exhibits first (components at the top of the page). Then, as you walk deeper into the museum or approach a new section, only those specific exhibits are powered up and made interactive (JavaScript is executed for those components as they become visible or needed).
•
How it works: Aims to solve the problem of an app feeling "frozen" on initial load due to large JavaScript execution. Instead of hydrating the entire page, it might render components at the top first, then wait until the user scrolls down before making other components interactive.
•
Analogy: A complex digital magazine. When you open it, you can immediately read the headlines and the top of the first article. The interactive elements like image carousels or video players further down the page only load and become active as you scroll to them.
•
Pros:
Improves the perceived performance and responsiveness of the app on initial load by making the top of the page interactive faster.
Reduces the initial JavaScript load and execution time.
•
Cons:
While not explicitly stated as a "con" in the source, it inherently adds complexity to the development process as you need to manage which parts hydrate when.
•
Supporting concepts: This pattern is facilitated by tools that support code splitting and lazy loading.

Best for: Long content pages with few interactive widgets (e.g., media articles, marketing pages).

Islands Architecture:
Imagine a vast, calm ocean (representing your static HTML) with several small, bustling islands scattered across it. The entire ocean is always there, providing the main content. However, only on these specific "islands" (interactive components) do you find active life and movement (JavaScript). Many parts of the ocean (static components) remain just water, meaning no boats (JavaScript) are ever sent there, making it very efficient.
•
How it works: The page starts with static HTML. JavaScript is only used to hydrate (make interactive) specific, isolated "islands" of interactivity. This is highly efficient because many components are often static and don't need JavaScript.
•
Analogy: A public bulletin board. The board itself and most of the notices tacked to it are static. But then there are a few QR codes or small digital screens embedded in the board that are interactive. You only need a battery (JavaScript) for those specific interactive parts, not the entire board.
•
Pros:
Extremely efficient: if a page is not interactive at all, no JavaScript is ever shipped to the client.
More efficient than hydrating the entire page.
•
Cons:
Requires a different way of thinking about component architecture.
•
Frameworks: Astro.

Best for: Mostly-static content sites with isolated interactive parts—think news sites with "like" buttons or comment forms.

Streaming SSR:
Think of receiving a long, important document. Instead of waiting for the entire document to be printed and bound before it's given to you, the printer starts sending you pages as soon as they are ready, in multiple chunks. You can start reading and interacting with the first pages while the printer is still working on the later ones, making the whole process feel much faster and more responsive.
•
How it works: This method allows the server to render content concurrently in multiple chunks rather than delivering everything all at once. It's a way to address inefficient hydration by making the UI interactive faster.
•
Analogy: Watching a video stream online. The video doesn't download entirely before it starts playing; it streams in chunks, allowing you to start watching almost immediately while the rest loads in the background.
•
Pros:
The UI becomes interactive faster.
Feels more performant to the end user.
•
Cons:
Not explicitly listed, but it adds complexity to the server-side setup.
•
Frameworks/Building Blocks: Supported in frameworks like Next.js 13 with the app directory, thanks to building blocks like React Server Components

Best for: Complex, data-heavy pages (e.g., dashboards, social media feeds) where rendering partial content ASAP improves UX.

Resumability:
Imagine a super-intelligent robot factory where robots are built in a unique way. When you "power on" a robot (load the website), all its blueprints, internal data, and even instructions for specific movements (like waving its arm or turning its head) are serialized and embedded directly into its physical structure (HTML). The actual "code" for those movements is then broken into tons of tiny, independent chips. When you tell the robot to wave, it doesn't need a huge "start-up" program; it just activates the tiny, specific chip needed for that exact wave, loading it only when required. No large initial power-up (hydration) is needed.
•
How it works: This is a new rendering paradigm. The website and all its data, including JavaScript event listeners, are serialized directly into the HTML. The actual JavaScript code is broken into many tiny chunks. This means the initial page load is always static HTML, and no hydration is needed. Any JavaScript required for interactivity is lazy-loaded only when specifically needed in the background.
•
Analogy: A self-sufficient modular home. Everything needed for the house to function is pre-built and embedded within its structure. If you want to turn on a light, the specific tiny wiring for that light switch is activated instantly, without needing to power up the entire house's electrical system first.
•
Pros:
Gets rid of hydration altogether, which is often a source of performance problems.
The initial page load is always static HTML.
JavaScript is lazy-loaded only when required for interactivity.
•
Cons:
It's a new and emerging paradigm, currently being pioneered by the Qwik framework. This means less community support or established best practices compared to more mature methods.
•
Frameworks: Qwik

Best for: Performance-critical apps with a need for almost instant load on mobile and slow networks.

SSR + RSC: Best of Both Worlds

nedajahanfar — Thu, 26 Jun 2025 20:22:21 +0000

When building web apps with React, two powerful rendering strategies are Server-Side Rendering (SSR) and React Server Components (RSC). Both aim to improve performance and user experience, but they do so in different ways. Let’s break them down.

What is SSR (Server-Side Rendering)?

With SSR, your app runs on the server first, and the server sends HTML to the browser. This means users see the content almost instantly—especially useful for content-heavy apps like blogs or news websites.

So when a user visits your site:

The server builds the page.

The HTML is sent immediately.

The browser renders the static page quickly.

The Downside?
While the page looks ready, it’s not fully interactive yet.

That’s because the JavaScript bundle—which handles interactivity (like clicking buttons, submitting forms, etc.)—still needs to download and run on the client. This process is called hydration.

Until hydration completes, your app might look alive but feel dead—buttons won’t respond, dropdowns won’t open, etc.

What are React Server Components (RSC)?

React Server Components are a newer model introduced by the React team. They allow parts of your component tree to be rendered entirely on the server, without being sent to the browser as JavaScript.

Here’s how they help:

You can keep logic securely on the server (e.g., API keys, database queries).

You send only the minimal necessary JavaScript to the client.

The client only hydrates the parts that actually need interactivity.

So what’s the benefit?
RSC gives you:

The fast initial load time of SSR.

The security of keeping sensitive logic hidden.

The efficiency of only sending JS to the components that need it.

This makes your app faster, more secure, and less bloated.

*SSR + RSC: *

When combined:

SSR handles the initial HTML rendering, making pages load fast.

RSC takes care of server-side logic and keeps sensitive data away from the client.

Client components handle interactivity, and hydration is smarter and more efficient.

_React Server Components are a game-changer for building modern apps. They help keep things snappy, reduce unnecessary JavaScript, and allow developers to write more secure and scalable applications.

So next time you're building an app that needs both speed and interactivity, consider combining SSR and RSC—you might just get the best of both worlds._

PHP Simplified: So, What Exactly Is PHP?

nedajahanfar — Tue, 24 Jun 2025 14:15:29 +0000

What Does “PHP” Mean?

PHP stands for “Hypertext Preprocessor” — a bit confusing, since the acronym is recursive. It’s a widely-used, open-source scripting language that’s especially popular for building websites.
But what does “scripting language” mean?
A programming language is a broader term that refers to any language used to write software, including desktop, mobile, and web apps. A scripting language is a type of programming language designed for automating tasks, often within another environment (like a web browser or server).So yes — PHP is a programming language, and specifically a scripting language, because it runs on the server to automate the generation of web content.

PHP in Action:

Here’s a very basic example of PHP in an HTML page:

<!DOCTYPE html>
<html>
<head>
  <title>Example</title>
</head>
<body>
  <?php echo "Hi, I'm a PHP thing!"; ?>
</body>
</html>

In this example:
You see regular HTML.
Inside it, there’s a special block that begins with <?php and ends with ?>.
Inside that block is the PHP code — in this case, echo is used to output a message.
Rather than writing lots of commands to output HTML (like in C or Perl), you just embed the PHP directly into your HTML.

How Does PHP Actually Work?

When someone visits a webpage written in PHP, here’s what happens:

The visitor’s browser sends a request to the website.
The server executes the PHP code on the backend (the visitor doesn’t see this).
The PHP code generates output, usually HTML.
The server sends the resulting HTML to the browser.

The user never sees the PHP code — they only see the final result.

This makes PHP great for creating dynamic content, like blog posts, user dashboards, or forms that save data.

What Can PHP Do?

PHP is mainly used in two ways:

1. Server-Side Scripting:

This is the most common use. PHP works with a:

PHP parser (a program that runs your PHP code)

Web server (like Apache)

Web browser

2. Command-Line Scripting:
You can also run PHP in your terminal or command prompt, with no browser needed. This is useful for:

Background tasks (like cron jobs on macOS/Linux)

Simple data processing

Script automation

Cross-Platform Freedom

PHP runs on all major operating systems (Windows, macOS, Linux). You can choose your preferred :

Operating system

Web server (Apache, Nginx, etc.)

Programming style (Procedural or Object-Oriented)

_Procedural vs. Object-Oriented:
Procedural programming: You write code as a sequence of instructions (step by step).

Object-Oriented programming (OOP): You structure your code around objects (like reusable templates for things).
PHP supports both, and you can even mix them if needed._

What Tools Do You Need to Use PHP?
That depends on how you’re using it:

For Command-Line PHP:
You only need to install PHP. That’s it.

For Web Development:
You’ll need a bit more:

PHP
A web server
A database
A browser

To make your life easier, use a tool like XAMPP.

What Is XAMPP?

X (cross-platform): Works on Windows, macOS, Linux

Apache: A web server that delivers your site to the browser

MySQL: A database system (used to store information — kind of like localStorage in JS, but much more powerful and persistent)

PHP: Already included!

Perl: Another scripting language (optional)

Once installed, XAMPP lets you:

Host websites on localhost
Manage databases with phpMyAdmin (a user-friendly dashboard)
Run and test PHP code easily.

How to Deal with APIs in a Cool Way

nedajahanfar — Mon, 23 Jun 2025 08:55:42 +0000

Imagine you’ve built something amazing — a backend, filled with valuable data (like the list of classic poets, maybe?). You’ve stored it somewhere on a server, and now you want the world to access it.
You’ve finished step one: building and hosting your backend.

But here comes step two:

How do people know how to talk to your API?
How do they know what endpoints exist, what data to send, or what they’ll receive back?
That’s where Swagger comes in.

What is Swagger?

Swagger is your API’s guidebook. It’s actually a set of tools built around a format called OpenAPI — a standard way to describe RESTful APIs(explained below).

With Swagger, you get:
A visual, interactive documentation of your API (you’ve seen those websites where you can test the endpoints live? That’s Swagger UI)
A way to describe all the endpoints, input parameters, and response shapes.
Tools to test and simulate API calls.

Basically, Swagger helps you answer:
“How do I interact with this API?”
...without guessing or asking the backend team every five minutes.

What are REST APIs?
APIs (Application Programming Interfaces) let two software pieces talk to each other.

REST APIs (REpresentational State Transfer) are the most common kind. They work using HTTP verbs like:

GET – retrieve data

POST – send new data

PUT – update existing data

DELETE – remove data

So when Swagger documents a REST API, it's just showing:
Here's how to GET /poets,
Here's how to POST /users,
And here’s what the response looks like.

What Is Orval?

Okay, now imagine you're building the frontend app — like a React Native app with Expo.

You read the Swagger doc and think, “Cool, now I know how to call the API.”
But wouldn't it be better if someone just wrote the code for calling the API for you?

That someone is Orval.
Orval:
Takes the Swagger/OpenAPI file
Understands all the endpoints
Generates perfect TypeScript code
Even gives you ready-made React Query hooks like useGetPoets()

So instead of writing boilerplate fetch or Axios calls, you get clean, type-safe, reusable functions.

Bonus: Zod

When using Orval, you can also enable Zod, a TypeScript-first schema validation library.
Zod acts like a gatekeeper at your app’s entrance:
It checks incoming data
If it doesn’t match your expected shape, it blocks it
Prevents bugs and crashes from unexpected responses.

Ps: Why use Zod?

Because TypeScript is only a compile-time tool.

It helps catch errors while you're writing code

But it doesn’t run in your final app

It can’t protect you at runtime

So if you call an API and the server sends broken or unexpected data, TypeScript won’t help.

From React to React Native

nedajahanfar — Fri, 06 Jun 2025 17:30:24 +0000

If you visit the React Native documentation, you'll see the following definition:

“React Native is an open-source framework for building Android and iOS applications using React and the app platform’s native capabilities.”

In simple terms, React Native is a JavaScript framework that allows us to build mobile applications for both ios and Android using the same codebase, similar to how we use React to build web applications.
Back in web development, we had to write code with different browsers in mind, but over time, tools like transpilers (e.g., Babel) helped bridge the gap between different environments. React Native does something similar for mobile: it lets developers write JavaScript that runs across different mobile platforms while rendering native components under the hood.

Performance Evolution:
In its early days, React Native had limitations — it was relatively slow and couldn’t communicate directly with the native (machine-level) code. However, newer technologies have significantly improved its performance:

JSI (JavaScript Interface): Allows direct communication between JavaScript and native code. This gives better performance and unlocks access to native features.

Fabric Renderer: Optimizes rendering to make the UI faster and closer in performance to true native apps.

Hot Reloading: Automatically updates code changes in real-time without rebuilding the app, improving development speed.

Expo: The Toolchain for React Native
Expo is the recommended tool for working with React Native. It acts like Vite or Create React App, but for mobile. It simplifies setup and offers built-in access to APIs like camera, location, and notifications — without needing native code configuration.

React vs. React Native

Similarities:
React Native shares many concepts with React:

JSX Syntax: You still write UI components using JSX.

Component-Based Architecture: You build your UI with reusable components.

JavaScript & Hooks: Logic and state management are the same.

Differences:

The key difference lies in core components. Instead of HTML elements like

`<div>`

`<button>`

, you use mobile-native components such as:

Common React Native Core Components
View: Basic container, similar to <div>
Text: Displays text, like <p>
Image: Display an image
ImageBackground: A container with a background image
TextInput: User input field
ScrollView: Scrollable container(renders all children)-(which can cause performance issues for long lists)
FlatList: Optimized list for large data sets (renders lazily)-(For large lists, use FlatList — it renders only visible items.)
Switch: Toggle switch(boolean on/off)
TouchableOpacity: A pressable component that reduces opacity on touch.
SafeAreaView: Ensures content fits within the safe area boundaries.

Styling in React Native

React Native does not use CSS files. Instead, styles are written in JavaScript using a special syntax:

Two main ways to style:

Inline styles:

`<View style={{ backgroundColor: 'blue', padding: 10 }} />`

2.StyleSheet API:

`const styles = StyleSheet.create({
  box: { backgroundColor: 'blue', padding: 10 }
});`

You can also use libraries like nativewind to write Tailwind-like utility classes in React Native(NativeWind is a library that brings Tailwind CSS utility classes to React Native. It lets you style your components using class names (e.g., className="bg-blue-500 p-4"). It's built on top of the [StyleSheet API] and works well with Expo.)

Routing in React Native:
React Native does not use traditional HTML routing (). Instead, it uses a library called react-navigation, which lets you manage navigation stacks like screens or tabs.
react-navigation, lets you define screen stacks (like web routes) using Stack.Navigator, Tab.Navigator, etc. Each screen is a component, and you use navigation.navigate('ScreenName') to move between them.

CSS in React - What Really Happens When You Import Styles And How to Keep Them Scoped-

nedajahanfar — Mon, 26 May 2025 09:02:15 +0000

Default CSS Behavior in React (Global CSS):
When you import a .css file like this (anywhere in your code)

import './App.css';

That CSS is applied globally across your React application.
Why? because CSS files are simply stylesheets , once they are loaded the browser applies them globally to all matching selectors in the DOM , ( even if you import ComponentA.css inside ComponentA, the styles can still "leak" into ComponentB if they share class names or tag selectors.)

Then Why Import CSS at the Component Level?
Purely for organization and developer clarity.(This makes it easier to find and manage styles related to each component, even though technically the styles are still global.)

Isolated CSS: How to Prevent Style Leakage

But can we scope css to a specific component , so it does not affect the rest of the app?? The answer is YES.

CSS Modules (Recommended & Simple): CSS Modules allow you to write CSS that’s scoped to the component where it's imported. Instead of global class names, they generate unique class names automatically — so there are no naming conflicts or style leaks.

You rename your file to :

Button.module.css

Then in your React component:
`
import styles from './Button.module.css';

function Button() {
return Click Me;
}`

Now, styles.primary is a unique, scoped class name (e.g., _Button_primary_abc12388) generated automatically.

Styled Components / Emotion (CSS-in-JS):

Styled Components is a popular CSS-in-JS library. It lets you write CSS inside your JavaScript and attach it directly to components. Styles are scoped automatically and can dynamically change based on props, themes, etc.

import styled from 'styled-components';

const Button = styled.button`
  background-color: blue;
  color: white;
`;

function App() {
  return <Button>Click Me</Button>;
}

Key Insight:
In default React setup, all imported CSS is global, even if you import it inside a component. Use CSS Modules or CSS-in-JS to isolate styles.

Event Handler Behavior in React vs HTML

nedajahanfar — Sat, 24 May 2025 13:23:35 +0000

In HTML , when you write this :
<button onclick="handleClick()">Click me</button>

The browser sees the string "handleClick()" and stores it as text inside the element.

It does not run it immediately — it waits for the user to click.

When the click happens, the browser reads the string and executes it like code.
So:

** The function call is stored as a string, not as an actual JavaScript command.

It’s only run when the event occurs.
**

In React when you write this :
<button onClick={handleClick}>Click me</button>

**React sees handleClick as a real function reference, not a string.

You are telling React:

“When this button is clicked, call this function.”
**

If you write :

onClick={handleClick()}

You're calling the function immediately during render .
Because the () makes it run now, not later.

In HTML, event handlers are written as strings that are stored inside the element and only run when the event happens.
In React, event handlers are real functions that React keeps track of — so you don’t use () because you don’t want the function to run right away.
If you do need to pass arguments (which requires ()), you wrap the call inside an arrow function so it waits for the event to trigger.

onClick={() => handleClick("hi")}