Choosing a tech stack

As a Tech Lead, you'll choose the "stack" (or list of technologies) that your team will use.

JumboCode recommends picking "full-stack JavaScript" — that is, choosing JavaScript to be the language you use for both frontend and backend.

I've put together some possible technologies for the common parts of your tech stack. Feel free to ask me if you want any help choosing or to bounce ideas off of someone!

Frontend

JumboCode strongly recommends choosing React as your frontend library. It's common to choose a framework to make working with React easier and to organize your code. Here are a few that JumboCode recommends:

• Next.js
  • Next.js is the most commonly used React framework, created by the hosting company Vercel. It features server-side rendering and other niceties.
  • Next.js allows you to write your backend code alongside your frontend, and it's all contained in one app.
  • Next.js 13 was the first framework that introduced React Server Components, which are a new type of component that executes only on the server. All the components we used to write are now "client" components, which are still possible but not the default. This new tech is called the "app/ router," while the established way of using Next.js is now called the "pages/ router." You can read an introduction into React Server Components in this article.
    • You have the tricky job of picking whether to use the app/ or pages/ router. I'm not sure which to recommend to be honest, but if you're on the fence I'd go with the app/ router — it's conceptually more difficult and has less learning materials online (due to being newer), but also represents the future direction of Next.js and React as a whole.
• Vite
  • Vite is another way to get a React app running.
  • Pros: Very easy to get started; less brittle than something like Next.js; less framework-specific stuff to wrap your head around.
  • Cons: No built-in way of writing an API; no server-side rendering.

Backend

• Next.js Route Handlers
  • Next.js allows you to write little bits of backend alongside your frontend as "API routes" — essentially URLs that fetch data or execute code. You'll need a backend to perform tasks that you can't securely do on the frontend (like fetch data but only according to a certain user's permissions, or update data but only the data that a user is allowed to update).
• Express
  • A classic Node.js server; requires running and hosting a separate Node server in addition to your frontend.
  • There are other alternatives if you are so inclined: Koa, for example.

Database

• MongoDB
  • Pros: flexible, very similar to JSON, easy to host.
  • Cons: easy to lose track of how your data is structured.
• Postgres / MySQL
  • Pros: more robust and scalable, more widely used in industry.
  • Cons: the scheme ("shape") of your data is enforced and if you change the schema of your app's database, all developers need to run the "migration" script that makes that change.

I would say to pick whichever you feel most comfortable in for these databases.

• Firebase
  • I would caution against picking Firebase because you can access it directly from the frontend. This is very cool and convenient, but also removes the need for a backend, which defeats the purpose a bit for developers who are learning.

Styling

• CSS modules
  • (Importing CSS into React components.)
• TailwindCSS
  • Tailwind is, in my opinion, one of the greatest pieces of technologies I have ever had the pleasure of using.
  • However, I would not recommend it if you (the Tech Lead) have not used it before on a project — it has a steep learning curve and may be rough to learn at the same time as your developers.
  • However, if you are drawn to it but haven't used it before, by all means go for it.