11 ms·

Next.js 8 released

241 points by keybits 8y ago

kowdermeister 8y ago
Here's the PR to Webpack: https://github.com/webpack/webpack/pull/8609 https://github.com/webpack/webpack/pull/8609
jypepin 8y ago
I've been using Next.js for a fairly big e-commerce project for a client, and I have to say it's great. The framework itself makes working with a React, universal rendering app much easier than other solutions I've worked with. It's doing a great job at starting very small while at the same time extending for your needs is pretty easy for most things (such as build configs, custom server, etc). The community is growing and very helpful too. I'm very glad to see it continue to move so fast and definitely already see it as a very strong option and probably becoming the de-facto solution for JS apps, just how Rails or Django are to Ruby and Python. Thanks to the team for the great work :) edit: typos
- chimen 8y ago
  It's great but not becoming the de-facto. I believe Gatsby is on that path, in terms of popularity they seem to be ahead.
  - skrebbel 8y ago
    I thought Gatsby is a static site generator?
    - toper-centage 8y ago
      Yes and in that sense it overlaps next a bit... But next is much more.
      - skrebbel 8y ago
        In the way that Jekyll and Rails overlap?
    - onion2k 8y ago
      It is, but "static site" is just a methodology for delivering content to the browser (static rendered HTML + server side [rendering|hydration] + client side routing). Traditionally people have used static sites for marketing, blogs and documentation but there's no reason why they have to be limited to just those sorts of sites. GatsbyJS's site has tutorials for how you can do authenticated users, ecommerce, etc with it. https://www.gatsbyjs.org/docs/authentication-tutorial/ https://www.gatsbyjs.org/docs/authentication-tutorial/
  - jypepin 8y ago
    Great answer from Tim [1], the lead maintainer of Next on the difference of the 2 (the whole thread is great). I've never used Gatsby so I can't really judge, but my understanding has always been that Gatsby is mostly focused on static sites. It can definitely do dynamic apps but it being not focused on this would concern me for support / experience of more complex things. [1] https://www.reddit.com/r/reactjs/comments/992n2r/next_vs_gatsby/e4lrffl/ https://www.reddit.com/r/reactjs/comments/992n2r/next_vs_gat...
    - fro0116 8y ago
      Also learned about Razzle through that thread: https://github.com/jaredpalmer/razzle https://github.com/jaredpalmer/razzle > Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or react-server, fork a boilerplate, or set things up yourself. Aiming to fill this void, Razzle is a tool that abstracts all complex configuration needed for SSR into a single dependency--giving you the awesome developer experience of create-react-app, but then leaving the rest of your app's architectural decisions about frameworks, routing, and data fetching up to you. With this approach, Razzle not only works with React, but also Reason, Elm, Vue, Angular, and most importantly......whatever comes next. Sounds like a really nice alternative to Next.js and Gatsby. Does anyone have any experience with it?
      - t1amat 8y ago
        Just finished running a project with Razzle. It’s nice, the only headaches we experienced were with the SCSS plugin and using environment variables. Decent experience.
  - andrewingram 8y ago
    We're currently migrating from Gatsby to Next (we need things to be more dynamic), and the experience has been extremely painful. The main reason for this is that with Gatsby you end up writing a lot of code in what I call "the Gatsby way", which is very different to how you'd do things in a dynamic site. One interesting comparison is on imports alone. The old site has 128 imports from gatsby* packages (it's not a very big site btw), the new site has around 10 from next* packages.
  - tekkk 8y ago
    I just have to say that Gatsby has a lot of work to do to reduce the amount of boilerplate and tweaking involved for creating say a simple blog site. In some parts I feel they are over-abstracting maybe a little too much at the cost of simplicity. Eg. the spagetti required to render blog-pages from markdown is pretty ugly.
    - tvanantwerp 8y ago
      Agree. Gatsby has some nice features out of the box, but learning to use them all isn't easy. As static site generators go, Jekyll was much simpler to learn and get going with.
- deleted 8y ago
  [deleted]
martpie 8y ago
Next.js is an awesome framework, but dynamic routing is still a mess, and clean URL masking [0] is unnecessary complicated: you have to add a route handler to Express.js, and you have to use 2 different props to your <Link> components to make it work. The Next team explains it because they don't want to solve this problem by shipping a definition of all the route of the app [1] because it does not scale. But while it is true, it makes dynamic routes extremely painful to use. Hopefully it will be fixed soon. Another thing not mentioned in the blog post is they started to rewrite the core of Next.js in TypeScript too, which is a big move! [0] https://nextjs.org/learn/basics/clean-urls-with-route-masking [1] https://github.com/zeit/next.js/issues/4989#issuecomment-442024894
- andrewingram 8y ago
  We had the same problem, and weren't happy with next-routes as a solution. Ultimately we ended up making our own library to handle routing. It's pretty low-level (some stuff is left for implementation in user-land), but so far it's been solid: https://github.com/Zegocover/next-route-resolver https://github.com/Zegocover/next-route-resolver There is a bug right now related to query strings being hidden from the visible URL (they're still there as far as Next is concerned), but we'll be fixing that pretty soon.
- adevx 8y ago
  This. I started out with a similar framework called nuxt.js but found the routing to be too limiting. It's a nice way to get started quickly, but once things become more complex you hit too many hurdles. In the end it pays to do the project setup yourself, which also helps a ton in debugging issues along the way.
  - thelittleone 8y ago
    Can you share what you found limiting with nuxtjs routing? Genuinely curious.
    - adevx 8y ago
      As you probably know, Nuxt.js uses a folder to url mapping, so say /src/views/contact/index.vue maps to /contact In my case I wanted to be able to change the url depending on the language of the user. And not by prefixing it with a /en/contact vs /de/kontact. To make matters more complicated, I serve multiple domains from the same node/express instance and determine the correct site data to render based on the domainname. There were plugins and hacks to make this somewhat possible, but it felt like going against the philosophy of nuxt.js. I still think it's a fantastic framework if your needs align with this type of routing. I ended up using the Vue SSR HackerNews repo as a template.
fredley 8y ago
Holy crap, these pages load fast. Honestly the best possible advertisement for a javascript framework at the moment is how quickly the page paints. For me it was virtually instantaneous. Bravo.
- Ndymium 8y ago
  I'm behind a mobile connection which has been acting up today. For me the experience on the website was pretty bad, as there were no loading indicators. I clicked on a link and it did nothing for several seconds. Since it's not a real page load, my browser did not show any indication of loading either. I'm not entirely sure what next.js does, but I would be wary of using this library due to the bad website experience on a non-optimal connection.
  - mAritz 8y ago
    Loading indicators are left up for developers to add in next.js, but aren't very difficult to do. I've used react-redux-loading-bar[1] in a recent small project of mine and it worked quite well so far. I'm not sure about working with the native loading indicators though. In general I quite like the way next.js is handling these things: It's pretty bare-bone but provides a lot of examples of how to do more advanced things.[2] There's even an example for loading indicators: https://github.com/zeit/next.js/tree/canary/examples/with-loading https://github.com/zeit/next.js/tree/canary/examples/with-lo... [1] https://github.com/mironov/react-redux-loading-bar https://github.com/mironov/react-redux-loading-bar [2] https://github.com/zeit/next.js/tree/canary/examples https://github.com/zeit/next.js/tree/canary/examples
    - timneutkens 8y ago
      Great explanation @mAritz! Thank you for your feedback @Ndymium, we've shipped a new version of the website that has a loading indication (based on the with-loading example posted above)
- subpixel 8y ago
  Note that these pages are not serving dynamic data - unless I'm mistaken, they are an example of Next.js static export
jackweirdy 8y ago
Interested to see serverless as part of a web framework. My understanding was AWS Lambda and similar platforms were best for asynchronous workloads, but for web stuff the cold start could be too long for things to feel snappy. Has that changed recently?
- timneutkens 8y ago
  It actually works really well for render workloads like server-side rendering too, the reason for this is that rendering can be quite expensive and blocks the thread. With Serverless you're able to scale the renderer to infinite instances. The cold-boot problem is an interesting one, it's heavily correlated to the serverless function size, this is why we implemented a complete output target for serverless, to output the smallest possible function that is completely standalone, no dependencies. This makes cold-boot considerably faster. For example on https://next-news.now.sh/ https://next-news.now.sh/ it's hard to tell the difference between cold-boot and warm functions.
  - revskill 8y ago
    You mean scale the renderer to infinite $$$$ ? It's a lol. In a non-serverless environment, i could control that scale better without scaling $$$.
  - jackweirdy 8y ago
    That’s interesting thanks - I didn’t know this. And thanks for the example site too! Definitely feels snappier than I anticipated.
midway 8y ago
What I don't get: Either you go full SPA or SSR. And If you go for latter then you can choose any stack, e.g. Rails, express with pug, Django, PHP, etc. Why do people take React's constraints to the backend? No bashing, really wondering what's so much better then. I know why a React SPA can be better than a SSR. But what is better about a React SSR vs the typical SSR?
- sshine 8y ago
  SPA? SSR?
  - mcescalante 8y ago
    They stand for Single Page Application (client side) and Server Side Rendering (which makes a JS app render more like a normal server side page for the client) respectively.
  - tunesmith 8y ago
    single-page-app, server-side-rendering
  - nfriedly 8y ago
    SPA = Single Page App SSR = Server Side Rendered SPAs run in the browser, therefore they must be written in JavaScript (or something that compiles to it.) SPAs have the drawback of having to load a bunch of JavaScript before rendering anything, so the initial page load tends to be slow. Next.js gets around this by performing SSR for the initial page view, and then you're already looking at that page while all of the JS loads to render subsequent pages.
    - nailer 8y ago
      The term 'SPA' is a little outdated - since HTML5 history (which is nearly a decade old now) most 'SPAs' are actually multiple pages. 'web apps' is better.
- rymate1234 8y ago
  I don't think it's any better or worse, it's just an additional way of writing SSR sites where React is a templating language. React is just another option for a stack - similar to express with pug, you can have express with React, without having to learn a new templating language if you already know React. And with things like TypeScript, you can have type checking into the mix too
andreareina 8y ago
So the tutorial requires me to login with github? Sorry, not gonna happen.
- midway 8y ago
  This is great comment and while Zeit/Next.js related folks are happy to explain in this thread why Next is so great, they're not give us any reason why we need to login for a random tutorial. Maybe it's to generate leads? Leads which can be converted to paying customers? This why this whole thing shouldn't be on HN, this thing is conflicted from the ground and driven by commercial interests.
  - lkbr 8y ago
    Yo, you wanna chillout with flinging the accusations? Every single one of your comments in this whole thread is either bullheaded negative or a subtle suggestion that Next.js is some marketing conspiracy without its own merit. If you don't like Next or don't see its usefulness thats fine, but 30,000 stars on Github and pretty varied list[1] of companies seems to suggest that some people do find it useful. I am not affiliated with Zeit or Next.js in any particular way. Just a happy user of Next and appreciative of all the hard work put into it. [1] https://nextjs.org/showcase/ https://nextjs.org/showcase/
    - deleted 8y ago
      [deleted]
- dirkc 8y ago
  You can still access the content without logging in, just use the navigation on the left rather than clicking on "login & start". It does feel pretty aggressive of them to want you to log in.
  - deltron3030 8y ago
    The content that is accessible through the navigation seams to be only a teaser for the content that is hidden behind the login.
proyb2 8y ago
One concern on mobile where I find the scrolling is not respond for a second or longer whenever I swipe back to previous page in Safari, applicable in some of the showcases in Next.js too, is it the expected user experience?
- tracker1 8y ago
  People are calling out the routing issues specific to next.js ... I am not using that, but am using react with redux and routing (connected-react-router) and haven't experienced the types of issue you mention. Though many on here point out that next.js routing is a major shortcoming.
gtycomb 8y ago
How similar is this with Nuxt.js?
- viiralvx 8y ago
  Next predates Nuxt, so Nuxt was inspired by Next. Next = SSR + React Nuxt = SSR + Vue.js
  - gtycomb 8y ago
    thank you, this helps. The question comes because I do not have a handle on react.js and I do know something about Vue.js.
seddin 8y ago
If you are going to use it as a static site generator, you should also try Hugo + the Mainroad theme, generated files are super light and easy to style as you wish.
seddin 8y ago
@zeit employees are some really talented developers
midway 8y ago
Interesting read from Dec 2018 [1] about Next.js: SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. [...] Using Pre-Rendered CRA addresses both the SEO and performance concerns around using CRA without the complexity that Next.js introduces [1] https://codeburst.io/next-js-ssr-vs-create-react-app-csr-7452f71599f6 https://codeburst.io/next-js-ssr-vs-create-react-app-csr-745...
- strictnein 8y ago
  Acronym translations: SSR: Server-side rendering CSR: Client-side rendering CRA: create-react-app

241 points by keybits 8y ago

Here's the PR to Webpack: https://github.com/webpack/webpack/pull/8609 https://github.com/webpack/webpack/pull/8609

I've been using Next.js for a fairly big e-commerce project for a client, and I have to say it's great. The framework itself makes working with a React, universal rendering app much easier than other solutions I've worked with. It's doing a great job at starting very small while at the same time extending for your needs is pretty easy for most things (such as build configs, custom server, etc). The community is growing and very helpful too. I'm very glad to see it continue to move so fast and definitely already see it as a very strong option and probably becoming the de-facto solution for JS apps, just how Rails or Django are to Ruby and Python. Thanks to the team for the great work :) edit: typos

chimen 8y ago
It's great but not becoming the de-facto. I believe Gatsby is on that path, in terms of popularity they seem to be ahead.
- skrebbel 8y ago
  I thought Gatsby is a static site generator?
  - toper-centage 8y ago
    Yes and in that sense it overlaps next a bit... But next is much more.
    - skrebbel 8y ago
      In the way that Jekyll and Rails overlap?
  - onion2k 8y ago
    It is, but "static site" is just a methodology for delivering content to the browser (static rendered HTML + server side [rendering|hydration] + client side routing). Traditionally people have used static sites for marketing, blogs and documentation but there's no reason why they have to be limited to just those sorts of sites. GatsbyJS's site has tutorials for how you can do authenticated users, ecommerce, etc with it. https://www.gatsbyjs.org/docs/authentication-tutorial/ https://www.gatsbyjs.org/docs/authentication-tutorial/
- jypepin 8y ago
  Great answer from Tim [1], the lead maintainer of Next on the difference of the 2 (the whole thread is great). I've never used Gatsby so I can't really judge, but my understanding has always been that Gatsby is mostly focused on static sites. It can definitely do dynamic apps but it being not focused on this would concern me for support / experience of more complex things. [1] https://www.reddit.com/r/reactjs/comments/992n2r/next_vs_gatsby/e4lrffl/ https://www.reddit.com/r/reactjs/comments/992n2r/next_vs_gat...
  - fro0116 8y ago
    Also learned about Razzle through that thread: https://github.com/jaredpalmer/razzle https://github.com/jaredpalmer/razzle > Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or react-server, fork a boilerplate, or set things up yourself. Aiming to fill this void, Razzle is a tool that abstracts all complex configuration needed for SSR into a single dependency--giving you the awesome developer experience of create-react-app, but then leaving the rest of your app's architectural decisions about frameworks, routing, and data fetching up to you. With this approach, Razzle not only works with React, but also Reason, Elm, Vue, Angular, and most importantly......whatever comes next. Sounds like a really nice alternative to Next.js and Gatsby. Does anyone have any experience with it?
    - t1amat 8y ago
      Just finished running a project with Razzle. It’s nice, the only headaches we experienced were with the SCSS plugin and using environment variables. Decent experience.
- andrewingram 8y ago
  We're currently migrating from Gatsby to Next (we need things to be more dynamic), and the experience has been extremely painful. The main reason for this is that with Gatsby you end up writing a lot of code in what I call "the Gatsby way", which is very different to how you'd do things in a dynamic site. One interesting comparison is on imports alone. The old site has 128 imports from gatsby* packages (it's not a very big site btw), the new site has around 10 from next* packages.
- tekkk 8y ago
  I just have to say that Gatsby has a lot of work to do to reduce the amount of boilerplate and tweaking involved for creating say a simple blog site. In some parts I feel they are over-abstracting maybe a little too much at the cost of simplicity. Eg. the spagetti required to render blog-pages from markdown is pretty ugly.
  - tvanantwerp 8y ago
    Agree. Gatsby has some nice features out of the box, but learning to use them all isn't easy. As static site generators go, Jekyll was much simpler to learn and get going with.
deleted 8y ago
[deleted]

martpie 8y ago

Next.js is an awesome framework, but dynamic routing is still a mess, and clean URL masking [0] is unnecessary complicated: you have to add a route handler to Express.js, and you have to use 2 different props to your <Link> components to make it work. The Next team explains it because they don't want to solve this problem by shipping a definition of all the route of the app [1] because it does not scale. But while it is true, it makes dynamic routes extremely painful to use. Hopefully it will be fixed soon. Another thing not mentioned in the blog post is they started to rewrite the core of Next.js in TypeScript too, which is a big move! [0] https://nextjs.org/learn/basics/clean-urls-with-route-masking [1] https://github.com/zeit/next.js/issues/4989#issuecomment-442024894

andrewingram 8y ago
We had the same problem, and weren't happy with next-routes as a solution. Ultimately we ended up making our own library to handle routing. It's pretty low-level (some stuff is left for implementation in user-land), but so far it's been solid: https://github.com/Zegocover/next-route-resolver https://github.com/Zegocover/next-route-resolver There is a bug right now related to query strings being hidden from the visible URL (they're still there as far as Next is concerned), but we'll be fixing that pretty soon.
adevx 8y ago
This. I started out with a similar framework called nuxt.js but found the routing to be too limiting. It's a nice way to get started quickly, but once things become more complex you hit too many hurdles. In the end it pays to do the project setup yourself, which also helps a ton in debugging issues along the way.
- thelittleone 8y ago
  Can you share what you found limiting with nuxtjs routing? Genuinely curious.
  - adevx 8y ago
    As you probably know, Nuxt.js uses a folder to url mapping, so say /src/views/contact/index.vue maps to /contact In my case I wanted to be able to change the url depending on the language of the user. And not by prefixing it with a /en/contact vs /de/kontact. To make matters more complicated, I serve multiple domains from the same node/express instance and determine the correct site data to render based on the domainname. There were plugins and hacks to make this somewhat possible, but it felt like going against the philosophy of nuxt.js. I still think it's a fantastic framework if your needs align with this type of routing. I ended up using the Vue SSR HackerNews repo as a template.

fredley 8y ago

Holy crap, these pages load fast. Honestly the best possible advertisement for a javascript framework at the moment is how quickly the page paints. For me it was virtually instantaneous. Bravo.

Ndymium 8y ago
I'm behind a mobile connection which has been acting up today. For me the experience on the website was pretty bad, as there were no loading indicators. I clicked on a link and it did nothing for several seconds. Since it's not a real page load, my browser did not show any indication of loading either. I'm not entirely sure what next.js does, but I would be wary of using this library due to the bad website experience on a non-optimal connection.
- mAritz 8y ago
  Loading indicators are left up for developers to add in next.js, but aren't very difficult to do. I've used react-redux-loading-bar[1] in a recent small project of mine and it worked quite well so far. I'm not sure about working with the native loading indicators though. In general I quite like the way next.js is handling these things: It's pretty bare-bone but provides a lot of examples of how to do more advanced things.[2] There's even an example for loading indicators: https://github.com/zeit/next.js/tree/canary/examples/with-loading https://github.com/zeit/next.js/tree/canary/examples/with-lo... [1] https://github.com/mironov/react-redux-loading-bar https://github.com/mironov/react-redux-loading-bar [2] https://github.com/zeit/next.js/tree/canary/examples https://github.com/zeit/next.js/tree/canary/examples
  - timneutkens 8y ago
    Great explanation @mAritz! Thank you for your feedback @Ndymium, we've shipped a new version of the website that has a loading indication (based on the with-loading example posted above)
subpixel 8y ago
Note that these pages are not serving dynamic data - unless I'm mistaken, they are an example of Next.js static export

jackweirdy 8y ago

Interested to see serverless as part of a web framework. My understanding was AWS Lambda and similar platforms were best for asynchronous workloads, but for web stuff the cold start could be too long for things to feel snappy. Has that changed recently?

timneutkens 8y ago
It actually works really well for render workloads like server-side rendering too, the reason for this is that rendering can be quite expensive and blocks the thread. With Serverless you're able to scale the renderer to infinite instances. The cold-boot problem is an interesting one, it's heavily correlated to the serverless function size, this is why we implemented a complete output target for serverless, to output the smallest possible function that is completely standalone, no dependencies. This makes cold-boot considerably faster. For example on https://next-news.now.sh/ https://next-news.now.sh/ it's hard to tell the difference between cold-boot and warm functions.
- revskill 8y ago
  You mean scale the renderer to infinite $$$$ ? It's a lol. In a non-serverless environment, i could control that scale better without scaling $$$.
- jackweirdy 8y ago
  That’s interesting thanks - I didn’t know this. And thanks for the example site too! Definitely feels snappier than I anticipated.

midway 8y ago

What I don't get: Either you go full SPA or SSR. And If you go for latter then you can choose any stack, e.g. Rails, express with pug, Django, PHP, etc. Why do people take React's constraints to the backend? No bashing, really wondering what's so much better then. I know why a React SPA can be better than a SSR. But what is better about a React SSR vs the typical SSR?

sshine 8y ago
SPA? SSR?
- mcescalante 8y ago
  They stand for Single Page Application (client side) and Server Side Rendering (which makes a JS app render more like a normal server side page for the client) respectively.
- tunesmith 8y ago
  single-page-app, server-side-rendering
- nfriedly 8y ago
  SPA = Single Page App SSR = Server Side Rendered SPAs run in the browser, therefore they must be written in JavaScript (or something that compiles to it.) SPAs have the drawback of having to load a bunch of JavaScript before rendering anything, so the initial page load tends to be slow. Next.js gets around this by performing SSR for the initial page view, and then you're already looking at that page while all of the JS loads to render subsequent pages.
  - nailer 8y ago
    The term 'SPA' is a little outdated - since HTML5 history (which is nearly a decade old now) most 'SPAs' are actually multiple pages. 'web apps' is better.
rymate1234 8y ago
I don't think it's any better or worse, it's just an additional way of writing SSR sites where React is a templating language. React is just another option for a stack - similar to express with pug, you can have express with React, without having to learn a new templating language if you already know React. And with things like TypeScript, you can have type checking into the mix too

andreareina 8y ago

So the tutorial requires me to login with github? Sorry, not gonna happen.

midway 8y ago
This is great comment and while Zeit/Next.js related folks are happy to explain in this thread why Next is so great, they're not give us any reason why we need to login for a random tutorial. Maybe it's to generate leads? Leads which can be converted to paying customers? This why this whole thing shouldn't be on HN, this thing is conflicted from the ground and driven by commercial interests.
- lkbr 8y ago
  Yo, you wanna chillout with flinging the accusations? Every single one of your comments in this whole thread is either bullheaded negative or a subtle suggestion that Next.js is some marketing conspiracy without its own merit. If you don't like Next or don't see its usefulness thats fine, but 30,000 stars on Github and pretty varied list[1] of companies seems to suggest that some people do find it useful. I am not affiliated with Zeit or Next.js in any particular way. Just a happy user of Next and appreciative of all the hard work put into it. [1] https://nextjs.org/showcase/ https://nextjs.org/showcase/
  - deleted 8y ago
    [deleted]
dirkc 8y ago
You can still access the content without logging in, just use the navigation on the left rather than clicking on "login & start". It does feel pretty aggressive of them to want you to log in.
- deltron3030 8y ago
  The content that is accessible through the navigation seams to be only a teaser for the content that is hidden behind the login.

proyb2 8y ago

One concern on mobile where I find the scrolling is not respond for a second or longer whenever I swipe back to previous page in Safari, applicable in some of the showcases in Next.js too, is it the expected user experience?

tracker1 8y ago
People are calling out the routing issues specific to next.js ... I am not using that, but am using react with redux and routing (connected-react-router) and haven't experienced the types of issue you mention. Though many on here point out that next.js routing is a major shortcoming.

gtycomb 8y ago

How similar is this with Nuxt.js?

viiralvx 8y ago
Next predates Nuxt, so Nuxt was inspired by Next. Next = SSR + React Nuxt = SSR + Vue.js
- gtycomb 8y ago
  thank you, this helps. The question comes because I do not have a handle on react.js and I do know something about Vue.js.

seddin 8y ago

If you are going to use it as a static site generator, you should also try Hugo + the Mainroad theme, generated files are super light and easy to style as you wish.

seddin 8y ago

@zeit employees are some really talented developers

midway 8y ago

Interesting read from Dec 2018 [1] about Next.js: SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. [...] Using Pre-Rendered CRA addresses both the SEO and performance concerns around using CRA without the complexity that Next.js introduces [1] https://codeburst.io/next-js-ssr-vs-create-react-app-csr-7452f71599f6 https://codeburst.io/next-js-ssr-vs-create-react-app-csr-745...

strictnein 8y ago
Acronym translations: SSR: Server-side rendering CSR: Client-side rendering CRA: create-react-app