This project looks awesome. Im going to be creating a new project and was just wondering between next.js, create-react-app, and razzle, what are the benefits, or what would be best long term. I would really like SSR so CRA is probably out of the question. I have built an app with next and then discovered this project. Hopefully this is an ok place to ask this but just wanted to get some thoughts on whats best for the long term.
knipferrc
All 5 comments
I think everyone would agree on that the correct answer would be that this depends on what you and your new project needs.
As far as I know Next.js is a complete framework which can be optionally used as a part of the ZEIT ecosystem? or platform?. Whereas Razzle is way more minimalistic. So it doesn't includes features which you may not need, but it is also true that it doesn't includes features which you may need or you will may need eventually.
I have also considered using Next.js before, but there were some small details which were irritating for me. For example Next.js doesn't minify the HTML output properly (I know this is not that important at all, but this was a deal breaker for me.). It also uses styled-jsx an CSS-in-JS, but I prefer Styled Components. Plus for my new project I didn't needed routing (yet 😄).
Finally and luckily after testing a bunch of example projects, I ended up finding and using Razzle. Actually I have started with creating an example project called Razzle Material UI Styled Example including some modules and features I need. So now I can work on my new project almost shamelessly. Feel free to use the mentioned repository if you need the same features or some of them.
kireerik
on 6 Jun 2017
Thanks @knipferrc
A similar experience led me to creating Razzle.
About 6 months ago, I started a huge app with Next.js right after it came out and the churn was too much for me to handle. I literally submitted the PR for the parameterized routing example (i.e. /user/:id). I remember that I lost an entire week of work because of some weird bug related to firing off getInitialProps on route changes. At the end of the day, Next.js makes a lot of very important decisions for you (i.e. routing, data-fetching, folder structure, and styling). Whether these are good or bad entirely depends on the kind of application you are building. As it turned out, I didn't actually need to server render every single route (only like 2), I wanted client loading states instead of full page reloads, and I didn't want to destroy the global state tree between route changes. That, coupled with my opinion that React-Router 4 is the best thing since sliced bread, meant Next.js was not the right fit for the project.
Looking for something more stable, I moved to NYT's kyt project. This was sufficient for around ~2 months, but 1) build times became insanely slow (>45s) as the app grew, 2) kyt's SCSS rules weren't the right fit for the project, and 3) I found kyt's logging (with the insane amount of emoji) pretty annoying. So I decided to start working on a thinner, faster replacement for kyt, but with universal HMR and a similar configuration API to Next.js--create-react-app-ssr, so to speak.
Once all was said and done, I realized I had created a nearly framework-agnostic build system and that this level of abstraction was more suited for my project's needs. By "framework-agnostic," I mean that Razzle will 100% work with Angular, Vue, Rax, Preact, Inferno, React-XP, RN-Web, Reason-React and, _most importantly to me_, whatever crazy stuff comes next. IMHO, Adaptability is the key differentiator between Razzle and pretty much everything else I've seen. With Razzle, you can read about something in a blog post, create a fork, add a babel-transform/webpack config/parallel build system and just go try shit. Why? Because unlike Next, Razzle isn't a framework and unlike CRA, Razzle lets you augment the underlying configuration without forking it. That's huge for the way I learn, teach, experiment and do business.
Razzle's flexibility and agnosticism have already paid off for me and my team:
- We incrementally moved our app from partially-Flow to 100% TypeScript by changing less than 10 lines of code in
razzle.config.js. - Without even trying, Razzle has become the fastest way to bootstrap a ReasonReact project (SSR or SPA).
As for Razzle's future. Two days ago, "adding SSR support to CRA" was mentioned as a top ~15 todo on the React Core team's roadmap. If SSR support is added to CRA, Razzle may no longer need to exist..._and I am totally cool with that_. Until that happens though, Razzle will push forward as a framework-agnostic build tool for server rendered universal JavaScript.
jaredpalmer
on 6 Jun 2017
Wow!! Thank you guys so much for the awesome replies.
knipferrc
on 7 Jun 2017
Hi Jared, I am not very clear on how to use Razzle to convert an SPA Angular project into SSR.
Can you please give me a hint or guide on how to do that? Thank you so much.
ngodichat
on 19 Sep 2019
+1 for a Razzle Angular solution. https://github.com/jaredpalmer/razzle/issues/1109
laurencefass
on 16 Dec 2019
Related issues
MaxGoh
·
4Comments
jcblw
·
4Comments
kkarkos
·
3Comments
piersolenski
·
4Comments
mhuggins
·
3Comments
Most helpful comment
Thanks @knipferrc
A similar experience led me to creating Razzle.
About 6 months ago, I started a huge app with Next.js right after it came out and the churn was too much for me to handle. I literally submitted the PR for the parameterized routing example (i.e.
/user/:id). I remember that I lost an entire week of work because of some weird bug related to firing off getInitialProps on route changes. At the end of the day, Next.js makes a lot of very important decisions for you (i.e. routing, data-fetching, folder structure, and styling). Whether these are good or bad entirely depends on the kind of application you are building. As it turned out, I didn't actually need to server render every single route (only like 2), I wanted client loading states instead of full page reloads, and I didn't want to destroy the global state tree between route changes. That, coupled with my opinion that React-Router 4 is the best thing since sliced bread, meant Next.js was not the right fit for the project.Looking for something more stable, I moved to NYT's kyt project. This was sufficient for around ~2 months, but 1) build times became insanely slow (>45s) as the app grew, 2) kyt's SCSS rules weren't the right fit for the project, and 3) I found kyt's logging (with the insane amount of emoji) pretty annoying. So I decided to start working on a thinner, faster replacement for kyt, but with universal HMR and a similar configuration API to Next.js--
create-react-app-ssr, so to speak.Once all was said and done, I realized I had created a nearly framework-agnostic build system and that this level of abstraction was more suited for my project's needs. By "framework-agnostic," I mean that Razzle will 100% work with Angular, Vue, Rax, Preact, Inferno, React-XP, RN-Web, Reason-React and, _most importantly to me_, whatever crazy stuff comes next. IMHO, Adaptability is the key differentiator between Razzle and pretty much everything else I've seen. With Razzle, you can read about something in a blog post, create a fork, add a babel-transform/webpack config/parallel build system and just go try shit. Why? Because unlike Next, Razzle isn't a framework and unlike CRA, Razzle lets you augment the underlying configuration without forking it. That's huge for the way I learn, teach, experiment and do business.
Razzle's flexibility and agnosticism have already paid off for me and my team:
razzle.config.js.As for Razzle's future. Two days ago, "adding SSR support to CRA" was mentioned as a top ~15 todo on the React Core team's roadmap. If SSR support is added to CRA, Razzle may no longer need to exist..._and I am totally cool with that_. Until that happens though, Razzle will push forward as a framework-agnostic build tool for server rendered universal JavaScript.