6 ms·

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,

by midway 8y 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.

andrewingram 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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.
egeozcan 8y 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.
- midway 8y 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.
  - egeozcan 8y 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 8y 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 8y 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.
  - sebdedeyne 8y 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.
chrisco255 8y 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 8y 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 8y 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://nextjs.org/#automatic-code-splitting https://facebook.github.io/create-react-app/docs/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.
Illniyar 8y 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.
Existenceblinks 8y 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.
Scarbutt 8y 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.
todd3834 8y 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.
- midway 8y 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 8y 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.
- tracker1 8y 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.

by midway 8y ago

andrewingram 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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.

egeozcan 8y 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.

midway 8y 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.
- egeozcan 8y 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 8y 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 8y 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.
- sebdedeyne 8y 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.

chrisco255 8y 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 8y 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 8y 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://nextjs.org/#automatic-code-splitting https://facebook.github.io/create-react-app/docs/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.

Illniyar 8y 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.

Existenceblinks 8y 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.

Scarbutt 8y 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.

todd3834 8y 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.

midway 8y 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 8y 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.
tracker1 8y 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.