Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js 8 released

nextjs.org

Post reply on HN
Print view View original

31–40 of 118 posts

Re: Next.js 8 released

#31

Post by midway »

nfriedly wrote: post #25
midway wrote: post #16

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?

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 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

Re: Next.js 8 released

#32

Post by timneutkens »

jackweirdy wrote: post #15

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?

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.

Re: Next.js 8 released

#34

Post by subpixel »

fredley wrote: post #12

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.

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

Re: Next.js 8 released

#35

Post by midway »

andrewingram wrote: post #30
midway wrote: post #29

Earlier quoted context omitted.

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 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…

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.

Re: Next.js 8 released

#36

Post by egeozcan »

midway wrote: post #29
Illniyar wrote: post #24

Earlier 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…

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

Re: Next.js 8 released

#37

Post by midway »

egeozcan wrote: post #36
midway wrote: post #29

Earlier quoted context omitted.

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…

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

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.

Re: Next.js 8 released

#38

Post by nfriedly »

midway wrote: post #31
nfriedly wrote: post #25

Earlier 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 long is the first page load of your react SPA?

Re: Next.js 8 released

#39

Post by egeozcan »

midway wrote: post #37
egeozcan wrote: post #36

Earlier quoted context omitted.

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

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.

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.

Re: Next.js 8 released

#40

Post by midway »

nfriedly wrote: post #38
midway wrote: post #31

Earlier quoted context omitted.

> 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 long is the first page load of your react SPA?

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.
Post reply on HN