
Hello friends!
Welcome to this week’s Sloth Bytes.
I hope you had an amazing week 😁

🦥 No selling out today
I am genuinely considering selling feet pics, so if you work at a company with a marketing budget please forward this to your boss immediately or the feet come out.

Sloths can’t throw up
A sloth’s esophagus does not go in a straight line from mouth to stomach, but instead has a loop in it. This loop prevents sloths from being able to vomit so they have to be very careful not to eat anything that makes them sick!

WebSockets For Dummies

Ever wondered how chat apps update instantly or how stock trading apps let you know when you lost all your money?
Let me introduce you to WebSockets and explain when you actually need them.
What Are WebSockets?
WebSockets are a communication protocol that allows for real-time, two-way communication between a client and a server
Think of WebSockets like a phone call between your browser and the server (instead of sending individual letters back and forth like regular HTTP).
When to Use WebSockets
✅ Perfect for:
Live chat applications
Real-time gaming
Live sports updates
Collaborative editing
Stock market tickers
Live dashboards
❌ Don't use for:
Simple form submissions
Image uploads
Regular CRUD operations
One-way data flow
Infrequent updates
HTTP vs WebSockets
A normal HTTP request/response is like sending a letter: the client asks for something and the server responds. If you need frequent updates and repeatedly send those requests, that pattern is called polling:
Client: "Hey, any updates?"
Server: "Nope"
Client: "How about now?"
Server: "Still no"
Client: "Now?"
Server: "Yes! Here's an update"
WebSockets are like a phone call:
Client: "Hey, let's connect"
Server: "Alright we’re connected I’ll start sending updates!"
Server: "Here’s an Update!"
Server: "Another update!"
Server: "More updates!"
The client no longer has to ask the server for updates.
Why WebSockets for Real-time?
Low-latency push
The connection stays open
The server can send a message as soon as new data is available
Less repeated protocol overhead than frequent polling
You avoid repeatedly creating application-level request/response cycles
You don’t have to poll when nothing has changed
Full-duplex communication
Client and server can both send messages over the same connection
Useful when updates need to flow in both directions
Trade-offs
Every open connection consumes some server/network resources
Large deployments need connection management, heartbeats/reconnection logic, load balancing, and careful scaling
Whether WebSockets save bandwidth, battery, or server resources depends on the workload and what you’re comparing them with
Think of frequent polling vs WebSockets like the difference between:
Checking your mailbox every minute even when nothing arrived (polling over HTTP)
Keeping a phone line open so either side can speak as soon as something happens (WebSockets)
That makes WebSockets a great fit when you truly need frequent, bidirectional updates. For ordinary request/response work, HTTP is usually simpler.
// HTTP: Keep asking "Any updates?"
setInterval(() => {
fetch('/api/updates')
.then(data => console.log(data))
}, 1000)
// WebSockets: Get notified when updates happen
const ws = new WebSocket('ws://myserver.com')
ws.onmessage = (event) => {
console.log("Got update:", event.data)
}WebSockets sound awesome why not use them for everything?
Read this stack overflow post to understand better
Real World Examples
Chat App
Users need instant messages
Typing indicators
Online status updates
Multiplayer Game
Player positions
Game state changes
Real-time interactions
Trading Platform
Price updates
Order confirmations
Market alerts
When to Stick with HTTP
Blog posts
User profiles
Product catalogs
Payment processing
File uploads
Remember
WebSockets maintain an open connection
Perfect for real-time, two-way communication
Use regular HTTP for simple request-response
Consider server resources and scaling
Not every app needs real-time updates
Now you know when to use WebSockets and when to stick with regular HTTP. Your users (and servers) will thank you.
If you want to keep learning
APIs explained — the normal request/response model WebSockets complement.
Webhooks explained — server-to-server event delivery when you don’t need a permanent two-way connection.
React Server Components — why browser-only features like WebSockets still belong behind a client boundary.
CORS and browser origins explained — WebSockets use a different protocol model, but the connection handshake still has origin-security concerns.



Lol it’s New Years. Relax and enjoy today (I’m just lazy)
Next week we’ll have resume challenges!

Video should be posted very very soon like this week FOR SURE.
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week and Happy New Years everyone 😁





