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

51–60 of 118 posts

Re: Next.js 8 released

#51

Post by andrewingram »

midway wrote: post #50
andrewingram wrote: post #48

Earlier quoted context omitted.

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

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.

Re: Next.js 8 released

#52

Post by tekkk »

chimen wrote: post #4
jypepin wrote: post #3

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

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.

Re: Next.js 8 released

#53

Post by dirkc »

andreareina wrote: post #33

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

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.

Re: Next.js 8 released

#54

Post by proyb2 »

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?

Re: Next.js 8 released

#55

Post by egeozcan »

midway wrote: post #41
egeozcan wrote: post #39

Earlier quoted context omitted.

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.

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.

Re: Next.js 8 released

#56

Post by davnicwil »

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.

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

Re: Next.js 8 released

#57

Post by deltron3030 »

dirkc wrote: post #53
andreareina wrote: post #33

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

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.

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

Re: Next.js 8 released

#58

Post by Illniyar »

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…

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.

Re: Next.js 8 released

#59

Post by Existenceblinks »

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…

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.

Re: Next.js 8 released

#60

Post by jackweirdy »

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…

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