More than half of UK novelists believe artificial intelligence will eventually replace their work entirely, according to a recent University of Cambridge study reported in The Guardian. The research suggests not only anxiety about technological change, but a deeper concern: that AI systems trained on vast amounts of fiction may fundamentally reshape the literary economy, devalue human writing, and flood the market with machine-generated books.

For many writers, this is no longer a distant speculation. It is already reflected in falling incomes, disputes over copyright, and fears that creative labor is being absorbed into systems trained on unlicensed texts. The question, then, is not simply whether AI can write novels — but what becomes of the novel when it no longer requires a novelist.

Beyond Economics: The Question of Authorship

Novels are not merely written words. They are forms of lived experience structured through language — attempts to translate feeling, memory, imagination, and perception into narrative form.

Most novels emerge from lived experience, or from the imaginative reconstruction of experience: relationships, personal contradictions, social observation, and emotional memory, rather than purely engineered plots or optimized storytelling structures.

This anxiety about authorship is not entirely new. Literary theory has long questioned the idea of the author as the sole origin of meaning. Thinkers such as Roland Barthes and Michel Foucault argued that texts are shaped less by individual intention and more by language, culture, and interpretation. The novel itself has also continually changed across history — from linear realist narratives to modernist stream-of-consciousness and postmodern fragmentation — suggesting that instability, rather than fixed identity, has always been part of the genre.

For example, when readers engage with authors like Haruki Murakami or Virginia Woolf, they are not only following plots. They are engaging with a particular way of seeing the world, a personal rhythm of thought and language, and an implicit human experience behind the text.

In this sense, literature is not just content. It is a form of structured subjectivity — a mind expressed through language. This is why authorship matters in novels in a way it often does not in other media. Readers do not simply want a story; they want a voice that carries meaning.

AI as a Creative Tool

AI is already on the path toward transforming novel writing, but it is unlikely to replace human novelists entirely. Instead, it is more plausible that AI will function as a tool within the creative process — reshaping how stories are drafted, structured, and refined, rather than eliminating the need for human authorship.

AI can already imitate narrative voice convincingly. It can generate emotional dialogue, symbolic plots, and even philosophical themes. For many readers, especially in popular or genre fiction, this may already be “good enough.”

From a market perspective, this creates a realistic scenario: AI produces large volumes of fiction quickly, readers consume stories without concern for authorship, and publishing becomes partially automated.

Evidence of Literary Anxiety

A study conducted for the Minderoo Centre for Technology and Democracy at the University of Cambridge suggests widespread unease about the speed and scale of AI’s advance into the literary world. Surveying 258 published novelists and 74 industry figures, the research found that just over half (51%) of novelists believe AI could eventually replace their work.

Many participants also reported concerns that their writing may already have been used — without permission — to train large language models. Beyond financial anxiety, there is a deeper worry: that the meaning of authorship itself is being quietly eroded.

In this sense, AI may indeed “replace” novelists as producers of content. But replacement in production is not the same as replacement in meaning.

Reading as Relationship

Reading a novel is often misunderstood as passive consumption. In reality, it is closer to a relationship between reader and author.

Readers follow authors over time, interpret recurring themes, and connect works to a perceived personality or life experience. The act of reading becomes a way of engaging with another consciousness.

This is where AI introduces a complication. If there is no lived experience behind the text, what exactly is the reader relating to?

Even if the story is identical, many readers may still distinguish between a human who meant the story and a system that generated it. That difference may not always affect entertainment value, but it affects perceived depth and authenticity.

Personalized Fiction and the End of Shared Texts

The most radical possibility is not AI-written books, but personalized novels. In this model, each reader receives a different version of a story tailored to their preferences, emotions, or even life history.

If this becomes common, literature may lose one of its defining features: the shared text. Two people reading the “same novel” would no longer be reading the same words. At that point, the novel becomes less like a cultural artifact and more like a dynamic simulation of storytelling.

Conclusion: What AI Really Challenges

The question “Can AI replace novelists?” assumes that novels are stable objects and novelists are replaceable producers of those objects. But AI forces us to reconsider both assumptions.

It is likely that AI will replace some forms of commercial storytelling, transform how stories are produced and consumed, and blur the boundary between author and reader. However, it is less clear that it will replace the deeper function of novelists as creators of human perspective.

Ultimately, the issue may not be whether AI can write novels, but whether literature without human intention is still literature in the same sense. In this way, AI does not only challenge novelists — it challenges the idea of authorship itself.

Defining a Novel and Authorship in the Time of AI was originally published in Philosophy Today on Medium, where people are continuing the conversation by highlighting and responding to this story.

I got a lot of claps on my early articles. I was happy to see that people had clapped for my articles on medium. But something didn’t feel right.

Even if they understood my article on basic physics programming, thinking that many beautiful women clapped was probably a bit overconfident.

I don’t know why my first four articles received claps from those accounts. But in my later posts, the number started to decrease. In my most recent article, I got only one from a similar account.

Yes, they are all just bots, as explained in the article ‘Are Some “Followers” Bots’. Now the question is, how can we trigger them to clap for our articles?

Are Some “Followers” Bots

It’s fascinating to observe the behavior of these automated accounts. They mimic engagement like real readers but without genuine understanding or intent. Some of them may be semi-automated accounts that seem to ‘train’ on your articles manually, producing outrageously long, AI-style comments that try to sound thoughtful and meaningful.

For me, as someone who loves talking with chatbots, I was excited to see even a bot clap for my post or leave an AI-generated comment. But if you’re a real human reading this, feel free to leave a comment, and I’ll follow you if you’re already following me.

Will those bots clap for this post? In my early posts, those bots started giving claps within 2–3 days.

I drank the holy water.

At least, that’s what they told me it was.

They said it came from a sacred place, carried across continents in plastic bottles that felt heavier than they should. Not because of the minerals — but because of expectation. One sip, and maybe the soul reboots. One gulp, and maybe the bugs disappear.

Spoiler: I was still running sinner.exe.

It made me think about Jonah.

People love the whale part. The drama. The storm. The lottery on the ship. The cinematic moment when he gets thrown into the sea like unwanted cargo.

But the real trouble with Jonah wasn’t the ocean.

It was orbit.

He was assigned to a people who wouldn’t listen. Imagine speaking truth into a wall of polite indifference. Imagine warning about consequences while everyone scrolls past you. At some point, he left. Not because he stopped believing — but because he was tired of being a satellite.

You know how it feels to orbit something that doesn’t see you?

In astronomy, a star shines by itself. A satellite doesn’t. It circles, reflects, depends. It lives in gravitational obedience. If the star collapses, the satellite drifts into cold silence.

Maybe Jonah was tired of orbiting a mission that felt like it had no light.

So he boarded a ship.

And the sea — that ancient debugger — responded.

The storm wasn’t random. It was interruption. A cosmic pop-up window:

“Are you sure you want to quit?”

They cast lots. His name surfaced. Into the water he went.

We always imagine punishment. But what if it was containment?

Inside the belly of the great creature, in darkness so complete it erased ego, Jonah finally stopped orbiting his frustration. There was no audience. No crowd. No metrics. No applause. No rejection.

Just him.

And God.

No star. No satellite. Just gravity.

He didn’t negotiate. He didn’t justify. He didn’t blame the people.

He said:

“I was wrong.”

That was the update.

Not the water.
Not the storm.
Not the fish.

The update was surrender.

When he was returned to land, it wasn’t random geography. It was the same mission. The same people. The same city.

But a different orbit.

And this time, something changed.

The people listened.

Maybe the real miracle wasn’t survival inside a fish. Maybe it was this: the star and the satellite finally aligned.

We spend our lives confused about what we are.

We want to be stars — self-burning, self-sufficient, undeniable.
But most of the time, we are satellites — reflecting borrowed light, circling meaning, hoping not to drift.

And sometimes we run.

We swap routines for distractions.
We ignore obligations.
We call it “self-care.”
We rename avoidance as wisdom.

Trouble with Jonah isn’t about a prophet and a fish.

It’s about us.

It’s about the moment we mistake exhaustion for permission.
It’s about thinking distance will fix disobedience.
It’s about believing holy water will cleanse what only surrender can transform.

I drank the holy water.

It didn’t rewrite my destiny.
It didn’t delete my flaws.
It didn’t silence the storm.

But it reminded me of something:

You can’t hydrate your way out of responsibility.

Sometimes the sea is mercy.
Sometimes the belly is protection.
Sometimes being thrown overboard is how you’re thrown back into purpose.

Maybe you’re not a failed star.

Maybe you’re just a satellite that forgot what it’s orbiting.

And maybe — just maybe — 
the trouble with Jonah
is the trouble with all of us.

The Trouble With Jonah was originally published in Write Your World on Medium, where people are continuing the conversation by highlighting and responding to this story.

Eigenvectors show up everywhere: Principal Component Analysis (PCA), dimensionality reduction, spectral methods, and even the internal stability analysis of neural networks.

Eigenfaces (PCA-based) method is mostly no longer used in modern production face-recognition systems, but it is still very important educationally and sometimes used in lightweight or research scenarios.

Most explanations lean heavily on dense linear algebra. This one focuses on intuition first.

The Core Idea: Stability in Motion

An eigenvector is a direction that stays the same when data is transformed. While the data around it might stretch or shrink, that specific direction remains fixed.

What “Transformation” Means in AI

In machine learning, data is constantly being manipulated through matrix operations:

• Feature Scaling: Stretching or squishing data ranges
• Rotation/Projection: Shifting how we look at data points to find patterns
• Compression: Squashing high-dimensional data into fewer dimensions

When a matrix transforms your data, most directions shift and tilt. However, a few specific directions remain perfectly aligned with their original path. Those stable directions are your eigenvectors.

Eigenvalues: The “Volume” Knob

If the eigenvector is the direction, the eigenvalue is the magnitude. It tells you how much the data is being stretched or squished along that specific eigenvector.

• Large Eigenvalue: This direction captures a lot of information (variance). It’s a “loud” signal
• Small Eigenvalue: This direction captures very little and might just be “noise.”

Real-World Use Cases in Machine Learning

Principal Component Analysis (PCA)

PCA is the most famous application of eigenvectors. It uses them to:

• Identify the most informative “paths” through a cloud of data
• Reduce the number of features without losing the “soul” of the dataset
• Pro Tip: In PCA, the “Principal Components” are simply the eigenvectors of the data’s covariance matrix

Data Compression

Images and audio contain massive amounts of redundant info. Eigenvectors help systems:

• Preserve the underlying structure (the “edges” of an image)
• Discard the unnecessary fluff, allowing for efficient storage without destroying meaning

Neural Network Stability

Behind the scenes, neural networks are massive stacks of matrix multiplications. Researchers use eigenvectors to:

• Analyze training stability (preventing gradients from exploding or vanishing)
• Understand how information moves through layers
• SVD (Singular Value Decomposition): A cousin of eigen-decomposition used in recommendation systems (like Netflix) to find hidden patterns in user behavior

Example: Seeing the Math in Action

The best way to understand this is to see it. Using Python’s NumPy library, we can visualize how an eigenvector refuses to "tilt" even when the space around it is warped.

Python Code:

import numpy as np
import matplotlib.pyplot as plt

# 1. Define a transformation matrix (Shear and Stretch)
A = np.array([[2, 1], 
              [1, 2]])
# 2. Calculate Eigenvalues and Eigenvectors
eigenvalues, eigenvectors = np.linalg.eig(A)

# 3. Setup the visualization
origin = [0], [0]
fig, ax = plt.subplots(figsize=(6, 6))

# Define a "random" vector (this will change direction)
v_random = np.array([1, 0])
v_random_transformed = A @ v_random

# Define an eigenvector (this should stay on its path)
v_eig = eigenvectors[:, 0]
v_eig_transformed = A @ v_eig

# 4. Plotting
ax.quiver(*origin, v_random[0], v_random[1], color='r', angles='xy', scale_units='xy', scale=1, label='Random Vector')
ax.quiver(*origin, v_random_transformed[0], v_random_transformed[1], color='salmon', angles='xy', scale_units='xy', scale=1, label='Transformed Random')
ax.quiver(*origin, v_eig[0], v_eig[1], color='b', angles='xy', scale_units='xy', scale=1, label='Eigenvector')
ax.quiver(*origin, v_eig_transformed[0], v_eig_transformed[1], color='skyblue', angles='xy', scale_units='xy', scale=1, label='Transformed Eigenvector')
plt.xlim(-1, 5); plt.ylim(-1, 5); plt.grid(True, linestyle='--')
plt.legend(); plt.title("Visualizing Eigenvectors: Directional Stability")
plt.show()

How to Read This Result

In the code above, we solve the fundamental equation:

• The Red Vector: It was pointing straight right, but after the transformation, it tilted upward. It “lost” its original direction
• The Blue Vector (Eigenvector): It stays on its original diagonal path. It only grew longer (scaled by its eigenvalue)

Mental Models for Mastery

The Spinning Globe

Picture a spinning globe.

• The Movement: Almost every point on the surface is moving in a circle
• The Eigenvector: The axis running from the North Pole to the South Pole. Despite the rotation, the axis itself stays fixed
• The Eigenvalue: The speed of the spin. A faster spin means a larger eigenvalue for that transformation

The “Skeleton” of Data

Imagine a cloud of points representing the height and weight of 1,000 people. The points will form an elongated oval shape.

• The long axis of that oval is an eigenvector. It shows the direction of the most variation
• The short axis is another eigenvector
• In AI, we often “throw away” the short axis to simplify our model, keeping only the “main” eigenvectors that hold the most information

Eigenvectors in Modern AI Systems

Even though modern deep learning systems are extremely advanced, eigenvector-based ideas still play essential roles across many areas of AI.

Dimensionality Reduction
PCA uses eigenvectors of covariance matrices to compress datasets while preserving the most important information. This remains a standard preprocessing and analysis tool.

Computer Vision
While classical methods like Eigenfaces are mostly no longer used in production face-recognition systems, eigenvector analysis is still fundamental to feature extraction, representation learning, and understanding visual variation in data.

Graph Learning
Spectral clustering and graph neural networks rely on eigenvectors of graph Laplacians to reveal structure, connectivity, and communities within graphs.

Optimization and Training Stability
Eigenvalues of Hessian and Jacobian matrices are used to analyze curvature, convergence behavior, and training stability in deep neural networks.

Eigenvectors quietly guide how machine learning models represent structure, stability, and meaningful variation in complex data , even when they are no longer explicitly visible in the final algorithms.

A Real-World Example: Face Recognition (Eigenfaces)

One of the most famous applications of eigenvectors is face recognition, often called the Eigenfaces method.

Suppose we collect thousands of face images. Each image may contain hundreds of thousands of pixel values, meaning that directly comparing two faces requires processing extremely large vectors. When a system must compare a new face against thousands or millions of stored images, raw-pixel comparison becomes computationally expensive and highly sensitive to noise such as lighting changes, facial expressions, or small pose differences.

Instead of working directly with raw pixels, we compute eigenvectors from the entire face dataset. These eigenvectors capture the main facial variation patterns across all faces, such as:

• Eye regions
• Nose structure
• Face outlines
• Lighting and shadow patterns

Each face can then be represented not by hundreds of thousands of pixel values, but by a small set of coefficients describing how strongly the face aligns with each eigenvector pattern. Recognition systems compare these compact representations rather than full images, making face matching much faster, more memory-efficient, and more robust.

Simple Example Code (Eigenfaces Concept)

Below is a simplified conceptual Python example showing how eigenvectors are used for face recognition using PCA:

import numpy as np
from sklearn.decomposition import PCA
from sklearn.datasets import fetch_olivetti_faces

# 1. Load dataset
faces = fetch_olivetti_faces()
X = faces.data   # each row = flattened face image

# 2. Reduce dimensionality using eigenvectors (PCA)
pca = PCA(n_components=100, whiten=True)
X_reduced = pca.fit_transform(X)

# 3. Reconstruct a face using eigenvectors
reconstructed = pca.inverse_transform(X_reduced)

print("Original shape:", X.shape)
print("Reduced representation:", X_reduced.shape)

In this example:

• PCA computes the eigenvectors of the face dataset
• Each face is converted into a much smaller vector representation
• Recognition systems compare these compact representations instead of full images

This dramatically improves speed while preserving important facial information.

A Real Eigenfaces Example Using Actual Photos

Below is a minimal but real example showing how Eigenfaces-style recognition works with real face images using OpenCV and PCA.

Assume your dataset is organized like this:

import cv2
import numpy as np
import matplotlib.pyplot as plt
from sklearn.datasets import fetch_lfw_people
from sklearn.decomposition import PCA
from sklearn.preprocessing import StandardScaler

# 1. Load dataset from internet
lfw = fetch_lfw_people(min_faces_per_person=20, resize=0.4)

X = lfw.data                # flattened images
y = lfw.target              # labels
label_map = lfw.target_names

print("Dataset shape:", X.shape)

# 2. Normalize pixel values
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)

# 3. PCA (Eigenfaces)
n_components = 100
pca = PCA(n_components=n_components, whiten=True, random_state=42)
X_pca = pca.fit_transform(X_scaled)

print("PCA shape:", X_pca.shape)

# 4. Select a test image
test_index = 0
test_img = X[test_index]
true_label = y[test_index]

test_scaled = scaler.transform([test_img])
test_pca = pca.transform(test_scaled)

# 5. Find closest match
distances = np.linalg.norm(X_pca - test_pca, axis=1)
match_index = np.argmin(distances)

print("True person   :", label_map[true_label])
print("Matched person:", label_map[y[match_index]])

# 6. Show the test image
plt.imshow(test_img.reshape(lfw.images[0].shape), cmap='gray')
plt.title("Test Image")
plt.axis('off')
plt.show()

In this real-world pipeline:

• Eigenvectors (Eigenfaces) form a compact facial basis
• Each face becomes a short numerical signature
• Recognition compares faces in eigenvector space, not pixel space

This is why eigenvectors were powerful enough to enable early, practical face recognition systems, long before modern deep learning models existed.

The Hidden Skeleton Analogy

Think of machine learning models as living organisms. Data is the flesh, algorithms are the muscles, and eigenvectors are the skeleton , the hidden structure that determines shape, stability, and movement.

You rarely see the skeleton directly, but without it, nothing functions properly.

Final Thought

Eigenvectors help machine learning models understand what really matters in complex data. They don’t just describe numbers , they reveal the structure. Once you see them as the “skeleton” of your data, the confusion fades and their importance in AI becomes clear.

Eigenvectors Explained: The Hidden Skeleton of AI and Machine Learning was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re going to take some glTF models and build our own interactive viewer with Three.js — so you can show 3D content on a website just as easily as you’d drop in an image.

Before we start experimenting with glTF viewers in Three.js, you might want to check out my previous posts: “Which Is Easier for Rendering GLB Models: Three.js or Babylon.js?” and “Loading a 3D Model in the Browser Using JavaScript FileReader”. Those articles cover the basics of loading 3D files and comparing rendering engines, which will give you some helpful background as we dive into building our own glTF viewer.

After comparing, I found that Babylon.js is actually easier to use and requires less code, but Three.js gives me more control, which lets me build a glTF viewer that’s more user-friendly. That’s why I decided to use Three.js to create this web-based glTF viewer.

The first thing I had to figure out was how to get a .gltf or .glb file into the browser so I could render it. As I explained in my previous post, “Loading a 3D Model in the Browser Using JavaScript FileReader”, I can use JavaScript’s FileReader for this.

Building the Viewer Core

With the FileReader handling the file upload, the next step is bringing that data into a 3D environment. To do this, I used Three.js to build a scene that acts like a virtual stage, a camera to act as our eyes, and a renderer to draw everything onto the screen.

Setting the Scene

This block creates the “world” where your 3D models live.

const scene = new THREE.Scene();
scene.background = new THREE.Color(0x121212);

const camera = new THREE.PerspectiveCamera(45, window.innerWidth / window.innerHeight, 0.1, 1000);
camera.position.set(0, 1.5, 12);

const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(window.innerWidth, window.innerHeight);
document.body.appendChild(renderer.domElement);

controls = new OrbitControls(camera, renderer.domElement);
controls.enableDamping = true;

// Ensure the camera is looking at the center of the scene (or slightly below)
controls.target.set(0, 1.5, 0); 
controls.update(); // Required after manually changing camera/target

The Scene

The Scene is your virtual stage. We set the background to a dark color to make the models pop.

The Camera

The PerspectiveCamera mimics the human eye—objects get smaller as they move further away, which makes the 3D space feel real.

The Renderer

This is the engine that draws the pixels. Enabling antialias ensures that the edges of your models are smooth and crisp, rather than "jaggy."

Lighting and Interaction

Without light, 3D objects are just black silhouettes. Without controls, you can’t explore the model.

scene.add(new THREE.AmbientLight(0xffffff, 1.5));

const light = new THREE.DirectionalLight(0xffffff, 2);
light.position.set(5, 10, 7.5);
scene.add(light);
const controls = new OrbitControls(camera, renderer.domElement);
controls.enableDamping = true;

The Lights

I used two types: AmbientLight provides a soft glow so no part of the model is pitch black, and DirectionalLight acts like the sun to create depth, shadows, and highlights.

The Controls

OrbitControls allows the user to rotate the model by dragging and zoom in with the scroll wheel. enableDamping adds a bit of "inertia," making the movement feel smooth and professional.

The GLTFLoader and Auto-Centering

This part takes the raw file data and turns it into a visible object, ensuring it’s positioned correctly.

const loader = new GLTFLoader();

loader.parse(result, '', (gltf) => {
    currentModel = gltf.scene;
    scene.add(currentModel);
    // Center and scale model automatically
    const box = new THREE.Box3().setFromObject(currentModel);
    const center = box.getCenter(new THREE.Vector3());
    currentModel.position.sub(center);
});

The Loader

The GLTFLoader is the translator. It takes the binary data from the FileReader and builds a Three.js group of meshes.

The Bounding Box logic

Because every 3D model is built at a different scale or offset, I used Box3 to measure the model's physical dimensions. By calculating the center and subtracting it from the model's position, the code ensures the object always appears in the middle of the screen.

Bringing it to Life with Animations

glTF models often come with built-in movements. This logic detects them and lets the user play them.

if (animations.length > 0) {
    mixer = new THREE.AnimationMixer(currentModel);
    const action = mixer.clipAction(animations[0]);
    action.play();
}

The Animation Mixer

Think of the AnimationMixer as a digital DJ. It coordinates all the moving parts (the "bones") of the model according to the clock.

ClipAction

This represents a specific movement. If the loader finds animations, it creates a “player” for them and starts the first one automatically.

The Render Loop

3D isn’t a static image; it’s a series of frames updated so fast it looks like video.

const clock = new THREE.Clock();

function animate() {
    requestAnimationFrame(animate);
    
    if (mixer) mixer.update(clock.getDelta());
    controls.update();
    renderer.render(scene, camera);
}

The Loop

requestAnimationFrame tells the browser to run this function roughly 60 times every second. When we talk about “60 times every second,” we are describing the FPS (Frames Per Second).

Updating State

In every single frame, we tell the mixer (for movement) and controls (for mouse dragging) how much time has passed using the clock. Finally, renderer.render draws the updated view of the stage through the camera lens.

The UI Development Part

After dealing with JavaScript, let’s move on to the CSS and HTML sections. We made the UI simple, where the user is given the option to drag a glTF file or open a folder here.

The CSS code:

<style>
    html, body { width: 100%; height: 100%; margin: 0; overflow: hidden; font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif; background-color: #121212; }
    canvas { width: 100%; height: 100%; display: block; }
    
    /* Landing Overlay (Matches your image) */
    #landing-overlay {
        position: fixed;
        top: 0; left: 0;
        width: 100%; height: 100%;
        background-color: #121212;
        display: flex;
        flex-direction: column;
        align-items: center;
        justify-content: center;
        z-index: 100;
        color: #888;
    }

    .drop-box {
        width: 400px;
        height: 150px;
        background: #1e1e1e;
        border-radius: 8px;
        display: flex;
        align-items: center;
        justify-content: center;
        font-size: 1.2rem;
        margin-bottom: 20px;
        border: 2px dashed transparent;
        transition: border 0.3s ease;
    }

    /* Visual feedback when dragging over the window */
    body.drag-active .drop-box {
        border-color: #1a73e8;
        color: #1a73e8;
    }

    .choose-file-btn {
        background: transparent;
        color: #888;
        border: none;
        cursor: pointer;
        display: flex;
        align-items: center;
        gap: 8px;
        font-size: 1rem;
    }
    .choose-file-btn:hover { color: #fff; }

    /* Controls Panel (Hidden until model loads) */
    .controls-panel {
        position: absolute; 
        top: 15px; right: 15px;
        z-index: 10;
        display: none; /* Hidden initially */
        flex-direction: column; 
        gap: 10px;
        align-items: flex-end;
        background: rgba(255, 255, 255, 0.9); 
        padding: 15px;
        border-radius: 8px; 
    }

    .anim-section { display: none; flex-direction: column; gap: 5px; border-top: 1px solid #ccc; padding-top: 10px; text-align: right; }
    select { padding: 8px; border-radius: 4px; border: 1px solid #ccc; }
    label { font-size: 11px; color: #555; font-weight: bold; }
  </style>

The HTML code:

<div id="landing-overlay">
    <div class="drop-box">
        Drag glTF 2.0 file here
    </div>
    <button class="choose-file-btn" onclick="document.getElementById('fileInput').click()">
        <span>⬆</span> Choose file
    </button>
</div>

<div class="controls-panel" id="uiPanel">
  <button style="padding: 8px 12px; background: #1a73e8; color: white; border: none; border-radius: 4px; cursor: pointer;" onclick="document.getElementById('fileInput').click()">Upload New</button>
  
  <div id="animContainer" class="anim-section">
    <label for="animSelect">ANIMATIONS</label>
    <select id="animSelect">
      <option value="-1">Static Pose</option>
    </select>
  </div>
</div>

When the user uploads a model with animation data, a dropdown is also shown to select the animation to play or to display the model in a static pose.

That’s it for now. Maybe you can improve the UI or fix the bug that happens when uploading a model that’s too big or something. Let’s start experimenting and make it better!

Live preview:

Three.js GLB Viewer

The full source code is available on my GitHub account, where you can explore, modify, and experiment.

GitHub - noryx-studio/gltf-viewer

For more tutorials and code examples, you can follow my GitHub account to keep learning, building your own projects, and supporting me!

Thank you for reading!

If you have any questions, feel free to ask — I’d be happy to explain more.

Build Your Own glTF Viewer with Three.js was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

At first, this can feel like a missing feature—but it’s actually a deliberate design choice. Python handles constants differently.

Python doesn’t have a const keyword by design, not because it’s missing a feature. It takes a different approach from languages that include const. Python’s philosophy is to be a simple, expressive tool for solving problems, rather than a language that exposes every possible control mechanism, as seen in more complex languages like C++.

The Confusion Around const

In JavaScript, const is often used to protect a variable from reassignment.

const x = 10
x = 20 // Error: Assignment to constant variable

At first glance, it looks like const makes values completely unchangeable.

However, objects behave differently.

const numbers = [1, 2, 3]
numbers.push(4)   // Allowed, array is mutable
numbers = [5, 6]  // Error: cannot reassign

This shows an important distinction.

const protects the variable binding, not the object it refers to.

Python makes this distinction explicit and builds its model around it.

Python’s Core Idea: Names and Objects

Python does not think in terms of variables holding values. Instead, it works with names and objects.

• Names point to objects
• Objects define whether their contents can change

x = 10

In this example:

• x is a name
• 10 is an object

Rebinding a name is always allowed.

x = 20

This behavior is intentional. Reassignment is explicit and easy to reason about.

Mutable vs Immutable — The Key Concept

Understanding mutability is essential to understanding why Python does not need const. For a more complete example, you can see it here.

• Immutable objects cannot be changed after creation. Any operation that appears to modify them actually creates a new object
• Mutable objects can be changed in place. Modifying them affects the original object

For example, if we use JavaScript:

// Immutable example: strings
let text = "hello"
text[0] = "H"
console.log(text) // "hello"

// Mutable example: arrays
const numbers = [1, 2, 3]
numbers.push(4)
console.log(numbers) // [1, 2, 3, 4]

In Python, the behavior is similar.

# Immutable: strings
s = "hello"
# s[0] = "H"  # Error: strings are immutable

# Mutable: lists
numbers = [1, 2, 3]
numbers.append(4)

Most bugs that const is meant to prevent come from mutable objects, not from reassignment itself.

How Constants Work in Python

Python uses naming conventions instead of enforced constants.

PI = 3.14159
MAX_RETRIES = 5

Uppercase names communicate intent. They tell other developers that these values should not be reassigned.

Python relies on discipline and readability rather than strict enforcement. In practice, this works well.

Protecting Mutable Data

Problems usually appear when a value is intended to be constant but refers to a mutable object.

CONFIG = {"debug": True}
CONFIG["debug"] = False

This is allowed because:

• CONFIG is only a name
• The dictionary is mutable

Ways to reduce accidental changes:

• Pass copies of objects to functions
• Use immutable types such as tuples or frozensets
• Use MappingProxyType to create read-only dictionary views

Passing Values to Functions Safely

Immutable values are safe by default.

def add_one(x):
    x += 1

n = 10
add_one(n)
print(n)  # 10

Mutable values can be modified unintentionally.

def add_item(items):
    items.append(4)

numbers = [1, 2, 3]
add_item(numbers)
print(numbers)  # [1, 2, 3, 4]

Protecting Data

Copy the object before modifying it.

def add_item(items):
    items = items.copy()
    items.append(4)
    return items

Or use immutable data structures.

def add_item(items):
    return items + (4,)

numbers = (1, 2, 3)

Optional: Static Warnings With Final

Python provides optional static hints using Final.

from typing import Final

PI: Final = 3.14159

This does not prevent runtime changes. It only helps tools like linters and editors warn about unintended reassignment.

Why Python’s Approach Works

Python is built on a few simple assumptions:

• Reassigning names is usually harmless
• Mutating objects is where most bugs appear
• Clear and explicit code is better than hidden restrictions

Immutable types, naming conventions, and straightforward patterns remove most of the need for a const keyword.

Controlling Shared State with deepcopy

Most of the confusion around const actually comes from mutable objects, not from reassignment. The real problem is shared state. When two names refer to the same mutable object, changing it through one name affects the other unexpectedly.

a = [1, 2, 3]
b = a

b.append(4)
print(a)  # [1, 2, 3, 4]

Even if the name a is intended to stay constant, the object it points to can still be changed. This is why Python does not rely on const. A keyword that prevents rebinding would not stop this kind of bug.

Python gives you explicit tools to control this behavior. The copy module lets you make a new, independent object. A shallow copy duplicates the outer container but keeps references to the inner objects. A deep copy duplicates everything recursively, breaking all shared references.

import copy

a = [[1, 2], [3, 4]]
b = copy.deepcopy(a)
b[0].append(99)

print(a)  # [[1, 2], [3, 4]]
print(b)  # [[1, 2, 99], [3, 4]]

This makes the behavior obvious: mutation only affects the objects you explicitly choose to change. Nothing happens behind the scenes. Python prefers this explicit approach over hidden rules or language-enforced constants.

Takeaways

This design makes Python a simple and expressive tool for most problems. At the same time, it can feel limiting in situations that require very fine-grained control over objects and memory — the kind of control exposed by more complex languages like C++. In Python, understanding the difference between mutable and immutable objects is essential.

How Python Solves const Without a const Keyword was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was alone.

The forest stretched in every direction, layered with palms and dense vegetation, like a massive open-world map rendered in high detail. Trees stood still, the sky washed in pale light.

The path to Ceheng Waterfall was quiet in a way that didn’t ask for attention. It just existed. Trees lined the hills, layered in different shades of green, stretching farther than the eye could follow. Everything looked alive, yet strangely still.

The forest felt like a world that had already loaded.

There were signs that people had been here before — a narrow trail, a small concrete structure near the path — but nothing moved now. No voices carried through the air. No footsteps followed behind.

Walking through it felt familiar, like exploring an open-world game before the story begins.

The environment is detailed, complete, and waiting — but nothing happens unless you move. Every sound suddenly feels louder when there’s nothing else competing with it.

Leaves shifted slightly in the breeze, as if it would continue the same way whether anyone was there or not.

That was the strange comfort of it.

For a brief moment, the world felt simple: just a path, a landscape, and the act of being present inside it.

Some places feel most real when they’re quiet.

And for a moment, this one felt like an empty map — complete, silent, and enough.

The sound of water gradually grew clearer.

Somewhere along the path, the search stopped mattering. I kept moving without checking anything, letting instinct lead instead of signs.

Dirt on my shoes, sweat on my skin, no rush to arrive. If the waterfall wanted to show itself, it would. And if it didn’t, that was fine too.

Ceheng Waterfall didn’t feel abandoned. It felt untouched — like a place that didn’t need an audience to exist.

The absence of movement didn’t create tension; it created space. Space to notice small details. Space to slow down. Space to breathe without being pulled in any direction.

Writers, We’d love to have you!!! Join us and share your stories. Let’s Publish it.

No Time — Publication

Ceheng Waterfall Felt Like an Empty Game Map was originally published in No Time on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous article, we discussed how using a struct in C++ can make code simpler because members are public by default. This is especially convenient for simple data containers like a Point or a Node in a linked list.

For example, a basic linked list node using a struct can look like this:

struct Node {
    int data;
    Node* next;
};

Creating and linking nodes is straightforward:

Node* head = new Node{10, nullptr};
Node* second = new Node{20, nullptr};
head->next = second;

Everything is simple, readable, and easy to follow.

So Why Does Hackerrank Use Classes and Look More Complex?

Hackerrank’s linked list template can look complicated at first, especially compared to a simple struct-based linked list:

class SinglyLinkedListNode {
public:
    int data;
    SinglyLinkedListNode* next;
    SinglyLinkedListNode(int node_data) {
        this->data = node_data;
        this->next = nullptr;
    }
};

class SinglyLinkedList {
public:
    SinglyLinkedListNode* head;
    SinglyLinkedListNode* tail;

    SinglyLinkedList() {
        this->head = nullptr;
        this->tail = nullptr;
    }

    void insert_node(int node_data) {
        SinglyLinkedListNode* node = new SinglyLinkedListNode(node_data);
        if (!this->head) this->head = node;
        else this->tail->next = node;
        this->tail = node;
    }
};

At first glance, it seems more complex than necessary. The design, however, has specific purposes.

Object-Oriented Style

Hackerrank uses classes to follow object-oriented programming principles. The SinglyLinkedList class encapsulates the logic of the list by automatically tracking the head and tail pointers. The insert_node method ensures nodes are inserted correctly without manually adjusting pointers. Even though the node’s data and next pointer are public, the class separates list operations from individual nodes. This approach makes the code more consistent and professional, especially for teaching and automated testing.

Constructors for Safe Node Initialization

The constructor in SinglyLinkedListNode guarantees that every node starts with its next pointer set to null:

SinglyLinkedListNode(int node_data) {
    this->data = node_data;
    this->next = nullptr;
}

Without a constructor, you would need to manually initialize the next pointer each time. Constructors reduce repetitive code and make node creation safer.

Automatic Tail Management

Storing a tail pointer in the SinglyLinkedList class allows insertion at the end of the list in constant time. Without the tail pointer, adding a node would require traversing the entire list, which is less efficient and more error-prone.

Using Structs Instead of Classes

Structs in C++ can have constructors, methods, and member functions just like classes. The main difference is that struct members are public by default. The same linked list can be implemented with structs:

#include <iostream>
using namespace std;

struct SinglyLinkedListNode {
    int data;
    SinglyLinkedListNode* next;

    // Constructor
    SinglyLinkedListNode(int node_data) {
        data = node_data;
        next = nullptr;
    }
};

struct SinglyLinkedList {
    SinglyLinkedListNode* head;
    SinglyLinkedListNode* tail;

    // Constructor
    SinglyLinkedList() {
        head = nullptr;
        tail = nullptr;
    }

    // Insert node at the end
    void insert_node(int node_data) {
        SinglyLinkedListNode* node = new SinglyLinkedListNode(node_data);
        if (!head) head = node;
        else tail->next = node;
        tail = node;
    }
}; 

int main() {
    SinglyLinkedList list;
    list.insert_node(10);
    list.insert_node(20);
    list.insert_node(30);

    SinglyLinkedListNode* current = list.head;
    while (current) {
        cout << current->data << endl;
        current = current->next;
    }

    // Free memory
    current = list.head;
    while (current) {
        SinglyLinkedListNode* temp = current;
        current = current->next;
        delete temp;
    }

    return 0;
}

This struct-based version behaves exactly the same as the class version, but it is simpler and easier to read.

Can We Print Data from the Simplest Linked List Version Like in HackerRank?

A question that comes to mind is: can we add data and print it using the simplest version of a linked list, like this?

struct Node {
    int data;
    Node* next;
};

Yes, we can, simply by using a function like this to add the data:

void insertNode(Node*& head, int data) {
    Node* newNode = new Node();
    newNode->data = data;
    newNode->next = nullptr;

    // If the list is empty
    if (head == nullptr) {
        head = newNode;
        return;
    }

    // Traverse to the end
    Node* temp = head;
    while (temp->next != nullptr) {
        temp = temp->next;
    }

    temp->next = newNode;
}

The *& combination is actually two things:

1. * → This is part of Node*, meaning “pointer to Node.” So Node* head is a pointer to a node.
2. & → This means we are passing the pointer by reference.

Why do we need & here?

If we wrote it like this:

void insertNode(Node* head, int data)

• head is passed by value, which means a copy of the pointer is made.
• If the list is empty (head == nullptr) and we try to assign head = newNode;, it would only change the copy inside the function.
• The original head in main() would remain nullptr.

Example:

Node* head = nullptr;
insertNode(head, 10); // head stays nullptr if we don't use &!

By using Node*& head, we are passing the pointer itself by reference, so any changes to head inside the function affect the original pointer in main().

Quick analogy

• Node* head → You have a copy of the address of the first node.
• Node*& head → You have a reference to the original address variable, so you can change where it points.

Without &, you’d have to return the new head:

Node* insertNode(Node* head, int data) {
    Node* newNode = new Node();
    newNode->data = data;
    newNode->next = nullptr;

    if (!head) return newNode; // return new head
    
    Node* temp = head;    
    while (temp->next != nullptr) temp = temp->next;
    temp->next = newNode;
    
    return head;
}

// usage
head = insertNode(head, 10);

Using *& just avoids returning and lets you modify head directly.

What if we want to print the data?

We can use the same approach we used to solve the “Print the Elements of a Linked List” problem on HackerRank.

// Function to print the linked list
void printLinkedList(Node* head) {
    Node* temp = head;
    while (temp != nullptr) {
        cout << temp->data << endl;
        temp = temp->next;
    }
}

Okay, Now What Is a Linked List and What Is It Used For?

A linked list is a way to store a group of data items in order. Instead of keeping everything next to each other in memory (like an array), each item in a linked list is stored in a separate piece called a node.

Each node contains two things:

1. The data (the value you want to store)
2. A reference (or link) to the next node in the list

Because of this, the nodes are connected like a chain.

How a Linked List Works

A linked list starts with a special node called the head. The head points to the first node in the list. Each node then points to the next one, and the last node points to null, which means the list ends there.

You move through a linked list by following these links, one node at a time.

Why Use a Linked List?

Linked lists are useful when:

• You need to add or remove data easily
• You don’t know the size of the data in advance
• You want to avoid shifting elements like you would in an array

For example, inserting a new element in the middle of an array can be slow because everything after it must move. In a linked list, you only change a few links.

Common Uses of Linked Lists

Linked lists are often used for:

• Implementing stacks and queues
• Managing dynamic memory
• Navigating items (like undo/redo actions)
• Handling large amounts of data where frequent changes are needed

Linked Lists vs Arrays (Simple View)

• Arrays are fast to access but hard to resize
• Linked lists are easy to resize but slower to access

Final Thoughts

A linked list is a simple but powerful data structure. It may not always be the fastest option, but it’s very flexible and great for situations where data changes often.

Once you understand linked lists, many other data structures become easier to learn.

Thank you for reading!

If you have any questions, feel free to ask — I’d be happy to explain more.

If you have experience with C++, you are already familiar with struct and class. In C++, the main difference between them is the default access specifier:

• struct members are public by default
• class members are private by default

This distinction is very helpful when designing data structures. For simple data structures, using a struct can be more convenient.

Example:

struct Point {
    float x;
    float y;
};

Using a struct, the code is simpler because we can access the member variables directly. This is possible because the default access specifier is public.

If we use a class, it looks like this:

class Point {
public:
    float x;
    float y;
};

When using a class, we must explicitly write the public keyword to make the member variables accessible.

For example:

Point position;

position.x = 20.0f;
position.y = 20.0f;

Why is struct simpler? Because we don’t need to write the public keyword to access member variables or data inside the Point data structure.

Another scenario where this is useful is when updating the position of an object using a function:

void UpdateObjectPos(Point& objectPos, const Point& updatePos) {
    objectPos.x = updatePos.x;
    objectPos.y = updatePos.y;
}

If we used a class for the Point data structure, we would still need to declare the members as public to perform this operation. For simple data containers like this, using a struct keeps the code cleaner and easier to read.

Built-in Data Structures in C++

In addition to custom data structures created with struct or class, C++ provides many built-in data structures through the Standard Template Library (STL). These data structures are designed to store and manage collections of data efficiently.

Sequence Containers

Sequence containers store elements in a specific order.

• std::array – fixed-size array
• std::vector – dynamic array (most commonly used)
• std::list – doubly linked list
• std::deque – double-ended queue

Example:

std::vector<Point> points;

This stores multiple Point objects in a dynamic array that can grow or shrink as needed.

Another example:

If the data in the vector is a set of numbers, we can sort it using the C++ standard library like this:

// A vector of integers that will be sorted in ascending order
std::vector<int> vec = {2, 3, 4, 5, 6, 9, 3, 2, 1, 1, 3, 8, 5};

// Sort the vector in ascending order
std::sort(vec.begin(), vec.end());

Associative Containers

Associative containers store data in a structured way for fast searching.

• std::map – key–value pairs, sorted by key
• std::set – unique sorted values
• std::multimap, std::multiset – allow duplicate keys or values

Example:

std::map<int, Point> pointMap;

This allows fast lookup of a Point using an integer key.

Unordered Containers

Unordered containers use hashing for faster average lookup time.

• std::unordered_map
• std::unordered_set

Example:

std::unordered_map<int, Point> pointTable;

Another example:

One useful thing we can do using an unordered_map is find the mode of a set of numbers, which is the value that appears most frequently. For example, consider the following data set: {1, 2, 3, 4, 4, 5, 2, 3, 4, 3, 4}. If the data is small, we can count the occurrences manually, but this becomes impractical when dealing with millions of values. Using an unordered_map, we can store each number as a key and its frequency as the value, then determine which number appears most often:

#include <unordered_map>
#include <vector>

// A vector of integers where we want to find the mode (most frequent value)
std::vector<int> numbers = {1, 2, 3, 4, 4, 5, 2, 3, 4, 3, 4};

// An unordered_map where:
// - key   = the number from the vector
// - value = how many times that number appears
std::unordered_map<int, int> frequency;

// Count how many times each number appears in the vector
for (int n : numbers) {
    // If the key does not exist, it is created with value 0, then incremented
    frequency[n]++;
}

// Initialize the mode with the first element in the vector
int mode = numbers[0];

// Keeps track of the highest frequency found so far
int maxCount = 0;

// Iterate through the frequency map to find the number with the highest count
for (const auto& pair : frequency) {
    // pair.first  -> the number
    // pair.second -> how many times it appears

    if (pair.second > maxCount) {
        maxCount = pair.second;   // Update highest frequency
        mode = pair.first;        // Update mode to the most frequent number
    }
}

This approach is efficient because unordered_map provides fast average-time insertion and lookup, making it ideal for large data sets.

Custom vs Built-in Data Structures

• Custom data structures (struct, class) define the shape and meaning of a single object.
• Built-in data structures (STL containers) manage collections of objects efficiently.

In practice, these are often used together:

struct Point {
    float x;
    float y;
};

std::vector<Point> points;

Here, Point defines what the data is, while std::vector defines how many and how the data is stored.

Summary

• Use struct for simple data containers
• Use class when encapsulation and behavior are important
• Use STL containers (vector, map, etc.) to store and manage collections of data

If you are coming back to React.js after a few years, things might look a bit busier than before. Like, what is Vite? I didn’t see it a few years ago. That’s what I feel right now. It seems more complicated than React.js a few years ago.

Rather than installing Node.js on my machine, for this article I’m simply using StackBlitz (https://stackblitz.com/) as the development environment, so everything runs directly in the browser without any local setup.

New tools, new names, new versions. Don’t worry — the core ideas are still the same. We still use commands like npm install or npm run dev, just like before, only with different tools.

In this article, we’ll build the simplest possible counter using Redux Toolkit, along with a todo list that used for my technical interview a few years ago.

What are we building first?

A counter with two buttons:

• + to increase the number
• - to decrease the number

The state will be stored in Redux, even though this example could easily be done with useState. We use Redux here only to understand how it works today.

The full source code is available on StackBlitz for you to try out:

The idea (before the code)

Think of Redux like this:

• There is one global store
• The store holds some state (count)
• We change the state by dispatching actions

Redux Toolkit just makes this process shorter and less painful than old Redux.

The store

This file contains everything related to our counter state.

// src/store.ts
import { configureStore, createSlice } from "@reduxjs/toolkit";

const counterSlice = createSlice({
  name: "counter",
  initialState: { value: 0 },
  reducers: {
    increment: (state) => {
      state.value += 1;
    },
    decrement: (state) => {
      state.value -= 1;
    },
  },
});
export const { increment, decrement } = counterSlice.actions;
export const store = configureStore({
  reducer: {
    counter: counterSlice.reducer,
  },
});
export type RootState = ReturnType<typeof store.getState>;

What’s happening here?

• createSlice replaces actions + reducers + constants from old Redux
• We are allowed to “mutate” the state because Redux Toolkit uses Immer under the hood

Connecting Redux to React

Now we provide the store to our app.

// src/main.tsx
import React from "react";
import ReactDOM from "react-dom";
import { Provider } from "react-redux";
import { store } from "./store";
import App from "./App";

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById("root")
);

This step is important, but simple:

The <Provider> makes the Redux store available to all components.

The App component

This is where we read and update the state.

// src/App.tsx
import React from "react";
import { useDispatch, useSelector } from "react-redux";
import { increment, decrement } from "./store";
import type { RootState } from "./store";

const App = () => {
  const count = useSelector((state: RootState) => state.counter.value);
  const dispatch = useDispatch();
  return (
    <div style={{ padding: 20 }}>
      <h1>Redux Counter</h1>
      <p>Count: {count}</p>
      <button onClick={() => dispatch(increment())}>+</button>
      <button onClick={() => dispatch(decrement())} style={{ marginLeft: 10 }}>
        -
      </button>
    </div>
  );
};
export default App;

What to notice here:

• useSelector reads data from the store
• useDispatch sends actions to the store
• No boilerplate, no extra files

What are we building next?

A few years ago (in 2019 — yes, before I graduated from university), I had a technical interview for a Software Engineer position at a startup. I already had experience developing a fully functional web application using Laravel. However, my experience with React.js was limited to building a simple CRUD application and a page that displayed a list of tourist attractions.

The main challenge of this technical test wasn’t the code itself, but explaining how Redux works and why we should use it. This project was a small-scale example of how Redux can solve problems in larger applications. If we can explain it using a good analogy, the chances of getting the job become much higher.

Back to the memory when I was 21 years old, seeing it now makes me a little bit scared. I remember thinking about how I had worked with many packages and folders, and that even though it was just a simple to-do list. How much more complicated must a real project be? The startup was a video streaming platform.

I wasn’t mentally prepared for that job at the time, but as a 21-year-old, I really wanted to get it, even though it looked very complicated and Redux felt like it could kill me. Still, I kept thinking that if I got the job — even if I only survived for a few months — I would still be a 22-year-old young man.

Now, at 27, looking back at it feels a little more scary.

I’m trying to challenge myself by recreating the technical test. Before I started all of these experiments, I believe React.js has become more complicated than it was before. Is that true? Let’s find out.

JavaScript Package Managers

Before we start doing anything with React, we need a package manager to install dependencies, and that’s also why I’m using StackBlitz. Today, we have several JavaScript package managers — npm, Yarn, pnpm, and even newer tools like Bun. For this project, using StackBlitz with npm feels like the simplest choice.

Now that all the development tools are ready, where should we start? I have the old project that I submitted a few years ago, and this is what it looks like:

After seeing that, I had a few questions:

• Why am I seeing React.js today not using class components?
• Why does the project at that time is use redux-storage-engine-localstorage and redux-storage, and now is not?

I can’t open the old technical test that was provided on Google Drive. But I remember that the old test focused on implementing the logic, while the UI was already provided. The UI was built using the todomvc-app-css package. So, if we write LESS code like this, the UI is already done:

export default function App() {
  return (
    <div className="todoapp">
      <header className="header">
        <h1>todos</h1>
        <input
          className="new-todo"
          placeholder="What needs to be done?"
        />
      </header>

      <ul className="todo-list">
        <li className="completed">
          <div className="view">
            <input className="toggle" type="checkbox" checked />
            <label>Learn React</label>
            <button className="destroy" />
          </div>
        </li>

        <li>
          <div className="view">
            <input className="toggle" type="checkbox" />
            <label>Use TodoMVC CSS</label>
            <button className="destroy" />
          </div>
        </li>
      </ul>
    </div>
  )
}

And this is what it looks like when rendered:

We only needed to implement the logic for the technical test, and because the interviewer said I was an honest person, he gave me good feedback so I knew what I should improve.

And redux-storage-engine-localstorage was mostly relevant around 2015–2017. By 2018 it was already fading, and after Redux Toolkit (2019), it no longer made sense for new projects.

Even though Redux Toolkit existed in 2019, Redux usage today is actually simpler than in 2019–2022, because best practices have matured and Redux is used more selectively.

Why am I seeing React.js today not using class components?

Because since React 16.8 (2018), Hooks allow functional components to handle state, side effects, and lifecycle logic. This made functional components simpler, more composable, and easier to reason about than class components.

As Hooks became the default pattern, new projects stopped writing class components. By around 2020, class components were effectively considered legacy for new development — still supported, but no longer recommended.

Modern React features and best practices are now hooks-first, so most contemporary codebases use functional components exclusively.

Now I don’t need to use as many folders as I did in 2019. Using fewer folders than the folder-heavy structures common in 2019 is considered a good practice today.

Old Redux folders solved a tooling problem, not a design problem.

Why we had many folders before (2016–2019)

Old Redux forced you to separate things because:

• Reducers were pure functions
• Actions were plain objects
• Types had to be constants
• No code generation

So we needed:

actions/
reducers/
constants/

This was mechanical separation, not architectural insight.

More folders existed because Redux was verbose, not because apps were complex.

Using fewer folders isn’t a bad practice. Older Redux needed many folders because of boilerplate. Modern tools like Redux Toolkit collapse that boilerplate safely. What matters is feature boundaries and change isolation, not folder count.

Contrast with 2019-era Redux architecture, Common 2019 structure:

src/
 ├─ actions/
 │   └─ todoActions.ts
 ├─ reducers/
 │   ├─ todoReducer.ts
 │   └─ index.ts
 ├─ constants/
 │   └─ actionTypes.ts
 ├─ middleware/
 │   └─ storage.ts
 └─ store/
     └─ configureStore.ts

Problems with this approach

• Logic for one feature is spread across many folders
• Boilerplate dominates business logic
• Persistence is global and implicit
• Small features feel “heavy”
• Refactors are expensive

This structure came from framework-first thinking, not feature-first thinking.

Modern Redux architecture, why it uses fewer files:

Overall architecture (big picture).

This code demonstrates modern Redux usage with Redux Toolkit and React Hooks, where:

• Redux is responsible only for state management
• Features are colocated
• Persistence is explicit, not hidden in middleware
• The entire app is understandable with three files

todosSlice.ts   → feature logic (state + actions + reducer)
store.ts        → Redux configuration
App.tsx         → UI + user interactions

This structure is simpler than 2019-era Redux, but not any less powerful. Everything here comes from my perspective as someone who doesn’t have any “real experience” with React.js yet and is just poking around, exploring things with ChatGPT. Hopefully, you’ll still get something useful out of it — especially if you’ve been in the same phase before and feel a bit nostalgic. And for real React.js developers, feel free to drop your actual wisdom.

Let’s build the app!

Defining the Todo logic (todosSlice.ts)

This file contains everything related to todos:

• what a todo looks like
• where it is stored
• how it can be changed

Defining a Todo

export interface Todo {
  id: string;
  title: string;
  completed: boolean;
}

A todo is just an object with:

• a unique id
• some text (title)
• a completed flag

No extra abstractions.

Initial state

const initialState: Todo[] = [];

At the beginning, we start with an empty list.

Creating a slice

const todosSlice = createSlice({
  name: 'todos',
  initialState,
  reducers: { ... }
});

A slice groups:

• state
• actions
• reducers

into one place.

Think of it as a small module that owns the todo list and nothing else.

Adding a todo

addTodo: {
  reducer(state, action) {
    state.push(action.payload);
  },
  prepare(title: string) {
    return {
      payload: {
        id: crypto.randomUUID(),
        title,
        completed: false,
      },
    };
  },
}

Here’s what happens when we add a todo:

1. The UI calls addTodo("Buy milk")
2. prepare() creates the full todo object
3. The reducer pushes it into the list

The UI doesn’t need to worry about IDs or default values — Redux handles it.

Toggling a todo

toggleTodo(state, action) {
  const todo = state.find((t) => t.id === action.payload);
  if (todo) todo.completed = !todo.completed;
}

This reducer:

• finds a todo by its ID
• flips the completed flag

This is triggered by clicking a checkbox in the UI.

Removing a todo

removeTodo(state, action) {
  return state.filter((t) => t.id !== action.payload);
}

This simply removes a todo by ID.

Exporting actions and reducer

export const { addTodo, toggleTodo, removeTodo } = todosSlice.actions;
export default todosSlice.reducer;

These exports allow other parts of the app to:

• dispatch todo actions
• register the todo reducer in the store

Creating the Redux store (store.ts)

This file sets up the global state container.

export const store = configureStore({
  reducer: {
    todos: todosReducer,
  },
});

The global state now looks like this:

{
  todos: Todo[]
}

Each key in the reducer object controls a part of the state.

Type helpers

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

These are TypeScript helpers:

• RootState describes the full state shape
• AppDispatch types the dispatch function

They improve safety but don’t affect runtime behavior.

Connecting Redux to the UI (App.tsx)

Now we connect React to Redux.

Reading data from the store

const todos = useSelector((state: RootState) => state.todos);

This:

• reads the todo list from Redux
• automatically re-renders the component when it changes

Dispatching actions

const dispatch = useDispatch<AppDispatch>();

This gives the component a way to tell Redux:

“Something happened. Update the state.”

Persisting todos to localStorage

useEffect(() => {
  localStorage.setItem('todos', JSON.stringify(todos));
}, [todos]);

Every time the todo list changes:

• it is saved to localStorage

This keeps data between page refreshes (saving only, not loading yet).

Adding new todos

onKeyDown={(e) => {
  if (e.key === 'Enter' && e.currentTarget.value.trim()) {
    dispatch(addTodo(e.currentTarget.value));
    e.currentTarget.value = '';
  }
}}

When the user presses Enter:

1. An action is dispatched
2. Redux updates the state
3. The UI re-renders automatically

Rendering the list

{todos.map((todo) => (
  ...
))}

Each todo:

• displays its title
• shows a checkbox
• has a delete button

Toggling completion

onChange={() => dispatch(toggleTodo(todo.id))}

Checkbox click → Redux action → state update → UI refresh.

Removing a todo

onClick={() => dispatch(removeTodo(todo.id))}

Button click → Redux action → item removed.

The full source code is available on StackBlitz for you to try out:

Final thoughts

If you used Redux years ago, this might feel too simple — and that’s the point.

Redux Toolkit removes most of the ceremony:

• Fewer files
• Less code
• Same core idea

And about Vite?

You don’t need to care much about it here. It’s just the tool that runs your app fast during development.

Thank you for reading!!