DEV Community: jackomosh

Go for Frontend Developers: Building Instant API Endpoints

jackomosh — Mon, 14 Sep 2026 09:01:20 +0000

When you first start out in frontend development, it is easy to think that User Experience (UX) is entirely about what happens inside the browser. You focus on smooth CSS transitions, pixel-perfect layouts, and fast React components. But eventually, you build a feature that feels laggy, even though your JavaScript code is totally fine.

The problem usually isn't your frontend code. It's the time your application spends waiting for the backend to reply.

The Backend Black Box

For many junior frontend developers, the backend feels like a distant black box. You send an HTTP request using fetch(), wait a moment, and hope JSON data comes back. But if that API endpoint takes half a second to respond every time a user clicks a button, your interface will feel heavy and unresponsive.

No amount of beautiful CSS can fix an app that constantly makes the user wait. Speed is a feature, and backend latency directly ruins frontend UX.

Why Learning a Bit of Go Helps You

This is where Go (or Golang) enters the picture. Go is a programming language built by Google specifically to be fast, simple, and efficient. You don't need to become a full-time backend engineer, but understanding why Go is so popular for APIs will instantly make you a better frontend developer.

Here is what Go teaches you about building better user experiences:

Sub-Millisecond Speed: Go compiles directly into machine code. It can handle incoming requests in a tiny fraction of a millisecond, meaning your UI gets its data back almost instantly.
Lightweight Payloads: Go encourages simple, clean data structures. When you see how backend languages format data, you start asking for smaller, leaner JSON payloads instead of massive objects that slow down browser rendering.
Concurrency Made Easy: Go can handle thousands of users making requests at the exact same time without slowing down. This means your UI stays fast even during high traffic.

The Junior to Senior Shift

As a junior developer, it's normal to focus only on your immediate codebase. But moving toward a senior mindset means seeing the whole picture. When you understand how lightweight backends work, you can talk to backend teams more effectively, help debug slow network requests, and design interfaces that account for real-world API performance.

Next time your app feels slow, look past your JavaScript components and check the network tab. Learning even the basics of a fast backend language like Go will help you build web applications that feel truly instant.

Which one? Loading Spinners vs Skeleton Screen vs Blank Page

jackomosh — Wed, 09 Sep 2026 07:58:12 +0000

When I first started out as a full stack developer, my go-to pattern for asynchronous data loading was simple: render a blank screen with a spinning wheel in the center until the API responded. It got the job done technically, but from a product perspective, it felt clunky and slow.

Eventually, I realized why: a loading spinner explicitly draws the user's focus to the wait time itself. It creates a focal point around the delay, making seconds feel noticeably longer.

Designing for speed is now a core requirement of good user experience. While developers can't always control network latency or server performance, we can shape perceived load times. This is why I choose skeleton screens over traditional loading indicators.

Why I Choose Skeleton Screens Over Spinners

As a developer focused on user experience, my goal is to reduce friction at every interaction point. I switched to skeleton screens for three main reasons:

They Lower Perceived Wait Time: Research shows that users perceive a page as loading faster when they see a layout wireframe taking shape rather than a looping spinner on a blank canvas.
They Eliminate Cumulative Layout Shift (CLS): A major problem with spinners is that once data arrives, elements suddenly pop into place, pushing content down and annoying the user. A skeleton screen reserves the exact vertical and horizontal space beforehand, ensuring a stable visual anchor.
They Direct Attention to the Content, Not the Delay: Instead of staring at an abstract circle spinning in isolation, the user's brain starts scanning the skeleton layout, mentally preparing for where text, avatars, and cards will appear.

What Exactly Is a Skeleton Screen?

A skeleton screen is a low-fidelity UI mockup that displays mock visual shapes in place of content while data loads in the background. It isn't just an aesthetic trick; it serves four distinct structural functions:

Communicates System Activity: Confirms to the user that their request was received and processing is actively happening.
Sets Clear Expectations: Gives a visual preview of what type of content is about to appear (e.g., a feed list vs. a media gallery).
Builds Product Trust: Prevents users from assuming the application has frozen or crashed.
Reduces Cognitive Load: Pre-structures the page so the user doesn't have to re-orient themselves when the actual data renders.

The 3 Core Types of Skeleton Screens

Depending on the type of content your application delivers, skeleton patterns generally fall into three categories:

Classic Content Wireframes: The most common approach, using static grey shapes that mirror paragraph lines, profile avatars, or card containers. Platforms like LinkedIn, YouTube, and Slack rely heavily on these to soften the impact of payload fetches.
Animated Shimmer Patterns: Static boxes can still feel frozen if an API call takes longer than expected. Adding a subtle, left-to-right light sweep or a gentle pulse effect visually signals ongoing background progress.
Dominant Color Placeholders: Popular on visual-heavy platforms like Pinterest or Unsplash. Instead of neutral grey boxes, the UI renders solid blocks matching the dominant background color of the incoming image, creating a seamless visual transition as media assets stream in.

Junior vs. Senior Perspective: Knowing When NOT to Use Skeletons

Choosing the right UX pattern means understanding its limitations. A senior engineering perspective recognizes that skeleton screens are not a universal fix.

Scenario	Best UI Pattern	Why?
Data Fetching (1s to 3s)	Skeleton Screen	Ideal window for managing perceived speed and layout stability.
Instant Actions (< 300ms)	No Indicator	Showing a skeleton for a fraction of a second creates jarring visual flickering.
Video Buffering	Centered Spinner	Spinners remain the established universal pattern for media playback pause states.
Long Operations (Uploads, Exports)	Progress Bar	Complex or long-running tasks require explicit status indicators (e.g., "Exporting 45%...").

My Final Verdict

Skeleton screens are a powerful UX optimization tool, but they aren't a substitute for actual backend performance tuning or lazy-loading strategies. However, when applied intentionally to content-rich dashboards, feeds, and cards, they bridge the gap between technical execution and a smooth, thoughtful user experience, reduce perceived load time because the user's brain prepares for the layout before the data arrives. Next time you build a dashboard, swap out that spinner for an inline skeleton.

I would love to hear your thoughts on this 🤔

Hello World! My First Post as a Software Developer 🚀

jackomosh — Tue, 14 Jul 2026 13:30:26 +0000

Hello, DEV Community! 👋

After spending a lot of time reading incredible articles on this platform, learning from all of you, and troubleshooting bugs late into the night, I’ve finally decided to take the plunge.

This is officially my first post as a software developer!

Starting a career in tech is an incredible, challenging, and endlessly exciting journey. It’s a world of constant learning, occasional imposter syndrome, and that unmatched feeling of pure joy when a complex piece of code finally works.

🛠️ My Developer Toolkit

Over the course of my journey, I've fallen in love with building things for the web. Here are some of the technologies I enjoy working with:

Frontend: HTML5, CSS3, and JavaScript (making things look good and feel interactive).
Backend & Scripting: Working with languages like PHP, Go, and Python to handle the heavy lifting.
Interests: Building clean user interfaces, working on backend logic, and figuring out how to make different systems talk to each other smoothly.

💡 Why I’m Writing on DEV

They say the best way to learn is to teach, and the best way to grow is to share. I’m here to:

Document my journey: Share the challenges I run into and how I solve them (so future-me and other developers don't have to suffer through the same bugs!).
Give back: Contribute to the developer community that has helped me countless times when I was stuck.
Connect: Meet other developers, exchange ideas, and collaborate on cool projects.

📫 Let's Connect!

I’m incredibly excited to be part of this community. Whether you're a seasoned senior developer, a fellow beginner, or just someone who loves tech:

What was the very first programming language you learned?
What’s one piece of advice you wish you had when you started out?

Drop a comment below and say hi—I’d love to connect with you!

Keep coding,