Телеграм канал «Web development»

🐛 Can You Find the Bug?

Think you can spot a JavaScript bug before running the code? 👀

Take a look at this:

const users = ["Alex", "Austin", "Max"];

for (let i = 0; i <= users.length; i++) {
console.log(users[i]);
}

🤔 What will happen?

A) It prints all 3 names
B) It prints the names and then undefined
C) It gives a syntax error
D) It creates an infinite loop

👇 Comment your answer before checking the solution!

💡 Hint: Look carefully at the loop condition.

🌐 What Actually Happens When You Type google.com?

You type a URL, press Enter, and the website appears in seconds.

But what actually happens behind the scenes? 👀

Let's break it down 👇

1. DNS Finds the Server 🔎
Your browser asks DNS:
*"Where is google.com?"*

DNS finds the IP address of the server hosting the website.

2. Your Browser Connects 🔗
Your browser establishes a connection with that server.

For HTTPS websites, encryption is also set up to keep the communication secure 🔐

3. Browser Sends an HTTP Request 📡
Your browser basically says:

*"Hey server, I want this webpage."*

The request contains information such as the URL, method and headers.

4. Server Processes the Request ⚙️
The server receives your request and decides what to return.

It may also communicate with databases, APIs or other services.

5. Server Sends a Response 📦
The server sends data back to your browser.

This could include HTML, CSS, JavaScript, images and other files.

6. Browser Builds the Page 🖥
Now the browser gets to work.

It reads the HTML, applies CSS, executes JavaScript and loads additional resources.

7. You See the Website ✨
After all of that happens in milliseconds...

You finally see:

Google.

And you probably thought you just *typed a URL*. 😂

💡 One simple action triggers an entire chain of systems working together.

💾 Save this. You'll understand the internet a little differently next time you open a website.

React Vite Project Structure

Interface Cheat Sheet

This is an insane collection of practical UI best practices (concentric border-radius, optical alignment, animation origins, typography details, colors, accessibility, etc.) with examples.

It will surely help if you are a web developer.

🔗 Link

👨‍💻 5 Things I Wish I Knew Before Learning Coding

Starting coding can feel confusing. Here are a few things that can make the journey much easier

1. You Don't Need to Learn Everything 🧠
• You don't need 5 programming languages
• Pick one and get comfortable with it first

2. Errors Are Part of Learning 🐛
• Getting errors doesn't mean you're bad at coding
• Debugging is one of the most important skills you'll develop

3. Tutorials Aren't Enough 📚
• Watching someone build a project isn't the same as building it yourself
• Practice by writing code without following every step

4. Projects Matter 🛠
• Build things even when you feel you're not ready
• Real projects expose you to problems that tutorials can't teach

5. Consistency Beats Motivation 🔥
• You won't feel motivated every day
• Even 30-60 minutes of consistent practice can add up over time

💬 The goal isn't to become a great developer overnight. It's to become slightly better every day.

FullStack Development Roadmap

Strong opinion:
You shouldn't write Server Actions that take FormData as an argument. They should take normal typed args instead.

The whole point of Server Actions is that they let us use TypeScript functions to call server code from the client.

The reason we want to use typed functions instead of fetch() is exactly the same as why we want to use Prisma or Drizzle to query our databases: they give us feedback directly in our editor when we write incorrect code.

If we write
const sql = "INSERT INTO users (namee) VALUES ('sam')"

We won't know we've made a mistake until we execute the query. The SQL statement is actually a data structure, but that structure is hidden behind an opaque string. Tools like Prisma and Drizzle make that structure comprehensible by TypeScript, so that when we write
prisma.users.create({ data: { namee: 'sam' }})
we know right away we've made a typo, and can fix it without needing to run the code.

The same is true for Server Actions. If we write an action that takes formData:
"use server"
async function createUser(formData: FormData) {
const name = formData.get('name')
await prisma.users.create({ data: { name }})
}
then call it from the client
<form action={createUser}>
<input type='text' name='namee' />
</form>
we'll get zero feedback that our HTML has a typo, until we run the code. The HTML `name` attribute is an opaque string, and like the SQL example, it has obscured the data structure underneath.

Compare that to this version, that accepts a normal name prop typed as a string:
"use server"
async function createUser(name: string) {
await prisma.users.create({ data: { name }})
}
Now in the client, if we make a mistake:
const [name, setName] = useState('')

<form action={() => createUser(namee)}>
<input type='text'
value={name}
onChange={e => setName(e​.target.value)}
/>
</form>
we'll know right away, thanks to createUser using the specific type we expect, rather than taking an opaque FormData object.

Note that this is exactly how we normally write event handlers in React:
<button onClick={() => setCount(count + 1)} />
You wouldn't use an opaque data structure to pull this off...
<button onClick={() => exec("increment 'count' by 1"} />
...because you don't have to. You're working in JavaScript, and you get to use all the features and data structures the language gives you to help you write your code. API calls and DB queries cross a serialization boundary, so traditionally that's where we've had to leave the safety of the language.

But where tools like Prisma brought us back to the language to write our db queries, Server Functions have now done exactly the same thing for our API calls.

Using FormData effectively breaks us out of the language again, taking our data structures and type safety right along with it.