DEV Community: Samir Tahiri

🚛 Ngarkoje.com – Turning Global Transport into a 1-Click Experience

Samir Tahiri — Fri, 25 Jul 2025 12:11:39 +0000

🌍 Ngarkoje.com – Reinventing Transport & Delivery 🚚✨

What if booking a driver or transport company was as simple as booking a ride?

That’s what we’re building with Ngarkoje.com – a next-generation platform that makes moving goods easier, faster, and fully transparent.

🚀 Why Ngarkoje.com?

Traditional transport is slow, outdated, and full of guesswork – calling multiple companies, comparing random prices, and hoping everything works out.

Ngarkoje.com changes this by being the ultimate logistics marketplace, built for people and businesses worldwide.

What We Offer:

Post Any Transport Request – Packages, furniture, vehicles, or heavy goods.
Get Instant Offers – Drivers and transport companies compete to give you the best deal.
Live Tracking & Status – From pickup to delivery, you’re always in control.
Trustworthy Ratings & Reviews – Work only with top-rated professionals.
Advanced Filters – Location, price, vehicle type, urgency, and more.

🛠 The Tech Behind the Magic

To make Ngarkoje.com lightning-fast and secure, we’ve built it on cutting-edge technology:

Frontend: Next.js 14 + TypeScript for ultra-fast performance.
Backend: Node.js + Express + Prisma ORM with PostgreSQL for scalable APIs.
Real-time: Powered by Socket.IO for instant offers and communication.
Authentication: Role-based access (USER, DRIVER, COMPANY) with secure JWT.
UI/UX: TailwindCSS for a modern, sleek experience.
Cloud-ready: Fully containerized and globally deployable.

🌟 Why It Stands Out

Ngarkoje.com isn’t just another logistics app – it’s a global transport network where clients and drivers connect in seconds, built with speed, transparency, and trust as the core pillars.

No more overpaying – competitive offers in real time.
No more uncertainty – every transport is tracked.
No more hidden players – reviews and ratings guarantee quality.

🎯 Our Vision

We’re on a mission to simplify the transport industry globally.

With Ngarkoje.com, shipping your items or finding work as a driver becomes as simple as clicking a button.

🌐 Join the Movement

We’re looking for:

Drivers and transport companies ready to grow their business.
Individuals and businesses who want fast, reliable, and transparent deliveries.

👉 Sign up at Ngarkoje.com and be part of the future of transport!

🧑‍💻 Follow the Journey

We’re building Ngarkoje.com in public – from tech stack breakdowns to startup growth strategies.

Follow me here on Dev.to and join the ride! 🚀

Would you use Ngarkoje.com for your next delivery?

Drop your thoughts, ideas, and features you’d love to see – we’re building this for YOU!

Angular Signals vs RxJS: Which Should You Use in 2025?

Samir Tahiri — Wed, 16 Jul 2025 19:05:45 +0000

Angular Signals vs RxJS: Which Should You Use in 2025?

Since the introduction of Angular Signals, the Angular ecosystem has been evolving rapidly toward a simpler, more intuitive way to handle reactivity. Meanwhile, RxJS has been the go-to for reactive programming in Angular for years.

So, what’s the difference? When should you use Signals, and when is RxJS still the better choice?

Let’s break it down 👇

🧠 What Are Angular Signals?

Signals are a new reactive primitive introduced in Angular. They're designed to track dependencies automatically and re-render components efficiently when values change.

import { signal } from '@angular/core';

const count = signal(0);

function increment() {
  count.set(count() + 1);
}

Unlike RxJS, Signals are pull-based and synchronous. That means changes propagate automatically, and you don’t have to manually subscribe/unsubscribe.

🔁 What Is RxJS?

RxJS (Reactive Extensions for JavaScript) is a powerful library for working with streams of data. It's push-based, async by design, and perfect for complex data flows like HTTP requests, WebSockets, and time-based operations.

import { BehaviorSubject } from 'rxjs';

const count$ = new BehaviorSubject(0);

function increment() {
  count$.next(count$.value + 1);
}

With RxJS, you get access to a rich set of operators like map, filter, mergeMap, etc.

✅ Signals: Pros & Cons

✅ Pros

Simplicity: Easy to use, especially for local state.
Automatic tracking: No manual subscriptions.
Great for UI bindings: Perfect in templates and components.
Sync updates: No async zone issues.

❌ Cons

Not suitable for streams: Can't handle time-based or event-based data well.
Limited operators: Lacks the powerful stream operators RxJS provides.

✅ RxJS: Pros & Cons

✅ Pros

Powerful: Perfect for complex data flows.
Mature ecosystem: Tons of operators and support.
Async-first: Great for HTTP, intervals, and async sources.

❌ Cons

Steep learning curve: Can be overkill for simple state.
Manual cleanup: Subscriptions need to be managed.
Less intuitive for beginners.

🤔 When to Use Signals

Use Angular Signals when:

Managing component-local state
Updating UI from synchronous events
Building simple, reactive forms
You want better performance with fine-grained reactivity

🔄 When to Use RxJS

Use RxJS when:

Working with async data (e.g. HTTP, WebSockets)
Needing debouncing, throttling, or merging
Handling complex streams or event sources
Building highly reactive services

🔥 Can You Use Both?

Yes — and you should!

Angular doesn't force you to choose one or the other. In fact, using RxJS for async flows and Signals for reactive UI state is often the best of both worlds.

import { Component, OnInit, computed, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { toSignal } from '@angular/core/rxjs-interop';
import { Observable } from 'rxjs';

@Component({
  selector: 'app-user',
  template: `
    <h1>{{ userSignal()?.name }}</h1>
  `
})
export class MyComponent implements OnInit {
  private user$: Observable<User> = this.http.get<User>('/api/user');
  userSignal = toSignal(this.user$);

  constructor(private http: HttpClient) {}
}

The toSignal() utility helps bridge RxJS Observables to Signals.

🧪 Performance Comparison

Feature	Signals	RxJS
State reactivity	✅ Blazing fast	⚠️ Needs `async` pipe
Async data handling	❌ Limited	✅ Best in class
Learning curve	✅ Beginner-friendly	❌ Steep
Template integration	✅ Seamless	✅ With `async` pipe

🧠 Final Thoughts

If you're building UI-heavy apps with mostly synchronous state, Signals will drastically simplify your code.
If you're building apps with data streams, async calls, or complex pipelines, stick to RxJS.
The best apps in 2025 will likely use both, where each shines.

💬 What are you using in your Angular projects? Let me know in the comments 👇

#angular #rxjs #signals #webdev #frontend

Single-File Components in React: Genius or Garbage?

Samir Tahiri — Fri, 11 Jul 2025 09:49:37 +0000

Let’s start a fight (respectfully) 🥊

Recently, I came across a few React projects where the entire component was written in one file — logic, styles, markup, all jammed together.

Example:

// Button.jsx
import './Button.css';

function Button({ label }) {
  const handleClick = () => {
    alert('Clicked!');
  };

  return <button onClick={handleClick}>{label}</button>;
}

export default Button;

They call this "Single-File Components (SFC)". The idea? Keep everything together: no more .js, .css, .test.js, etc.

But here's where it gets spicy 🔥

🧠 The Argument For SFCs

🪄 Easier to read and understand in one glance
🚀 Less context switching between files
📦 More portable (copy one file, done)
🧼 Cleaner when using CSS-in-JS or Tailwind

😤 The Argument Against SFCs

🤯 Can get bloated fast (200+ lines easy)
🧪 Tests get ignored or written elsewhere
💣 Harder to scale in large teams
📁 Violates Separation of Concerns (SoC)

💬 What Do You Think?

Do you love the simplicity, or do you miss the old-school modularity?

👇 Comment below:

Do you use SFCs in React?
What are the pros and cons you’ve experienced?
Would you recommend it to your team?

Let's debate 👇

🗳️ Bonus: React devs — should we embrace single-file components like Vue? Or stick to separation?

React #WebDev #Frontend #DevOpinion

#🚀 React Clean Code Cheatsheet — Visual Guide

Samir Tahiri — Mon, 07 Jul 2025 16:17:37 +0000

Writing clean React code isn't just about making things work — it’s about readability, maintainability, and scaling your components.

Here’s a simple visual cheatsheet that highlights best practices for building better React components.

✅ Do’s & Don’ts

🔸 Props

❌ Bad:

<MyButton txt="Click" col="blue" />

✅ Good:

<MyButton label="Click" color="primary" />

💡 Use meaningful, descriptive prop names.

🔸 Conditional Rendering

❌ Bad:

{!isLoading ? <Data /> : null}

✅ Good:

{isLoading && <Spinner />}

💡 Use early returns and avoid nesting where possible.

🔸 Folder Structure

❌ Bad:

/components
  Button.js
  Card.js
  Modal.js

✅ Good:

/components
  /Button
    index.tsx
    styles.module.css
    types.ts

💡 Organize by component, not by file type.

🔸 Logic Separation

❌ Bad:

const fetchData = async () => {
  const res = await fetch(...);
  const data = await res.json();
  setState(data);
};

✅ Good:

import { getUserData } from '@/services/user';

const user = await getUserData();
setUser(user);

💡 Keep logic in services or hooks. Components should be mostly UI.

🔸 useEffect Usage

❌ Bad:

useEffect(() => {
  window.addEventListener('resize', handleResize);
}, []);

✅ Good:

useEffect(() => {
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []);

💡 Always clean up your effects to avoid memory leaks.

📌 Final Tip

Clean code in React isn’t just for you — it’s for your teammates, your future self, and the community. Refactor small, commit often, and prioritize clarity over cleverness.

🔥 The Ultimate Frontend Developer Guide for 2025

Samir Tahiri — Thu, 03 Jul 2025 07:27:46 +0000

If you want to stay relevant, hireable, and ahead of the curve as a frontend developer in 2025 — this post is your roadmap 🧭

🧠 TL;DR

Learn React, TypeScript, Next.js, and TailwindCSS
Get familiar with AI coding tools
Embrace component-driven and atomic design
Explore micro frontends, server components, and edge rendering
Master performance, a11y, and testing

💻 Core Tech Stack to Master

✅ JavaScript

Still the core of the web. Focus on:

Modern features: ??, ?., async/await, Proxy, Intl
Debugging and browser APIs
Deep DOM understanding

✅ TypeScript

2025 is all about type safety:

Advanced typing: infer, satisfies, keyof, mapped types
Master tsconfig.json
Understand strict mode, enums, and generics

✅ React

Still top in demand, but now with deeper performance:

React Server Components (RSC)
Suspense + lazy loading
TanStack Query, Zustand, Jotai
Custom hooks & memoization best practices

🧪 Try this: Migrate a small project to use RSC + Suspense + TailwindCSS

🎨 Styling in 2025

TailwindCSS: Still the go-to
CSS features: :has(), container queries, @layer
Design tokens + dark mode support
Avoid over-complicated custom CSS unless necessary

🧱 Modern Architecture Patterns

Component-Driven Development (CDD)
Atomic Design: atoms → molecules → organisms
Folder structure: features/, entities/, shared/
Build with reusability in mind

🤖 AI + Frontend = 💡

Use AI to:

Scaffold code (Copilot, Codeium, Cody)
Generate tests
Convert Figma → JSX
Explain errors, refactor code, write docs

Devs using AI ship 2x faster and focus more on UX & logic

🌐 Frameworks to Learn in 2025

Framework	Why Learn It
Next.js	Fullstack, server components, edge rendering
Remix	Forms, nested routes, data mutations
Astro	Zero-JS static sites, Markdown focused
Qwik	Fastest TTI via resumability

🚀 Trending Skills for 2025

Skill	Why It Matters
Web Performance	Core Web Vitals = UX + SEO
Accessibility (a11y)	Legal + Inclusive + User Retention
Testing	Use Vitest + Playwright for fast feedback
GraphQL / REST	Many teams now build & manage their own APIs
Multiplayer UI	Real-time apps are in demand (CRDTs/WebRTC)

🧰 Recommended Tools

VSCode + GitHub Copilot
Chrome DevTools + React Profiler
Storybook + Figma + Token Studio
Vitest + Playwright

📚 Useful Resources

🗣️ Final Thoughts

The frontend world in 2025 is more powerful and flexible than ever — but it can feel overwhelming.

Don’t chase every trend. Pick a tech stack, build projects, and share your learnings. Growth comes from consistency.

💬 Let’s connect!

👉 What are you learning in 2025? Drop your stack or goals in the comments!

🔁 Share this post if it helped.

🧠 Follow me for more practical dev content every week.

#React #JavaScript #Frontend #Webdev #TypeScript

🔥 The Ultimate Frontend Developer Guide for 2025

Samir Tahiri — Thu, 03 Jul 2025 07:16:13 +0000

🔥 The Ultimate Frontend Developer Guide for 2025

If you want to stay relevant, hireable, and ahead of the curve as a frontend developer in 2025 — this post is your roadmap 🧭

🧠 TL;DR

Learn React, TypeScript, Next.js, and TailwindCSS
Get familiar with AI coding tools
Embrace component-driven and atomic design
Explore micro frontends, server components, and edge rendering
Master performance, a11y, and testing

💻 Core Tech Stack to Master

✅ JavaScript

Still the core of the web. Focus on:

Modern features: ??, ?., async/await, Proxy, Intl
Debugging and browser APIs
Deep DOM understanding

✅ TypeScript

2025 is all about type safety:

Advanced typing: infer, satisfies, keyof, mapped types
Master tsconfig.json
Understand strict mode, enums, and generics

✅ React

Still top in demand, but now with deeper performance:

React Server Components (RSC)
Suspense + lazy loading
TanStack Query, Zustand, Jotai
Custom hooks & memoization best practices

🧪 Try this: Migrate a small project to use RSC + Suspense + TailwindCSS

🎨 Styling in 2025

TailwindCSS: Still the go-to
CSS features: :has(), container queries, @layer
Design tokens + dark mode support
Avoid over-complicated custom CSS unless necessary

🧱 Modern Architecture Patterns

Component-Driven Development (CDD)
Atomic Design: atoms → molecules → organisms
Folder structure: features/, entities/, shared/
Build with reusability in mind

🤖 AI + Frontend = 💡

Use AI to:

Scaffold code (Copilot, Codeium, Cody)
Generate tests
Convert Figma → JSX
Explain errors, refactor code, write docs

Devs using AI ship 2x faster and focus more on UX & logic

🌐 Frameworks to Learn in 2025

Framework	Why Learn It
Next.js	Fullstack, server components, edge rendering
Remix	Forms, nested routes, data mutations
Astro	Zero-JS static sites, Markdown focused
Qwik	Fastest TTI via resumability

🚀 Trending Skills for 2025

Skill	Why It Matters
Web Performance	Core Web Vitals = UX + SEO
Accessibility (a11y)	Legal + Inclusive + User Retention
Testing	Use Vitest + Playwright for fast feedback
GraphQL / REST	Many teams now build & manage their own APIs
Multiplayer UI	Real-time apps are in demand (CRDTs/WebRTC)

🧰 Recommended Tools

VSCode + GitHub Copilot
Chrome DevTools + React Profiler
Storybook + Figma + Token Studio
Vitest + Playwright

📚 Useful Resources

🗣️ Final Thoughts

The frontend world in 2025 is more powerful and flexible than ever — but it can feel overwhelming.

Don’t chase every trend. Pick a tech stack, build projects, and share your learnings. Growth comes from consistency.

💬 Let’s connect!

👉 What are you learning in 2025? Drop your stack or goals in the comments!

🔁 Share this post if it helped.

🧠 Follow me for more practical dev content every week.

#React #JavaScript #Frontend #Webdev #TypeScript

I Compared ChatGPT, Gemini, Claude, and DeepSeek for Coding – Here's What Surprised Me

Samir Tahiri — Wed, 02 Jul 2025 16:26:11 +0000

🤖 I Compared ChatGPT, Gemini, Claude, and DeepSeek for Coding – Here's What Surprised Me

As a developer, I’m constantly experimenting with tools to speed up my workflow — and lately, that includes a lot of AI assistants.

So I tested ChatGPT, Gemini, Claude, and DeepSeek for real-world dev tasks — from debugging to generating code — and here’s my breakdown of what each one did well (and not so well).

🧠 1. ChatGPT (GPT-4 / GPT-4o)

Strengths:

Consistently the most accurate for code generation
Great at understanding context, even across multiple prompts
Plugins & GPTs are useful for docs, UI, testing, etc.
GPT-4o is fast, smart, and feels conversational

Weaknesses:

Needs very specific prompts for edge cases
Code explanations can get verbose

Best for: Fullstack devs, code refactoring, architecture advice

🌐 2. Gemini (by Google)

Strengths:

Clean UI, integrated into Google ecosystem
Surprisingly good at Google search + dev combo tasks
Works well inside Docs, Gmail, and other Google tools

Weaknesses:

Can hallucinate or guess answers
Sometimes gives confident but incorrect code
Fewer dev-specific formatting features

Best for: Research-heavy tasks, documentation help

🤖 3. Claude (by Anthropic)

Strengths:

Super long context window — great for pasting entire files
Responses feel thoughtful, structured, and logical
Great with explanations and summarizing

Weaknesses:

Sometimes hesitates with full code solutions
Less “code aggressive” than ChatGPT or DeepSeek

Best for: Reading through long logs, refactoring, understanding legacy code

🔧 4. DeepSeek (Open Source-ish Dev AI)

Strengths:

Trained specifically for coding tasks
Faster and more aggressive than other open-source tools
Lightweight, solid performance for common patterns

Weaknesses:

Feels “robotic” — less conversational
Not as reliable on complex or edge-case logic

Best for: Auto-generating simple functions, code completions, fast experimentation

⚔️ TL;DR: Which AI Should You Use?

AI Tool	Best For	Rating
ChatGPT	Fullstack coding, deep context	⭐⭐⭐⭐⭐
Gemini	Research + documentation	⭐⭐⭐
Claude	Reading + summarizing large code	⭐⭐⭐⭐
DeepSeek	Quick code generation	⭐⭐⭐

💬 What Do You Think?

Have you tried these tools as a developer?

Which AI do you trust most for real coding work — and why?

Drop your thoughts in the comments 👇 Let's compare experiences!

👉 Follow me for more developer tool breakdowns, frontend architecture tips, and real-world dev experiments.

I Compared ChatGPT, Gemini, Claude, and DeepSeek for Coding – Here's What Surprised Me

Samir Tahiri — Wed, 02 Jul 2025 13:52:12 +0000

🤖 I Compared ChatGPT, Gemini, Claude, and DeepSeek for Coding – Here's What Surprised Me

As a developer, I’m constantly experimenting with tools to speed up my workflow — and lately, that includes a lot of AI assistants.

🧠 1. ChatGPT (GPT-4 / GPT-4o)

Strengths:

Consistently the most accurate for code generation
Great at understanding context, even across multiple prompts
Plugins & GPTs are useful for docs, UI, testing, etc.
GPT-4o is fast, smart, and feels conversational

Weaknesses:

Needs very specific prompts for edge cases
Code explanations can get verbose

Best for: Fullstack devs, code refactoring, architecture advice

🌐 2. Gemini (by Google)

Strengths:

Clean UI, integrated into Google ecosystem
Surprisingly good at Google search + dev combo tasks
Works well inside Docs, Gmail, and other Google tools

Weaknesses:

Can hallucinate or guess answers
Sometimes gives confident but incorrect code
Fewer dev-specific formatting features

Best for: Research-heavy tasks, documentation help

🤖 3. Claude (by Anthropic)

Strengths:

Super long context window — great for pasting entire files
Responses feel thoughtful, structured, and logical
Great with explanations and summarizing

Weaknesses:

Sometimes hesitates with full code solutions
Less “code aggressive” than ChatGPT or DeepSeek

Best for: Reading through long logs, refactoring, understanding legacy code

🔧 4. DeepSeek (Open Source-ish Dev AI)

Strengths:

Trained specifically for coding tasks
Faster and more aggressive than other open-source tools
Lightweight, solid performance for common patterns

Weaknesses:

Feels “robotic” — less conversational
Not as reliable on complex or edge-case logic

Best for: Auto-generating simple functions, code completions, fast experimentation

⚔️ TL;DR: Which AI Should You Use?

AI Tool	Best For	Rating
ChatGPT	Fullstack coding, deep context	⭐⭐⭐⭐⭐
Gemini	Research + documentation	⭐⭐⭐
Claude	Reading + summarizing large code	⭐⭐⭐⭐
DeepSeek	Quick code generation	⭐⭐⭐

💬 What Do You Think?

Have you tried these tools as a developer?

Which AI do you trust most for real coding work — and why?

Drop your thoughts in the comments 👇 Let's compare experiences!

👉 Follow me for more developer tool breakdowns, frontend architecture tips, and real-world dev experiments.

10 Subtle React Mistakes I Made – and What They Taught Me

Samir Tahiri — Tue, 01 Jul 2025 18:12:37 +0000

1️⃣ Overusing `useEffect` Instead of Thinking in React

🔧 What I did: Triggered effects for logic that could’ve been derived from props or state.

💡 What I learned: If you think you need useEffect, ask yourself: Can I compute this directly from props or state?

2️⃣ Forgetting the `key` Prop in List Rendering

🐞 What it caused: UI glitches, especially with dynamic lists.

✅ Fix: Always use a stable, unique key. Avoid using indexes if the list can change.

3️⃣ Treating State as Synchronous

📉 The mistake: Logging console.log(state) right after setState.

🧠 Reminder: State updates are asynchronous. Use effects or callbacks to react to changes.

4️⃣ Using Too Many `useState` Calls

🎢 What happened: State spaghetti everywhere.

🔀 Better approach: When state becomes complex or dependent, reach for useReducer.

5️⃣ Not Memoizing Expensive Calculations

🐌 Issue: Slow re-renders.

⚡ Fix: Wrap expensive operations in useMemo or functions in useCallback where necessary.

6️⃣ Writing Logic Directly in JSX

🤯 What I did: Conditionals, array filtering, and more directly inside the return block.

🧹 Fix: Extract complex logic before the return. JSX should stay clean and declarative.

7️⃣ Not Extracting Components Early Enough

😩 Result: Giant files, hard to reuse or test.

🔧 Lesson: If a part of the UI feels reusable or has its own logic—split it into its own component.

8️⃣ Using Context for All Shared State

🌍 What happened: Context bloat, unnecessary re-renders.

🛠️ Alternative: Use lightweight state libraries like Zustand, Jotai, or Redux Toolkit when scaling up.

9️⃣ Not Handling Async States Properly

⏳ Mistake: Ignored loading/error states in fetch requests.

✅ Fix: Always build in loading, error, and success states for better UX and debugging.

🔟 Ignoring Accessibility (a11y)

🧩 Examples: Using <div> instead of <button>, no keyboard support.

👀 Reminder: Accessibility matters! Use semantic HTML and test with a keyboard/screen reader.

🔚 Final Thoughts

React is an amazing tool, but small mistakes can snowball. These are just a few lessons I’ve learned the hard way—and I hope they help you write cleaner, faster, and more scalable React apps.

💬 Your Turn!

Have you made any of these mistakes in React?

Which one tripped you up the most?

Let me know in the comments—I’d love to hear your experience! 👇

📌 Follow me for more posts on React, frontend architecture, and web development tips.

Builder.io + Qwik: The Slot Problem No One Told You About (And How to Fix It)

Samir Tahiri — Tue, 10 Jun 2025 09:05:15 +0000

👋 Hey Dev. I'm diving into Qwik and Builder.io, and I hit a strange problem that had no clear answers online. If you’re working with custom components and multiple slots in Builder, read this before you lose time.

🧩 The Problem: Named Slots Don’t Work in Builder

Qwik supports named slots like this:

// MyLayout.tsx
import { Slot } from '@builder.io/qwik';

export const MyLayout = () => {
  return (
    <div>
      <header><Slot name="header" /></header>
      <main><Slot /></main> {/* default slot */}
      <footer><Slot name="footer" /></footer>
    </div>
  );
};

And you’d use it like this:

<MyLayout>
  <div q:slot="header">Header content</div>
  <div>Main content (default slot)</div>
  <div q:slot="footer">Footer content</div>
</MyLayout>

❌ The Catch

When using Builder.io’s visual editor, there’s no way to assign content to named slots like q:slot="header" or q:slot="footer". It only supports the default unnamed slot.

This means your <Slot name="..."> content won’t show up as intended.

✅ The Solution: Use Custom Props Instead of Slots

Builder.io does support custom @input props. So instead of relying on slots, pass content directly via props:

🔧 Refactored `MyLayout` Component

// MyLayout.tsx
export interface MyLayoutProps {
  headerContent?: JSX.Element;
  footerContent?: JSX.Element;
  children?: JSX.Element;
}

export const MyLayout = (props: MyLayoutProps) => {
  return (
    <div>
      <header>{props.headerContent}</header>
      <main>{props.children}</main>
      <footer>{props.footerContent}</footer>
    </div>
  );
};

Now your component still renders cleanly with isolated regions, but it works perfectly inside Builder.io.

🧠 How to Use It in Builder

In the Builder visual editor:

Add your MyLayout component from the components panel
In the side panel, you’ll see headerContent and footerContent as assignable props
Drag and drop elements or bind other components into those fields
The default children (main) still go in the regular content area

It just works™ — no slot syntax needed.

✨ Why This Matters

When building design systems or reusing layouts in Builder, relying on Slot name="..." will break your components inside the visual editor.

Using custom input props gives you full control, better integration, and a cleaner editing experience.

💬 Final Thoughts

I think Qwik is amazing, and Builder.io is incredibly powerful. But small gaps like this can frustrate newcomers or slow down production teams.

If this post helped you — or if you’ve solved this another way — let me know in the comments.

Thanks for reading! 🧡

Follow me for more Qwik + Builder tips soon — I’m just getting started!

Qwik is NOT React — And That’s Exactly Why It’s Fast ⚡

Samir Tahiri — Sat, 07 Jun 2025 10:48:12 +0000

What if your frontend could load instantly — even on 3G?

That’s not a fantasy. That’s Qwik.

I’ve spent years building React, Angular and Next.js apps, tuning bundle sizes, adding lazy loading, tweaking hydration... and still struggling to make things fast for real users.

Then I found Qwik — and everything changed.

🚀 What Is Qwik?

Qwik is a next-gen web framework designed for instant-loading apps, even at scale. Unlike React, Qwik doesn’t hydrate your app on load. Instead, it uses a concept called resumability.

💡 "Resumability" means the app picks up from where the server left off — no hydration, no re-running component trees on the client.

🧠 The Problem With Hydration

Frameworks like React/Next hydrate apps like this:

Server renders HTML ✅
Then loads JS bundles 📦
Then re-runs the app to attach listeners 😩

This delay hurts Time-to-Interactive (TTI), especially on mobile or low-end devices. Even with code-splitting, you still ship and hydrate large chunks of JS.

🧩 Qwik’s Game-Changer: Resumability

Qwik does this instead:

Server renders the app with all state serialized into HTML
Only loads the specific JS needed when the user interacts
No re-running of the entire app. No hydration.

Result? 🔥 Time to Interactive = Time to First Byte

👋 My Use Case: Dynamic CMS + MFE Fragments

I had a challenge:

Use Builder.io for dynamic CMS-driven content
Render fragments of the app in multiple microfrontends (MFE)
Keep bundle size tiny and performance top-tier

Qwik + Builder.io was a perfect fit.

🛠️ Real Qwik Code Example

tsx
// src/components/HelloWorld.tsx
import { component$, useSignal } from '@builder.io/qwik';

export const HelloWorld = component$(() => {
  const count = useSignal(0);

  return (
    <button onClick$={() => count.value++}>
      Clicks: {count.value}
    </button>
  );
});

✅ No hydration needed
✅ Loads instantly
✅ useSignal is reactive and trackable by Qwik’s optimizer

🔌 Builder.io Integration

Builder.io lets me define dynamic pages visually, but I still want control over components. So I register my Qwik components like this:

import { builder } from '@builder.io/sdk-qwik';
import { HeroBlock } from './HeroBlock';

builder.registerComponent(HeroBlock, {
  name: 'HeroBlock',
  inputs: [
    { name: 'title', type: 'text' },
    { name: 'subtitle', type: 'text' },
    { name: 'backgroundImage', type: 'file' },
  ],
});

Now my marketing team can use it visually, but the component is still blazing fast and 100% typed.

📊 Lighthouse Score?

💯 Zero hydration. Minimal JS. Instant interactivity.

If you care about SEO, conversions, or user experience — this matters.

🧠 Final Thoughts

Qwik is not trying to be React. It’s trying to be what React was never built to be:

Fast-by-default

Serializable

Hydration-less

MFE-friendly

And it works.

🗣️ Over to You
Have you tried Qwik yet?
What’s holding you back — or what blew your mind?

Drop a comment below.
I’d love to hear how others are using Qwik in production or experimenting with it.

And if you’re curious, I’ll happily share my full Builder + Qwik MFE setup in another post 🔧