Next.js 8 released

(nextjs.org)

241 points | by keybits 11 days ago

12 comments

  • martpie 11 days 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 11 days 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

      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 11 days 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 11 days ago

          Can you share what you found limiting with nuxtjs routing? Genuinely curious.

          • adevx 11 days 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.

      • jekrb 11 days ago

        Hey there!

        Not sure if you've seen this guide here, but there is a way to setup dynamic routing with clean URLs that doesn't require adding your own server handler if you use Now v2 for deployments:

        https://zeit.co/guides/custom-next-js-server-to-routes/

        Also, I recently wrote about how I locally develop Now v2 apps with an example of SSR dynamic routes:

        https://medium.com/digital-surgeons-engineering/how-to-set-u...

        • nikolay 11 days ago

          Is this Now only as I'm sure most of us don't use Now?

      • ex3ndr 11 days ago

        We are using `next-routes` and they are working really well for us.

        • atombender 11 days ago

          next-routes is good, but it was unmaintained for a long time, with issues and PRs (27 at the time of writing!) piling up. A new maintainer was just added [1] who seems more active, so hopefully things will improve.

          [1] https://github.com/fridays/next-routes/issues/244#issuecomme...

          • ex3ndr 10 days ago

            Almost all of them are just version bumps. We wasn't needed anything for a year of usage.

          • acoyfellow 11 days ago

            Second this. In production for nearly a near now.

          • midway 11 days ago

            > they started to rewrite the core of Next.js

            This is such an important piece of information. Imagine you opt for Next and have to rewrite your app soon. I know, APIs can be backwards compatible and Next's next version will be backwards compatible but there is always something which doesn't work, sending you down the rabbit hole...

            • mxstbr 11 days ago

              The core stays the same, they are only adding static types. I am certain they will make sure nothing meaningful will change in the outputted JavaScript, except for potential bug fixes uncovered by the types!

              Your apps should not be affected at all.

              • midway 11 days ago

                > they are only adding static types.

                The parent says something different and if it were just about adding types then you need just to add a file to DefinitelyTyped which I guess happened already.

                • mxstbr 11 days ago

                  Yes it says they are "rewriting the core in TypeScript", but that does not necessarily mean changing the code in any meaningful way. It means adding static types to the core itself, not only the interface (which DefinitivelyTyped is for).

                  • timneutkens 11 days ago

                    Max is definitely right here. We're not planning to deprecate or "completely rewrite" anything.

                    We're not even "rewriting everything in Typescript at once". We're slowly converting files over one by one. No public APIs are changed. Furthermore, we have an extensive test suite of end-to-end tests for both development and production behavior.

          • midway 11 days 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?

            • Illniyar 11 days ago

              Simple, SEO. We want full SPA, but also want SEO to work without shaky unreliable prerendering. Hence server-side-rendering for SPAs.

              Some will tell you that it's for first time loading performance, but in this day and age, I doubt that even registers for business impact.

              • midway 11 days ago

                Still don't get it. Next.js gives you a vendor lock-in and its features are easily avail w/o Next (eg. automatic code-splitting, this is standard stuff in CRA, why the fuss?). If your business is about SEO then React is the wrong choice anyway. In my understanding SEO is about hundred-thousands or even millions landing pages, keyword management, content spinning, ultra fast loads, AMP, etc. This is really not the field of React or SPAs and you can tweak them as much as you want. React is great to build eg stateful SaaS, interactive stuff, dashboard, nice shop check-outs.

                That they rewrite Next doesn't sound more convincing. And why do I need to sign-in on the learn page on Nextjs?

                Sorry, not convinced. If you want some brute-force SEO, I'll write you anything in express/pug/style in one afternoon (with millions of landing pages, sitemap generation and smart routing, all comes out of the box with express), without all the baggage React brings along. Nothing against React, it's still one of the best SPA libs there but SSR, no way.

                Maybe, I am still missing something but Next.js feels just like content marketing from its company Zeit trying to promote their commercial stuff.

                Edit: guys, pls don't downvote if you disagree, downvoting is if comments don't add anything substantial to the discussion. I understand that Zeit is happy about the free promotion for Next on HN and doesn't like such comments but pls stay professional if people question your product without downvoting.

                • todd3834 11 days ago

                  I’m very involved in this space. The company I work for wrote a library similar to Next.js before it was announced and before create-react-app. There are so many things that these solutions solve to only focus on SSR is missing the point. SSR is one benefit of many and others have already explained why they care about that. There are many use cases where both SEO and complex interactions make sense on the same page. Next.js is also going to help you with overall architecture decisions like routing, page level code splitting, where you fetch data just off the top of my head. Sure you can build these yourself, that’s what I did before Next.js was a thing but now that I have a deep understanding of all of the things we wrote. I would use an existing community backed solution before building from scratch in a new app. We are even very interested in migrating from our home rolled solution. Currently we are vendor locked into our own creation which means we have to continue to maintain it. It is way more expensive than any lock in that would have come with Next.js.

                  • tracker1 11 days ago

                    +1, even though I don't use the next.js tools, sometimes having certain things configured in the box is useful. I tend to stick with jest for testing simply because code coverage tooling can be a pain to get working right with babel, etc and it's just easier to use jest.

                    As to why SSR React, it's mostly going to come down to SEO, I don't know how much you'll get negatively impacted for being SSR vs SPA these days with proper routing myself. Google has been working on supporting client rendered scraping for at least 6-7 years now. And when a user hits more than one route, they've usually gained back anything they've lost for the extra load time.

                    • midway 11 days ago

                      > Next.js is also going to help you with [...] routing

                      I respect your experience and knowledge but people in this thread say exactly the opposite: Next.js' routing is actually not helping you.

                      • todd3834 11 days ago

                        Fair enough. It helps you but it could be better. Depends if you need dynamic routing or not. Personally I don’t find their solution for dynamic routing terrible but it could be better.

                    • andrewingram 11 days ago

                      I don't buy the vendor lock-in argument here. The vast majority of your code will have nothing Next-related in it, this is a sharp contrast to a lot of the other options out there. Your page entry points will have getInitialProps, but that's actually a pretty decent pattern I'd probably choose to keep even if I moved away from Next.

                      The reason we actually went with Next is because it's relatively easy to drop if our needs diverge.

                      • midway 11 days ago

                        Of course there is a lock-in. Every lib you use locks you in. You don't know how many libs don't play well together. The more code and libs you add to your app the more complexity.

                        It's not hard to write code, it's hard to keep code complexity low and maintainable and IDK if Next.js helps here.

                        • andrewingram 11 days ago

                          Yes, all libs give you vendor lock-in, which means unless Next is a particularly egregious example, there's not much point calling it out as a particular wart. My argument is that it's closer to the opposite, because as far as web frameworks go, Next does this better than most -- very little of the code you write is different just because you're using Next, your code is just normal React code. This is a huge contrast to something like Gatsby, where the lock-in is much stronger.

                          • midway 11 days ago

                            Sorry but I disagree. Just take any of your a bit bigger React projects and transform them to Next or the way around. In. One. Hour. And production-ready please. Good luck, man (this is vendor lock-in).

                            • andrewingram 11 days ago

                              If your threshold for vendor lock-in is one hour, there's no point discussing this. But I could probably do it in a day or two, which is good enough in my mind.

                              • ricardobeat 11 days ago

                                I actually just did this a couple days ago (from Razzle to Next), took around two hours mostly fiddling with updated dependencies. Will take longer for a complex app but the lock-in is way weaker than traditional frameworks.

                        • Illniyar 11 days ago

                          SEO isn't just about landing pages or corporate websites. Every public facing route is part of SEO.

                          Some of the most SEO heavy websites are social networks, ecommerce sites, marketplaces and other interactive websites.

                          Even for corporate websites though, why should we degrade the user experience for SEO if we can easily have both?

                          And yes whether you agree or not (and by your comment I think you don't) the vast majority of users and UI/UX designers consider SPA to be a much better user experience than loading pages.

                          If you are making websites for a living, I suggest you come aboard the SPA train quickly or risk losing north of 90% of job opportunities.

                          • chrisco255 11 days ago

                            Next.js gives you prefetching as well as code splitting as well as server rendering.

                            You get to use all the modern tools that React gives you, an abundance of open source React components, and get an SEO and load time optimized website with minimal configuration. Building a server rendered, dynamic web app is non trivial. Next.js makes it a lot easier.

                            React coupled with Node.js has been used for SSR since 2015 in sites like PayPal so I'm not sure why you doubt it's veracity. React is a very strong UI library that is more than suitable for multiple rendering targets. It has never been limited to SPA apps. Facebook itself is not a pure SPA app.

                            • midway 11 days ago

                              > prefetching

                              Prefetching is a questionable and a lot discussed feature, do you want to prefetch all the 50 links on my page? Even if you think this a great feature, I am sure the user using your page doesn't like that you abuse his/her bandwidth. Especially those on mobile.

                              > code splitting

                              This is not a feature. Automatic code splitting is turn-key-ready in CRA. I wrote this now for the tenth time...

                              > server rendering

                              I explained this, if you really need SSR, a plain express/pug blows Next out of the water. Speed, flexibility, routing, everything. There is no single reason to use anything like Next.js. And writing a plain express/pug app is trivial and much easier than React, this is 10 years old tech.

                              I don't want to sound negative but again why is React as SSR 10x better than typical SSRs? It's not, React is great for real SPAs and Next feels to me like, let's jump on the React hype train and generate organic leads for Zeit.

                              • chrisco255 11 days ago

                                You're just being nitty and not adding any value to the conversation.

                                Code-splitting in Next.js is fundamentally different than in CRA: https://nextjs.org/#automatic-code-splitting https://facebook.github.io/create-react-app/docs/code-splitt...

                                It's automatic, handled server side...and it gets hydrated on the server side if necessary with asynchronous data. The benefits of this on browser performance and developer performance should be self-evident.

                                Doing a truly isomorphic React app on your own with pure Node.js is non-trivial. As for using pug templates...just...no. You might want to read about why JSX is a thing to begin with.

                                It's not a hype thing. It's a tool that solves a problem. It's not needed for all applications. For many apps, a SPA is fine. That an engineer has to make evaluations on the trade-offs of various decisions goes without saying...But Next.js is a solid choice for a SSR framework.

                                • midway 11 days ago

                                  Next.js is some over-engineered thing without a proper use case.

                                  If Next.js was good in SEO, nextjs.org would rank well on the search query 'react ssr' but you know what, it couldn't even rank within the top 10. There's nothing, no nextjs dot org, just a Medium article below the fold. Just want to see your face after you convinced your management and your entire team to move to Next and facing how your organic search volume is nosediving...

                                  This whole thing is pure content marketing paired with forum spamming to get people converted to Zeit's products. I am bit surprised that not more 'real users' defend Next.js here, seems like just some maintainers/contributors could show up worshipping Next. This is all too obvious and maybe young devs fall into your trap.

                                  Btw, I know what JSX is capable of and I prefer it over many things but it's not about JSX or pug or whatever. Next.js is abusing a powerful lib/framework for SSR and templating. SSR is much more, e.g. proper routing, read the thread, Next doesn't get routing (the #1 req of SSR) right and wants to do SSR? Sure.

                                  • dntrkv 11 days ago

                                    >If Next.js was good in SEO, nextjs.org would rank well on the search query 'react ssr' but you know what, it couldn't even rank within the top 10.

                                    What kind of argument is that? They're not in the business of SEO. If they were SEO consultants, you might have something there but SEO has nothing to do with their business model.

                                    Also, Next.js isn't "good" at SEO, it allows you to server-side render your app, which is required for good SEO.

                                    Sounds like you just have it out for Next.js, or the Zeit team altogether.

                                • andrethegiant 11 days ago

                                  > Prefetching is a questionable and a lot discussed feature, do you want to prefetch all the 50 links on my page?

                                  This isn't how Next prefetches with dynamic routing. It fetches the JS required to construct the DOM of those pages, but doesn't execute it. If on one page you have three links to /gallery/a, /gallery/b, and /gallery/c, then gallery.js will be prefetched once. You can confirm this in devtools. Also, prefetching is opt-in.

                              • egeozcan 11 days ago

                                > Next.js gives you a vendor lock-in and its features are easily avail w/o Next

                                Think Next.js not like a framework but an SSR version of create-react-app. It's incredibly easy to port into your custom thing.

                                • davnicwil 11 days ago

                                  If you're already on create-react-app or any other framework or stack and don't want to port to a new framework, but want to add easy "just works" SSR, you can use react-frontload.

                                  https://github.com/davnicwil/react-frontload

                                  It's a small library that lets you load data into Components - using the same code on both client and server render. You can use it to add server rendering to any existing React app. It's designed to just plug in and work. I'm the author :-)

                                  • midway 11 days ago

                                    Pls check my other comment, anything you add to your code adds complexity and a natural lock-in. Maintainable code is not about adding every lib which crosses your way.

                                    • sebdedeyne 11 days ago

                                      I see Next.js more as a build system than a framework / library. Of course it adds complexity, but in a comment above you say that "CRA does that too". You're not introducing any more or less complexity than CRA.

                                      • egeozcan 11 days ago

                                        And what I'm saying is that Next.js does add the same complexity that you would add yourself but with great documentation. Also I have to say that's a very generic argument for any library.

                                        • midway 11 days ago

                                          Then why don't you just use the automatic code splitting of CRA?? And it's not generic, if you ever worked on a years old code base you are happy if complexity is low. Do you know if all the page transition libs will play well with Next? They do not play well even with react-router, the standard React routing lib. Code can be more complex than you might think.

                                          • egeozcan 11 days ago

                                            SSR. CRA and Next.js are "templates" more than libraries with different aims. If you have specific arguments against SSR, just tell them because otherwise the discussion doesn't make sense.

                                        • chrisco255 11 days ago

                                          CRA is a SPA. Next.js is not. When you hit a page in Next.js, it can prefetch and hydrate the data before it sends it down to the client. CRA cannot do this. First the client has to load the app, then the app has to fetch data from the server.

                                      • Scarbutt 11 days ago

                                        Forget about nextjs and SPAs for a moment, think of react as a better alternative to pug, instead of express/pug you can use express/react, better because is component based and you write all your logic in JS instead of some new limited mini language.

                                        • Existenceblinks 11 days ago

                                          I will sacrifice more my HN points since I will add nothing but to say that regardless of rationality you put, if being negative to React/javascript, it's guarantee to get downvote to hell.

                                      • rymate1234 11 days 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

                                        • mattferderer 11 days ago

                                          I selected React & Next.JS for our templating framework to use with an API driven website. There are hardly any SPA features incorporated into the website, though we set that as a possible down the road feature.

                                          For me, the biggest reason to use React & Next.JS over any other template language was how enjoyable the JavaScript ecosystem is to work with once setup. React just happens to be the modern day JQuery & is leading the pack. I also prefer its XML/JSX type syntax.

                                          The ability for us to write code that would work on the SSR portion & front end was also a big plus.

                                          Also Storybook isn't a React only thing, but it is a JS thing. Allowing our designers to create components with mock API calls & having Webpack update the component (without reloading) on save is an amazing time saver & productivity gain. I know of no other language that has a component template system that is close to JavaScript, Storybook & Webpack. As WASM matures, I hope to see other languages match it.

                                          • tracker1 11 days ago

                                            React's constraints aren't particularly bad... the context bases for controls in a single file, better with React-JSS imho make it much easier to write against. SSR with React is sometimes a PITA, but that's rarely required imho.

                                            I'm okay with SSR, but often you get to a point where you want to mix in dynamic functionality on the client that just becomes more difficult with it. I think that Vue, React and others can be integrated into SSR, but doing SSR of React makes for a nice application development as a whole imho.

                                            In the end, it's up to the developer. I will say with JS client and direct server there's less disconnect for most development, and the lack/reduction of context switching can be a huge productivity boost. I'm usually a proponent of a JS client talking to/through a JS API, that can talk to other things. SSR with that server platform just makes it a bit more coupled, which isn't in itself a bad thing.

                                            YMMV.

                                            • smacktoward 11 days ago

                                              Because they already know React, and they don't know Rails, Pug, Django, Laravel, et al. And using the skills they already have is easier than learning new ones. When all you have is a hammer, everything looks like a nail.

                                              It's the same reason why Electron is so popular for desktop apps. On just about every measure, there's a better alternative available for that sort of thing -- native apps if you want speed and great integration with the host environment, Qt if you're willing to sacrifice on those fronts to get a single cross-platform solution. But Electron has one thing those alternatives don't, namely that if you're a Web developer you don't have to learn any new languages, toolkits, etc. to be productive with it. And it turns out that, for an awful lot of developers, "I don't have to learn anything new" beats just about every other consideration.

                                              • 11 days ago
                                                [deleted]
                                              • mikl 11 days ago

                                                With frameworks like Next.js, it's no longer either/or, the explicit goal is to have the best of both worlds. The first page is delivered with SSR (for speed), then it boots React in the browser and works as an SPA.

                                                • lilactown 11 days ago

                                                  I still think that you should endeavor to server-render anything you can get away with. Because of that, we have invested heavily in React SSR.

                                                  The biggest value-add of using React on the server is being able to share our design library and business logic with our front- and back-end. We can develop the structure, style and behavior of our website as React components and deploy them server side or client-side. In general, our team has found that the component model is far more composable than templates like pug, PHP, etc.

                                                  • atombender 11 days ago

                                                    > And If you go for latter then you can choose any stack, e.g. Rails

                                                    You suggested Rails, but a big reason people like Next is exactly because it's an opinionated, batteries-included framework like Rails.

                                                    The "vendor lock-in" situation, which seems to be one of your main arguments, is exactly the same time. If you don't like vendor lock-in, I don't know why you'd propose Rails.

                                                    • nfriedly 11 days ago

                                                      Next.js is a SPA with that loads a little faster and is more SEO-friendly.

                                                      • midway 11 days ago

                                                        > Next.js [...] loads a little faster

                                                        IDK, my dockerized express site loads much faster. At 20ms without network time (and this w/o caching). My real React SPA give you instant (0ms) page loads.

                                                        Nextjs.org initial load is at 580ms and the doc came at whopping 1.38sec (oh yeah) and page loads are not instantly... this thing doesn't make sense (for my use cases). If the only thing I know is React and JSX, then maybe but routing with express is much easier.

                                                        => you want make serious money with SEO => get some real SSR environment

                                                        => you want a great SPA, buttersmooth, interactive, maintainable code => React or other popular SPA libs

                                                        • austincheney 11 days ago

                                                          How can that be possible? The DNS lookup takes longer than that and you still haven't even gotten to your site. Once there the first byte time from the initial HTTP round strip still take considerably more. This is all network traffic that does matter what the application is doing.

                                                          • midway 11 days ago

                                                            > How can that be possible? The DNS lookup takes longer than that and you still haven't even gotten to your site.

                                                            I wrote without networking time which includes DNS lookup

                                                          • nfriedly 11 days ago

                                                            How long is the first page load of your react SPA?

                                                            • midway 11 days ago

                                                              This is the wrong question. I use React for SPA use cases and then initial loading time is secondary but I tell you something, my stock React SPA with tons of js and assets has following loading times:

                                                                DOMContentLoad: 1.08sec, Load: 2.26sec
                                                              
                                                              and let's look at nextjs.org:

                                                                DOMContentLoad: 1.09sec, Load: 2.31sec
                                                              
                                                              I mean this comparison doesn't make sense because you don't know my SPA and I could write anything here but test it yourself. I just don't see a clear use case for Next.js. Just make an example, you sell some SaaS. Make the web product as React SPA but the marketing landing pages as normal express/pug site. Both the web product and the landing pages have different use cases: one needs to create leads and the other one has to increase customer satisfaction. These are different goals, so maybe you should also use different tools.
                                                              • tracker1 11 days ago

                                                                My own react app, not using next with a rather heavy payload (async splitting in webpack broke in the past 3 months and haven't been able to get it working again) is under a load of 1.24s Finished time, locally (static content server, with 2 db queries via api).

                                                                Unless you MUST have the absolute best SEO, I'm not sure that it really matters having SSR for most people/apps. I don't know how much traffic is really driven from search engines depending on the site, and I really don't know how much you get penalized for having an SPA anymore. I mean if your initial load is under 2-3s and in-site navigation is fast, you'll probably be fine.

                                                                The past few sites/apps I've consulted on got the majority of their traffic from outside SEO.

                                                                • andrethegiant 11 days ago

                                                                  DOMContentLoaded isn't as relevant with SSR, because the markup and styles come rendered on the first response, so you never see an initial blank white page.

                                                                  More relevant metrics are TTFB (time to first byte) and TTI (time to interactive).

                                                                  I wouldn't want to implement a marketing site in express/pug. I want the flexibility of components and all the other benefits that React offers.

                                                                  • midway 11 days ago

                                                                    > How can that be possible? The DNS lookup takes longer than that and you still haven't even gotten to your site.

                                                                    Me too. But if you ever did marketing landing pages for products you might know that one landing page is not enough. You need thousands which match to Ad Word campaigns or which are optimized to different SEO fields, domains and whatever. While you still could manage this with Next and nice components, Next's subpar routing might be an obstacle.

                                                          • sshine 11 days ago

                                                            SPA? SSR?

                                                            • nfriedly 11 days 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 11 days 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.

                                                              • mcescalante 11 days 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 11 days ago

                                                                  single-page-app, server-side-rendering

                                                                • icemelt8 11 days ago

                                                                  react templating language is better than Django templates

                                                                • jypepin 11 days 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 11 days 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.

                                                                    • tekkk 11 days 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 11 days 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.

                                                                      • jypepin 11 days 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_gat...

                                                                        • fro0116 11 days ago

                                                                          Also learned about Razzle through that thread:

                                                                          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 11 days 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 11 days 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.

                                                                          • skrebbel 11 days ago

                                                                            I thought Gatsby is a static site generator?

                                                                            • onion2k 11 days 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/

                                                                              • toper-centage 11 days ago

                                                                                Yes and in that sense it overlaps next a bit... But next is much more.

                                                                                • skrebbel 11 days ago

                                                                                  In the way that Jekyll and Rails overlap?

                                                                            • 11 days ago
                                                                              [deleted]
                                                                            • fredley 11 days 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 11 days 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.

                                                                              • subpixel 11 days ago

                                                                                Note that these pages are not serving dynamic data - unless I'm mistaken, they are an example of Next.js static export

                                                                              • midway 11 days 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-745...

                                                                                • strictnein 11 days ago

                                                                                  Acronym translations:

                                                                                     SSR: Server-side rendering
                                                                                     CSR: Client-side rendering
                                                                                     CRA: create-react-app
                                                                                • kowdermeister 11 days ago
                                                                                  • seddin 11 days ago

                                                                                    @zeit employees are some really talented developers

                                                                                    • jackweirdy 11 days 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 11 days 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/ it's hard to tell the difference between cold-boot and warm functions.

                                                                                        • jackweirdy 11 days ago

                                                                                          That’s interesting thanks - I didn’t know this. And thanks for the example site too! Definitely feels snappier than I anticipated.

                                                                                          • revskill 11 days 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 $$$.

                                                                                        • proyb2 11 days 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 11 days 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.

                                                                                          • seddin 11 days 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.

                                                                                            • andreareina 11 days ago

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

                                                                                              • dirkc 11 days 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 11 days ago

                                                                                                  The content that is accessible through the navigation seams to be only a teaser for the content that is hidden behind the login.

                                                                                                • vtambourine 11 days ago

                                                                                                  Why they require login for tutorial pages in the first place?

                                                                                                  • andreareina 11 days ago

                                                                                                    The copy says it's some interactive thing with quizzes and such.

                                                                                                    • ozten 11 days ago

                                                                                                      I didn't get any value out of the 'gamification' element. Would have preferred to have not logged in.

                                                                                                      • timneutkens 11 days ago

                                                                                                        We're currently working on rewriting /learn to not require any login while still retaining the gamification element (in offline storage). Meaning that you get the best of both worlds.

                                                                                                        Just to explain the reason there is a login at all, this is mostly for historical reasons. The original learnnextjs.com built by Arunoda was based on another project he created for teaching Meteor.

                                                                                                        Anyway as said we're rewriting /learn, using MDX (http://github.com/mdx-js/mdx) for content and the quizzes will store the result in your browser.

                                                                                                        • ozten 11 days ago

                                                                                                          Very cool! Makes sense that you got it for free from Meteor, great that you're iterating based on feedback.

                                                                                                • midway 11 days 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 11 days 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/

                                                                                                    • 10 days ago
                                                                                                      [deleted]
                                                                                                • gtycomb 11 days ago

                                                                                                  How similar is this with Nuxt.js?

                                                                                                  • viiralvx 11 days ago

                                                                                                    Next predates Nuxt, so Nuxt was inspired by Next.

                                                                                                    Next = SSR + React Nuxt = SSR + Vue.js

                                                                                                    • gtycomb 11 days 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.