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

41–50 of 118 posts

Re: Next.js 8 released

#41

Post by midway »

egeozcan wrote: post #39
midway wrote: post #37

Earlier quoted context omitted.

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.

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.

Re: Next.js 8 released

#42

Post by nailer »

nfriedly wrote: post #23
sshine wrote: post #17

Earlier quoted context omitted.

SPA? SSR?

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…

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.

Re: Next.js 8 released

#43

Post by chrisco255 »

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

Re: Next.js 8 released

#44

Post by sebdedeyne »

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.

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.

Re: Next.js 8 released

#45

Post by chrisco255 »

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.

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.

Re: Next.js 8 released

#46

Post by midway »

chrisco255 wrote: post #43
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 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 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.

Re: Next.js 8 released

#47

Post by mAritz »

Ndymium wrote: post #14
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.

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…

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

[1] https://github.com/mironov/react-redux-loading-bar [2] https://github.com/zeit/next.js/tree/canary/examples

Re: Next.js 8 released

#48

Post by andrewingram »

midway wrote: post #35
andrewingram wrote: post #30

Earlier quoted context omitted.

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.

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.

Re: Next.js 8 released

#49

Post by revskill »

timneutkens wrote: post #32
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…

You mean scale the renderer to infinite $$$$ ? It's a lol. In a non-serverless environment, i could control that scale better without scaling $$$.

Re: Next.js 8 released

#50

Post by midway »

andrewingram wrote: post #48
midway wrote: post #35

Earlier quoted context omitted.

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.

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…

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