So the tutorial requires me to login with github? Sorry, not gonna happen.
Why they require login for tutorial pages in the first place?
Next.js 8 released
61–70 of 118 posts
Re: Next.js 8 released
#62Earlier quoted context omitted.
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.
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.
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.
Re: Next.js 8 released
#63How similar is this with Nuxt.js?
Re: Next.js 8 released
#64Re: Next.js 8 released
#65How similar is this with Nuxt.js?
Next predates Nuxt, so Nuxt was inspired by Next.
Next = SSR + React Nuxt = SSR + Vue.js
Re: Next.js 8 released
#66Earlier quoted context omitted.
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 si…
> 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 rende…
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.
Re: Next.js 8 released
#67Earlier quoted context omitted.
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.
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 fie…
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.
Re: Next.js 8 released
#68Earlier quoted context omitted.
Next.js is a SPA with that loads a little faster and is more SEO-friendly.
> 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 bu…
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.
Re: Next.js 8 released
#69Earlier quoted context omitted.
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.
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 fie…
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.
Re: Next.js 8 released
#70Earlier quoted context omitted.
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/comment…
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 o…
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.