DEV Community: hasnain alam

React Native vs Flutter: Which One Should You Pick

hasnain alam — Thu, 22 Oct 2026 22:24:57 +0000

If you are planning a mobile app, you have probably heard the same question over and over. Should you use React Native or Flutter? I have built apps with both, and I can tell you there is no single winner. The better choice depends on your team, your budget, and what your app needs to do.

In this post I will explain both tools in simple words, compare them on the things that matter, and help you choose without the confusion.

What Is React Native?

React Native is a framework made by Meta (the company behind Facebook). It lets you build iOS and Android apps using JavaScript or TypeScript. If you already know React for the web, you will feel at home very quickly.

The big idea is simple. You write your app once, and React Native turns your code into real native parts on each phone. A button on iPhone looks like an iPhone button, and a button on Android looks like an Android button.

Many well known apps use it, including parts of Instagram, Shopify, and Discord.

What Is Flutter?

Flutter is a framework made by Google. It uses a language called Dart, which is easy to pick up if you know Java, C#, or JavaScript.

Flutter works in a different way. It does not use the native buttons of the phone. Instead, it draws every pixel on the screen by itself using its own engine. This gives you full control over how your app looks, and it means your app looks the same on every device.

Language and Learning Curve

This is where many people make their choice.

React Native uses JavaScript or TypeScript. These are some of the most popular languages in the world. If your team builds websites already, they can start building mobile apps with very little training.

Flutter uses Dart. Dart is clean and friendly, but fewer people know it. Most developers learn it in a week or two, so it is not a big wall. Still, it is one more thing to learn.

If your team is full of web developers, React Native feels easier. If you are starting fresh or hiring new people, Flutter is just as easy to learn.

Apps like Google Pay, BMW’s app, and Alibaba’s Xianyu use Flutter.

Performance

Let me be honest here. For most apps, both are fast enough, and your users will not notice a difference.

Flutter has a small edge in smooth animations and heavy visual screens. Because it draws everything itself, it can keep a steady frame rate even with complex designs. Its newer rendering engine has made this even better.

React Native used to have a problem with a slow bridge between JavaScript and the native side. The newer architecture has fixed most of this. Today, React Native feels quick for normal business apps, shopping apps, social apps, and booking apps.

If you are building a game or an app with very rich animations, lean toward Flutter. For almost everything else, performance should not decide this for you.

Development Speed

Both tools have hot reload. This means you change your code and see the result on the screen in a second, without restarting the app. It saves a huge amount of time.

Flutter comes with many things built in, like buttons, menus, and animations. You can build a nice looking app fast without adding many outside packages.

React Native gives you more choices, but that also means more decisions. You will pick your own tools for navigation, state management, and styling. This can be good if you like freedom, and tiring if you do not.

In my own work, I find Flutter faster for building a brand new app with custom screens. I find React Native faster when I am adding mobile to an existing React project.

When to Choose React Native

React Native is a good fit when:

Your team already knows JavaScript or React.
You want to share code with a web app built in React.
You want the app to feel fully native on each platform.
You need to hire quickly from a large pool of developers.
You are adding mobile features to an existing JavaScript project.

When to Choose Flutter

Flutter is a good fit when:

You want a very custom design that looks the same everywhere.
Your app has many animations or rich visuals.
You are starting from zero and do not have a strong language preference.
You want one codebase for mobile, web, and desktop.
You like having most tools built in and ready to use.

Final Thoughts

React Native and Flutter are both strong, mature, and trusted by big companies. You cannot make a terrible choice here. The best way to decide is to list your needs, look at your team, and build a small test screen in both if you have time. You will learn more in two days of testing than in two weeks of reading opinions.

If you are still not sure which one fits your project, feel free to reach out. I am happy to look at your idea and help you pick the right path before you spend any money.

Building a Landscaping Website Template with Next.js and WordPress

hasnain alam — Sun, 04 Oct 2026 21:51:40 +0000

I recently finished a project called LeafLife, a website template for landscaping companies. Here is a quick look at how I built it and what I learned.

The stack

Next.js for the front end and routing
WordPress as the content manager
Custom post types for services and projects
A custom field for project location
Lucide icons and responsive CSS

Why WordPress and Next.js together

Many small business owners already know WordPress. They do not want to learn a new dashboard. So I kept WordPress for editing and used Next.js to show the content fast on the front end.

The content model

There are two main post types. Services have a title, excerpt, content, and featured image. Projects have the same, plus a location field. Each one gets its own detail page and its own SEO title and description.

A few things that helped

Keeping the number of fields small, so the layout never breaks
Using the same heading sizes and spacing for all long content
Writing unique meta titles for every page from day one
Building for mobile screens first

The result

A landscaping company can add its logo, colors, and photos, and start publishing the same day.

You can see the full project, screenshots, and details here: LeafLife on hasnainalam.com

If you have built something similar with a headless WordPress setup, I would like to hear how you handled custom fields. Leave a comment or review the project and tell me what you would improve.

Why I use WordPress as a headless CMS with Next.js (and skip the custom backend)

hasnain alam — Mon, 28 Sep 2026 14:00:31 +0000

Quick story. Every time i started a simple Next.js site, I ended up building the same things again. Auth, admin panel, post editor, image upload. Boring and it takes time.
So I switched to headless WordPress. WordPress stores and manages the content, Next.js shows it. You just call the REST API (or WPGraphQL if you like that more) and thats about it.

Whats better for me:

No admin panel to build or maintain
Editor, media and categories work out of the box
Clients can manage content themselves
Next.js gives fast pages and good SEO
I use it on my MERN Stack Developer portfolio website, on my dev blog and on QuickPicConvert, a Free online image converter.
Small tip, use ISR so your pages update when you publish something new, without rebuilding the whole site.
Anyone else doing this? Curious what setups you all use.

Why You Should Replace useEffect API Calls With Tanstack React Query

hasnain alam — Sun, 13 Sep 2026 07:28:11 +0000

Every React dev has written this at least once.

useEffect(() => {
  fetchData();
}, []);

It works sure. But once your app gets a bit bigger this pattern starts causing problems, specially performance and backend load.

I'm a Mern stack developer and for a long time i just used useEffect for every single api call in my apps, until i actually tried Tanstack React Query properly. Now i barely write a raw useEffect for fetching data anymore.

Here is why i made the switch.

Your API Gets Called Twice (and its not a bug)

If you're using React 18 with StrictMode, you probably noticed your effects run twice in development. This is intentional, React does this to help catch side effect bugs. But it also means your api is getting hit 2 times on mount which confuses a lot of devs, and even in production if a component remounts often, useEffect fires again and again without any smart caching.

That means more load on your backend for no real reason.

React query fixes this because it caches by query key. If the data is already there and still "fresh" it wont refetch, it just returns the cached data instantly.

Boilerplate for Loading and Error States

With plain useEffect you end up writing this same block over and over.

const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

Do this for every single fetch in a medium size app and you got a lot of repeated code, plus more chances of bugs, like forgetting to reset loading in the catch block or not handling cleanup on unmount.

React Query gives you all this for free from the hook itself, isLoading, isError, data, error, done.

No More Dependency Array Guessing

Dependency arrays are one of the most confusing part of hooks for beginners and even experienced devs mess it up sometime. Missing a dependency causes stale data bugs. Adding too many causes unnecessary re renders and re fetching.

React Query removes this whole problem. You give it a query key and a fetch function, that's it. It manages refetching based on mount, focus, or your staleTime settings, not a manually managed array.

The Real Power: Cache, StaleTime and Invalidation

These are the 3 features that actually changed how i build react apps.

Cache: data fetched once is stored under its key, come back to same page and you instantly see data while it refreshes quietly in background if its stale.
staleTime: tells react query how long the data stays "fresh". Fresh data means no unnecessary refetch, which directly reduces backend calls.
invalidateQueries: after a mutation like updating or deleting something, you just invalidate the related query key and react query refetches it automatically. No manual syncing of state after mutations.

Once you use these together, most of the manual data fetching logic you used to write with useEffect just disappears.

A Project Where This Actually Mattered

I worked on a Next js SaaS platform recently where the dashboard was firing multiple api calls on every tab switch, all because of useEffect running on every mount. The backend was getting hammered with repeated requests and users noticed the slow loading.

After replacing useEffect with react query, adding staleTime, and using invalidateQueries for mutations, the whole dashboard felt way faster and the backend load dropped a lot. That project is live here if you want to see it, it was a Next.js SaaS Platform built for managing mineral owner contact data.

Is useEffect Useless Now

No, not at all. useEffect still has its place for things like subscriptions, event listeners, timers, syncing with non react code etc. Its just not the right tool for data fetching anymore, specially when a purpose built library like react query exists and handles it so much better.

Wrapping Up

As a Mern stack developer i learned this the hard way, after debugging way too many "why is my api getting called 3 times" issues that all came back to useEffect misuse. Switching to react query fixed most of it instantly, and gave me caching and invalidation on top, basically for free.

If you're building serious apps and want to reduce backend load while writing cleaner code, i'd say give react query a shot on your next project. As someone who works as a Full stack Mern & Next.js developer, this is one of those changes i recommend to almost every team i work with now.

I have covered some common issues with Tanstack here, Common React Query Issues, Query Key and Invalidate Queries Problems Explained, where i explained why invalidate queries sometime dont work and how to fix pagination, update and delete cases properly.

Let me know if you already use react query or still on useEffect, curious to hear what others think.

Surviving the iOS Push Notification Setup Process

hasnain alam — Thu, 23 Jul 2026 03:03:36 +0000

Why iOS is a different beast

To be real with you, setting up notifications on Android is like a walk in the park compared to iOS. Apple takes security seriously, which is great for users but a bit of a nightmare for us developers. You can't just drop a config file and call it a day. You have to deal with the Apple Developer Portal, certificates, and provisioning profiles. I've lost count of how many times a notification failed to deliver because of a mismatched Bundle ID or a missing capability in Xcode.

The magic of the P8 file

Back in the day, we used P12 certificates that expired every year. It was a mess. If you forgot to renew it, your app's notifications just stopped working one morning. Thankfully, we now have Authentication Keys (the .p8 file). It's way better because it doesn't expire and one key can work for all your apps. You upload this to your Firebase settings under the Cloud Messaging tab. But make sure you have your Team ID and Key ID ready. If you get those wrong, Firebase won't be able to talk to the Apple Push Notification service (APNs).

Xcode configurations you can't miss

Open your project in Xcode and go to the Signing & Capabilities tab. You need to add two specific things. First is Push Notifications. Second is Background Modes. Inside Background Modes, make sure you check Remote notifications. Without this, your app won't wake up to handle the incoming data when it's in the background. It's a small checkbox, but it's the difference between a working app and a broken one.

// Even if you have the token, you must register for remote notifications on iOS

import { useEffect } from 'react';

import { Platform } from 'react-native';

import messaging from '@react-native-firebase/messaging';

const usePushNotification = () => {


  useEffect(() => {


    if (Platform.OS === 'ios') {


      // This is crucial for iOS device registration


      messaging().registerDeviceForRemoteMessages();


    }


  }, []);


};

I've spent hours debugging iOS notifications only to realize I forgot to enable the capability in Xcode. It happens to the best of us. Take your time with the Developer Portal and double-check every string. Once you get that first 'Hello World' notification on an iPhone, you can breathe a sigh of relief. You've cleared the hardest part of the project.

Hasnain Alam, Full-Stack Developer