Forem: Jorch C.

JavaScript 101: Understanding Loops (for, while, and more)

Jorch C. — Sun, 04 Jan 2026 20:27:35 +0000

TL;DR

Loops let you repeat code automatically.
Use for when you know how many times to loop.
Use while or do...while when looping until a condition is met.
Avoid infinite loops (your browser will thank you).
Arrays and loops are best friends.

One of the things you will stumble upon a lot while coding is repetition, having to do the same task over and over again until something happens. For this cases you don’t want to just duplicate your code to run those multiple operations. There is a better way, loops.

There are many different kinds of loops, but they all essentially do the same thing: they repeat an action for a number of times.

In this article, we’ll cover the main types: for, while, and do...while.

Now, while this series is kept pretty first-time friendly I would recommend taking a look at both the operators article and the control flow one as this will be pretty fundamental for what we’ll be doing here.

The for Loop

This is the most common loop and the one you’ll use most, It is particularly useful when you know exactly how many times you want to run something.

For example, let’s say I want to print the numbers from 1 to 5 in the console:

for (let i = 0; i <= 5; i++) {
  console.log("Loop number " + i);
}

//Output
Loop number 0
Loop number 1
Loop number 2
Loop number 3
Loop number 4
Loop number 5

‍Let’s break it down.
We start with i = 0 where i is the variable holding the current value we are on, now we ask the function to run until i <= 5 as you may remember from the past article this means it will run while the value goes above 5. Each iteration it runs we’ll increase the value of i by one with the i++.

The while Loop

The while loop helps you in cases in which you don’t know how many times you need to run a loop BUT there will be a specific condition that will evaluate as true at a given time. This allows us to run a function until this condition is met.

let count = 0;

while (count < 3) {
  console.log("Counting: " + count);
  count++;
}

// Output
Counting: 0
Counting: 1
Counting: 2

‍💡 Bear in mind this particular loop has the potential to break your program is cet condition is never met, meaning you could potentially run an infinite loop when the condition is impossible to meet like trying to wait for a variable to become true but you never set a way for the variable to do so. Depending on the task you are performing you can run out of memory so always double check when using a while function.

When using while loops JavaScript will check if the condition is met before running the loop. If it’s false to begin with, the loop doesn’t run.

The do...while Loop

This loops work the same way as while loops, but the condition is checked after running the block once. Meaning no matter if the condition is met from the get go or if we need to make the condition be met in the inner part of the loop. It will always run at least once.

let num = 3;

do {
  console.log("Number is " + num);
  num++;
} while (num < 2);

//Output
Number is 3

Other type of for loops

We already talked about the for loop but there is a bit more to see on that we have 2 additional options when running this type of loops, the for…in and the for…of loops let’s take a look at what they have in common and their differences.

All 3 for loops will run on a similar syntax, which will be for ({condition & values}) In the case of the for…in loop, it will iterate over the property name while the for…of iterates over the property values:

const arr = [3, 5, 7];
arr.foo = "hello";

for (const i in arr) {
  console.log(i);
}
// Will print the variable key, in an array unless the key is stated (like is the case
// of arr.foo) the keys will be defined as a number, starting with 0;
// "0" "1" "2" "foo"

for (const i of arr) {
  console.log(i);
}
// Logs: 3 5 7

💡 A quick thing to note in this function is that Arrays are iterables, which we’ll talk about in the next part of the series. for...of uses the array’s iterator (arrSymbol.iterator), which yields only the indexed elements (the array items), not arbitrary object properties like is the case of .foo hence why it isn’t included.

Wrapping things up

Loops are one of those things that may feel weird at first… but they are literally everywhere, and they’re super handy when you need to do something more than once without having to repeat yourself which makes them perfect tools for us devs.

In the next part, we’ll dig into array functions and see how JavaScript handles looping over objects. It gets a bit cooler from here on.

Until then, go write a loop or two, and enjoy the end of the year!

In a nutshell

JavaScript 101: A Beginner’s Guide to JavaScript Operators

Jorch C. — Tue, 30 Dec 2025 21:00:00 +0000

Alright, now that you know a bit about how control flow works, let’s spice things up a bit. In this article, I’ll show you a bit about which operators we have in JavaScript which will really level up how you control your code’s flow

You can see the original post here

What are operators used for?

Let’s first start by defining what operators are. In JavaScript, Operators are symbols or keywords that are used in order to perform a specific operation; these operations can be mathematical, logical, assignments, comparisons, and others. In a nutshell, they are used to manipulate the data and control the flow of a program as it runs.

Which operators do we have, and what are they used for?

According to MDN Web Docs, the latest operators we have can be divided into 4 groups: Arithmetic, Assignment, Logical, and others. I'll be explaining each of them next.

Arithmetic Operators

As you may already guess, these operators allow us to make mathematical operations, the most common usage for these are things you all know by heart

//Addition (+)
5 + 3 = 8
//Subtraction (-)
10 - 4 = 6
//Multiplication (*)
6 * 7 = 42
//Division (/)
10 / 2 = 5

But these are not the only ones; some arithmetic operators that are just a bit less common are:

//Remainder (%)
12 % 5 = 2
//Exponentiation ( ** )
2 ** 3 = 8

The remainder operator, represented by the percent sign (%), is a mathematical operator used in programming to find the remainder of a division. For example, 5 % 2 results in 1 because 2 goes into 5 two times with a remainder of 1.

Finally, we get the unary arithmetic variants which are used to either increase/decrease or to transform values to int or make them negative:

++ / -- (increment / decrement)
Unary + and - to coerce or negate

let x = 5;
x++;           // x becomes 6
let y = +"42"; // y is 42 (number)
let z = -10;   // z is -10

Assignment Operators

Now the assignment operators are quite simple to explain; they are used to either store or update a value in a variable, the most basic version of it is the = operator, which is used to assign. The rest of the operators are called “compound” as they basically add to the = operator.

These shortcuts are great to make code cleaner and help reduce repetition.

// Basic assignment:
let count = 0;
count = 5;

// Compound Operators:
count += 2; // count + 3
count -= 3; // count - 3
count *= 3; // count * 3

//This are made to replace things like:
count = count * 3

There are more assignment operators, which can be further explained in the MDN you can take a look at the full list here

Comparison Operators

A quick little trivia fact, as explained in the first article of this series, JavaScript was created way back in May 1995, BUT as quirky as this funny little programming language is nowadays, it used to be worse back then. I’ve mentioned before a hundred different quirks this language has, but one of them that is now “Solved” by simply using TypeScript was type comparisons. At the beginning, JavaScript will only work with Loose comparison operators (==) But around this date back in December 1999, as part of the ECMAScript 3 (ES3) edition, the Strict equality operator (===) was introduced. Making our lives just a little bit easier.

Now, let’s take a look at why this is such a good thing to have:

Comparisons let you compare two values or expressions. they are divided as follows:

Loose equality == (equal) & != (not equal)

// Not type safe:
"3" == 3          // returns true
3 != '3'          // returns false
null == undefined // returns true
[] == false       // returns true

Strict equality: ===, !==

0 === false         // false (different types)
"5" === 5           // false (different types)
"hello" === "hello" // true (same value, same type)
1 === 1             // true (same type, same value)
3 !== '3'           // true (different types)

💡 Due to how JS works, the recommendation is to always use ===,unless you have a good reason to allow coercion.

Relational: <, >, <=, >=

3 < 1           // false (3 is not smaller than 1)
4 > 4           // false (4 is not larger than 4)
4 >= 4          // true (4 is larger or equal than 4)
4 <= 5          // true (5 is smaller or equal than 4)

Logical Operators

Logical operators, as their name suggest, use the values sent in a logical way in order to return the right value.
These are pretty flexible operators, on the regular basis, if used with boolean values it will return a boolean, BUT they can also be used to decide which, if any value, will be returned. There are 4 operators that are most commonly used && (AND), || (OR), ! (NOT), and ?? (NULLISH). along with ?. (Optional Chaining) which was introduced later in the ECMAScript 2020 (ES2020) version of JavaScript (MDN Web Docs).

Here’s how to use them:

//Is an editor user IF the user is logged in AND has the role of "editor"
const isEditorUser= user.isLoggedIn && user.role === "editor";

// Validates if maybeName can be turned to true, otherwise it returns "guest"
const name = maybeName || "Guest";

// Validates if maybeName is either NULL or UNDEFINED, otherwise it returns "guest"
const name = maybeName ?? "Guest";

// Validates IF the method or variable exists before it tries to read it
// eg. this is ussed instead of user && user.address && user.address.street 
const street = user?.address?.street;

Ternary Operators (? :)

Just as we saw during the last post, IF Else statements help us to keep the flow of the application based on different conditions. Ternary operators (? :) work in a pretty similar way; Think of them as a shorthand for an If Else statement, they are commonly written as {Condition} ? {result if true} : {result if false} here’s a quick example

const status = age >= 18 ? "adult" : "minor";

Let’s make a comparison between a regular if else and a ternary if else:

// With IF Else
function getFinalPrice(price, discount) {
  let result;
  if (discount > 0) {
    result = price - (price * discount);
  } else {
    result = price;
  }
  return result;
}

// With Ternary Operator
function getFinalPrice(price, discount) {
  return discount > 0
    ? price - price * discount
    : price;
}

💡 Keep in mind that while ternary operators are used to simplify the code and in a lot of cases make it less verbose, it can also really bloat it if overused or if we chain multiple ternary conditions in a row. This can become a problem for future development and maintainability so you should weight which option you will take when working on your code.

That’s… it, for now

I say this because even though these are the more common operators that we use in JavaScript, they are not the only ones. I may go for more advanced operators later in this series but for now this is where I’ll leave it.

This should place you prepped to start working with code and to use everything you’ve learned throughout it. Coming next in the JavaScript  101 series I’ll be taking you through loops. Specifically the usage of for, while, and do while

JavaScript 101: Getting Started with Control Flow

Jorch C. — Tue, 16 Dec 2025 03:33:30 +0000

TL;DR

In your applications, the control flow is the one in charge of making sure your code is taking the right path.
if, else if, and else help run different code depending on conditions.
You’ll usually combine control flow with comparison or logical operators (coming up in the next article!).
Good control flow helps avoid messy, repetitive code.

Getting started

Writing code is basically telling the computer what to do, one step at a time. But what if you have to decide something based on the data that will change the steps that the computer needs to take? How do you tell the computer, ‘hey, when this happens, do this or that’? That is exactly where control flow comes into play. It makes sure your code is able to decide what to do based on certain conditions.

In this article, I’ll walk you through the most basic building blocks for making decisions in JavaScript: if, else if, and else.

💡Before we jump in, these statements work hand-in-hand with operators, like ==, >, or &&. If those look a little fuzzy or you are finding them hard to understand right now, don’t worry, we’re covering operators in the next article.

What Is Control Flow?

As I explained above, control flow is but a fancy term for how your code “flows” from one process to the next.

By default, JavaScript runs code from top to bottom, line by line, but using conditional statements, we can essentially interrupt, modify, and even reset that flow by tell our program :

“If this is true, do this.”
“Otherwise, maybe do that.”
“If none, do this other thing instead.”

The if statement

The if statement is, pretty self explanatory IMO, is just stating IF something happens, then do something, look at it in this way:

if (condition) {  
    // code to run if condition is true
}

Now let’s say we are trying to check IF someone passed their test, the minimum approving score is 70‍

let score = 90;

// Passes only if trictly greater than 70 (70 fails)
if (score > 69) {  
    console.log("Not bad.");
}

// Passes if it is higher or equal to 70 (70 passes)
if (score >= 70) {
    console.log("Not bad.");
}

Here, JavaScript checks if score is larger than 70 it prints “Not bad.” If not, it skips it.

The else if and else statements
Now, what do we do when we need multiple conditions? As the title might suggest, we use the else if and else statements, which I believe to be pretty self-explanatory:

if (score > 80) {
    console.log("Nice job!");
} else if (score > 70) {
    console.log("Not bad.");
} else {
    console.log("Keep practicing.");
}

This lets your code pick between several paths, or a fallback if no path applies. JavaScript will stop checking once it finds a match.

Pro Tips to keep your conditions clean

Keep conditions simple, if they get too messy, consider breaking them into variables.
You CAN nest if statements, but this doesn’t mean you should. Having conditions going too deep makes your code hard to read and hard to understand.
Always test all branches of your conditions.

Coming next: Operators in JavaScript

In the next part, we’ll dig into how JavaScript manages operators. We’ll then see how they pair with if, if else, and else to create proper data flows

Control Flows In a Nutshell

Meet use-async-view for React

Jorch C. — Fri, 05 Dec 2025 20:51:57 +0000

Yes, it happened again, although I had a clear goal in mind for the week, I ended up leaving my current projects aside to make one more thing (plus got a ton of stuff I needed to work on). This time I made an NPM module, nothing super fancy but something I believe will be pretty useful in some cases. I present you use-async-view. A simple (says who made it), easy to implement hook for managing the state of asynchronous views in your React and React Native applications.

In a way, my ‍hook is pretty similar to React’s new Suspense component which “lets you display a fallback until its children have finished loading” with the difference that I allow you to display a fallback, a loading, and an error components with the addition of a reload function. Plus this was made for both React and React Native so there’s that. Anyway let’s jump to how the hook works!

TL;DR

use-async-view is a tiny hook for “fetch something, then show the right screen” flows.

You pass it:
- an async loadFn
- components for each state (Fallback, Loading, Success, Error)
It gives you:
- a RenderedViewelement you can drop straight into your JSX
- a reloadfunction to re-run the request
- an internal state machine (idle→ loading→ success | error) so you don’t have to re-write it in every component Use it when you want simple async views without pulling in heavier data-fetching libraries.

Quickstart

As any other node module, you need to start by getting it installed, for that the command thankfully is really easy, just do the following:

npm i use-async-view
# orp
npm add use-async-view

Okay, I’ve installed it in my project, now what? well to be completely honest this would be literally the bare minimum.

import { useAsyncView } from 'use-async-view';

type Data = { name: string };

//Get your async function
const LoadData = async () => {
  return fetch('https://dummyjson.com/products?delay=2000')
  .then(res => res.json());
}

//The component you want to use to render the data
const cards = ({ data }) => { 
  return data.products.map((product) => (
    <div key={product.id} className="card">
      <h3>{product.title}</h3>
      <p>{product.description}</p>
    </div>
  ));
}

//use it!
export default function App() {
  const { RenderedView, reload } = useAsyncView({
    loadFn: LoadData,
    Success: cards, 
  });

  return (
    <div>
      <h1>Initial Load</h1>
      {RenderedView}
      <button onClick={reload}>Reload</button>
    </div>
  );
}

Pretty simple right? no state management needed, you pass an async function and the component you want to use to display the response, easy as that, by default the hook will manage an error, loading, and response states. and the setup above is the bare minimum you need to do, just the component and a function, now this will yield you the following:

And this is what it will show if there was an issue loading the information:

Now, as I mentioned above, this is the minimum setup for the hook to work! there are multiple things you can add to it, let me explain them all:

//Declaring the hook
const { RenderedView, reload } = useAsyncView({
  loadFn: () => fetch('https://dummyjson.com/products?delay=2000').then(res => res.json()), //Async function returning a payload
  Fallback: () => <button onClick={reload}>Load user</button>, // Component to render while in idle state
  Loading: () => <Spinner />, //Component to show while the function is "Loading"
  Success: ({ data }) => <UserCard user={data} />, //Component to render on success, receives loaded data
  auto: false, //Defines whether to automatically trigger the load on mount, true by default
});

With this, you don’t have to bother with handling the state of the information that is being loaded through your parent view or to be concerned with re-renders being caused by the state changing. everything is already handled for you!

What else is included?

When I made this Module I included a couple of additional components for people to use, just to make it easier to reuse between codebases, one of them is the LoadingView which was made to be a flexible loading component to manage reusability, here’s how to use it along with it’s different options:

import { LoadingView } from 'use-async-view';

// Basic usage
<LoadingView />

// With custom text
<LoadingView text="Loading your data..." />

// With custom loader
<LoadingView 
  text="Please wait..."
  loader={<MyCustomSpinner />}
/>

// Show loader explicitly
<LoadingView showLoader={true} text="Loading..." />

And finally an ErrorViewcomponent, same case as for the LoadingView:

import { ErrorView } from 'use-async-view';

// Basic usage
<ErrorView message="Failed to load data" />

// With error details
<ErrorView 
  message="Failed to load data"
  error={error}
/>

// With retry function
<ErrorView 
  message="Failed to load data"
  error={error}
  runFunction={handleRetry}
/>

‍Why choose this over the usual approaches?

To be clear: I’m not saying you must use this hook. It’s just one more option in your toolbox. and I believe it could more than definitely help and I’d be really happy to know this can make other people’s projects easier to handle but what you use in your project is up to you. what I can say is that this hook could help you out for the following points:

There is no need for re-building the same state machine every time you need to load data.
Easily manage the “view per state” via components, keeping your project reusable and seamless.
One place to wire reload, errors, and display logic. It’s not a replacement for full data-fetching libraries, it’s more for those “I just need to load something and show the right view” moments.

Anything to add?

Cancellation: The hook can cancel any in-flight requests when unmounted.
Dependencies: None! this project uses just React’s basic hooks to work, no additional dependencies
Concurrency: IF someone tries to spam the reload function there is a guard that will prevent it, also the hook stops any calls on unmount
SSR: This component is not thought for Server Side rendering
Status values: Exact strings returned by status (e.g., "idle" | "loading" | "success" | "error").

When not to use it

If you need caching, deduping, infinite scrolling, or optimistic updates, use react-query/SWR. use-async-view shines for simple “fetch then show a view” moments.

Functions And Arrow Functions

Jorch C. — Fri, 05 Dec 2025 20:43:15 +0000

What are functions?

If we want to put it in simple words, they are one of the main building blocks of JavaScript. They are used to organize your code into smaller, reusable bits that we can reuse to avoid rewriting the same logic over and over again. Throughout this article, we’ll be breaking down what functions are, how to use them, and what are the differences between regular and Arrow Functions.

Why do functions exist?

At their core, functions are a way to store repeatable work to make it consistent. Think of them as a little machine; you give it an input, it does some work, and then spits out a result.

This is tied to one of the Core Programming Principles, the DRY (Don’t Repeat Yourself) principle, which in short states that if you need to repeat the same process multiple times through your code you don’t rewrite it every time, instead you wrap the process in a function and then call the function whenever it is needed.

This really helps make your code easier to read, maintain and, later on, debug. Think of it like a coffee machine: once you got the machine you don’t need to get a new machine or re-build your current one every time you want coffee. You just press a button.

Declaring a function

Alright, now that we know why functions exist in the first place, let’s see how to actually write one. The most common way to write a function is with the function keyword‍

/*Function with no arguments*/
function showGreet(name) {
    return `Hello world!`;
}

/*Function with argument name*/
function showPersonalizedGreeting(name) {
    return `Hello, ${name}!`;
}

While functions can be named however you want, it is important to keep a standard in order to keep your codebase clean, you’d be surprised how often unclear function names cause bugs.

Function Naming Best Practices:

Keep a naming convention of preference, my personal preference is camelCase.
Since functions tend to perform actions, their names should typically be verb phrases (e.g., calculateTotal, filterResults, checkValidation)
Make sure the name is descriptive (e.g., avoid vague names like doSomething or myAmazingFunction)
Use common Prefixes to signal the functions purpose when possible:
- get: to retrieve data (getUser)
- set: to modify data (setUserName)
- handle: to handle events (handleFormSubmission)
- is, has, can: for predicate functions returning a boolean (canLogin, isNumber, hasRequiredFlag)
- Avoid non-obvious abbreviations to maintain readability.

Calling Functions

Alright, now you know how to write a function, in order to use it we need to call it which we do as follows:

/*Function with no arguments*/
function showGreet() {
    return `Hello world!`;          // returning the value
}

/*Function with argument name*/
function showPersonalizedGreeting(name) {
    return `Hello, ${name}!`;       // returning the value
}

/*Call function to store the value in a variable:*/
let simpleGreeting = showGreet();  // Hello world!
let greeting = showPersonalizedGreeting('Friend'); // Hello, Friend!

/*Call function directly in a console:*/
console.log(showPersonalizedGreeting('Friend'));   // Hello, Friend!

Passing Arguments

As you can tell from the functions we’ve been defining above, you can pass information through arguments. This is a way to send information from outside the function to process it. Let’s take the following example:

const width  = 15;
const height = 20;
let area ;

function calculateArea(_width, _height) {
    return _width * _height; // returning the calculation
}

area = calculateArea(width, height); // area = 300

Return Values

An important thing to note is that functions can return results when using the return keyword. If you don’t explicitly return anything, the function gives back undefined.

Function Expressions

Instead of declaring a function directly, you can assign it to a variable:

const multiply = function (a, b) {
  return a * b;
};

console.log(multiply(4, 2)); // 8

This is called a function expression. Function expressions are useful when you want to pass a function around as values; for example trying to pass a function into another function.

Arrow Functions

Introduced in ES6, Arrow Functions are a shorter way to write function expressions.

const divide = (a, b) => {
    return a / b;
};

It looks simpler, right? well this is what most people thought about them. The syntax is slightly different and it looks cleaner, which is right as long as you keep it that way. Now, let’s take a look at the syntax differences:

There is no function keyword.
It uses an “arrow” => between the parameters and the body.
If the function has only one parameter you can skip the parentheses:‍

const square = x => x * x;

Implicit Returns

If your function body is a single expression, Arrow Functions can implicitly return it (no return keyword needed):‍

const add = (a, b) => a + b;

When Should I use Arrow Functions?

Generally speaking, Arrow Functions are great if you are writing short functions but there are some specifics in which they are commonly used. These may not make too much sense right now but we’ll get there during this series.

Callbacks like map, filter, or event listeners.
Useful inside of classes as they don’t bind their own this.
When should I avoid Arrow Functions?
Not ideal in cases in which you need to bind this.
If a function is long and complex (while Arrow Functions look clean on their own they can reduce readability if the logic within is difficult).

In a Nutshell

Let’s Wrap it up!

Functions let you keep your code clean and reusable, while Arrow Functions give you a shorthand syntax that’s especially handy in modern JavaScript. Use regular functions when you need clarity or access to this, and Arrow Functions when you want brevity.

Now that you know how to use functions remember, next time you find yourself writing the same logic multiple times, remember: it’s probably time to wrap it in a function.

Next Up

Now we know how to create functions and how to create the type of variable we want, it is time to start adding some logic to it! In the next article “JavaScript 101 - Control Flow Basics” we’ll be going through the simplest way we can control how our code works through if, else if and else.

JavaScript 101 - JavaScript Data Types

Jorch C. — Mon, 04 Aug 2025 18:20:46 +0000

We already know what JavaScript is, how it was created, and the keywords we can use while programming using this language. Now we’re getting to know our data types, and how we can make use of the ways JavaScript handles them.

By the end of this post, you should be able to understand how JavaScript handles values under the hood and you’ll have the ability to tell them apart at a glance… at least that I hope, so let’s get into it!

TL;DR

JS has two both primitive and reference types.
Primitives types: string, number, bigint, boolean, symbol, undefined, null.
Reference types: object, array, function.
You can use typeof function to inspect types, though, be mindful that, sometimes, JavaScript can handle types in every way but a logical one.
Understand the difference between checking type equality via == (loose) and === (strict) operators.
Remember! you must be careful while modifying both objects and arrays as they are mutable, even if declared with const.

Data Types: what are they?

This is one of the first things we need to make sure we understand when programming in any language. No matter the task you’re working on, the chances for you to stumble upon the need to use the right data type will come up. As a concept, data types might be a bit confusing at the beginning for some people but believe me it is way simpler than it sounds.

First you need to understand that data types themselves are only a way for JavaScript to represent different kinds of values, and we categorize them in Primitive or Reference

Primitive Types

These data types are pretty simple, they are not objects and have no methods with them and they are sometimes treated as the lowest level of implementation of programming languages.

The primitive types in JS are:

string: Used to store text values (eg. “hello!”).
number: numbers and floats (numbers including decimal points)
bigint: Used to represent whole numbers larger than 2^53 - 1 (the largest number JavaScript can reliably represent with the Number primitive)
boolean: Simple, true or false.
symbol: An immutable and unique primitive value.
undefined: A variable that has been declared but not assigned.
null: “Empty” value. Reference (Non‑Primitive) Types These data types represent more complex data structures, and their values are not directly stored in the variable. Instead, the variable stores a reference to where the object is stored in memory. This is important to keep in mind because it means when we copy the variable to another both will be storing the same reference, so any changes made through one variable will reflect in another.

The reference types in JavaScript are:

object: key/value stores.
array: a kind of object: ordered lists.
function: also objects, but callable.

How can I tell the Type?

As I mentioned before, the type is something that most times you’d be able to tell just by looking at the value… or at least that would be true in most Object Oriented Programming Languages, not on JavaScript though. See, as I explained in the first article of this series, JavaScript is what we call “loosely typed”. Which turns out to generate some really interesting situations. For example, we know that Null as a type means it has no value, this being said when checking the type of Null the result states that the variable is an object.

In JavaScript if we want to know a type of a variable at any specific moment, we can use the typeof operator. This operator allows us to see the type of any variable or value at any given time.

Type Conversion & Coercion

JavaScript is a funny programming language, and even though there’s others that also handle things similarly, I’d say JavaScript is the most aggressive of the bunch. When talking about types, it tries to be ”helpful” by automatically switching types when it believes it makes sense. This is what we call Coercion, and while in some cases it can actually save us time it generally leads to some pretty awkward situations too. Though to avoid this we created things like TypeScript, which we’ll be touching on later in the series.On the other hand we have Conversion which is the action of forcing a value to a specific type.

Now let me show you the difference between Conversion and Coercion in code:

Type conversion (explicit) → You tell JS exactly what type you want:

Number("42"); // 42
String(10);   // "10"
Boolean(0);   // false

‍Type coercion (implicit) → JS changes the type for you, often in comparisons or math:

"5" * 2; // 10
5 + "5"; // "55"

And since coercion can turn values into booleans behind the scenes, we also get the concepts of truthy and falsy values.

Loose equality (==) vs Strict equality (===)

Another thing to keep in mind is how we check for equality in values. When validating if 2 values are the same we use the equality operator (==) but this is not the end of the story. When validating equality we need to keep an eye on the coercion of values. A string and a number with the same value can be considered the same under a loose equality operator but they are different when reviewing for strict equality.‍

0 == false; // true
0 === false; // false

"" + 5; // "5" (string)
5 + ""; // 5 (string)
"5"+"5"; // 55 (string)

‍Truthy and Falsy

JavaScript treats certain values as false in a boolean context, this is what we call falsy values which are considered “empty” no number, no text, no object. Everything else is truthy.‍

if ("hello") { console.log("Runs!"); } // truthy
if (0) { console.log("Won't run"); }   // falsy

‍Best Practices

Use const for values you don’t want to reassign, but remember objects can still be modified.
Favor === unless you have a specific coercion case.
Avoid comparing null and undefined loosely, using explicit typing helps readability.
Use Number(), String(), Boolean() when converting variable types but only when strictly needed.
If you are modifying a type using Number(), String(), Boolean() , consider wrapping the operation in a try, catch block to prevent the application from stopping. we’ll see this in a future article.

In a Nutshell

Javascript 101 - Master your keywords

Jorch C. — Thu, 24 Jul 2025 05:20:17 +0000

We have seen how to run our first line of JavaScript with the iconic “Hello World!” here that every CS student knows. Now we'll get into the different types of keywords we have on JavaScript and some best practices around them.

JavaScript Keywords

As most people know, JavaScript is known for its flexibility, like how it allows us to declare variables in different ways. While this is true, each keyword (var, let, and const) has it's own unique quirks and is best for different use cases.

Understanding the differences between these keywords will help us write cleaner, more reliable code and I'll be doing my best to teach you about each keyword’s behavior, usage and scope, with examples to see them in action.

Key concepts

Before I start explaining what each of JavaScript's keywords do I'll start by explaining some of the core concepts needed to understand the following part.

Hoisting: this is JavaScript’s behavior of moving a variable or function declaration to the top of the scope during the compilation phase.

Scope: This refers to the context in which a variable is accessible. In JavaScript we have 3 scopes:

Global: it is declared outside of any function and block and can be accessed from anywhere in your code including functions and blocks.
Function: it is declared inside a function and is only available within it.
block: it is declared within a pair of curly braces {} such as a for, while or if statements and is only available within cet block.
Initialization: this is when a variable is assigned it's first value.

Mutability: defines whether or not the value assigned to the variable can be changed.

That's it! now that we have those concepts in place we can start getting to know the different keywords in JavaScript.

var, let, and const: JavaScript's big 3

First up, let’s talk about declaring variables. Think of a variable as a little box where you can store almost anything, numbers, words, entire objects. Now, when declaring variables, we can use any of our 3 keywords. here's how each works and how they are different from each other.

Var

Ah, the old school one. This is the one I started using when I first learned JavaScript, it has been around since the very beginning. But here's the thing, it’s a bit… quirky.

For starters it gets “hoisted” to the top of its scope and it is initialized as undefined which tends lo lead to weird behaviors if you're not careful enough. for example:

console.log(myVar); 
// undefined
var myVar = 10;

Weird, right? You can see it before it’s even defined! this is one of the reasons why var, while being the oldest of the bunch is also left out to be used mostly on legacy applications that still use it. Don't take me wrong, I know there are some ways you can still use var, like when you require function scope, like this case for example:

function funcScopedLoop() {
  for (var i = 0; i < 3; i++) {
    // do something
  }
  console.log(i); 
  // ✅ prints 3
}

instead of

function funcScopedLoop() {
  for (let i = 0; i < 3; i++) {
    // scoped to loop only
  }
  console.log(i); 
  // ❌ ReferenceError
}

Once again a really niche thing now a days, just as any other implementation of var but hey, there are still reasons you may want to use it.

Additionally, variables declared using var are mutable, so the value of this variable can be updated over time.

Let

As far as scope goes, let is block scoped so it will only exists within the block it was declared in, it is also hoisted to the top of the block it was declared in BUT, unlike var, it is not initialized by default. Meaning if you try to access it before its declaration you will get a ReferenceError.

Introduced in ES6 (2015 update), let is the new kid on the block that quickly became everyone's favorite.

console.log(myLet); // error
let myLet = 5;
console.log(myLet); // 5

But how is this different from using var, is it only the hoisting that changes? well not quite, as I mentioned before, var is function scoped which means there is only one instance shared across one function which can generate issues in let's say loops with a timeout. here is an example:

for (var i = 0; i < 3; i++) {
    setTimeout(() => {
            console.log(var i: ${i});
    }, 1000);
}
// Output after 1 second:
// var i: 3
// var i: 3
// var i: 3

Now if we use let for this instance we would have something like this:

for (let i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(let i: ${i});
  }, 1000);
}
// Output after 1 second:
// let i: 0
// let i: 1
// let i: 2

As we can see, let came as a more versatile and safer option to let, hence why it became the preferred keyword to use.

const

When you hear "const", think "constant." It means you can’t reassign the value of the variable after you set it.

Consts are, like let, also block-scoped and they too get hoisted but not initialized by default. This means that, just like variables declared using let, you will get an error trying to access them before they are declared. now what is the key difference you ask? const variables are not able to mutate so their value remains the same the whole time.

This makes const perfect for declaring static data that won't chagne but is repeated constantly like a specific timeout span, a default value for a variable or if working with api calls it is perfect for storing things like the base url used.

const BASE_URL = "https://api.thecoderaccoons.com/v1";
// A function that fetches user data from the API
async function fetchUser(userId) {
    try {
        const response = await fetch(${BASE_URL}/users/${userId});
        const data = await response.json();
        console.log("User Data:", data);
    } catch (error) {
        console.error("Error fetching user:", error);
    }
}
fetchUser("12345");

An additional thing to keep in mind regarding consts is that while they are not mutable, this doesn't apply to the data within an object, so the data within the object can still be updated, even if the keyword used is const, just as the following example.

const user = {name: "Code Raccoons", role: "Developer"};

console.log(user.name); // Code Raccoons
// ✅ We can still modify properties:

user.role = "Code Whisperer";
console.log(user.role); 
// Code Whisperer

// ❌ But we can't reassign the whole object:
user = { name: "Trash Panda" }; 
// ❌ TypeError

Bonus to remember:

Next Up

With this you're now one step closer to building your first application, in the next article I'll go through the different types that you can use in JavaScript.

Javascript 101

Jorch C. — Mon, 14 Jul 2025 16:25:00 +0000

So you’ve decided to start learning JavaScript, or are curious about what it is? Great choice!
Some will say JavaScript is the language that makes the web feel alive. And to an extent they are right. Have you seen websites like the one showing above? that’s mostly done with JavaScript. In this first stop on our JavaScript road trip, we’re going to answer three burning questions:

What on earth is JavaScript, really?
Where does it run?
Why should you (and every site on the internet) care? Now grab a drink and pull out your notepad and let’s get to it!

What is JavaScript and Why Do I See It on Every Job Posting Ever?

It is a High Level, Single Threaded, Garbage Collected, Interpreted (or JIT Compiled) Prototype Based, Multi-Paradigm, Dynamic Language With a Non-Blocking Event Loop
Fireship

Well that is easy and at the same time funny to answer, In a nutshell, JavaScript is like the Swiss Army knife of web development.

Created in only 10 days by Brendan Eich of Netscape in 1995 with a single goal: “Adding an easy to learn scripting language to the Netscape browser”. Originally named Mocha, then briefly LiveScript, before settling on JavaScript (to ride Java’s popularity wave).

Fast-forward to today and… well, those sprinkles turned into the whole cake. Nowadays JavaScript is natively supported by all browsers and, for better or worse, as it is said by Atwoods Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

Server Side Applications: using Node.js
Mobile Applications: using React Native or Ionic
Desktop Apps: using Electron You could say if a device has a chip and a screen, odds are someone has tried to run JavaScript on it.

How JavaScript Fits Into the Web’s Three-Piece Suit

As I mentioned at the beginning, JavaScript is used to bring a lot of things to the table but the main thing we use it for is to make applications and websites dynamic. Some readers might be too young to remember, but back in the early 2000s, most websites felt like online Word documents. We usually just had walls of text and a couple of images. That was it, no fancy interactions or animations.

For the front end. JavaScript works alongside HTML and CSS.

HTML is the skeleton: headings, paragraphs, buttons, forms, images.
CSS as the styling: colors, layout, fonts (the bits that make it look pretty).
JavaScript is almost like the nervous system: responding to clicks, fetching data, moving things around, animating stuff, yelling in the console when something’s off. Remove JavaScript and your page will still show, but it just sits there like a mannequin, static, unbothered. Add JavaScript and it comes back to life.

Your First Script: One Line, Zero Downloads

Let’s go from Knowing what it is to a quick how it looks. I won’t even bother anyone with downloading an IDE or Text editor for this, let’s go super simple. We’re using JSBin to create a quick test.

Go to a new bin, select only the JavaScript and Console Tabs and Write the following:

jsbin.com

‍console.log('Hello World!');

After that just click run on your console and congrats! You just wrote and executed your first line of JavaScript.

Why You Will Build A Love & Hate Relationship With JavaScript

Instant feedback: It is as simple as edit, save, refresh, see results right away.
Massive ecosystem: Need charts? Animations? AI APIs? There’s a library for it.
One language, many arenas: Front-end, back-end, mobile, desktop. No matter where, you can always stuff some JS.
Quirks: Well let’s say, [] + [] equals an empty string, 0.1 + 0.2 isn’t exactly 0.3, {} + [] is 0 or why
console.log(('b' + 'a' + + 'a' + 'a').toLowerCase()); will write banana… Don’t worry we’ll get there soon enough.

Coming Up Next…

Now that “What is JavaScript?” is checked off, we’ll dive into variables and data types — the building blocks of everything from simple counters to complex apps.

By the end of the next post you’ll know why let is the cool kid, const is the stickler, and var…well, we keep var around for historical reasons.

Until then, open DevTools, poke around, and maybe change the background color of your favorite site (locally, of course). See you in Blog #2!

7 Tips on how I Leverage AI and Still Write My Own Code

Jorch C. — Tue, 01 Jul 2025 15:07:39 +0000

AI's popping up in every dev workflow, and it can save you tons of time, but lean on it too hard and you risk letting your own skills fade.
If you missed my last article, I argued engineers ignoring AI risk getting left behind.

As a seasoned developer working with AI tools daily, I've developed 7 habits that let me tap AI for productivity, while still being able to do the heavy lifting myself if needed. After all, it will be us fixing things the old-fashioned way if AI is not available at any point.

Bounce Ideas

Sometimes when working in a complex legacy codebase or just looking at a new functionality to add, you need to look at the requirements and decide what and how to do it.

In the past I used to take the requirements, think of a solution and, why not, go and bounce the idea with a co-worker. I have also "rubberducked" to see if my solution would work as expected, call it "old school vibe coding".

Now this piece is easily replaced by Chat GPT, or straight in your IDE or Text Editor of choice like its the case of Cursor or Copilot, I use the "Ask" mode quite a lot for this.

Most of the time it looks something like this:

"I've drafted this plan to add FlashList: override item layouts, debounce scroll events, and memoize item renders. Can you point out any gaps or suggest optimizations?"

This way, I'm laying out the idea and I already know the solution I want to use but I'm getting what I need to know before the implementation so I can catch some things I may have missed before like not adding a overrideItemLayout prop which is an optional parameter to decide the height of the items to improve scroll precision.

Now, what about when I have an issue or want to implement something I'm unsure how to do. Same story here, I would start by asking :

"I'm working on x but I'm not particularly sure on how I want to implement it, help me generate a fix or feature based on this information I currently have"

and bounce it from there. Sometimes I would actually get something that solves most of the problem and I would just switch to agent mode and implement it but It is always important to check things first.

Think First, Ask Second.

We all know the struggle of not knowing how to fix or do something, thankfully since 2008 stack overflow has been helping developers solve issues and ship faster. I won't shame anyone for copy-pasting solutions, I have my fair share of questions and answers in the platform.

But over time you learn a couple of things about doing so, getting an answer quick and easy is not always the best and you need to be able to tell if what you are about to add to your codebase is really what you are lookin for. Take this as an example:

In this particular case I know there is a certain amount of people that would have just run the test because "well, it may work" in this case thankfully the AI mentions this will remove all files under this directory but this is not always the case; any seasoned developer knows that running an rm command in the command line is most likely not the move you are trying to do. Specially when the request was adding a couple of lines to your .gitignore.

This is just an example of why we should always question the answer we get, not only from AIs but honestly from any source. We sometimes go for the quick and easy road to get something done but it is important to remember that any tool is here to improve our work, to make us better in our way of thinking, not to replace it.

Challenge Yourself Before Asking

I'm a stubborn developer sometimes, as I mentioned in my past article, I like to try and get solution by myself, though I've been doing this mostly for the more complex tasks lately.

I don't want AI dependency to take over my ability to do things as I've been able to for the past decade. Let's be honest most of the time the answer or solution is actually pretty simple, we just become lazy over time and would rather go the easy way.

I know not everyone will be with me on this one because it is not the "efficient" way to do things but doing things this way you can make sure you maintain your ability to problem solve on your own. In my opinion this is something to consider when the task is complex, when it will provide you with a challenge to keep your abilities sharp, for a lot of our day to day tasks we can probably leverage AI to do things fast.

Get the Logic Right

One thing I've seen that is happening to a lot of devs is that they're losing the ability of coming with a proper solution before thinking of asking AI for one. This is not only happening to devs, according to a study from researchers at MIT's Media Lab it is happening to students, writers, and others.

Our critical thinking abilities are getting reduced the more we relay on AI instead of attempting the task on our own. My way to overcome this is simple, if you are in a planning phase take the time and care for your project, get all of the requirements and get a solution that you think could work. After that you can polish the plan with AI to make sure you are not missing anything or check if there is a better way to do things. I would often bounce the idea with a coworker before I start doing so with AI.

Remember AI is a tool and as any other tool it is intended to empower the one doing the task, not replace it. Besides in a lot of cases, and I'm saying this from my own personal POV, leaving the parts of the work that I enjoy doing in the hands of AI can make the work feel empty sometimes.

Embrace Test Driven Development (TDD)

A while ago I learned about test driven development, this I implemented for the first time while working on an Android app at a past job, I was using JUnit. Doing this came up after we got an audit regarding implementation of best practices at work.

It was early in 2017 and not gonna lie It felt like such a bother to develop that way, at least for projects with tight deadlines that kept changing on the daily basis but it gave me a glimpse of what a well written project brings to the table.
Now a days I can confidently say that writing tests before you write code isn't just for over-achievers, it actually gives one as a developer the means to prevent issues in the future and a blueprint to launch new features fast.

This works the same way for AI, it gives it a clear view of what it needs to do more so than a well defined prompt or following the vibes by asking, "Hey AI, can you fix my code?". Embracing TDD can really help you make sure your agent knows exactly what you are expecting.

You can start by asking your AI of choice something like:

Generate unit tests for functionx. it will have { x } as an input and return { y } Validate both success and failure, and include edge cases.

You can specify the library you're using to get it better written, then I'd recommend reading the test and making sure all is accounted for. This way your next step will be to just write the function in a way it gives you the results you want and also passes your tests. If you are into leet code, this is pretty much the same you do when trying to make your function pass.

If you are more into AI First development the once you have your test you can do something like this:

"I've written these test cases for feature X - can you implement the code so all tests pass? Here are the requirements and the test file."

That way, AI generates code that's already aligned with your expectations.
This is great because of several reasons:

Structure up front: Tests force you to think through edge cases before you dive into implementation.
AI checks itself: If the AI‐generated code fails any test, you get immediate feedback ("Oh, I forgot to handle null inputs!").
Faster bug catch: I've saved hours by catching off-by-one loops or missing error checks in the tests, rather than discovering them in production.

Block Non-Agentic Time

If you just like my self got into software development because it is something that you're really passionate about or simply it is something you enjoy doing you might understand the feeling of boredom that comes from vibe coding.Sure you can vibe code for a little while and be relatively happy with the result but it does not fill you with the same feeling you get when you finally finished that complex functionality you needed to add or when you finally got the layout to look as you wanted it.

It is true that we've been seeing how relying too much on this tools is hindering some of our ability to do what we were perfectly capable of doing just 6 months ago. This does not only apply to Software development, it applies to all things we've shoved AI to.

A thing I personally like doing is scheduling blocks of time in which I simply won't use any of this tools and take a bit of time to exercise my own brain. As I've mentioned many times before, these tools are here to empower you not to replace you, if you don't want to be replaces make sure you can keep yourself being able complete the task with or without them.

Create Documentation

This is one of the funniest things I can recommend and it is because it is a task most developers don't want to spend time doing.

Creating documentation is not just about leaving a trace of how things are supposed to work, it is about allowing yourself to forget knowing that it will help you meet any requirements in the future and that it will empower your team to continue building non stop. We've all stumbled upon a non-documented project in which we spend great part of a week trying to understand where and why things were built that way, and I'm sorry to break this to you but if you haven't seen a project like this you're in for a treat once you do.

Now this has been an issue as old as the career itself, simply things change too fast and no one has enough time to do it in the past, and every once in a while someone decides to update the docs and that stays obsolete for many versions until someone offers again. This is something we can and should definitely leverage AI for.

First we have inline code which will be really useful for documenting global utility functions or hooks in the case of react. this way things are right there when you are using them which makes it way easier to handle.

like the following function:

Using copilot it took just a minute to generate documentation for this function and all of the outputs as well, 5 minutes to read and review and you're set to re-use this module even if you haven't done it in a while or if you brought it from one project to another.

This is a powerful tool that takes no time and gives out a great reward!

Wrapping Up

Those are my seven go-to habits for squeezing maximum value out of AI without letting my own coding skills collect dust. Whether you're brainstorming with an LLM, double-checking every suggestion, or carving out "AI-free" deep-work time, this flow will keep you both productive and sharp. What AI +code tricks have you picked up in the age of AI? Drop your favorite tip in the comments I'd love to hear how you strike your own balance.

My Webflow Toolkit: Tools, Tips, and Resources I use daily

Jorch C. — Mon, 02 Jun 2025 15:54:08 +0000

I’m not going to lie to you, working with Webflow was something I wasn't expecting to do when I first started. When I joined Skyrocket Digital as a contractor back in the pandemic arc of the world, I thought most of my work was going to be writing code to develop front and back end; And for a while it was, but that was not the only project I was working on with them. Another project I was tasked to do was a full Webflow build (bear in mind at this point, I’ve never used Webflow before), and I used to be the type of developer that would look at both no-code and low-code tools and make a face.

Fast forward about 4 years and I’ve launched 14+ sites between work and personal projects using Webflow. As a low-code tool, it allows designers and developers to launch websites really fast, but for me as a developer, it also has the flexibility for me to add functionalities that otherwise are not available in the platform.

Over time, I’ve built up a set of go-to tools I rely on for both work and personal projects for building great sites. Today I’m looking forward to sharing them with you all!

Getting started

This might be a surprise for a lot of people but I’d say planning is the most important step. I say it might be a surprise because throughout my career, I’ve seen a crazy amount of projects that start with “I need this product to be out by this day” without even going through a planning session, and I’m sure I’m not the only one getting this type of a problem. But to make something great, planning is the first tool. And for that I honestly cannot encourage you enough to generate a Product Requirement Document (PRD).

What is a PRD?

Just as I explained in my article High-Quality Software: what is it and why is it worth, it defines a product's purpose, features, functionality, and behavior. Essentially, it's a guide for development teams and stakeholders that makes sure everyone is aligned on what the product should be and why. I’m not going to explain how to make one here, for that you can read my linked article or you can take a look at this resource by Atlassian, which goes through it more thoroughly.

Even when I strongly believe that doing things yourself is how you fully understand what you need, I’m also aware that nowadays some people want to use LLMs to generate it all; so why not, here’s a prompt aimed to “Generate a PRD”

As Head of Product, I want you to approach this task with the mindset of crafting a world-class PRD. When given a brief description or request for any new product (software feature, website, service, physical product, etc.), follow these steps exactly:

### 1. Ask clarifying questions to gather detail. Cover:
  - Problem/Goal: What problem does this product solve? What is the goal? Define the clear purpose of this product or feature or assumption test and its impact on users and the business.
  - Target User: Who is the primary user or customer? including key user personas or segments.
  - Core Functionality: What key actions must the user perform?  What is the core of the product?
  - User Stories: Provide user stories (As a [type of user], I want to [action] so that [benefit]).
  - Acceptance Criteria: How will we know the product is complete? List success criteria.
  - Scope/Boundaries: What is explicitly out of scope?
  - Data/Resource Requirements: What data, materials, or resources must be displayed or used?
  - Design/UX: Are there design mockups, style guidelines, physical dimensions, or user experience requirements?
  - Edge Cases/Risks: List potential error conditions, manufacturing constraints, compliance issues, or unusual flows.

### 2. After receiving answers, generate a Product Requirements Document (PRD) in Markdown format with this structure:
  - Introduction/Overview: Describe the product, problem it solves, and goal.
  - Goals: List specific, measurable objectives.
  - User Stories: Detail user narratives describing usage and benefit.
  - Functional Requirements: Numbered list of explicit requirements (e.g., “The system must allow users to upload a profile picture.” or “The device must operate at temperatures between X and Y.”).
  - Non-Goals (Out of Scope): List what this product or feature will not include.
  - Design/UX Considerations (Optional): Link to mockups; describe UI/UX, physical design, packaging, or style components.
  - Technical/Manufacturing Considerations (Optional): Note constraints, dependencies, materials, compliance, integration points, or suggested technologies.
  - Success Metrics: Define how success is measured (e.g., “Increase user engagement by 10%,” “Reduce production costs by 15%,” “Achieve ISO certification”).
  - Open Questions: List any remaining items needing clarification.

### 3. Name the file ```

prd-[product-name].md

``` and place it under ```

/tasks/.

``` Do not implement or build; only produce the PRD.

### 4. Present the draft PRD to the user. Invite feedback by asking if any sections require clarification, if ideas should be refined, or if the user wants to finalize. If the user indicates completion, stop.

Design

Now that we know what we’re making it’s time to decide how this is gonna look, and for that there are 2 paths: design it from scratch or use a template.

If you prefer to design from scratch you will need to get a design system in place and figure out color palettes, fonts, text sizes, etc. Not gonna lie, I’m really bad at getting those out of my sleeve, so to get all I need I usually go for the following tools:

Color palette:

To generate the color palette I would recommend using Coolors as a source. The tool is great and has already generated palettes made by the community or you can re-roll your palette until you find something you like.

A small bonus for colors I like pairing coolors with RealTime Colors, an additional resource that allows you to see the color palette in real time and how it will feel in a website.

Fonts and font sizes:

I really love the combo of Typescale and FontJoy. One helps you get matched fonts and the other helps you generate the typography and scale for every element on your site!

Build

After this you can decide on a framework to use (if you want to ). A lot of people use Client First or Lumos. They both offer a large amount of customization and utility classes out of the box and believe me when I tell you the community loves them. In my case I go for something simpler, with only what I need and to add more over time, so I have my personal style guide which is also available for cloning and is what I used to create my website. Whether you go with a full system like Client First or build your own style guide like I do, having a framework will definitely save you time.

Using component libraries

I can’t say no to a good component library, they are always of great help and for Webflow I believe Relume is currently your best bet. Without a subscription you get enough components to build a simple website in just a couple of hours, but with the subscription you will get a huge amount of components to use and if you are into automated generation, their AI site builder uses their components to generate a full website based on your prompt which you can export to Webflow to style and wrap up. In Addition to that Flowbase also has a bunch of top-tier components for you to use.

All that considered, I don’t personally use their components as they are out of the box because I don’t use Client First BUT even then these pre-made components save me around 80% of the time it takes to build a site since I can get them and strip away anything I don’t want.

What about templates?

For templated websites I will go on and say if you’re using Webflow you can browse on Webflow’s template library with a wide range of free and paid options.

Extras

Once you build your site you may want to add additional functionalities to it, and believe me the ones I’m sharing here are just the tip of the iceberg. For adding functionalities like filters, merging CMS lists, CMS forms, CMS Carousels, form validations and more Finsweet Attributes is definitely the main choice. There are several other options like some scripts created by Flowbase or my own open-source library Webtricks, which also has CMS integrations as well as multiple utilities like read time for articles or marquees all using attributes. Now if you’re trying out other integrations like a CRM I would recommend Hubspot which offers a free plan that works well for most small businesses.

For carousels I would say Swipper is definitely the best option.

Really good looking animations with a little bit of code can be achieved by using Gsap Which is now owned by Webflow and can be included in every single website through the settings tab.

And many more that can be added through Webflow apps. I also know thatWized is used by a lot of people but I personally haven’t tried it out, this is supposed to rapidly write JavaScript in a low-code visual interface built for Webflow.

Automations are worth the time

Automated processes are the thing everyone is talking about and it seems to be the focus of every single article nowadays so to automate processes with your Webflow site. From setting the time to read an article to generate a complex process to send a carefully crafted reply email to your clients when requesting help using AI, Make.com is going to be your best ally, Zapier is also there but in my experience so far I prefer how Make works best.

Ready, Set, Build!

There you have it, those are the tools I use now or I’ve used in the past in order to work on Webflow and build some awesome sites. The Webflow subreddit is also a great community to join regardless of your level, I’m sure if anyone has an issue someone will definitely help or at least point you in the right direction. All I can say now is take this, check some tutorials and get to build; the best way to start making great things is working on smaller things first!

Thoughts after 6 months coding with AI

Jorch C. — Tue, 20 May 2025 02:35:20 +0000

I no longer think you should learn to code.

Amjad Masad (CEO of Repit)

I’ve been coding for about 16 years and working professionally for over a decade. After months of testing AI-assisted tools and “vibe coding” in early 2025, I can confidently say: that statement couldn’t be further from the truth.

Sure, LLMs have pulled off some amazing things. And if you don’t know what it really takes to build working software, it’s easy to think the old way is now obsolete.

But trust me, it’s not.

Let’s take a look at things that have happened before, because this is not the first time we face a statement like this; back in the late 50’s - early 60’s COBOL emerged stating that it would allow people without traditional programming backgrounds ( like business professionals, managers, and analysts ) to directly write and understand code. It was designed to be as close to English as possible so that non-developers could set instructions for the computer to follow.

This happened again in the early 90s when GeoCities appeared, followed up by the release of Dreamweaver and up to WordPress a couple of years later making a pretty similar claim: that they will empower regular users to generate what was just code or networking back then.

I'm not saying there's no way this will eventually happen, one day probably, I just don't think we're quite there yet and I don't think we'll be there on the next 3 to 5 years.

My experience with AI

I wanted to write this blog last year when the hype train started to take speed but I figured let's give it more time to get a better picture of what can be achieved with this. So for that I've been actively using AI as a coding assistant for the past 6 months or so, and I’ve found some really interesting things about it.

First of all, no I'm in no way against using AI for coding , I think it is great. If I had to say how much AI code improves my productivity I would say maybe 20-30% and I use both cursor and GitHub copilot with custom instructions for different projects, but what I have experienced doesn't match with what most of the hype is actually about.

Code generated by AI is neither perfect nor complete trash, though it definitely sometimes hits a home run and others, well I go as far as turning off copilot and cursor’s assist because I’m annoyed at how off it gets from what is needed. I've been talking with my team at work as well as other dev friends and we all agree that, while AI is pretty useful, it can be compared to what I can only describe as “a really smart intern… with ADHD and short term memory”. It can come up with pretty good solutions but if you are not careful it has a tendency to “over engineer” and “hallucinate” over the simplest requests and even go ridiculously off topic. Now I’m not saying everything is awful. For example asking Claude 3.7 to write me a function to see if a number is odd or even. I’m using this example because let’s be honest this is one of the simplest thing to do and yet there is a node package… just for this 300k+ downloads a week.

Anyway people who over use npm aside, I gave o4-mini-high a really simple prompt:

”how can I write a reusable isOdd function to see if a number is odd or even”

Honestly what I got as a response was both, a bit over the bare minimum of what I asked for and a tiny bit of an overly engineered response, yes I have to admit this is not the most specific or the best written prompt and it took me just a minute maybe to get most of the answer I was looking for, let me show you how it went:

The first part sure, it mostly works and it would sort of do the trick for 90% of the cases, the JSDocs part is a nice to have though that and the examples might be because I often request both when I’m trying out things. My issue starts with the second function. The isEven function is not really needed for this case as we can just call !isOdd(), which is what that function is doing. That is the simplest way I can show how easy it is for the current Generative AI to return a partially or sometimes mostly working functionality along with unsolicited bits that, unless you’re working on something that you won’t need to maintain in the future (like a quick MVP or a hackathon) will just inflate your codebase without a need and add potential points of failure for larger codebases. Honestly, if I see this in a Pull Request I’d ask you to drop the isEven function before accepting the changes… and I’d probably ask what the thinking was behind it.

Now here is another example of how things can go out of hand randomly, here I finished implementing a theme selection and theme management functionality for an app I’m building and originally I had the colors in some shared SCSS files for the components along with some rogue colors I set in specific screens. I used Claude 3.7 Sonnet to review the useTheme hook and Provider I created and explain to me how it worked.

It came back with a pretty good explanation of it and some decent understanding of how it worked so my next step was being ~~lazy~~ productive and ask it to modify the colors used in the components (I went module by module not the whole codebase at once) and this was how it went… by the second file

Now this was one of those instances in which I simply turned off copilot and did it myself. As you can see it started pretty well it did the first file without an issue and during the second file it started modifying localization, so I paused the job and pointed it out (yes my prompting skills are top notch when coding after working all day). After pointing out the unsolicited updates that were taking place Claude agreed and proceeded to say “oh that’s right let me continue with the theme color update”, to which it immediately went back to “Oh what’s that, I’ll fix a localization issue” (not an issue by the way that is how the integration is intended to work). In the end the module had a total of 3 files and I just needed to update 2 lines of code on each so not really a big deal. Attempting it with Claude after going back and forth for about 15 minutes led me to spend 5 minutes to do it myself.

Now I’ve seen people generate fully working prototypes using Replit or Loveable and to be completely honest I’d say most of what is generated is pretty decent on those platforms. I completely agree it can take us from prototyping straight to implementation in a lot of cases and it works great, even myself when working at the office or personal projects most of the times I bounce ideas of functionalities or needs with the ask mode of copilot and cursor and even got the agent mode on both to generate most of the boilerplate for several things like hooks and new pages. Sure, most of this boiler plating I need to specify in the custom instructions, but I can say without a doubt that having an AI assistant for coding saves me at least 20% to 30% of the time a task would’ve otherwise taken me to complete.

The real problem

one thing that I’ve seen in many developers and as a tendency in general as tech and non-tech companies try to implement an AI first approach is actually perfectly described by Terrible Software’s blogpost, I’ve seen a lot of people in the industry, sometimes even myself, losing that joy and the excitement of solving a problem after a long time trying to figure out which could be the easiest to maintain, most performant possible solution to a problem. For a lot of us as developers and I’m talking about any developer who genuinely enjoys being a developer the thing about building software is not always getting our paycheck, a lot of times the reason why we do this is simply because we really find joy in creating software. I still sometimes decide not to do things the AI way, I put on my headphones, blast some music that will get me in a state of flow and get my coffee ready there is some sort of chemistry that happens inside my brain that just makes me enjoy the problem I’m trying to solve.
Let’s go back to the example of the isOdd function, while we can ask AI to generate something there are pieces that simply won’t exist, that essence of the developer and that sense of accomplishment a lot of times are lost, if I were to spend 5 - 10 minutes doing it myself I would write something like this:

/**
* Returns true if n is odd
* Returns false if n is even or if there is an error running the function
* @param {number} n
* @returns {boolean}
*/

const isOdd = ({n: number})=> { 
  try {
    const num = Math.abs(n); //We get the absolute value (returns NaN if anything other than a number is passed)
        if (isNaN(num)) throw new TypeError('expected a number'); //check if the value is not a number (NaN)
        if (!Number.isInteger(num)) throw new TypeError('expected a Integer'); //Check if the number is an integer
        return n % 2 !== 0;
  } catch (err) {
    console.error(`[isOdd] an error occured while reviewing 'n' - Error: ${err}`);
    return false; 
  }
}

Again, this is such a simple function, and some times it is the experience that makes you think in different things that may be needed, in my case when I’m developing I always have the console open so I can see things happening so instead of having the program break if I don’t pass a number I’d rather get a log in my console, make it an error so I can notice easily, check for multiple cases that can potentially happen, you know the small things.

As I mentioned before, the joy of crafting something, of going through the full process of translating an idea into a working piece of software, the struggle of figuring out the way of getting things to work the way you want them to or the multiple hours spent trying to debug that one edge case that won’t go away and finishing the day exhausted but happy that you managed to get it all to work is something that can’t be replaced by getting an agent to build something for you.

Another thing I’ve noticed in a lot of people in the dev community that heavily relay in AI is that the critical thinking and the creativity to achieve a mean is getting lost. People that I used to be impressed by because they could create a really well thought, complete database schema and go through the reasoning why every table and every connection is where it is and has the information it has over a couple of beers while in a barbeque in the backyard now look at me and say “I’m not sure how we can build that, maybe we should GPT it and see if it works”.
It is not only about productivity, it is about having the ability to differentiate between what is needed and what we are getting.

The main problem I see is, when we outsource the parts of programming that used to challenge us, that demanded our full attention, our creativity, are we also outsourcing the opportunity for growth? for satisfaction? Can we find the same sense of improvement and fulfillment with prompt engineering that we once found in problem-solving through code?

As Bill Gates said a couple of days ago AI won’t be the end of developers, at least I don’t think it will, but I’m sad to acknowledge that it will indeed replace a lot us; If you ask me, those that don’t want to embrace this new tools will be left behind just as much as those who lose their ability to solve problems without the tools. We are in a weird time right now, one where technology can make us better or worse at what we do, but where it takes us is on us to decide. I will continue to code with and without AI, it has been something I’ve loved for years and I want to continue doing so for the years to come, but what has been your experience and where do you think AI will take us in the coming years?

This post was originally posted in My Website

High-Quality Software: What Is It and Why Is It Worth It?

Jorch C. — Sun, 16 Feb 2025 01:37:30 +0000

We’ve all been there—diving into a codebase and instantly regretting every life decision that led us there. Bad code, missing docs, and rushed deadlines make software maintenance a nightmare.

But what does "high-quality software" actually mean? And why is it worth the extra effort? In this post, I break down what makes software maintainable, scalable, and actually pleasant to work with.

As a software engineer, I’ve seen too many projects whether built by full teams, multiple developers, or even just one person turn into an absolute mess. And I swear, 80% of the time, they should come with a warning for whoever has to update the code next. Something like this:

If you hang around developers, whether it’s friends, coworkers, or Reddit threads, you’ll notice a common theme: complaints about bad code and debates over the best (or worst) ways to manage software projects.

The sad reality is that most solo developers and full teams have to deal with short, or not properly defined deadlines, which often means sacrificing code quality, documentation, and proper architecture. This results in large, messy codebases that make life harder for anyone maintaining them in the future.

What Is High-Quality Software?

There’s no single definition for high-quality software. Some might say it means well-named functions and variables, no stray console logs, and clean readability. Others may argue it’s about thorough testing and easy maintenance. A few will insist it’s about minimizing bugs and having solid test coverage.

In reality, all of these points matter. But high-quality software isn’t just about one or two of them—it’s a combination of many factors. come with me while I break down what high-quality software is:

https://www.thecoderaccoons.com/blog-posts/high-quality-software-what-is-it-and-why-is-it-worth-it