Choosing a modern tech stack is difficult because of the sheer number of tools available. Let's look at 8 important decisions you'll need to make when building a web or mobile app today https://fireship.io

#learntocode #programming #tech 

🔗 Resources

Svelte Kit https://kit.svelte.dev
Firebase https://firebase.google.com/
Stack overflow survey https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted
Tech Stacks Explained https://youtu.be/Sxxw3qtb3_g
Svelte in 100 Seconds https://youtu.be/rv3Yq-B8qp4


🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- Best tools to build web apps 
- What is a Tech Stack
- 2022 Developer roadmap
- Web framework comparison
- Top Web Technologies
2024-02-04T05:24:50.479Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
554925a6-089b-40a1-a042-740c7487467b
26b9907ceb09a40848fe779abb445c86965a481be74699baf37a2e0d66ad7d12
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
If you're building a web or mobile app in 2022, there's literally a 1,000,000 different ways to get the job done by combining different front end and back end libraries along with APIs, tooling, and infrastructure to form a complete tech stack.
In today's video, I wanna give you a guided tour of my tech stack, which I plan on using through 2025.
Assuming the world hasn't been destroyed by that point.
Not only will I explain my thought process when making these decisions, but we'll also look at a ton of alternatives that you may want to consider for yourself because you definitely just copy some random guy on YouTube.
Before we get into it, as many of you know, I recently had a baby.
I haven't been uploading quite as many videos, but it's giving me time to work on a complete rebuild of Fireship IO.
And in the process, I've analyzed all kinds of different technologies that I might want to use for that project.
With now I don't really need to rebuild Fireship, but I do it every couple years just because I enjoy the process.
Most of the coding I'll do with my bare hands, but the project will be open source and I will likely collaborate with a couple of other engineers to round out the project.
It's a small team effort, which is an important consideration when choosing your tech stack, because many technologies are more well suited for large teams.
Software engineers love to flex.
That tech stack gotta be busin' or drippin'.
In other words, ridiculously over engineered.
The reality is that I I could build FireShip as a WordPress blog, add a membership plugin, and scale it up to millions of users.
If I wanna make money, that would be the smart thing to with you.
But I wanna build something a little more special than just a WordPress blog.
In the next version of the site, courses will have progress tracking that will also include challenges like quizzes active demos powered by Stackblitz.
In my experience, the majority of modern web development happens on the front end.
That being said, one of the most important decisions to make is your front end UI library, and for with that, I have chosen Svelte.
I've built something with pretty much every UI library on the market.
They all have their pros and cons, but Svelte is the one what feels most productive to me.
And coincidentally, just yesterday, it debuted at the top of the most loved web frameworks on the Stack Overflow 2022 survey.
I think developers love it for how natural it makes reactive data feel.
When a mutable variable changes, the UI reacts.
You don't have to jump through any hoops to make things reactive.
Now, the other thing I really like about Svelte is the way you share data across components, which is done with stores.
A store is like a subject in RxJS that can be observed anywhere in the application by simply putting a dollar sign in front of it.
This pattern is actually very similar to the way things are done in Angular, but Svelte does it with a lot less boilerplate.
The current version of Fireship, is actually built with Angular.
And, in my opinion, Angular is awesome and the most underappreciated framework out there.
It's extremely popular in enterprise for a good reason.
But in 20 with me too.
React is definitely still the most popular UI library and it has a huge ecosystem of supporting libraries.
I think that's the most compelling argument to use it.
When it comes down to the UI library itself.
There are cleaner options out there like SolidJS that would also provide better performance.
I also seriously considered Vue, which is not only a great framework, but also has a large number of supporting libraries as well.
But the more important decision is which meta framework do you wanna use?
React has Next, Vue has Nuxt, Angular has Universal, and Svelte with askit.
Most applications out there need some form of server side rendering to make their sites visible to search engines and bots.
SvelteKit is the official SSR solution it's being worked on by Rich Harris, but as of today, it's still in beta.
Using a framework that's not at a stable release is kind of risky.
You could pour a ton of work into an app, then the framework developers decide to pull a feature on the final release that torpedoes your entire business.
Not very likely, so that's a risk I'm willing to take.
Now, there are other ways to server render Svelte.
Another good option is Astro.
It has a lot of awesome features for content driven sites.
But the reason I prefer SvelteKit for this project is because it does client side routing after the initial page load, which becomes written on more interactive sites, especially when user authentication is involved.
But my plan is to use Astro for my personal portfolio if I ever get around rebuilding it.
Now, the other framework that I would say is my second choice is Next JS.
Next is already a great framework, but it has a bunch of cool stuff coming as well, like nested routing and stuff like that.
I also recently made a video on Nuxt, yet another awesome framework that I hope to make a full course on in the future.
It's also worth mentioning that there's new framework called QUIC that has an entirely different take on rendering with resumable or replayable applications, but even that's a little too bleeding edge for me.
Now when it comes to server rendering, you don't need to using a meta framework that's tied to some JavaScript library.
Instead, you can use a full stack framework like Ruby on Rails, Laravel, Django, or whatever to render all of your content on the server.
These frameworks have advantages for certain types of applications.
But in my case, full blown server side rendering is not really necessary because the content on the actual site doesn't change all that often.
It's far more simple to pre render the entire site, upload it to a storage bucket, and then cache it on a CDN around the world.
When you have a dedicated Urber, you then need to think about how to scale it with either serverless functions, or if you want a really complicated tech stack, something like Kubernetes.
The next thing I want to talk about Ace TypeScript.
If you're building a big complicated project, you should use it.
The end.
A more complicated question you'll have to ask is how am I going to manage my CSS?
Us.
When I work on a solo project, I spend more time dicking around with the CSS than I do writing JavaScript.
It's depressing, man.
I've only got so much time left to hold Fortran 3.
Life goes by much faster than we think.
Yet, here I am, wasting hours of this precious time trying to figure out why this navbar won't be sticky.
That being said, a tool that makes CSS much easier is Tailwind.
End.
Most importantly, it makes prototyping and the implementation of your designs go much faster.
I like to have a lot of control over my designs, because for me, it's a creative process.
Tailwind it won't magically make your website look good, but it does provide enough of a framework to get things done way quicker.
The current version of FireShip is 100% custom with Sass.
With Tailwind, I feel like I have the same amount of control, but things just get done much more rapidly.
And, another huge benefit is that it will automatically purge styles to keep the CSS bundle as small as possible.
That's important because the initial page load speed from my site is critical.
If you like the utility class approach, another option to check out is windy CSS, or if you don't care about having that much control, you can use something like Bootstrap, in addition to many other CSS frameworks out there.
And you've also got tons of framework specific UI why libraries to analyze as well.
And if you're using Tailwind, you should definitely check out Daisy UI, but I'm just doing everything from scratch myself because I'm an idiot.
That's enough for the front end.
Now, I want to talk about the back end.
As you know, I'm a big fan of Firebase and it's been the foundation of this channel from day 1.
But But, as I've grown older and wiser, I've come to realize something about Firebase.
This may be shocking to some of you, but Firebase is still awesome and I plan on using it until the day I die, IE, or at least until Google decides to kill it, whichever comes first.
Firebase will do 90% of what most apps need on the back end.
The main drawback is that you're tightly locked into Google Cloud Platform with Swarm, and you may run into edge cases that it just doesn't support, like advanced authentication features or complex database queries, and that can be a deal breaker for certain types with apps.
What you could do is architect your entire back end from scratch by picking and choosing different services in the cloud, but then the complexity of your code base is going to explode.
Luckily in 2022, there are quite a few alternatives to Firebase.
You've got big ones like AWS Amplify and MongoDB Realm, and then smaller start apps like Enho, Supabase, and AppRite.
I recently compared all of them, and each one has its own set of unique trade offs.
Expect a full video on that Xun.
The most important thing is the database.
Firebase uses Firestore, which is a document database similar to MongoDB, which can get the job done for most apps, but does have some limitations that can be kind of annoying at times.
A traditional SQL database is probably the safest bet for most people, but they're generally harder to work with.
Although, there are some services out there like PlanetScale and CockroachDB, that have made things a lot easier in recent years, especially when used with an ORM like Prisma.
In addition, you might consider other NoSQL databases like Redis and Cassandra, which can actually be used as a primary app database.
Now in addition to the back end, there are a lot of other smaller tools in the stack.
When it comes to testing, I find that I need to keep things very simple, otherwise I'm not going to test anything at all.
And my preferred way to do that is with Cypress, RISC, which is basically an all in one package that can do everything from end to end tests to individual unit tests and everything in between.
If you're not into Cypress, another good option for end to end testing is Playwright.
And if you just wanna do unit tests, another framework I've really been wanting to try out is Vtest, which is based on Vite, the build tool that powers SvelteKit.
My tech stack also uses variety of APIs to do things that I can't do on my own.
One of which is send transactional email.
I currently use SendGrid and will continue doing so in the future, but I wish Firebase or Google Cloud would come out with its own email service.
In addition, a content driven site needs to have really good full text search.
To handle that, I'm using Lia.
Algolia can get pretty expensive on very large sites, but for me it's pretty inexpensive and very easy to use.
This is yet another feature I wish would be implemented into Firebase, but I'm not going to hold my breath.
And finally, I'll be using Stripe and PayPal to manage payments because to be honest, I haven't looked at any alternatives in a long time.
The end result is a pretty simple tech stack, with the main components being Sveltekit and Firebase.
The only major problem is that it doesn't form an obvious acronym.
We could go with the FIST stack, or maybe FireKit or perhaps bucket, but I don't know man.
Let me know if you have a better idea.
Thanks for watching, and I will see you in the next one.

Speaker 0: If you're building a web or mobile app in 2022, there's literally a 1,000,000 different ways to get the job done by combining different front end and back end libraries along with APIs, tooling, and infrastructure to form a complete tech stack. In today's video, I wanna give you a guided tour of my tech stack, which I plan on using through 2025. Assuming the world hasn't been destroyed by that point. Not only will I explain my thought process when making these decisions, but we'll also look at a ton of alternatives that you may want to consider for yourself because you definitely just copy some random guy on YouTube. Before we get into it, as many of you know, I recently had a baby.

I haven't been uploading quite as many videos, but it's giving me time to work on a complete rebuild of Fireship IO. And in the process, I've analyzed all kinds of different technologies that I might want to use for that project. With now I don't really need to rebuild Fireship, but I do it every couple years just because I enjoy the process. Most of the coding I'll do with my bare hands, but the project will be open source and I will likely collaborate with a couple of other engineers to round out the project. It's a small team effort, which is an important consideration when choosing your tech stack, because many technologies are more well suited for large teams.

Software engineers love to flex. That tech stack gotta be busin' or drippin'. In other words, ridiculously over engineered. The reality is that I I could build FireShip as a WordPress blog, add a membership plugin, and scale it up to millions of users. If I wanna make money, that would be the smart thing to with you.

But I wanna build something a little more special than just a WordPress blog. In the next version of the site, courses will have progress tracking that will also include challenges like quizzes active demos powered by Stackblitz. In my experience, the majority of modern web development happens on the front end. That being said, one of the most important decisions to make is your front end UI library, and for with that, I have chosen Svelte. I've built something with pretty much every UI library on the market.

They all have their pros and cons, but Svelte is the one what feels most productive to me. And coincidentally, just yesterday, it debuted at the top of the most loved web frameworks on the Stack Overflow 2022 survey. I think developers love it for how natural it makes reactive data feel. When a mutable variable changes, the UI reacts. You don't have to jump through any hoops to make things reactive.

Now, the other thing I really like about Svelte is the way you share data across components, which is done with stores. A store is like a subject in RxJS that can be observed anywhere in the application by simply putting a dollar sign in front of it. This pattern is actually very similar to the way things are done in Angular, but Svelte does it with a lot less boilerplate. The current version of Fireship, is actually built with Angular. And, in my opinion, Angular is awesome and the most underappreciated framework out there.

It's extremely popular in enterprise for a good reason. But in 20 with me too. React is definitely still the most popular UI library and it has a huge ecosystem of supporting libraries. I think that's the most compelling argument to use it. When it comes down to the UI library itself.

There are cleaner options out there like SolidJS that would also provide better performance. I also seriously considered Vue, which is not only a great framework, but also has a large number of supporting libraries as well. But the more important decision is which meta framework do you wanna use? React has Next, Vue has Nuxt, Angular has Universal, and Svelte with askit. Most applications out there need some form of server side rendering to make their sites visible to search engines and bots.

SvelteKit is the official SSR solution it's being worked on by Rich Harris, but as of today, it's still in beta. Using a framework that's not at a stable release is kind of risky. You could pour a ton of work into an app, then the framework developers decide to pull a feature on the final release that torpedoes your entire business. Not very likely, so that's a risk I'm willing to take. Now, there are other ways to server render Svelte.

Another good option is Astro. It has a lot of awesome features for content driven sites. But the reason I prefer SvelteKit for this project is because it does client side routing after the initial page load, which becomes written on more interactive sites, especially when user authentication is involved. But my plan is to use Astro for my personal portfolio if I ever get around rebuilding it. Now, the other framework that I would say is my second choice is Next JS.

Next is already a great framework, but it has a bunch of cool stuff coming as well, like nested routing and stuff like that. I also recently made a video on Nuxt, yet another awesome framework that I hope to make a full course on in the future. It's also worth mentioning that there's new framework called QUIC that has an entirely different take on rendering with resumable or replayable applications, but even that's a little too bleeding edge for me. Now when it comes to server rendering, you don't need to using a meta framework that's tied to some JavaScript library. Instead, you can use a full stack framework like Ruby on Rails, Laravel, Django, or whatever to render all of your content on the server.

These frameworks have advantages for certain types of applications. But in my case, full blown server side rendering is not really necessary because the content on the actual site doesn't change all that often. It's far more simple to pre render the entire site, upload it to a storage bucket, and then cache it on a CDN around the world. When you have a dedicated Urber, you then need to think about how to scale it with either serverless functions, or if you want a really complicated tech stack, something like Kubernetes. The next thing I want to talk about Ace TypeScript.

If you're building a big complicated project, you should use it. The end. A more complicated question you'll have to ask is how am I going to manage my CSS? Us. When I work on a solo project, I spend more time dicking around with the CSS than I do writing JavaScript.

It's depressing, man. I've only got so much time left to hold Fortran 3. Life goes by much faster than we think. Yet, here I am, wasting hours of this precious time trying to figure out why this navbar won't be sticky. That being said, a tool that makes CSS much easier is Tailwind.

End. Most importantly, it makes prototyping and the implementation of your designs go much faster. I like to have a lot of control over my designs, because for me, it's a creative process. Tailwind it won't magically make your website look good, but it does provide enough of a framework to get things done way quicker. The current version of FireShip is 100% custom with Sass.

With Tailwind, I feel like I have the same amount of control, but things just get done much more rapidly. And, another huge benefit is that it will automatically purge styles to keep the CSS bundle as small as possible. That's important because the initial page load speed from my site is critical. If you like the utility class approach, another option to check out is windy CSS, or if you don't care about having that much control, you can use something like Bootstrap, in addition to many other CSS frameworks out there. And you've also got tons of framework specific UI why libraries to analyze as well.

And if you're using Tailwind, you should definitely check out Daisy UI, but I'm just doing everything from scratch myself because I'm an idiot. That's enough for the front end. Now, I want to talk about the back end. As you know, I'm a big fan of Firebase and it's been the foundation of this channel from day 1. But But, as I've grown older and wiser, I've come to realize something about Firebase.

This may be shocking to some of you, but Firebase is still awesome and I plan on using it until the day I die, IE, or at least until Google decides to kill it, whichever comes first. Firebase will do 90% of what most apps need on the back end. The main drawback is that you're tightly locked into Google Cloud Platform with Swarm, and you may run into edge cases that it just doesn't support, like advanced authentication features or complex database queries, and that can be a deal breaker for certain types with apps. What you could do is architect your entire back end from scratch by picking and choosing different services in the cloud, but then the complexity of your code base is going to explode. Luckily in 2022, there are quite a few alternatives to Firebase.

You've got big ones like AWS Amplify and MongoDB Realm, and then smaller start apps like Enho, Supabase, and AppRite. I recently compared all of them, and each one has its own set of unique trade offs. Expect a full video on that Xun. The most important thing is the database. Firebase uses Firestore, which is a document database similar to MongoDB, which can get the job done for most apps, but does have some limitations that can be kind of annoying at times.

A traditional SQL database is probably the safest bet for most people, but they're generally harder to work with. Although, there are some services out there like PlanetScale and CockroachDB, that have made things a lot easier in recent years, especially when used with an ORM like Prisma. In addition, you might consider other NoSQL databases like Redis and Cassandra, which can actually be used as a primary app database. Now in addition to the back end, there are a lot of other smaller tools in the stack. When it comes to testing, I find that I need to keep things very simple, otherwise I'm not going to test anything at all.

And my preferred way to do that is with Cypress, RISC, which is basically an all in one package that can do everything from end to end tests to individual unit tests and everything in between. If you're not into Cypress, another good option for end to end testing is Playwright. And if you just wanna do unit tests, another framework I've really been wanting to try out is Vtest, which is based on Vite, the build tool that powers SvelteKit. My tech stack also uses variety of APIs to do things that I can't do on my own. One of which is send transactional email.

I currently use SendGrid and will continue doing so in the future, but I wish Firebase or Google Cloud would come out with its own email service. In addition, a content driven site needs to have really good full text search. To handle that, I'm using Lia. Algolia can get pretty expensive on very large sites, but for me it's pretty inexpensive and very easy to use. This is yet another feature I wish would be implemented into Firebase, but I'm not going to hold my breath.

And finally, I'll be using Stripe and PayPal to manage payments because to be honest, I haven't looked at any alternatives in a long time. The end result is a pretty simple tech stack, with the main components being Sveltekit and Firebase. The only major problem is that it doesn't form an obvious acronym. We could go with the FIST stack, or maybe FireKit or perhaps bucket, but I don't know man. Let me know if you have a better idea.

Thanks for watching, and I will see you in the next one.
If you're building a web or mobile app in 2022, there's literally a 1,000,000 different ways to get the job done by combining different front end and back end libraries along with APIs, tooling, and infrastructure to form a complete tech stack. In today's video, I wanna give you a guided tour of my tech stack, which I plan on using through 2025. Assuming the world hasn't been destroyed by that point. Not only will I explain my thought process when making these decisions, but we'll also look at a ton of alternatives that you may want to consider for yourself because you definitely just copy some random guy on YouTube.
technology
infrastructure
internet
robotics
Before we get into it, as many of you know, I recently had a baby. I haven't been uploading quite as many videos, but it's giving me time to work on a complete rebuild of Fireship IO. And in the process, I've analyzed all kinds of different technologies that I might want to use for that project.
streaming
multimedia
With now I don't really need to rebuild Fireship, but I do it every couple years just because I enjoy the process.
Most of the coding I'll do with my bare hands, but the project will be open source and I will likely collaborate with a couple of other engineers to round out the project. It's a small team effort, which is an important consideration when choosing your tech stack, because many technologies are more well suited for large teams. Software engineers love to flex. That tech stack gotta be busin' or drippin'. In other words, ridiculously over engineered. The reality is that I I could build FireShip as a WordPress blog, add a membership plugin, and scale it up to millions of users. If I wanna make money, that would be the smart thing to with you. But I wanna build something a little more special than just a WordPress blog. In the next version of the site, courses will have progress tracking that will also include challenges like quizzes active demos powered by Stackblitz. In my experience, the majority of modern web development happens on the front end. That being said, one of the most important decisions to make is your front end UI library, and for with that, I have chosen Svelte.
blogging
engineering
computer science
software development
technology
computers
infrastructure
I've built something with pretty much every UI library on the market. They all have their pros and cons, but Svelte is the one what feels most productive to me. And coincidentally, just yesterday, it debuted at the top of the most loved web frameworks on the Stack Overflow 2022 survey.
computer science
computers
I think developers love it for how natural it makes reactive data feel. When a mutable variable changes, the UI reacts. You don't have to jump through any hoops to make things reactive. Now, the other thing I really like about Svelte is the way you share data across components, which is done with stores. A store is like a subject in RxJS that can be observed anywhere in the application by simply putting a dollar sign in front of it. This pattern is actually very similar to the way things are done in Angular, but Svelte does it with a lot less boilerplate. The current version of Fireship, is actually built with Angular. And, in my opinion, Angular is awesome and the most underappreciated framework out there. It's extremely popular in enterprise for a good reason. But in 20 with me too. React is definitely still the most popular UI library and it has a huge ecosystem of supporting libraries. I think that's the most compelling argument to use it.
When it comes down to the UI library itself. There are cleaner options out there like SolidJS that would also provide better performance. I also seriously considered Vue, which is not only a great framework, but also has a large number of supporting libraries as well. But the more important decision is which meta framework do you wanna use?
software
React has Next, Vue has Nuxt, Angular has Universal, and Svelte with askit. Most applications out there need some form of server side rendering to make their sites visible to search engines and bots. SvelteKit is the official SSR solution it's being worked on by Rich Harris, but as of today, it's still in beta.
Using a framework that's not at a stable release is kind of risky. You could pour a ton of work into an app, then the framework developers decide to pull a feature on the final release that torpedoes your entire business. Not very likely, so that's a risk I'm willing to take.
software
software development
Now, there are other ways to server render Svelte. Another good option is Astro.
It has a lot of awesome features for content driven sites. But the reason I prefer SvelteKit for this project is because it does client side routing after the initial page load, which becomes written on more interactive sites, especially when user authentication is involved. But my plan is to use Astro for my personal portfolio if I ever get around rebuilding it. Now, the other framework that I would say is my second choice is Next JS. Next is already a great framework, but it has a bunch of cool stuff coming as well, like nested routing and stuff like that. I also recently made a video on Nuxt, yet another awesome framework that I hope to make a full course on in the future. It's also worth mentioning that there's new framework called QUIC that has an entirely different take on rendering with resumable or replayable applications, but even that's a little too bleeding edge for me. Now when it comes to server rendering, you don't need to using a meta framework that's tied to some JavaScript library.
astrology
graphic design
software
Instead, you can use a full stack framework like Ruby on Rails, Laravel, Django, or whatever to render all of your content on the server. These frameworks have advantages for certain types of applications. But in my case, full blown server side rendering is not really necessary because the content on the actual site doesn't change all that often. It's far more simple to pre render the entire site, upload it to a storage bucket, and then cache it on a CDN around the world. When you have a dedicated Urber, you then need to think about how to scale it with either serverless functions, or if you want a really complicated tech stack, something like Kubernetes.
The next thing I want to talk about Ace TypeScript. If you're building a big complicated project, you should use it. The end. A more complicated question you'll have to ask is how am I going to manage my CSS? Us. When I work on a solo project, I spend more time dicking around with the CSS than I do writing JavaScript.
graphic design
It's depressing, man. I've only got so much time left to hold Fortran 3. Life goes by much faster than we think. Yet, here I am, wasting hours of this precious time trying to figure out why this navbar won't be sticky.
That being said, a tool that makes CSS much easier is Tailwind. End. Most importantly, it makes prototyping and the implementation of your designs go much faster. I like to have a lot of control over my designs, because for me, it's a creative process. Tailwind it won't magically make your website look good, but it does provide enough of a framework to get things done way quicker.
graphic design
The current version of FireShip is 100% custom with Sass. With Tailwind, I feel like I have the same amount of control, but things just get done much more rapidly. And, another huge benefit is that it will automatically purge styles to keep the CSS bundle as small as possible. That's important because the initial page load speed from my site is critical. If you like the utility class approach, another option to check out is windy CSS, or if you don't care about having that much control, you can use something like Bootstrap, in addition to many other CSS frameworks out there. And you've also got tons of framework specific UI why libraries to analyze as well. And if you're using Tailwind, you should definitely check out Daisy UI, but I'm just doing everything from scratch myself because I'm an idiot. That's enough for the front end. Now, I want to talk about the back end. As you know, I'm a big fan of Firebase and it's been the foundation of this channel from day 1. But But, as I've grown older and wiser, I've come to realize something about Firebase. This may be shocking to some of you, but Firebase is still awesome and I plan on using it until the day I die, IE, or at least until Google decides to kill it, whichever comes first. Firebase will do 90% of what most apps need on the back end. The main drawback is that you're tightly locked into Google Cloud Platform with Swarm, and you may run into edge cases that it just doesn't support, like advanced authentication features or complex database queries, and that can be a deal breaker for certain types with apps. What you could do is architect your entire back end from scratch by picking and choosing different services in the cloud, but then the complexity of your code base is going to explode.
Luckily in 2022, there are quite a few alternatives to Firebase. You've got big ones like AWS Amplify and MongoDB Realm, and then smaller start apps like Enho, Supabase, and AppRite. I recently compared all of them, and each one has its own set of unique trade offs. Expect a full video on that Xun. The most important thing is the database. Firebase uses Firestore, which is a document database similar to MongoDB, which can get the job done for most apps, but does have some limitations that can be kind of annoying at times. A traditional SQL database is probably the safest bet for most people, but they're generally harder to work with. Although, there are some services out there like PlanetScale and CockroachDB, that have made things a lot easier in recent years, especially when used with an ORM like Prisma. In addition, you might consider other NoSQL databases like Redis and Cassandra, which can actually be used as a primary app database. Now in addition to the back end, there are a lot of other smaller tools in the stack. When it comes to testing, I find that I need to keep things very simple, otherwise I'm not going to test anything at all.
databases
data management
streaming
amazon
And my preferred way to do that is with Cypress, RISC, which is basically an all in one package that can do everything from end to end tests to individual unit tests and everything in between. If you're not into Cypress, another good option for end to end testing is Playwright. And if you just wanna do unit tests, another framework I've really been wanting to try out is Vtest, which is based on Vite, the build tool that powers SvelteKit.
My tech stack also uses variety of APIs to do things that I can't do on my own. One of which is send transactional email. I currently use SendGrid and will continue doing so in the future, but I wish Firebase or Google Cloud would come out with its own email service. In addition, a content driven site needs to have really good full text search. To handle that, I'm using Lia. Algolia can get pretty expensive on very large sites, but for me it's pretty inexpensive and very easy to use. This is yet another feature I wish would be implemented into Firebase, but I'm not going to hold my breath.
websites
internet
email
networking
streaming
And finally, I'll be using Stripe and PayPal to manage payments because to be honest, I haven't looked at any alternatives in a long time. The end result is a pretty simple tech stack, with the main components being Sveltekit and Firebase. The only major problem is that it doesn't form an obvious acronym. We could go with the FIST stack, or maybe FireKit or perhaps bucket, but I don't know man. Let me know if you have a better idea. Thanks for watching, and I will see you in the next one.
If you're building a web or mobile app in 2022, there's literally a 1,000,000 different ways to get the job done by combining different front end and back end libraries along with APIs, tooling, and infrastructure to form a complete tech stack. In today's video, I wanna give you a guided tour of my tech stack, which I plan on using through 2025. Assuming the world hasn't been destroyed by that point. Not only will I explain my thought process when making these decisions, but we'll also look at a ton of alternatives that you may want to consider for yourself because you definitely just copy some random guy on YouTube. Before we get into it, as many of you know, I recently had a baby. I haven't been uploading quite as many videos, but it's giving me time to work on a complete rebuild of Fireship IO. And in the process, I've analyzed all kinds of different technologies that I might want to use for that project. With now I don't really need to rebuild Fireship, but I do it every couple years just because I enjoy the process. Most of the coding I'll do with my bare hands, but the project will be open source and I will likely collaborate with a couple of other engineers to round out the project. It's a small team effort, which is an important consideration when choosing your tech stack, because many technologies are more well suited for large teams. Software engineers love to flex. That tech stack gotta be busin' or drippin'. In other words, ridiculously over engineered. The reality is that I I could build FireShip as a WordPress blog, add a membership plugin, and scale it up to millions of users. If I wanna make money, that would be the smart thing to with you. But I wanna build something a little more special than just a WordPress blog. In the next version of the site, courses will have progress tracking that will also include challenges like quizzes active demos powered by Stackblitz. In my experience, the majority of modern web development happens on the front end. That being said, one of the most important decisions to make is your front end UI library, and for with that, I have chosen Svelte. I've built something with pretty much every UI library on the market. They all have their pros and cons, but Svelte is the one what feels most productive to me. And coincidentally, just yesterday, it debuted at the top of the most loved web frameworks on the Stack Overflow 2022 survey. I think developers love it for how natural it makes reactive data feel. When a mutable variable changes, the UI reacts. You don't have to jump through any hoops to make things reactive. Now, the other thing I really like about Svelte is the way you share data across components, which is done with stores. A store is like a subject in RxJS that can be observed anywhere in the application by simply putting a dollar sign in front of it. This pattern is actually very similar to the way things are done in Angular, but Svelte does it with a lot less boilerplate. The current version of Fireship, is actually built with Angular. And, in my opinion, Angular is awesome and the most underappreciated framework out there. It's extremely popular in enterprise for a good reason. But in 20 with me too. React is definitely still the most popular UI library and it has a huge ecosystem of supporting libraries. I think that's the most compelling argument to use it. When it comes down to the UI library itself. There are cleaner options out there like SolidJS that would also provide better performance. I also seriously considered Vue, which is not only a great framework, but also has a large number of supporting libraries as well. But the more important decision is which meta framework do you wanna use? React has Next, Vue has Nuxt, Angular has Universal, and Svelte with askit. Most applications out there need some form of server side rendering to make their sites visible to search engines and bots. SvelteKit is the official SSR solution it's being worked on by Rich Harris, but as of today, it's still in beta. Using a framework that's not at a stable release is kind of risky. You could pour a ton of work into an app, then the framework developers decide to pull a feature on the final release that torpedoes your entire business. Not very likely, so that's a risk I'm willing to take. Now, there are other ways to server render Svelte. Another good option is Astro. It has a lot of awesome features for content driven sites. But the reason I prefer SvelteKit for this project is because it does client side routing after the initial page load, which becomes written on more interactive sites, especially when user authentication is involved. But my plan is to use Astro for my personal portfolio if I ever get around rebuilding it. Now, the other framework that I would say is my second choice is Next JS. Next is already a great framework, but it has a bunch of cool stuff coming as well, like nested routing and stuff like that. I also recently made a video on Nuxt, yet another awesome framework that I hope to make a full course on in the future. It's also worth mentioning that there's new framework called QUIC that has an entirely different take on rendering with resumable or replayable applications, but even that's a little too bleeding edge for me. Now when it comes to server rendering, you don't need to using a meta framework that's tied to some JavaScript library. Instead, you can use a full stack framework like Ruby on Rails, Laravel, Django, or whatever to render all of your content on the server. These frameworks have advantages for certain types of applications. But in my case, full blown server side rendering is not really necessary because the content on the actual site doesn't change all that often. It's far more simple to pre render the entire site, upload it to a storage bucket, and then cache it on a CDN around the world. When you have a dedicated Urber, you then need to think about how to scale it with either serverless functions, or if you want a really complicated tech stack, something like Kubernetes. The next thing I want to talk about Ace TypeScript. If you're building a big complicated project, you should use it. The end. A more complicated question you'll have to ask is how am I going to manage my CSS? Us. When I work on a solo project, I spend more time dicking around with the CSS than I do writing JavaScript. It's depressing, man. I've only got so much time left to hold Fortran 3. Life goes by much faster than we think. Yet, here I am, wasting hours of this precious time trying to figure out why this navbar won't be sticky. That being said, a tool that makes CSS much easier is Tailwind. End. Most importantly, it makes prototyping and the implementation of your designs go much faster. I like to have a lot of control over my designs, because for me, it's a creative process. Tailwind it won't magically make your website look good, but it does provide enough of a framework to get things done way quicker. The current version of FireShip is 100% custom with Sass. With Tailwind, I feel like I have the same amount of control, but things just get done much more rapidly. And, another huge benefit is that it will automatically purge styles to keep the CSS bundle as small as possible. That's important because the initial page load speed from my site is critical. If you like the utility class approach, another option to check out is windy CSS, or if you don't care about having that much control, you can use something like Bootstrap, in addition to many other CSS frameworks out there. And you've also got tons of framework specific UI why libraries to analyze as well. And if you're using Tailwind, you should definitely check out Daisy UI, but I'm just doing everything from scratch myself because I'm an idiot. That's enough for the front end. Now, I want to talk about the back end. As you know, I'm a big fan of Firebase and it's been the foundation of this channel from day 1. But But, as I've grown older and wiser, I've come to realize something about Firebase. This may be shocking to some of you, but Firebase is still awesome and I plan on using it until the day I die, IE, or at least until Google decides to kill it, whichever comes first. Firebase will do 90% of what most apps need on the back end. The main drawback is that you're tightly locked into Google Cloud Platform with Swarm, and you may run into edge cases that it just doesn't support, like advanced authentication features or complex database queries, and that can be a deal breaker for certain types with apps. What you could do is architect your entire back end from scratch by picking and choosing different services in the cloud, but then the complexity of your code base is going to explode. Luckily in 2022, there are quite a few alternatives to Firebase. You've got big ones like AWS Amplify and MongoDB Realm, and then smaller start apps like Enho, Supabase, and AppRite. I recently compared all of them, and each one has its own set of unique trade offs. Expect a full video on that Xun. The most important thing is the database. Firebase uses Firestore, which is a document database similar to MongoDB, which can get the job done for most apps, but does have some limitations that can be kind of annoying at times. A traditional SQL database is probably the safest bet for most people, but they're generally harder to work with. Although, there are some services out there like PlanetScale and CockroachDB, that have made things a lot easier in recent years, especially when used with an ORM like Prisma. In addition, you might consider other NoSQL databases like Redis and Cassandra, which can actually be used as a primary app database. Now in addition to the back end, there are a lot of other smaller tools in the stack. When it comes to testing, I find that I need to keep things very simple, otherwise I'm not going to test anything at all. And my preferred way to do that is with Cypress, RISC, which is basically an all in one package that can do everything from end to end tests to individual unit tests and everything in between. If you're not into Cypress, another good option for end to end testing is Playwright. And if you just wanna do unit tests, another framework I've really been wanting to try out is Vtest, which is based on Vite, the build tool that powers SvelteKit. My tech stack also uses variety of APIs to do things that I can't do on my own. One of which is send transactional email. I currently use SendGrid and will continue doing so in the future, but I wish Firebase or Google Cloud would come out with its own email service. In addition, a content driven site needs to have really good full text search. To handle that, I'm using Lia. Algolia can get pretty expensive on very large sites, but for me it's pretty inexpensive and very easy to use. This is yet another feature I wish would be implemented into Firebase, but I'm not going to hold my breath. And finally, I'll be using Stripe and PayPal to manage payments because to be honest, I haven't looked at any alternatives in a long time. The end result is a pretty simple tech stack, with the main components being Sveltekit and Firebase. The only major problem is that it doesn't form an obvious acronym. We could go with the FIST stack, or maybe FireKit or perhaps bucket, but I don't know man. Let me know if you have a better idea. Thanks for watching, and I will see you in the next one.
If
if
you're
you're
building
building
a
a
web
web
or
or
mobile
mobile
app
app
in
in
2022,
2022
there's
there's
literally
literally
a
a
1,000,000
1,000,000
different
different
ways
ways
to
to
get
get
the
the
job
job
done
done
by
by
combining
combining
different
different
front
front
end
end
and
and
back
back
end
end
libraries
libraries
along
along
with
with
APIs,
apis
tooling,
tooling
and
and
infrastructure
infrastructure
to
to
form
form
a
a
complete
complete
tech
tech
stack.
stack
In
in
today's
today's
video,
video
I
i
wanna
wanna
give
give
you
you
a
a
guided
guided
tour
tour
of
of
my
my
tech
tech
stack,
stack
which
which
I
i
plan
plan
on
on
using
using
through
through
2025.
2025
Assuming
assuming
the
the
world
world
hasn't
hasn't
been
been
destroyed
destroyed
by
by
that
that
point.
point
Not
not
only
only
will
will
I
i
explain
explain
my
my
thought
thought
process
process
when
when
making
making
these
these
decisions,
decisions
but
but
we'll
we'll
also
also
look
look
at
at
a
a
ton
ton
of
of
alternatives
alternatives
that
that
you
you
may
may
want
want
to
to
consider
consider
for
for
yourself
yourself
because
because
you
you
definitely
definitely
just
just
copy
copy
some
some
random
random
guy
guy
on
on
YouTube.
youtube
Before
before
we
we
get
get
into
into
it,
it
as
as
many
many
of
of
you
you
know,
know
I
i
recently
recently
had
had
a
a
baby.
baby
I
i
haven't
haven't
been
been
uploading
uploading
quite
quite
as
as
many
many
videos,
videos
but
but
it's
it's
giving
giving
me
me
time
time
to
to
work
work
on
on
a
a
complete
complete
rebuild
rebuild
of
of
Fireship
fireship
IO.
io
And
and
in
in
the
the
process,
process
I've
i've
analyzed
analyzed
all
all
kinds
kinds
of
of
different
different
technologies
technologies
that
that
I
i
might
might
want
want
to
to
use
use
for
for
that
that
project.
project
With
with
now
now
I
i
don't
don't
really
really
need
need
to
to
rebuild
rebuild
Fireship,
fireship
but
but
I
i
do
do
it
it
every
every
couple
couple
years
years
just
just
because
because
I
i
enjoy
enjoy
the
the
process.
process
Most
most
of
of
the
the
coding
coding
I'll
i'll
do
do
with
with
my
my
bare
bare
hands,
hands
but
but
the
the
project
project
will
will
be
be
open
open
source
source
and
and
I
i
will
will
likely
likely
collaborate
collaborate
with
with
a
a
couple
couple
of
of
other
other
engineers
engineers
to
to
round
round
out
out
the
the
project.
project
It's
it's
a
a
small
small
team
team
effort,
effort
which
which
is
is
an
an
important
important
consideration
consideration
when
when
choosing
choosing
your
your
tech
tech
stack,
stack
because
because
many
many
technologies
technologies
are
are
more
more
well
well
suited
suited
for
for
large
large
teams.
teams
Software
software
engineers
engineers
love
love
to
to
flex.
flex
That
that
tech
tech
stack
stack
gotta
gotta
be
be
busin'
busin'
or
or
drippin'.
drippin'
In
in
other
other
words,
words
ridiculously
ridiculously
over
over
engineered.
engineered
The
the
reality
reality
is
is
that
that
I
i
I
i
could
could
build
build
FireShip
fireship
as
as
a
a
WordPress
wordpress
blog,
blog
add
add
a
a
membership
membership
plugin,
plugin
and
and
scale
scale
it
it
up
up
to
to
millions
millions
of
of
users.
users
If
if
I
i
wanna
wanna
make
make
money,
money
that
that
would
would
be
be
the
the
smart
smart
thing
thing
to
to
with
with
you.
you
But
but
I
i
wanna
wanna
build
build
something
something
a
a
little
little
more
more
special
special
than
than
just
just
a
a
WordPress
wordpress
blog.
blog
In
in
the
the
next
next
version
version
of
of
the
the
site,
site
courses
courses
will
will
have
have
progress
progress
tracking
tracking
that
that
will
will
also
also
include
include
challenges
challenges
like
like
quizzes
quizzes
active
active
demos
demos
powered
powered
by
by
Stackblitz.
stackblitz
In
in
my
my
experience,
experience
the
the
majority
majority
of
of
modern
modern
web
web
development
development
happens
happens
on
on
the
the
front
front
end.
end
That
that
being
being
said,
said
one
one
of
of
the
the
most
most
important
important
decisions
decisions
to
to
make
make
is
is
your
your
front
front
end
end
UI
ui
library,
library
and
and
for
for
with
with
that,
that
I
i
have
have
chosen
chosen
Svelte.
svelte
I've
i've
built
built
something
something
with
with
pretty
pretty
much
much
every
every
UI
ui
library
library
on
on
the
the
market.
market
They
they
all
all
have
have
their
their
pros
pros
and
and
cons,
cons
but
but
Svelte
svelte
is
is
the
the
one
one
what
what
feels
feels
most
most
productive
productive
to
to
me.
me
And
and
coincidentally,
coincidentally
just
just
yesterday,
yesterday
it
it
debuted
debuted
at
at
the
the
top
top
of
of
the
the
most
most
loved
loved
web
web
frameworks
frameworks
on
on
the
the
Stack
stack
Overflow
overflow
2022
2022
survey.
survey
I
i
think
think
developers
developers
love
love
it
it
for
for
how
how
natural
natural
it
it
makes
makes
reactive
reactive
data
data
feel.
feel
When
when
a
a
mutable
mutable
variable
variable
changes,
changes
the
the
UI
ui
reacts.
reacts
You
you
don't
don't
have
have
to
to
jump
jump
through
through
any
any
hoops
hoops
to
to
make
make
things
things
reactive.
reactive
Now,
now
the
the
other
other
thing
thing
I
i
really
really
like
like
about
about
Svelte
svelte
is
is
the
the
way
way
you
you
share
share
data
data
across
across
components,
components
which
which
is
is
done
done
with
with
stores.
stores
A
a
store
store
is
is
like
like
a
a
subject
subject
in
in
RxJS
rxjs
that
that
can
can
be
be
observed
observed
anywhere
anywhere
in
in
the
the
application
application
by
by
simply
simply
putting
putting
a
a
dollar
dollar
sign
sign
in
in
front
front
of
of
it.
it
This
this
pattern
pattern
is
is
actually
actually
very
very
similar
similar
to
to
the
the
way
way
things
things
are
are
done
done
in
in
Angular,
angular
but
but
Svelte
svelte
does
does
it
it
with
with
a
a
lot
lot
less
less
boilerplate.
boilerplate
The
the
current
current
version
version
of
of
Fireship,
fireship
is
is
actually
actually
built
built
with
with
Angular.
angular
And,
and
in
in
my
my
opinion,
opinion
Angular
angular
is
is
awesome
awesome
and
and
the
the
most
most
underappreciated
underappreciated
framework
framework
out
out
there.
there
It's
it's
extremely
extremely
popular
popular
in
in
enterprise
enterprise
for
for
a
a
good
good
reason.
reason
But
but
in
in
20
20
with
with
me
me
too.
too
React
react
is
is
definitely
definitely
still
still
the
the
most
most
popular
popular
UI
ui
library
library
and
and
it
it
has
has
a
a
huge
huge
ecosystem
ecosystem
of
of
supporting
supporting
libraries.
libraries
I
i
think
think
that's
that's
the
the
most
most
compelling
compelling
argument
argument
to
to
use
use
it.
it
When
when
it
it
comes
comes
down
down
to
to
the
the
UI
ui
library
library
itself.
itself
There
there
are
are
cleaner
cleaner
options
options
out
out
there
there
like
like
SolidJS
solidjs
that
that
would
would
also
also
provide
provide
better
better
performance.
performance
I
i
also
also
seriously
seriously
considered
considered
Vue,
vue
which
which
is
is
not
not
only
only
a
a
great
great
framework,
framework
but
but
also
also
has
has
a
a
large
large
number
number
of
of
supporting
supporting
libraries
libraries
as
as
well.
well
But
but
the
the
more
more
important
important
decision
decision
is
is
which
which
meta
meta
framework
framework
do
do
you
you
wanna
wanna
use?
use
React
react
has
has
Next,
next
Vue
vue
has
has
Nuxt,
nuxt
Angular
angular
has
has
Universal,
universal
and
and
Svelte
svelte
with
with
askit.
askit
Most
most
applications
applications
out
out
there
there
need
need
some
some
form
form
of
of
server
server
side
side
rendering
rendering
to
to
make
make
their
their
sites
sites
visible
visible
to
to
search
search
engines
engines
and
and
bots.
bots
SvelteKit
sveltekit
is
is
the
the
official
official
SSR
ssr
solution
solution
it's
it's
being
being
worked
worked
on
on
by
by
Rich
rich
Harris,
harris
but
but
as
as
of
of
today,
today
it's
it's
still
still
in
in
beta.
beta
Using
using
a
a
framework
framework
that's
that's
not
not
at
at
a
a
stable
stable
release
release
is
is
kind
kind
of
of
risky.
risky
You
you
could
could
pour
pour
a
a
ton
ton
of
of
work
work
into
into
an
an
app,
app
then
then
the
the
framework
framework
developers
developers
decide
decide
to
to
pull
pull
a
a
feature
feature
on
on
the
the
final
final
release
release
that
that
torpedoes
torpedoes
your
your
entire
entire
business.
business
Not
not
very
very
likely,
likely
so
so
that's
that's
a
a
risk
risk
I'm
i'm
willing
willing
to
to
take.
take
Now,
now
there
there
are
are
other
other
ways
ways
to
to
server
server
render
render
Svelte.
svelte
Another
another
good
good
option
option
is
is
Astro.
astro
It
it
has
has
a
a
lot
lot
of
of
awesome
awesome
features
features
for
for
content
content
driven
driven
sites.
sites
But
but
the
the
reason
reason
I
i
prefer
prefer
SvelteKit
sveltekit
for
for
this
this
project
project
is
is
because
because
it
it
does
does
client
client
side
side
routing
routing
after
after
the
the
initial
initial
page
page
load,
load
which
which
becomes
becomes
written
written
on
on
more
more
interactive
interactive
sites,
sites
especially
especially
when
when
user
user
authentication
authentication
is
is
involved.
involved
But
but
my
my
plan
plan
is
is
to
to
use
use
Astro
astro
for
for
my
my
personal
personal
portfolio
portfolio
if
if
I
i
ever
ever
get
get
around
around
rebuilding
rebuilding
it.
it
Now,
now
the
the
other
other
framework
framework
that
that
I
i
would
would
say
say
is
is
my
my
second
second
choice
choice
is
is
Next
next
JS.
js
Next
next
is
is
already
already
a
a
great
great
framework,
framework
but
but
it
it
has
has
a
a
bunch
bunch
of
of
cool
cool
stuff
stuff
coming
coming
as
as
well,
well
like
like
nested
nested
routing
routing
and
and
stuff
stuff
like
like
that.
that
I
i
also
also
recently
recently
made
made
a
a
video
video
on
on
Nuxt,
nuxt
yet
yet
another
another
awesome
awesome
framework
framework
that
that
I
i
hope
hope
to
to
make
make
a
a
full
full
course
course
on
on
in
in
the
the
future.
future
It's
it's
also
also
worth
worth
mentioning
mentioning
that
that
there's
there's
new
new
framework
framework
called
called
QUIC
quic
that
that
has
has
an
an
entirely
entirely
different
different
take
take
on
on
rendering
rendering
with
with
resumable
resumable
or
or
replayable
replayable
applications,
applications
but
but
even
even
that's
that's
a
a
little
little
too
too
bleeding
bleeding
edge
edge
for
for
me.
me
Now
now
when
when
it
it
comes
comes
to
to
server
server
rendering,
rendering
you
you
don't
don't
need
need
to
to
using
using
a
a
meta
meta
framework
framework
that's
that's
tied
tied
to
to
some
some
JavaScript
javascript
library.
library
Instead,
instead
you
you
can
can
use
use
a
a
full
full
stack
stack
framework
framework
like
like
Ruby
ruby
on
on
Rails,
rails
Laravel,
laravel
Django,
django
or
or
whatever
whatever
to
to
render
render
all
all
of
of
your
your
content
content
on
on
the
the
server.
server
These
these
frameworks
frameworks
have
have
advantages
advantages
for
for
certain
certain
types
types
of
of
applications.
applications
But
but
in
in
my
my
case,
case
full
full
blown
blown
server
server
side
side
rendering
rendering
is
is
not
not
really
really
necessary
necessary
because
because
the
the
content
content
on
on
the
the
actual
actual
site
site
doesn't
doesn't
change
change
all
all
that
that
often.
often
It's
it's
far
far
more
more
simple
simple
to
to
pre
pre
render
render
the
the
entire
entire
site,
site
upload
upload
it
it
to
to
a
a
storage
storage
bucket,
bucket
and
and
then
then
cache
cache
it
it
on
on
a
a
CDN
cdn
around
around
the
the
world.
world
When
when
you
you
have
have
a
a
dedicated
dedicated
Urber,
urber
you
you
then
then
need
need
to
to
think
think
about
about
how
how
to
to
scale
scale
it
it
with
with
either
either
serverless
serverless
functions,
functions
or
or
if
if
you
you
want
want
a
a
really
really
complicated
complicated
tech
tech
stack,
stack
something
something
like
like
Kubernetes.
kubernetes
The
the
next
next
thing
thing
I
i
want
want
to
to
talk
talk
about
about
Ace
ace
TypeScript.
typescript
If
if
you're
you're
building
building
a
a
big
big
complicated
complicated
project,
project
you
you
should
should
use
use
it.
it
The
the
end.
end
A
a
more
more
complicated
complicated
question
question
you'll
you'll
have
have
to
to
ask
ask
is
is
how
how
am
am
I
i
going
going
to
to
manage
manage
my
my
CSS?
css
Us.
us
When
when
I
i
work
work
on
on
a
a
solo
solo
project,
project
I
i
spend
spend
more
more
time
time
dicking
dicking
around
around
with
with
the
the
CSS
css
than
than
I
i
do
do
writing
writing
JavaScript.
javascript
It's
it's
depressing,
depressing
man.
man
I've
i've
only
only
got
got
so
so
much
much
time
time
left
left
to
to
hold
hold
Fortran
fortran
3.
3
Life
life
goes
goes
by
by
much
much
faster
faster
than
than
we
we
think.
think
Yet,
yet
here
here
I
i
am,
am
wasting
wasting
hours
hours
of
of
this
this
precious
precious
time
time
trying
trying
to
to
figure
figure
out
out
why
why
this
this
navbar
navbar
won't
won't
be
be
sticky.
sticky
That
that
being
being
said,
said
a
a
tool
tool
that
that
makes
makes
CSS
css
much
much
easier
easier
is
is
Tailwind.
tailwind
End.
end
Most
most
importantly,
importantly
it
it
makes
makes
prototyping
prototyping
and
and
the
the
implementation
implementation
of
of
your
your
designs
designs
go
go
much
much
faster.
faster
I
i
like
like
to
to
have
have
a
a
lot
lot
of
of
control
control
over
over
my
my
designs,
designs
because
because
for
for
me,
me
it's
it's
a
a
creative
creative
process.
process
Tailwind
tailwind
it
it
won't
won't
magically
magically
make
make
your
your
website
website
look
look
good,
good
but
but
it
it
does
does
provide
provide
enough
enough
of
of
a
a
framework
framework
to
to
get
get
things
things
done
done
way
way
quicker.
quicker
The
the
current
current
version
version
of
of
FireShip
fireship
is
is
100%
100%
custom
custom
with
with
Sass.
sass
With
with
Tailwind,
tailwind
I
i
feel
feel
like
like
I
i
have
have
the
the
same
same
amount
amount
of
of
control,
control
but
but
things
things
just
just
get
get
done
done
much
much
more
more
rapidly.
rapidly
And,
and
another
another
huge
huge
benefit
benefit
is
is
that
that
it
it
will
will
automatically
automatically
purge
purge
styles
styles
to
to
keep
keep
the
the
CSS
css
bundle
bundle
as
as
small
small
as
as
possible.
possible
That's
that's
important
important
because
because
the
the
initial
initial
page
page
load
load
speed
speed
from
from
my
my
site
site
is
is
critical.
critical
If
if
you
you
like
like
the
the
utility
utility
class
class
approach,
approach
another
another
option
option
to
to
check
check
out
out
is
is
windy
windy
CSS,
css
or
or
if
if
you
you
don't
don't
care
care
about
about
having
having
that
that
much
much
control,
control
you
you
can
can
use
use
something
something
like
like
Bootstrap,
bootstrap
in
in
addition
addition
to
to
many
many
other
other
CSS
css
frameworks
frameworks
out
out
there.
there
And
and
you've
you've
also
also
got
got
tons
tons
of
of
framework
framework
specific
specific
UI
ui
why
why
libraries
libraries
to
to
analyze
analyze
as
as
well.
well
And
and
if
if
you're
you're
using
using
Tailwind,
tailwind
you
you
should
should
definitely
definitely
check
check
out
out
Daisy
daisy
UI,
ui
but
but
I'm
i'm
just
just
doing
doing
everything
everything
from
from
scratch
scratch
myself
myself
because
because
I'm
i'm
an
an
idiot.
idiot
That's
that's
enough
enough
for
for
the
the
front
front
end.
end
Now,
now
I
i
want
want
to
to
talk
talk
about
about
the
the
back
back
end.
end
As
as
you
you
know,
know
I'm
i'm
a
a
big
big
fan
fan
of
of
Firebase
firebase
and
and
it's
it's
been
been
the
the
foundation
foundation
of
of
this
this
channel
channel
from
from
day
day
1.
1
But
but
But,
but
as
as
I've
i've
grown
grown
older
older
and
and
wiser,
wiser
I've
i've
come
come
to
to
realize
realize
something
something
about
about
Firebase.
firebase
This
this
may
may
be
be
shocking
shocking
to
to
some
some
of
of
you,
you
but
but
Firebase
firebase
is
is
still
still
awesome
awesome
and
and
I
i
plan
plan
on
on
using
using
it
it
until
until
the
the
day
day
I
i
die,
die
IE,
ie
or
or
at
at
least
least
until
until
Google
google
decides
decides
to
to
kill
kill
it,
it
whichever
whichever
comes
comes
first.
first
Firebase
firebase
will
will
do
do
90%
90%
of
of
what
what
most
most
apps
apps
need
need
on
on
the
the
back
back
end.
end
The
the
main
main
drawback
drawback
is
is
that
that
you're
you're
tightly
tightly
locked
locked
into
into
Google
google
Cloud
cloud
Platform
platform
with
with
Swarm,
swarm
and
and
you
you
may
may
run
run
into
into
edge
edge
cases
cases
that
that
it
it
just
just
doesn't
doesn't
support,
support
like
like
advanced
advanced
authentication
authentication
features
features
or
or
complex
complex
database
database
queries,
queries
and
and
that
that
can
can
be
be
a
a
deal
deal
breaker
breaker
for
for
certain
certain
types
types
with
with
apps.
apps
What
what
you
you
could
could
do
do
is
is
architect
architect
your
your
entire
entire
back
back
end
end
from
from
scratch
scratch
by
by
picking
picking
and
and
choosing
choosing
different
different
services
services
in
in
the
the
cloud,
cloud
but
but
then
then
the
the
complexity
complexity
of
of
your
your
code
code
base
base
is
is
going
going
to
to
explode.
explode
Luckily
luckily
in
in
2022,
2022
there
there
are
are
quite
quite
a
a
few
few
alternatives
alternatives
to
to
Firebase.
firebase
You've
you've
got
got
big
big
ones
ones
like
like
AWS
aws
Amplify
amplify
and
and
MongoDB
mongodb
Realm,
realm
and
and
then
then
smaller
smaller
start
start
apps
apps
like
like
Enho,
enho
Supabase,
supabase
and
and
AppRite.
apprite
I
i
recently
recently
compared
compared
all
all
of
of
them,
them
and
and
each
each
one
one
has
has
its
its
own
own
set
set
of
of
unique
unique
trade
trade
offs.
offs
Expect
expect
a
a
full
full
video
video
on
on
that
that
Xun.
xun
The
the
most
most
important
important
thing
thing
is
is
the
the
database.
database
Firebase
firebase
uses
uses
Firestore,
firestore
which
which
is
is
a
a
document
document
database
database
similar
similar
to
to
MongoDB,
mongodb
which
which
can
can
get
get
the
the
job
job
done
done
for
for
most
most
apps,
apps
but
but
does
does
have
have
some
some
limitations
limitations
that
that
can
can
be
be
kind
kind
of
of
annoying
annoying
at
at
times.
times
A
a
traditional
traditional
SQL
sql
database
database
is
is
probably
probably
the
the
safest
safest
bet
bet
for
for
most
most
people,
people
but
but
they're
they're
generally
generally
harder
harder
to
to
work
work
with.
with
Although,
although
there
there
are
are
some
some
services
services
out
out
there
there
like
like
PlanetScale
planetscale
and
and
CockroachDB,
cockroachdb
that
that
have
have
made
made
things
things
a
a
lot
lot
easier
easier
in
in
recent
recent
years,
years
especially
especially
when
when
used
used
with
with
an
an
ORM
orm
like
like
Prisma.
prisma
In
in
addition,
addition
you
you
might
might
consider
consider
other
other
NoSQL
nosql
databases
databases
like
like
Redis
redis
and
and
Cassandra,
cassandra
which
which
can
can
actually
actually
be
be
used
used
as
as
a
a
primary
primary
app
app
database.
database
Now
now
in
in
addition
addition
to
to
the
the
back
back
end,
end
there
there
are
are
a
a
lot
lot
of
of
other
other
smaller
smaller
tools
tools
in
in
the
the
stack.
stack
When
when
it
it
comes
comes
to
to
testing,
testing
I
i
find
find
that
that
I
i
need
need
to
to
keep
keep
things
things
very
very
simple,
simple
otherwise
otherwise
I'm
i'm
not
not
going
going
to
to
test
test
anything
anything
at
at
all.
all
And
and
my
my
preferred
preferred
way
way
to
to
do
do
that
that
is
is
with
with
Cypress,
cypress
RISC,
risc
which
which
is
is
basically
basically
an
an
all
all
in
in
one
one
package
package
that
that
can
can
do
do
everything
everything
from
from
end
end
to
to
end
end
tests
tests
to
to
individual
individual
unit
unit
tests
tests
and
and
everything
everything
in
in
between.
between
If
if
you're
you're
not
not
into
into
Cypress,
cypress
another
another
good
good
option
option
for
for
end
end
to
to
end
end
testing
testing
is
is
Playwright.
playwright
And
and
if
if
you
you
just
just
wanna
wanna
do
do
unit
unit
tests,
tests
another
another
framework
framework
I've
i've
really
really
been
been
wanting
wanting
to
to
try
try
out
out
is
is
Vtest,
vtest
which
which
is
is
based
based
on
on
Vite,
vite
the
the
build
build
tool
tool
that
that
powers
powers
SvelteKit.
sveltekit
My
my
tech
tech
stack
stack
also
also
uses
uses
variety
variety
of
of
APIs
apis
to
to
do
do
things
things
that
that
I
i
can't
can't
do
do
on
on
my
my
own.
own
One
one
of
of
which
which
is
is
send
send
transactional
transactional
email.
email
I
i
currently
currently
use
use
SendGrid
sendgrid
and
and
will
will
continue
continue
doing
doing
so
so
in
in
the
the
future,
future
but
but
I
i
wish
wish
Firebase
firebase
or
or
Google
google
Cloud
cloud
would
would
come
come
out
out
with
with
its
its
own
own
email
email
service.
service
In
in
addition,
addition
a
a
content
content
driven
driven
site
site
needs
needs
to
to
have
have
really
really
good
good
full
full
text
text
search.
search
To
to
handle
handle
that,
that
I'm
i'm
using
using
Lia.
lia
Algolia
algolia
can
can
get
get
pretty
pretty
expensive
expensive
on
on
very
very
large
large
sites,
sites
but
but
for
for
me
me
it's
it's
pretty
pretty
inexpensive
inexpensive
and
and
very
very
easy
easy
to
to
use.
use
This
this
is
is
yet
yet
another
another
feature
feature
I
i
wish
wish
would
would
be
be
implemented
implemented
into
into
Firebase,
firebase
but
but
I'm
i'm
not
not
going
going
to
to
hold
hold
my
my
breath.
breath
And
and
finally,
finally
I'll
i'll
be
be
using
using
Stripe
stripe
and
and
PayPal
paypal
to
to
manage
manage
payments
payments
because
because
to
to
be
be
honest,
honest
I
i
haven't
haven't
looked
looked
at
at
any
any
alternatives
alternatives
in
in
a
a
long
long
time.
time
The
the
end
end
result
result
is
is
a
a
pretty
pretty
simple
simple
tech
tech
stack,
stack
with
with
the
the
main
main
components
components
being
being
Sveltekit
sveltekit
and
and
Firebase.
firebase
The
the
only
only
major
major
problem
problem
is
is
that
that
it
it
doesn't
doesn't
form
form
an
an
obvious
obvious
acronym.
acronym
We
we
could
could
go
go
with
with
the
the
FIST
fist
stack,
stack
or
or
maybe
maybe
FireKit
firekit
or
or
perhaps
perhaps
bucket,
bucket
but
but
I
i
don't
don't
know
know
man.
man
Let
let
me
me
know
know
if
if
you
you
have
have
a
a
better
better
idea.
idea
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speakers discuss the benefits of combining front and back end libraries and APIs to create a complete tech stack, including Svelte for their website and recommendations for Svelte's performance, security, and features. They also recommend Svelte for their personal portfolio and use it for their second choice, pages and content. The speakers also discuss the benefits of using a full stack framework like alignment and control over websites, and recommend using node variables for building a fully-characterized website. They mention other tools for server rendering and the potential drawbacks of edge cases with node variables. Finally, they discuss the benefits of using Tailwind and other options for building a back end, including using a document database and building a web app.
My Bleeding Edge Tech Stack for 2025
If you're building a web or mobile app in 2022, there's literally a 1,000,000 different ways to get the job done by combining different front end and back end libraries along with APIs, tooling, and infrastructure to form a complete tech stack. In today's video, I wanna give you a guided tour of my tech stack, which I plan on using through 2025. Assuming the world hasn't been destroyed by that point. Not only will I explain my thought process when making these decisions, but we'll also look at a ton of alternatives that you may want to consider for yourself because you definitely just copy some random guy on YouTube. Before we get into it, as many of you know, I recently had a baby. I haven't been uploading quite as many videos, but it's giving me time to work on a complete rebuild of Fireship IO. And in the process, I've analyzed all kinds of different technologies that I might want to use for that project. With now I don't really need to rebuild Fireship, but I do it every couple years just because I enjoy the process. Most of the coding I'll do with my bare hands, but the project will be open source and I will likely collaborate with a couple of other engineers to round out the project. It's a small team effort, which is an important consideration when choosing your tech stack, because many technologies are more well suited for large teams. Software engineers love to flex. That tech stack gotta be busin' or drippin'. In other words, ridiculously over engineered. The reality is that I I could build FireShip as a WordPress blog, add a membership plugin, and scale it up to millions of users. If I wanna make money, that would be the smart thing to with you. But I wanna build something a little more special than just a WordPress blog. In the next version of the site, courses will have progress tracking that will also include challenges like quizzes active demos powered by Stackblitz. In my experience, the majority of modern web development happens on the front end. That being said, one of the most important decisions to make is your front end UI library, and for with that, I have chosen Svelte. I've built something with pretty much every UI library on the market. They all have their pros and cons, but Svelte is the one what feels most productive to me. And coincidentally, just yesterday, it debuted at the top of the most loved web frameworks on the Stack Overflow 2022 survey. I think developers love it for how natural it makes reactive data feel. When a mutable variable changes, the UI reacts. You don't have to jump through any hoops to make things reactive. Now, the other thing I really like about Svelte is the way you share data across components, which is done with stores. A store is like a subject in RxJS that can be observed anywhere in the application by simply putting a dollar sign in front of it. This pattern is actually very similar to the way things are done in Angular, but Svelte does it with a lot less boilerplate. The current version of Fireship, is actually built with Angular. And, in my opinion, Angular is awesome and the most underappreciated framework out there. It's extremely popular in enterprise for a good reason. But in 20 with me too. React is definitely still the most popular UI library and it has a huge ecosystem of supporting libraries. I think that's the most compelling argument to use it. When it comes down to the UI library itself. There are cleaner options out there like SolidJS that would also provide better performance. I also seriously considered Vue, which is not only a great framework, but also has a large number of supporting libraries as well. But the more important decision is which meta framework do you wanna use? React has Next, Vue has Nuxt, Angular has Universal, and Svelte with askit. Most applications out there need some form of server side rendering to make their sites visible to search engines and bots. SvelteKit is the official SSR solution it's being worked on by Rich Harris, but as of today, it's still in beta. Using a framework that's not at a stable release is kind of risky. You could pour a ton of work into an app, then the framework developers decide to pull a feature on the final release that torpedoes your entire business. Not very likely, so that's a risk I'm willing to take. Now, there are other ways to server render Svelte. Another good option is Astro. It has a lot of awesome features for content driven sites. But the reason I prefer SvelteKit for this project is because it does client side routing after the initial page load, which becomes written on more interactive sites, especially when user authentication is involved. But my plan is to use Astro for my personal portfolio if I ever get around rebuilding it. Now, the other framework that I would say is my second choice is Next JS. Next is already a great framework, but it has a bunch of cool stuff coming as well, like nested routing and stuff like that. I also recently made a video on Nuxt, yet another awesome framework that I hope to make a full course on in the future. It's also worth mentioning that there's new framework called QUIC that has an entirely different take on rendering with resumable or replayable applications, but even that's a little too bleeding edge for me. Now when it comes to server rendering, you don't need to using a meta framework that's tied to some JavaScript library. Instead, you can use a full stack framework like Ruby on Rails, Laravel, Django, or whatever to render all of your content on the server. These frameworks have advantages for certain types of applications. But in my case, full blown server side rendering is not really necessary because the content on the actual site doesn't change all that often. It's far more simple to pre render the entire site, upload it to a storage bucket, and then cache it on a CDN around the world. When you have a dedicated Urber, you then need to think about how to scale it with either serverless functions, or if you want a really complicated tech stack, something like Kubernetes. The next thing I want to talk about Ace TypeScript. If you're building a big complicated project, you should use it. The end. A more complicated question you'll have to ask is how am I going to manage my CSS? Us. When I work on a solo project, I spend more time dicking around with the CSS than I do writing JavaScript. It's depressing, man. I've only got so much time left to hold Fortran 3. Life goes by much faster than we think. Yet, here I am, wasting hours of this precious time trying to figure out why this navbar won't be sticky. That being said, a tool that makes CSS much easier is Tailwind. End. Most importantly, it makes prototyping and the implementation of your designs go much faster. I like to have a lot of control over my designs, because for me, it's a creative process. Tailwind it won't magically make your website look good, but it does provide enough of a framework to get things done way quicker. The current version of FireShip is 100% custom with Sass. With Tailwind, I feel like I have the same amount of control, but things just get done much more rapidly. And, another huge benefit is that it will automatically purge styles to keep the CSS bundle as small as possible. That's important because the initial page load speed from my site is critical. If you like the utility class approach, another option to check out is windy CSS, or if you don't care about having that much control, you can use something like Bootstrap, in addition to many other CSS frameworks out there. And you've also got tons of framework specific UI why libraries to analyze as well. And if you're using Tailwind, you should definitely check out Daisy UI, but I'm just doing everything from scratch myself because I'm an idiot. That's enough for the front end. Now, I want to talk about the back end. As you know, I'm a big fan of Firebase and it's been the foundation of this channel from day 1. But But, as I've grown older and wiser, I've come to realize something about Firebase. This may be shocking to some of you, but Firebase is still awesome and I plan on using it until the day I die, IE, or at least until Google decides to kill it, whichever comes first. Firebase will do 90% of what most apps need on the back end. The main drawback is that you're tightly locked into Google Cloud Platform with Swarm, and you may run into edge cases that it just doesn't support, like advanced authentication features or complex database queries, and that can be a deal breaker for certain types with apps. What you could do is architect your entire back end from scratch by picking and choosing different services in the cloud, but then the complexity of your code base is going to explode. Luckily in 2022, there are quite a few alternatives to Firebase. You've got big ones like AWS Amplify and MongoDB Realm, and then smaller start apps like Enho, Supabase, and AppRite. I recently compared all of them, and each one has its own set of unique trade offs. Expect a full video on that Xun. The most important thing is the database. Firebase uses Firestore, which is a document database similar to MongoDB, which can get the job done for most apps, but does have some limitations that can be kind of annoying at times. A traditional SQL database is probably the safest bet for most people, but they're generally harder to work with. Although, there are some services out there like PlanetScale and CockroachDB, that have made things a lot easier in recent years, especially when used with an ORM like Prisma. In addition, you might consider other NoSQL databases like Redis and Cassandra, which can actually be used as a primary app database. Now in addition to the back end, there are a lot of other smaller tools in the stack. When it comes to testing, I find that I need to keep things very simple, otherwise I'm not going to test anything at all. And my preferred way to do that is with Cypress, RISC, which is basically an all in one package that can do everything from end to end tests to individual unit tests and everything in between. If you're not into Cypress, another good option for end to end testing is Playwright. And if you just wanna do unit tests, another framework I've really been wanting to try out is Vtest, which is based on Vite, the build tool that powers SvelteKit. My tech stack also uses variety of APIs to do things that I can't do on my own. One of which is send transactional email. I currently use SendGrid and will continue doing so in the future, but I wish Firebase or Google Cloud would come out with its own email service. In addition, a content driven site needs to have really good full text search. To handle that, I'm using Lia. Algolia can get pretty expensive on very large sites, but for me it's pretty inexpensive and very easy to use. This is yet another feature I wish would be implemented into Firebase, but I'm not going to hold my breath. And finally, I'll be using Stripe and PayPal to manage payments because to be honest, I haven't looked at any alternatives in a long time. The end result is a pretty simple tech stack, with the main components being Sveltekit and Firebase. The only major problem is that it doesn't form an obvious acronym. We could go with the FIST stack, or maybe FireKit or perhaps bucket, but I don't know man. Let me know if you have a better idea. Thanks for watching, and I will see you in the next one.
The speakers discuss the benefits of combining front and back end libraries and APIs to create a complete tech stack, including Svelte for their website and recommendations for Svelte's performance, security, and features. They also recommend Svelte for their personal portfolio and use it for their second choice, pages and content. The speakers also discuss the benefits of using a full stack framework like alignment and control over websites, and recommend using node variables for building a fully-characterized website. They mention other tools for server rendering and the potential drawbacks of edge cases with node variables. Finally, they discuss the benefits of using Tailwind and other options for building a back end, including using a document database and building a web app.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : My Bleeding Edge Tech Stack for 2025 
        and a small summary : The speakers discuss the benefits of combining front and back end libraries and APIs to create a complete tech stack, including Svelte for their website and recommendations for Svelte's performance, security, and features. They also recommend Svelte for their personal portfolio and use it for their second choice, pages and content. The speakers also discuss the benefits of using a full stack framework like alignment and control over websites, and recommend using node variables for building a fully-characterized website. They mention other tools for server rendering and the potential drawbacks of edge cases with node variables. Finally, they discuss the benefits of using Tailwind and other options for building a back end, including using a document database and building a web app.
        [/INST]
        
        Generate the video : If you're building a web or mobile app in 2022, there's literally a 1,000,000 different ways to get the job done by combining different front end and back end libraries along with APIs, tooling, and infrastructure to form a complete tech stack. In today's video, I wanna give you a guided tour of my tech stack, which I plan on using through 2025. Assuming the world hasn't been destroyed by that point. Not only will I explain my thought process when making these decisions, but we'll also look at a ton of alternatives that you may want to consider for yourself because you definitely just copy some random guy on YouTube. Before we get into it, as many of you know, I recently had a baby. I haven't been uploading quite as many videos, but it's giving me time to work on a complete rebuild of Fireship IO. And in the process, I've analyzed all kinds of different technologies that I might want to use for that project. With now I don't really need to rebuild Fireship, but I do it every couple years just because I enjoy the process. Most of the coding I'll do with my bare hands, but the project will be open source and I will likely collaborate with a couple of other engineers to round out the project. It's a small team effort, which is an important consideration when choosing your tech stack, because many technologies are more well suited for large teams. Software engineers love to flex. That tech stack gotta be busin' or drippin'. In other words, ridiculously over engineered. The reality is that I I could build FireShip as a WordPress blog, add a membership plugin, and scale it up to millions of users. If I wanna make money, that would be the smart thing to with you. But I wanna build something a little more special than just a WordPress blog. In the next version of the site, courses will have progress tracking that will also include challenges like quizzes active demos powered by Stackblitz. In my experience, the majority of modern web development happens on the front end. That being said, one of the most important decisions to make is your front end UI library, and for with that, I have chosen Svelte. I've built something with pretty much every UI library on the market. They all have their pros and cons, but Svelte is the one what feels most productive to me. And coincidentally, just yesterday, it debuted at the top of the most loved web frameworks on the Stack Overflow 2022 survey. I think developers love it for how natural it makes reactive data feel. When a mutable variable changes, the UI reacts. You don't have to jump through any hoops to make things reactive. Now, the other thing I really like about Svelte is the way you share data across components, which is done with stores. A store is like a subject in RxJS that can be observed anywhere in the application by simply putting a dollar sign in front of it. This pattern is actually very similar to the way things are done in Angular, but Svelte does it with a lot less boilerplate. The current version of Fireship, is actually built with Angular. And, in my opinion, Angular is awesome and the most underappreciated framework out there. It's extremely popular in enterprise for a good reason. But in 20 with me too. React is definitely still the most popular UI library and it has a huge ecosystem of supporting libraries. I think that's the most compelling argument to use it. When it comes down to the UI library itself. There are cleaner options out there like SolidJS that would also provide better performance. I also seriously considered Vue, which is not only a great framework, but also has a large number of supporting libraries as well. But the more important decision is which meta framework do you wanna use? React has Next, Vue has Nuxt, Angular has Universal, and Svelte with askit. Most applications out there need some form of server side rendering to make their sites visible to search engines and bots. SvelteKit is the official SSR solution it's being worked on by Rich Harris, but as of today, it's still in beta. Using a framework that's not at a stable release is kind of risky. You could pour a ton of work into an app, then the framework developers decide to pull a feature on the final release that torpedoes your entire business. Not very likely, so that's a risk I'm willing to take. Now, there are other ways to server render Svelte. Another good option is Astro. It has a lot of awesome features for content driven sites. But the reason I prefer SvelteKit for this project is because it does client side routing after the initial page load, which becomes written on more interactive sites, especially when user authentication is involved. But my plan is to use Astro for my personal portfolio if I ever get around rebuilding it. Now, the other framework that I would say is my second choice is Next JS. Next is already a great framework, but it has a bunch of cool stuff coming as well, like nested routing and stuff like that. I also recently made a video on Nuxt, yet another awesome framework that I hope to make a full course on in the future. It's also worth mentioning that there's new framework called QUIC that has an entirely different take on rendering with resumable or replayable applications, but even that's a little too bleeding edge for me. Now when it comes to server rendering, you don't need to using a meta framework that's tied to some JavaScript library. Instead, you can use a full stack framework like Ruby on Rails, Laravel, Django, or whatever to render all of your content on the server. These frameworks have advantages for certain types of applications. But in my case, full blown server side rendering is not really necessary because the content on the actual site doesn't change all that often. It's far more simple to pre render the entire site, upload it to a storage bucket, and then cache it on a CDN around the world. When you have a dedicated Urber, you then need to think about how to scale it with either serverless functions, or if you want a really complicated tech stack, something like Kubernetes. The next thing I want to talk about Ace TypeScript. If you're building a big complicated project, you should use it. The end. A more complicated question you'll have to ask is how am I going to manage my CSS? Us. When I work on a solo project, I spend more time dicking around with the CSS than I do writing JavaScript. It's depressing, man. I've only got so much time left to hold Fortran 3. Life goes by much faster than we think. Yet, here I am, wasting hours of this precious time trying to figure out why this navbar won't be sticky. That being said, a tool that makes CSS much easier is Tailwind. End. Most importantly, it makes prototyping and the implementation of your designs go much faster. I like to have a lot of control over my designs, because for me, it's a creative process. Tailwind it won't magically make your website look good, but it does provide enough of a framework to get things done way quicker. The current version of FireShip is 100% custom with Sass. With Tailwind, I feel like I have the same amount of control, but things just get done much more rapidly. And, another huge benefit is that it will automatically purge styles to keep the CSS bundle as small as possible. That's important because the initial page load speed from my site is critical. If you like the utility class approach, another option to check out is windy CSS, or if you don't care about having that much control, you can use something like Bootstrap, in addition to many other CSS frameworks out there. And you've also got tons of framework specific UI why libraries to analyze as well. And if you're using Tailwind, you should definitely check out Daisy UI, but I'm just doing everything from scratch myself because I'm an idiot. That's enough for the front end. Now, I want to talk about the back end. As you know, I'm a big fan of Firebase and it's been the foundation of this channel from day 1. But But, as I've grown older and wiser, I've come to realize something about Firebase. This may be shocking to some of you, but Firebase is still awesome and I plan on using it until the day I die, IE, or at least until Google decides to kill it, whichever comes first. Firebase will do 90% of what most apps need on the back end. The main drawback is that you're tightly locked into Google Cloud Platform with Swarm, and you may run into edge cases that it just doesn't support, like advanced authentication features or complex database queries, and that can be a deal breaker for certain types with apps. What you could do is architect your entire back end from scratch by picking and choosing different services in the cloud, but then the complexity of your code base is going to explode. Luckily in 2022, there are quite a few alternatives to Firebase. You've got big ones like AWS Amplify and MongoDB Realm, and then smaller start apps like Enho, Supabase, and AppRite. I recently compared all of them, and each one has its own set of unique trade offs. Expect a full video on that Xun. The most important thing is the database. Firebase uses Firestore, which is a document database similar to MongoDB, which can get the job done for most apps, but does have some limitations that can be kind of annoying at times. A traditional SQL database is probably the safest bet for most people, but they're generally harder to work with. Although, there are some services out there like PlanetScale and CockroachDB, that have made things a lot easier in recent years, especially when used with an ORM like Prisma. In addition, you might consider other NoSQL databases like Redis and Cassandra, which can actually be used as a primary app database. Now in addition to the back end, there are a lot of other smaller tools in the stack. When it comes to testing, I find that I need to keep things very simple, otherwise I'm not going to test anything at all. And my preferred way to do that is with Cypress, RISC, which is basically an all in one package that can do everything from end to end tests to individual unit tests and everything in between. If you're not into Cypress, another good option for end to end testing is Playwright. And if you just wanna do unit tests, another framework I've really been wanting to try out is Vtest, which is based on Vite, the build tool that powers SvelteKit. My tech stack also uses variety of APIs to do things that I can't do on my own. One of which is send transactional email. I currently use SendGrid and will continue doing so in the future, but I wish Firebase or Google Cloud would come out with its own email service. In addition, a content driven site needs to have really good full text search. To handle that, I'm using Lia. Algolia can get pretty expensive on very large sites, but for me it's pretty inexpensive and very easy to use. This is yet another feature I wish would be implemented into Firebase, but I'm not going to hold my breath. And finally, I'll be using Stripe and PayPal to manage payments because to be honest, I haven't looked at any alternatives in a long time. The end result is a pretty simple tech stack, with the main components being Sveltekit and Firebase. The only major problem is that it doesn't form an obvious acronym. We could go with the FIST stack, or maybe FireKit or perhaps bucket, but I don't know man. Let me know if you have a better idea. Thanks for watching, and I will see you in the next one.
        