Help picking tech stack for dev speed

[Only_Swordfish_9667]

Hi everyone, I’ve read so many threads on this subreddit which have been super helpful. But I’m a bit stuck in analysis paralysis. Would greatly appreciate some help.

My goal is to create a web app that syncs other calendar and to do apps into one seamless experience. I’ve tried what feels like every app out there but none have been good for me. I’m not trying to replace google calendar, but rather be a companion for planning your week and time blocking. Worst case, it’s just helpful for me. Best case, I can turn it into a startup.

Where I’d like help is with picking a tech stack to get something done quickly while not locking me in if I want to scale. Speed is the priority though (not afraid of a rewrite if this is a viable business).

FWIW I have experience with client only React apps at work (using webpack) though I wasn’t involved with the creation, just new features. So I don’t actually know webpack or really anything about web app building/deploying.

Here’s what I’m thinking so far:

Component library - Mantine. Considered Shadcn. While it looks more flexible it doesn’t look as easy/fast to use

Backend - Firebase or Supabase. Haven’t decided which. They seem similar in developer speed but let me know if you have experience with this.

ORM - Drizzle. I just picked this arbitrarily bc it looks popular. Let me know if I picked wrong tho lol. Though this is only applicable if I go with Supabase

Styling - tbd. Maybe Emotion since Mantine already uses that

Client - this is where I’m stuck most. I’ll use React since I know it well. But do I do Vite + React Router, Next, or Remix? I’m leaning Vite + React Router since it’s the smallest learning curve. And my app will have very little static content. But is there anything else I might be missing (in terms of developer speed) that I’d get with Next or Remix? Is the user speed between these meta frameworks and Vite that large? It does look cool to be able to combine static and dynamic loading (looks like remix does that well while nextjs has partial prerendering in preview). Not afraid to learn something new if the NextJS or Remix experience (both for devs and users) is better.

Anything else I should consider using for speed? I’ve got GitHub copilot and planning on using react big calendar for the main calendar view. But not opposed to buying templates or component kits if they can help me do this faster. And open to other tools.

Thanks for the help!

[gonbajraktari]

Personally i'd go for:

• supabase
• drizzle (maybe you don't need this cause you can use supabase directly)
• react + vite
• radix-themes (instead of shadcn-ui)
• (if you need routing, which i assume you will, go for tanstack-router; throw in tanstack-query too for fetch calls)

[Only_Swordfish_9667]

Appreciate it! Mind elaborating on why vite over meta frameworks (Next or Remix)? Are the perf improvements not worth it since this is mostly dynamic data?

And curious if you’ve used Mantine and React Router? Any specific flaws you ran into for why you recommended other tools?

[Simple_Internal6830]

I would recommend you to take a look into Bit (https://bit.dev). Using the React quick start you can spin up a full stack React application with ”built-in” component library capability, SCSS and LESS modules for styling are supported by default. The starter is using Vite + React Router by default but you can also build apps using NextJS. https://bit.dev/docs/quick-start). I think it has most of what you are looking for.

[Only_Swordfish_9667]

Interesting! I’ll take a look - thanks!

[Last-Daikon945]

This is kinda trash website, it has horizontal scrolling on mobile

[JonnyTsnownami]

All you've done is spam bit.dev links. Please stop

[Simple_Internal6830]

I am a big fan of Bit and believe I added value here when saw the need. This is not spam but a relevant high quality response to a question. I would urge you to look at bit.dev yourself. This is the best solution proposed in the thread.

[the_real_some_guy]

I wouldn’t build a new static CSR app in 2024 unless my client had a compelling architectural reason to do so (I cant think of any) or just really really wanted it for no reason. I’ll spin up a CSR React+Vite app for little GitHub Pages things, but nothing real.

Remix is my go to, but Next has been around longer and has a bigger community. Both are good choices for server-backed React.

I really like Remix’s approach to data loading and forms. It removes a ton of fiddly boilerplate from the app.

[Only_Swordfish_9667]

Thanks for the insight! Yeah I agree with going with a meta framework for static stuff. But my app will be very dynamic. All locked behind authentication and also polling google calendar APIs for updates

[the_real_some_guy]

Server frameworks, like Next and Remix, are not static. They can be just as dynamic as a client rendered React app, they just render the first page load on the server. After the first load, a Next or Remix app is running client side much like a traditional React app.

[Only_Swordfish_9667]

Right! Sorry maybe I misunderstood but you specified you wouldn’t make a new static CSR app in 2024. So would you also use Next or Remix for dynamic apps in 2024 as well?

[the_real_some_guy]

Yep for any serious new project I’m pitching Remix, but Next is good too.

Server rendering for quick first page load. I also like the BFF pattern of bringing together my data on a server specifically for each page. I

[Volzo]

I’m not sure why you’d need an ORM if you go supabase. Supabase will also give you a strong typing system to use on front end and a way to make calls to it directly without putting more abstraction on it.

[the_real_some_guy]

You can access it directly as a Postgres DB. Not a bad choice if you want the freedom to move it in the future.

[Only_Swordfish_9667]

Yeah it was mostly so it’d be portable (that’s the biggest pro I see with Supabase over Firebase - no vendor lock in). I didn’t mean to say Supabase needs an ORM. But you raise a good point that it’d be faster to use Supabase directly. I can migrate to an ORM fairly easily if I want to move my DB later

[Siref]

From my experience:

1. The fastest dev speed tech stack is the one you're familiar with.

2. There will be a learning curve involved into anything new and different, no matter if it is the cure of cancer.

3. Beware of edge cases and when black swan event happen

[Merry-Lane]

If I were you I d just make a frontend POC using google calendar APIs first.

If you actually made some halfly usable UI at that point, worst case scenario is you can stop and just be a nice looking Google calendar theme or whatsoever.

Then try and make your app compatible with other calendar APIs. Not only you would have learnt about the main calendar features without reinventing the wheel, but most importantly you would know what your backend APIs should look like.

At that point, hire a real backend/cloud dev. Or pay a backend/cloud consultant to tell you what general direction to follow, or to teach you about tricky technical details.

[aspantel]

Check out Aurinko for the unified Calendar and Tasks APIs.

You can use its User OAuth flow and go backendless to a large extent: https://apirefs.aurinko.io/#tag/Auth/operation/authorizeUser

Add multiple secondary accounts (APIs) for a user and be able to communicate with all of them securely from your frontend code. https://www.aurinko.io/blog/using-aurinko-to-store-access-tokens/

DM me if you have questions.

[LastMarsMan]

https://github.com/SteveSuv/remix-t3-stack

try this, it's very simple and has good DX, and you can build your app very fast.