DEV Community: Shaunak Das

My Takeaways from Anthropic's MCP Session

Shaunak Das — Wed, 19 Mar 2025 12:04:49 +0000

Hey there, fellow developers! I recently watched a YouTube session by Anthropic about the Model Control Protocol (MCP), and I couldn’t resist taking some handwritten notes to capture the key points. I’ve included those sketches below for reference (converted hand sketched diagrams to eraser diagrams), and if you want to check out the session yourself, you can find it here.

MCP is a fascinating topic that ties together AI, agents, and seamless integration with tools and data sources, so let’s dive into what I learned!

What Caught My Attention

The big idea that grabbed me was this: models are only as good as the context provided to them. It’s a simple but powerful reminder that even the most advanced AI needs the right data and tools to deliver useful results.

If the input’s lacking, the output won’t be much better—no matter how smart the model is.

Understanding MCP at a Glance

MCP is described as an open protocol that enables smooth integration between AI agents, tools, and data sources. Here’s what I noted down:

It standardizes how AI applications interact with external systems, covering:

Prompts
Tools
Resources

This standardization feels like a potential game-changer, making it easier to integrate AI across different platforms without reinventing the wheel each time.

The MCP Client and Server Dynamic

I sketched out the relationship between an MCP client and server (you can see this in my first sketch below). The client can:

Invoke tools
Query for resources
Interpolate prompts

Meanwhile, the server:

Exposes tools
Exposes resources
Exposes prompts

This setup creates a collaborative ecosystem where clients and servers work together, giving developers a lot of flexibility in how they build AI-driven solutions.

Key Features of MCP

The session highlighted a few key features of MCP that I found really interesting:

1. An Official MCP Registry API (Coming Soon)

Unified host metadata service: This will enable:

Discovery
Centralization
Verification

I jotted down a possible structure for this (check out my second sketch below):

registry: npm
published: ...
version: 1.2.0
type: studio
Another instance with type: sse and a url: ...

Anthropic mentioned that the registry API is still in the works and will be rolled out in the coming days. Once it’s live, it could be a solid foundation for managing and verifying agent interactions, which I’m really looking forward to.

2. Sampling

Sampling allows a server to request completions from a client, giving the user application full control over security, privacy, and cost. I noted down some Sampling parameters:

Model Preferences & Hints
System Prompt
Temperature & Max Tokens

This control is a big deal—it lets us fine-tune how agents behave without being stuck with server-side limitations.

3. Composability

Composability enables agents to chain together while the client application controls inference. My third sketch (see below) shows:

An application + LLM requesting inference from a client-server orchestrator agent, involving analysis agents and coding agents, all coordinated by a research agent.

This opens up some creative possibilities for designing AI systems that can handle complex workflows.

In this sketch, sampling & composabilty are working together:

Building Effective Agents with MCP

The session also covered how to build effective agents using MCP. Here’s what I took away:

Tool-Mode Controlled Functions: These are inspired by the model and include:

1. Retrieve/Search

2. Send a message

3. Update DB records

Resources: Application-controlled data exposure, files, and API responses.
Prompts: User-controlled, pre-defined templates for AI interactions, with output as JSON.

Simplifying Interactions

MCP simplifies how clients and servers interact by allowing a server to request completions from a client, putting the user application in charge of security, privacy, and cost. It’s a practical way to streamline AI workflows while keeping control in the developer’s hands.

A Practical Example from the Session: Grafana Servers

One example from the video that I found really interesting was about installing and invoking Grafana servers.

The idea was to use MCP to query logs and suggest fixes based on agent insights. My fourth sketch (see below) captures this concept, showing an agent searching for an official Grafana server via the upcoming Registry API.

This use case got me thinking about the automation possibilities once the API launches—being able to seamlessly integrate with tools like Grafana could be a huge time-saver.

Wrapping Up

This session gave me a lot to think about regarding how MCP could transform the way we integrate AI agents with our tools and data. The focus on composability, the upcoming registry API, and the flexibility it offers are really inspiring.

The Grafana example was a great illustration of how MCP can be applied in real-world scenarios, and I’m eager to see the registry API launch soon so I can start experimenting with these concepts in my own projects. If you’ve watched the session or have thoughts on MCP, I’d love to hear your take in the comments!

PS: I have already used the github MCP from Smithery.ai and the browsermcptools from agentdeskai in my cursor for 2 projects.

Until next time, happy coding!🚀

From Zero to PlanetHop: How I Built a 3D Space Game in 6 Hours with AI and Three.js

Shaunak Das — Mon, 10 Mar 2025 19:23:22 +0000

Hey Dev.to crew, buckle up—because I’m about to take you on a wild, cosmic ride!🪐

Over one crazy weekend, I went from knowing nothing about game development or Three.js to launching PlanetHop, a 3D space exploration game where you zip through a galaxy, hopping neon planets with a boost-powered spaceship.

It’s live at planethop.fun, and I’m still buzzing from the adrenaline of pulling it off in roughly 6 hours.

How? With a little help from AI magic—Cursor, Claude 3.7 Sonnet, and xAI’s Grok as my trusty co-pilot. Let’s dive into this journey—it’s messy, it’s fun, and it’s proof you can build something epic faster than you think!

The Spark: X and Indie Game Dev Vibes

It all started on X (you know, the artist formerly called Twitter). I kept seeing these indie devs—Levelsio with fly.pieter.com and Nicola Manzini with vibe.sail—whipping up games in hours using AI tools.

Levelsio’s retro flight sim? Built in 3 hours. Manzini’s chill sailing vibe? Pure inspiration. I thought, “Wait, I could do that!” No game dev skills? No problem. I had curiosity, a laptop, and a weekend to burn.

So, I decided: I’m making a space game. Planets, spaceships, neon lights—let’s go!

The Tools: AI as My Wingman

I didn’t start with a blank slate—I had some serious AI firepower:

Cursor: An AI-powered IDE that writes code like a dream. It’s like having a pair programmer who never sleeps.
Claude 3.7 Sonnet: Anthropic’s beast of a model, churning out Three.js snippets faster than I could Google them.
Grok (xAI): My guide, answering questions like “How do I tilt a spaceship?” or “What’s a HUD?” with cosmic patience.

Picture this: me, a total newbie, asking Grok, “How do I make a 3D cube fly in space?” Six hours later, I’ve got a glowing green ship hopping planets. AI didn’t just help—it made this happen.

The Build: Chaos, Code, and Cosmic Fun

Saturday morning, coffee in hand, I kicked off with Three.js. First step? A spinning cube—my “spaceship.” Cursor spat out a basic scene:

const scene = new THREE.Scene();
const geometry = new THREE.BoxGeometry(1, 1, 1);
const material = new THREE.MeshBasicMaterial({ color: 0x00ff00 });
const spaceship = new THREE.Mesh(geometry, material);
scene.add(spaceship);

It spun like a fidget spinner in space. I was hooked.

Next, controls. “Claude, give me WASD movement!” Boom—my cube was zooming. But it felt flat. I asked Grok, “How do I tilt it?” We cranked the pitch to 0.5 radians—suddenly, it’s dipping and soaring like a real ship. I flipped the camera 180° to stare down its nose, and whoa—it felt alive.

Then came the planets. I wanted them random, glowing, and wild. Claude cooked up a generator—neon hues, sizes from 5 to 20 units, some with cyan rings that burst on spawn. Press P, and a new planet pops into the galaxy. I’d hop toward one, grinning like a kid.

Boost mechanics? Space key, a draining bar, and a trail of fiery particles—thanks, Cursor. I even threw in a synthwave track from Pixabay, loaded via Three.js’s AudioListener. Picture this: me bobbing my head to retro beats, flying through a neon cosmos I built. Six hours in, I’m yelling, “This is a GAME!”

The Launch: planethop.fun Takes Flight

Sunday night, I deployed it to Vercel—pushed my public/audio/background.mp3 and all. Bought planethop.fun on Namecheap (because .fun screams indie vibes), linked it up, and bam—it’s live.

No game dev degree, no months of planning—just a weekend, some AI, and a domain that’s now my little corner of the web.

What’s Next? The Sky’s Not the Limit

I’m buzzing to keep going. Multiplayer, maybe—imagine hopping planets with friends! Or mobile controls for on-the-go cosmic fun.

But for now, I’m thrilled. From zero to this in 6 hours? That’s the power of AI and a bit of reckless enthusiasm.

Hop over to planethop.fun and take it for a spin—tell me what you think! Ever built something wild in a weekend? Let’s swap stories in the comments—I’m all ears.

Happy coding!🚀

You Don’t Know JS Yet: My Weekly Journey Through JavaScript Mastery

Shaunak Das — Sun, 02 Mar 2025 16:05:27 +0000

Hey dev.to community!👋 I’m excited to announce a new blog post series I’ll be embarking on over the coming weeks. If you’ve ever felt like JavaScript has more layers than an onion, you’re not alone—and neither am I.

I’m diving into You Don’t Know JS Yet (Second Edition) by Kyle Simpson, and I’ll be sharing what I learn from each chapter in weekly posts right here on dev.to.

Why This Series?

JavaScript is one of the most powerful and ubiquitous (present, appearing, or found everywhere) languages in web development, but it’s also notoriously tricky to master.

I’ve been coding for a while, but there’s always more to uncover—especially with a language that evolves as quickly as JS does. You Don’t Know JS Yet is a fantastic resource for peeling back those layers, and the second edition promises fresh insights, updated for today’s JavaScript landscape (as of 2025).

This series isn’t just about me learning—it’s about us learning together. Each week, I’ll tackle a chapter from the book, take notes (yes, I’m old-school with pen and paper!), and distill the key takeaways into a blog post.

My goal? To break down complex concepts, share practical insights, and spark discussions with all of you. Whether you’re a beginner or a seasoned dev, I hope you’ll find value in this journey.

Getting Started with "Getting Started"

Let’s kick things off with the first book in the series: Getting Started. This book lays the foundation for understanding JavaScript, and my handwritten notes (scribbled on graph paper, because why not?) already have me rethinking some basics. Here’s what I’ve learned so far from the first chapter, "What is JavaScript":

JavaScript’s Quirky Origins

Did you know the name "JavaScript" was initially given to lure Java developers, but there’s almost zero similarity between the two languages? It’s a fun tidbit—and a reminder that JS has its own unique identity.

Today, JavaScript is maintained by organizations like TC39 and ECMA, who meet every other month to decide and vote on new features and review the development of current ones. TC39 proposals go through a rigorous 5-stage process (Stage 0 through 4), with members from companies like Mozilla, Apple, Google, and Samsung shaping the language’s future.

Forward-Compatible? Not Quite.

One surprising takeaway: JavaScript isn’t forward-compatible. That means any new feature added to the JS language specification won’t work in older JS engines.

For new and incompatible syntax, the solution is transpiling—converting newer JS syntax to older syntax that can run on older engines. The most popular transpiler? Babel. This process ensures modern JS code can still reach a wide audience, even on legacy systems.

Backward-Compatible, Though!

On the flip side, JS is backward-compatible. All JS code written in the past will always be valid through the future and present. This stability is a huge win for developers, ensuring our old codebases don’t break as the language evolves.

How JS Executes: A Quick Peek

JS isn’t just an interpreted language—it’s compiled, too (In the book, Kyle mentions that JS is a compiled language and proves it, but I have decided to stay out of this debate 😝).

Here’s a high-level look at the execution steps, as outlined in the book:

The JS code gets transpiled by tools like Babel, then bundled (often by Webpack) into a single or few files (like bundle.js). This optimizes the website to load faster, as the browser can fetch everything from one file instead of multiple.
The JS Virtual Machine (JS engine) executes the program, starting with an optimizing JIT (Just-In-Time) compiler.
The engine parses the code into an Abstract Syntax Tree (AST), then converts it into a kind of bytecode, which is further refined and optimized.

These steps highlight how modern tools and engines work together to make JS fast and flexible—a far cry from its humble beginnings!

What’s Next?

Over the next few weeks, I’ll work through each chapter of You Don’t Know JS Yet (Second Edition), starting with Getting Started and moving on to the other books in the series (as they become available—I hear the series isn’t complete yet, but I’m too excited to wait!).

You can find more about the book series on Kyle Simpson’s website or check out the GitHub repository for additional resources.

Each blog post will dive deeper into the concepts, share my aha moments, and invite your questions and insights in the comments. If you’re curious about JS, want to brush up on the fundamentals, or just enjoy a good coding journey, stick with me. Let’s explore JavaScript together—one chapter, one week, and one blog post at a time.

Stay tuned for next week’s post, where I’ll dive into the next chapter of Getting Started. In the meantime, what’s your favorite JavaScript quirk or challenge? Drop a comment—I’d love to hear from you!

Happy coding!🚀

[PS: There were many other things on topics like WebAssembly etc, that I have not covered here you can find the full chapter in YDKJSY GitHub repository]

Micro-Frontends: The Next Big Thing or Just Hype?

Shaunak Das — Wed, 26 Feb 2025 14:38:05 +0000

If you’ve been anywhere near web development circles lately, you’ve probably heard the buzz about micro-frontends.

It’s being pitched as the shiny new solution to all our frontend woes—modular, scalable, team-friendly. But is it really the game-changer it’s hyped up to be, or just another buzzword destined to fade into obscurity? Let’s break it down.

What Are Micro-Frontends, Anyway?

Think of micro-frontends as the frontend cousin of microservices. Instead of one giant, monolithic app, you split your UI into smaller, independent pieces.

Each piece can be owned by a different team, built with its own tech stack, and deployed on its own schedule. Imagine a dashboard where the navigation bar, a widget grid, and a settings panel are all separate apps, stitched together seamlessly (or so the theory goes).

The promise? Faster development cycles, easier scaling, and happier teams who aren’t stepping on each other’s toes. Sounds dreamy, right?

But like any shiny new toy, it comes with trade-offs.

The Good: Why They’re Turning Heads

First off, micro-frontends shine when you’ve got big teams or sprawling apps. If you’ve ever waited for a 20-person team to align on a single release, you know the pain. Splitting the frontend lets teams move at their own pace—Team A can ship a new feature while Team B polishes their widget, no bottlenecks required.

They’re also a godsend for legacy migrations. Got an old monolith you’re dying to modernize? Micro-frontends let you incrementally replace chunks of it without a full rewrite.

Start with a new sidebar in React, keep the rest in jQuery, and phase things out as you go. Check out this intro to micro-frontends by Martin Fowler for a deeper dive into the concept.

And let’s not forget flexibility. Want to experiment with a new framework? Go for it—one micro-frontend can be Vue, another Svelte, and the rest whatever your team’s comfy with. No more "all-in" framework bets.

The Messy: Where It Gets Complicated

But here’s the catch: simplicity isn’t free. Stitching those independent pieces together can feel like herding cats. You’ve got to figure out how they talk to each other—shared state, routing, and styling become your new headaches. Ever tried keeping a consistent look when three teams are wielding their own CSS? Good luck.

Performance is another gotcha. Each micro-frontend might load its own dependencies, so you could end up with duplicate libraries clogging the browser. Sure, there are tricks like Webpack’s Module Federation or server-side composition, but they add complexity. And complexity, as we all know, is the enemy of deadlines.

Bundle Size Comparison

Approach	Bundle Size (MB)	Key Notes
Monolith	5.0 MB	Single, unified bundle. No duplication, but includes everything upfront.
Micro-Frontends (Duplicates)	8.5 MB	Each micro-frontend loads its own dependencies (e.g., 3x React at ~2 MB).
Optimized Micro-Frontends	6.2 MB	Shared dependencies (e.g., via Module Federation) reduce redundancy.

Explanation of Values

Monolith (5.0 MB): A single app with all features bundled together. Efficient in terms of no duplication, but it can grow unwieldy for large apps.
Micro-Frontends with Duplicates (8.5 MB): Assumes three micro-frontends, each bundling a framework like React (~2 MB) plus their own code. Duplication bloats the total size.
Optimized Micro-Frontends (6.2 MB): Uses shared dependencies (e.g., one React instance via Module Federation), cutting redundancy while still splitting the app.

Then there’s the tooling. Micro-frontends aren’t as plug-and-play as a monolith yet. You’ll likely need custom build pipelines, deployment scripts, and a solid CI/CD setup. Tools like Nx can help here—its monorepo approach is a lifesaver for managing multiple micro-frontends in one cohesive workspace. Their micro-frontend guide is worth a peek if you’re curious.

Real-World Vibes: Is It Worth It?

I’ve been knee-deep in micro-frontends lately, and here’s my take: they’re not a silver bullet, but they’re not hype either. They’re a tool—one that’s clutch when your app’s big, your team’s distributed, or your roadmap’s a moving target. For a small startup churning out an MVP? Probably not worth the hassle.

The key is knowing your context. If your app’s complexity is outpacing your ability to ship, micro-frontends might save your sanity.

But if you’re just jumping on the bandwagon because it’s trendy, you might end up with a fragmented mess and a lot of regret.

So, Next Big Thing or Just Noise?

Micro-frontends aren’t here to replace everything—they’re an evolution, not a revolution. They solve real problems for the right projects, but they’re not a one-size-fits-all fix. The hype’s loud, sure, but beneath it lies a practical approach that’s earning its keep in the wild.

Should You Use Micro-Frontends?

Question	Yes	No	Outcome After All Questions
Do you have a big team?	Move to next question	Move to next question	-
Is your app complex?	Move to next question	Move to next question	-
Need independent deploys?	If Yes to any prior question: "Go for it"	If No to all: "Stick to the monolith"	Final Decision

What do you think—are micro-frontends the future, or just another chapter in the endless frontend saga? Drop your thoughts below; I’d love to hear how they’re working (or not) for you!

Happy coding!🚀

JavaScript vs. TypeScript: A Developer’s Guide to Choosing the Right Tool

Shaunak Das — Sun, 23 Feb 2025 05:39:17 +0000

JavaScript has been the backbone of web development for decades, powering dynamic and interactive experiences. But as projects grow in complexity, its flexibility can become a double-edged sword.

Enter TypeScript—a superset of JavaScript that brings static typing and enhanced tooling to the table. In this post, I’ll break down the differences between JavaScript and TypeScript, explore their strengths, and help you decide which one fits your next project.

What’s the Deal with JavaScript?

JavaScript is the wild child of programming languages—dynamic, forgiving, and everywhere. It’s what makes your browser dance, from simple button clicks to full-blown single-page applications. Here’s what makes it shine:

Universal Adoption: It runs natively in browsers and, thanks to Node.js, on servers too.
Flexibility: No strict rules. Want to change a variable’s type mid-flight? Go for it.
Fast Prototyping: You can whip up a working app without much setup.

But that freedom comes with a catch. Take this example:

function add(a, b) {
  return a + b;
}

console.log(add(5, 10)); // 15
console.log(add("5", 10)); // "510" – Oops!

JavaScript’s loose typing means bugs like this can sneak in, especially in larger codebases. You won’t know until runtime, and by then, it might be too late.

Enter TypeScript: JavaScript with Guardrails

TypeScript, developed by Microsoft, builds on JavaScript by adding static types. It’s not a separate language—it’s JavaScript with extra features that get compiled down to plain JS. Here’s why developers love it:

Type Safety: Catch errors early, during development.
Better Tooling: Autocomplete, refactoring, and code navigation in IDEs like VS Code are top-notch.
Scalability: Ideal for big teams and complex projects.

Let’s rewrite that add function in TypeScript:

function add(a: number, b: number): number {
  return a + b;
}

console.log(add(5, 10)); // 15
console.log(add("5", 10)); // Error: Argument of type 'string' is not assignable to parameter of type 'number'

The TypeScript compiler flags the issue before you even run the code. No surprises in production!

Key Differences at a Glance

When to Use JavaScript

JavaScript is your go-to when:

You’re building a small project or prototype where speed matters more than structure.
You’re new to coding and want to avoid extra complexity.
Your team prefers minimal tooling and maximum flexibility.

Think personal portfolios, quick scripts, or small apps where you can keep the codebase in your head.

When to Use TypeScript

TypeScript shines when:

You’re working on a large-scale app with multiple developers.
You want to reduce bugs and improve maintainability.
You’re integrating with frameworks like React, Angular, or Vue, which have stellar TypeScript support.

Projects like enterprise software, open-source libraries, or anything with a long lifespan benefit hugely from TypeScript’s discipline.

A Real-World Example

Imagine you’re building a user profile feature. Here’s how it might look in JavaScript:

function displayUser(user) {
  return `${user.name} is ${user.age} years old`;
}

const user = { name: "Alex", age: 28 };
console.log(displayUser(user)); // "Alex is 28 years old"
console.log(displayUser({ name: "Sam" })); // "Sam is undefined years old" – No error, just a silent fail

Now, with TypeScript:

interface User {
  name: string;
  age: number;
}

function displayUser(user: User): string {
  return `${user.name} is ${user.age} years old`;
}

const user: User = { name: "Alex", age: 28 };
console.log(displayUser(user)); // "Alex is 28 years old"
console.log(displayUser({ name: "Sam" })); // Error: Property 'age' is missing in type '{ name: string; }'

TypeScript forces you to define what a User should look like, catching missing properties before they cause trouble.

Getting Started with TypeScript

Ready to give it a whirl? Here’s a quick setup:

Install TypeScript: npm install -g typescript
Create a file, say app.ts, and write some code.
Compile it to JavaScript: tsc app.ts
Run the resulting app.js with Node.js.

For a real project, you’ll want a tsconfig.json to customize your setup—check the TypeScript docs for details.

My Take: Why I Lean Toward TypeScript

I started with JavaScript, loving its simplicity. But as my projects grew, so did the chaos—random runtime errors, unclear APIs, and refactoring nightmares. TypeScript changed that. It’s like having a co-pilot who spots mistakes before they crash the plane. Yes, there’s a learning curve, but the payoff in confidence and productivity is massive.

That said, JavaScript still has its place. Not every project needs the overhead of types. It’s about picking the right tool for the job.

What Do You Think?

Are you a JavaScript purist or a TypeScript convert? Maybe you’ve got a killer use case for one over the other—drop it in the comments! If you’re new to TypeScript, try it on your next side project and see how it feels.

Happy coding!🚀

My Journey: From Angular Dev to Remote Job Hunter 🚀

Shaunak Das — Wed, 19 Feb 2025 15:39:19 +0000

The Start of the Journey

I've been working with TypeScript and Angular for almost three years now, building frontend applications and navigating the ever-evolving world of web development. While I enjoy my current work, I’ve always had a bigger goal: landing a remote job with great flexibility and work-life balance—ideally something like Buffer or Ghost, where a four-day workweek is a reality. 💡

The Remote Job Hunt Begins🏹

A few weeks ago, I decided to seriously pursue a remote JavaScript/TypeScript job, specifically targeting companies in the USA or Europe that allow me to work from India. But it turns out, finding legit remote jobs is harder than I expected. Most job boards are flooded with irrelevant postings, and competition is intense.

So far, I’ve applied to multiple roles, mostly through platforms like Working Nomads, RemoteOk, JsJobs, Remotive.io, etc and direct company career pages. But responses? Crickets... 🦗

The Open-Source Route

To increase my chances, I started contributing to open-source projects. First, I tried Ghostfolio (Angular + Nest.js)—a great learning experience, but the workflow wasn’t always smooth. I also explored ToolJet, but their contribution process was too limited.

Now, I’m at a crossroads: Should I stick to TypeScript projects or explore Golang, since Go developers are in demand? 🤔 (That is what I noticed while applying). So far, I’m leaning towards staying in the JS/TS ecosystem because that’s where my strengths lie.

Current Hurdles 🏗️

Lack of responses: Even after applying to multiple jobs, I haven’t landed an interview yet.
Finding active remote job listings: Many listings are outdated or not truly remote.
Balancing work and job hunting: Managing my full-time job while applying and contributing to open source is exhausting.

What’s Next?

Improve outreach: Cold emails, Twitter networking, and possibly writing tech blog posts.
Polish my portfolio: I built Itinerary GPT (Next.js), but the landing page needs work.
Explore more open-source projects: Maybe a project where I can work on AI integrations and Stripe payments?

Wrapping Up

This journey is tough, but I’m not giving up. If you’re also trying to break into remote work, let’s connect!

How did you land your first remote job?
Drop your tips in the comments. 👇