Open-source marketing automation dashboard — React + Supabase + TailwindCSS #91443
Replies: 3 comments 3 replies
-
|
Nice work! Have you considered adding server-side rendering with Next.js App Router for the dashboard pages? Would improve initial load performance significantly. Also your UTM attribution engine could benefit from Next.js middleware for cleaner URL handling. |
Beta Was this translation helpful? Give feedback.
-
|
Good showcase, but it is not a Next.js project. Please do consider sharing it on other communities likes r/reactjs or r/react over at Reddit. |
Beta Was this translation helpful? Give feedback.
-
|
Next.js consideration — I appreciate the suggestion! However, this project intentionally uses Vite + React for a few specific reasons: Simplicity & Lower Barrier to Entry: Vite offers instant dev server startup and a simpler mental model for developers who want to fork and customize without learning Next.js conventions What do u think about this? |
Beta Was this translation helpful? Give feedback.
-
Next.js deploys to all of these too. This isn't a Vite advantage. You name Vercel as a pro for Vite while also calling it "vendor lock in" for Next.js in the other discussion.
Again, Next.js doesn't require serverless. Self-hosting is totally possible, and platforms do support Next.js. The lock-in coined against Next.js often comes from trying to map features, 1-to-1 to existing infrastructure. And for that the Adapters project exists, to an API for those with an infrastructure, to hook into Next.js features.
Next.js with Turbopack has fast HMR too. When HMR feels slow, it's usually a bottleneck in server-side evaluation, something you'd hit client-side too, just masked as a loading spinner instead.
This is perhaps one of the biggest gaps in education. React Server Components, means you don't have to design into one or the other. A dashboard that ships minimal JS to handle graphs, and other sorts of visualizations, while still allowing you to keep implementation details and API calls, on the server, exposing their results to plain HTML, is not complex. In the worst case, you add 'use client' on every page and get essentially an old SPA. You can easily defer to client side rendering too. The gain, is a dashboard that serves data immediately, and whose performance is not 100% tied to the browser CPU.
This means nothing. It'd be nice to see what you really think and in what experience it is grounded rather than a LLM answer. This is the kind of conversation that advances the ecosystem, but if I am just gonna prompt to a bot through you, then I rather answer at top of the thread instead. |
Beta Was this translation helpful? Give feedback.
-
|
Next.js — Intentional choice. Vite gives us: Zero-config deployment (Vercel/Netlify/CF Pages) SSR would add complexity without measurable gain here. The dashboard is sub-1s load with code-splitting already. If you need SSR, fork it — that's why it's MIT licensed. Bonus: Ship first, optimize later. 9 pages, full attribution engine, and payment webhooks in open source beats bikeshedding framework choices. Hope it helps someone build faster 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
Oh you are the same user as above? Are you spamming now? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Built an open-source marketing automation toolkit with React:
Tech: React 18 + Vite + TailwindCSS + Supabase + Recharts
⭐ GitHub: https://github.com/krishna-build/claude-coach-kit
MIT licensed. Free forever.
Beta Was this translation helpful? Give feedback.
All reactions