I have been using Vite for a couple of weeks and it's amazing. I tried Next JS but it took 45 seconds to load an image from Firebase. Deploying took about the same time compared to Vite's 5 seconds. I don't know anything about coding though so maybe I was doing something wrong but sticking with Vite for now.
@@danquixote6072 vite does load and build faster. Yet NextJS isn't slow. When it takes so long to load an image from an external source that's a different kind of problem :) Do you use firebase to deploy your apps?
@@theSnackableCTO Yes, I do. But the hero image that was taking so much time to load was coming from my public/images file. So I had two image sources. I am sure Next JS wasn't the problem but I'm terrified to go back now:)
I have add Vite and Deno 2.0 to an existing CRA React App and it is very fast and user friendly. I can just do all the linting, formatting, typestript settings with Deno 2 and it just updates instantly because of Vite. Layers of config and boilerplate just disappeared.
That's interesting. When you say Create React App you probably on client side rendering? I realized how fast the development process becomes with vite and thats pretty cool. We were talking about deno as well. Maybe it would a good topic to investigate next :)
when we have vite + React SPA and backend API running as different entities, how do we safely handle authN? That's one of the main reason, I'm switching from Vite to Next.js to handle it at SSR
We are using oAuth2.0 (JWT) with secure cookies. Additionally we use federation, so out backend (API Gateway) and frontend are using the same domain. Doable with proxies like NGINX or included in PaaS solutions like DigitalOceans App platform. Passed several manual Pentests in enterprise sector. Does this help?
I had a really great developing experience using vite and react, I like how fast vite is and all the feature it has, I like freedom when it comes to libraries choice that you can choose to install along with react, so you are free to use and choose the tools you prefer, fast build and production time, then yeah vite can be a great choice, oh and also of you prefer to have front and back end to be separated then yea it's a great choice.
@@GeeGnebAbas I said in the video,we aren't using SSR in webapps. Those are running smoothly without and being able to move on (agnosticism) is good long term. On the other hand it would be interesting how it works. I heard one saying the way vite introduced SSR is preferable. Others say Next.js is defining the standard here.
Awesome content, Adrian! Some stuff I’ve struggled with in Next.js: handling env variables across dev, staging, and production, and generating root-level pages (like /product-1, /product-2). We had to add a custom server on top of Next.js to make it work. Curious how you guys set up your Next.js apps and deal with envs. Would love to hear your take!
Do you run next server in production or exported static site regarding the routes? You have env files for prod and dev but you can overwrite them during build phase) in pipeline. We run our apps all in DigitalOcean App Platform and are very happy with it. Does this help?
@@theSnackableCTO We're running a Next.js server in production mainly because we have routes like /product-1 and don’t want to rebuild the app every time we add a new product. Do you guys manage with a single build for all environments, or do you build separately for each? When we started with Next.js about 5 years ago, we opted for a single build and just swapped the env variables per environment-but that approach ended up being a bit of a headache!
@@theSnackableCTO We're running a Next.js server in production mainly because we have routes like /product-1 and don’t want to rebuild the app every time we add a new product. Do you guys manage with a single build for all environments, or do you build separately for each? When we started with Next.js about 5 years ago, we opted for a single build and just swapped the env variables per environment-but that approach ended up being a bit of a headache!
We handle routing like this: Dynamic: /product/this-is-name-1 /product/this-is-name-2 or with static app (More agnostic, since it's web standard) /product?name=this-is-name-1 /product?name=this-is-name-2
Regarding Build/Deployment. We have a Monorepo and some Next Apps inside there on root. We deploy via push to trunk (main) to production. Sometimes we have a staging branch for automated testing. It's basically straight forward and deploys it directly to App Platform (based on K8s/containers). In each environment we have custom ENV vars in the "app-spec" which is a YAML file, very similar to a docker compose file. Works like a charm and can be used and observed by Juniors as well :) We love it. Does this help?
No need to do migration or choose. Know your requirements first. - Next.js for SEO-friendly pages, where server-side rendering is a must and fast loading cache-able public pages such as e-commerce and blogs - Vite or single-page app (client-side routing) for internal apps such as for company dashboard app, productivity apps, company operations app There is no perfect tooling for everything.
Agree regarding the requirements and the general differentation makes sense to me. But sometimes you can have SEO + User interaction heavy apps at the same time. NextJS does provide SPA capabilities. This is what we have since years, bit it feels a little bit like: "Vercels needs to maintain this function". On the other hand Vite puts focus on that.
You can do SSR with Vite which is great for SEO and Express js is one of the easiest thing for the backend so I don't even know why we use Next at this point
3-4 months ago, I tried to get it running with turbopack, but it wouldn't start. After 30 mins or so I gave up since I don't wanted to waste time. In general it's interesting and I will give it another try. Turbopack was declarded stable in Next 15. Let's see :)
YES. vite. vite. if they keeping webpack, why not just bundle jquery in as well for old times. For me if its in NextJS, just keep it that way.. if starting fresh... vite.
This week we had our discussions about that. In fact we will stay with next until end of year and then reconsider. We know now we can migrate, but we don't know 100% what we are going to do with SSG next year. So basically we have the following todos: - check out nextjs 15 with turbo pack - understand what vite can do in terms of SSG when needed.
@@theSnackableCTO indeed and with vite 6.0 having more than just server / client... things get even harder decisions and all the money evan raised for vites continued development. right now is the "inbetween". the other tech is not mature enough and the OG, ie nextjs even though starting to look a little dated - is still the defacto. oh yeh just to throw another spanner in the works as it were... i just did an astro project and it felt like everything nextjs could be. It was fast and easy to get running + vite ;)
@@mrrolandlawrence I totally get you and I agree. Regarding Astro, it's interesting, tho it's mainly focused on static apps, as far as I know. Remix on the other hand is vice versa; many mentioning this one as well. Vite sounds indeed promising, since maturity is a important NFR. I don't want to change underlying foundations every year. Maybe I take a look into comparing next15+ and vite 6+ with a side&view on Astro and Remix. Could be an interesting topic.
I feel the same way, as a mnemonic I have the backend sitting in a bird's nest high up in a tree where nobody can see it. 😀 Maybe a bit complicated. But it works for me.
Well, they are different, but they have in common to be platforms for react. Since this gap between them becomes larger it makes sense think deeper which of them (or others) makes sense for the future. Basically reevaluating.
@@duncandejong when you have decided that Vue is your way to go and you are willing to rebuild or start a migration with strangler-fig approach then that's a possible way. Wouldn't be interesting for us in our context, tho. You prefer Vue in general?
@@theSnackableCTO Only in marketing pages when required. Some page does have the nextjs data fetching but we don't use any fancy server action. It is far more better and transparent to build APIs and call them.
Interesting. So far I tried to avoid server actions, since they aren't agnostic. I heard that vercel is planning to keep it like that, but a solid backend with API is currently what serves us best.
@@iamerika1937 interesting! I would have two questions, if you don't mind? A: Are you using SSR? B: What would be your number one reason to go with next?
When Tanstack Start goes 1.0, it will be the newer, better Next.js (uses Vite, React and Nitro server from Nuxt stack)
@@pixelready cool! Didn't knew that one. It's essentially a possible answer to that video.
What color theme were you using in the clip output @ 3:44 - btw great video
WebStorm "Dark" Theme with new UI. If there is even the old one still :)
That was the in-IDE zsh shell.
I have been using Vite for a couple of weeks and it's amazing. I tried Next JS but it took 45 seconds to load an image from Firebase. Deploying took about the same time compared to Vite's 5 seconds. I don't know anything about coding though so maybe I was doing something wrong but sticking with Vite for now.
@@danquixote6072 vite does load and build faster. Yet NextJS isn't slow. When it takes so long to load an image from an external source that's a different kind of problem :)
Do you use firebase to deploy your apps?
@@theSnackableCTO Yes, I do. But the hero image that was taking so much time to load was coming from my public/images file. So I had two image sources. I am sure Next JS wasn't the problem but I'm terrified to go back now:)
I have add Vite and Deno 2.0 to an existing CRA React App and it is very fast and user friendly. I can just do all the linting, formatting, typestript settings with Deno 2 and it just updates instantly because of Vite. Layers of config and boilerplate just disappeared.
That's interesting. When you say Create React App you probably on client side rendering?
I realized how fast the development process becomes with vite and thats pretty cool.
We were talking about deno as well. Maybe it would a good topic to investigate next :)
vite has docs on implementing ssr, so you are not limited to csr
That's true. Have you experience with SSR on vite?
when we have vite + React SPA and backend API running as different entities, how do we safely handle authN? That's one of the main reason, I'm switching from Vite to Next.js to handle it at SSR
We are using oAuth2.0 (JWT) with secure cookies. Additionally we use federation, so out backend (API Gateway) and frontend are using the same domain. Doable with proxies like NGINX or included in PaaS solutions like DigitalOceans App platform.
Passed several manual Pentests in enterprise sector.
Does this help?
with token
great video!
@@Miwo99 appreciate your feedback! 😊
I had a really great developing experience using vite and react, I like how fast vite is and all the feature it has, I like freedom when it comes to libraries choice that you can choose to install along with react, so you are free to use and choose the tools you prefer, fast build and production time, then yeah vite can be a great choice, oh and also of you prefer to have front and back end to be separated then yea it's a great choice.
@@GeeGnebAb thanks for the insights! Have you used any SSR Plugins for vite and got some experience there es well?
@@theSnackableCTO very interesting question, I was thinking about it for a while but never used SSR plug-ins.
@@GeeGnebAbas I said in the video,we aren't using SSR in webapps. Those are running smoothly without and being able to move on (agnosticism) is good long term.
On the other hand it would be interesting how it works. I heard one saying the way vite introduced SSR is preferable. Others say Next.js is defining the standard here.
Awesome content, Adrian!
Some stuff I’ve struggled with in Next.js: handling env variables across dev, staging, and production, and generating root-level pages (like /product-1, /product-2). We had to add a custom server on top of Next.js to make it work.
Curious how you guys set up your Next.js apps and deal with envs. Would love to hear your take!
Do you run next server in production or exported static site regarding the routes?
You have env files for prod and dev but you can overwrite them during build phase) in pipeline.
We run our apps all in DigitalOcean App Platform and are very happy with it.
Does this help?
@@theSnackableCTO We're running a Next.js server in production mainly because we have routes like /product-1 and don’t want to rebuild the app every time we add a new product. Do you guys manage with a single build for all environments, or do you build separately for each?
When we started with Next.js about 5 years ago, we opted for a single build and just swapped the env variables per environment-but that approach ended up being a bit of a headache!
@@theSnackableCTO We're running a Next.js server in production mainly because we have routes like /product-1 and don’t want to rebuild the app every time we add a new product. Do you guys manage with a single build for all environments, or do you build separately for each?
When we started with Next.js about 5 years ago, we opted for a single build and just swapped the env variables per environment-but that approach ended up being a bit of a headache!
We handle routing like this:
Dynamic:
/product/this-is-name-1
/product/this-is-name-2
or with static app (More agnostic, since it's web standard)
/product?name=this-is-name-1
/product?name=this-is-name-2
Regarding Build/Deployment.
We have a Monorepo and some Next Apps inside there on root.
We deploy via push to trunk (main) to production. Sometimes we have a staging branch for automated testing.
It's basically straight forward and deploys it directly to App Platform (based on K8s/containers).
In each environment we have custom ENV vars in the "app-spec" which is a YAML file, very similar to a docker compose file.
Works like a charm and can be used and observed by Juniors as well :) We love it.
Does this help?
No need to do migration or choose. Know your requirements first.
- Next.js for SEO-friendly pages, where server-side rendering is a must and fast loading cache-able public pages such as e-commerce and blogs
- Vite or single-page app (client-side routing) for internal apps such as for company dashboard app, productivity apps, company operations app
There is no perfect tooling for everything.
Agree regarding the requirements and the general differentation makes sense to me.
But sometimes you can have SEO + User interaction heavy apps at the same time.
NextJS does provide SPA capabilities. This is what we have since years, bit it feels a little bit like: "Vercels needs to maintain this function".
On the other hand Vite puts focus on that.
@@joemgap how do you handle SSO in SPA?
You can do SSR with Vite which is great for SEO
and Express js is one of the easiest thing for the backend
so I don't even know why we use Next at this point
Just know that Vite is about to go through some major updates
Referring to OXC, Rolldown, etc.? OXC is exciting.
It is becoming more and more complex everyday, and it has become hard to scale projects with it.
how to compare a bazooka with a knife?
Place them side by side, compare them and then decide which of them fulfils the task better and meets the economic constraints better.
how about nextjs with --turbo flag vs vite
3-4 months ago, I tried to get it running with turbopack, but it wouldn't start. After 30 mins or so I gave up since I don't wanted to waste time. In general it's interesting and I will give it another try. Turbopack was declarded stable in Next 15. Let's see :)
YES. vite. vite. if they keeping webpack, why not just bundle jquery in as well for old times. For me if its in NextJS, just keep it that way.. if starting fresh... vite.
This week we had our discussions about that. In fact we will stay with next until end of year and then reconsider.
We know now we can migrate, but we don't know 100% what we are going to do with SSG next year.
So basically we have the following todos:
- check out nextjs 15 with turbo pack
- understand what vite can do in terms of SSG when needed.
@@theSnackableCTO indeed and with vite 6.0 having more than just server / client... things get even harder decisions and all the money evan raised for vites continued development.
right now is the "inbetween". the other tech is not mature enough and the OG, ie nextjs even though starting to look a little dated - is still the defacto.
oh yeh just to throw another spanner in the works as it were... i just did an astro project and it felt like everything nextjs could be. It was fast and easy to get running + vite ;)
@@mrrolandlawrence I totally get you and I agree.
Regarding Astro, it's interesting, tho it's mainly focused on static apps, as far as I know.
Remix on the other hand is vice versa; many mentioning this one as well.
Vite sounds indeed promising, since maturity is a important NFR. I don't want to change underlying foundations every year.
Maybe I take a look into comparing next15+ and vite 6+ with a side&view on Astro and Remix.
Could be an interesting topic.
Stupid me always confuses Next.js and Nest.js :-)
I feel the same way, as a mnemonic I have the backend sitting in a bird's nest high up in a tree where nobody can see it. 😀 Maybe a bit complicated. But it works for me.
comparing apples with bananas
Well, they are different, but they have in common to be platforms for react. Since this gap between them becomes larger it makes sense think deeper which of them (or others) makes sense for the future. Basically reevaluating.
Next => Nuxt
@@duncandejong when you have decided that Vue is your way to go and you are willing to rebuild or start a migration with strangler-fig approach then that's a possible way.
Wouldn't be interesting for us in our context, tho.
You prefer Vue in general?
@@theSnackableCTO for now nuxt/vue is my goto. But its just one character difference :-)
hehe yes. The differnece is just a typo, why should we bother that much 😀
We uses next js. But I feel like vite is a better option. Next project will start with vite.
That's interesting and pretty much what we think.
Do you use server-side components or SSG in general a lot?
@@theSnackableCTO Only in marketing pages when required. Some page does have the nextjs data fetching but we don't use any fancy server action. It is far more better and transparent to build APIs and call them.
Interesting. So far I tried to avoid server actions, since they aren't agnostic. I heard that vercel is planning to keep it like that, but a solid backend with API is currently what serves us best.
next js is good product but not good framework
Next.js is better I think.
@@iamerika1937 interesting!
I would have two questions, if you don't mind?
A: Are you using SSR?
B: What would be your number one reason to go with next?