81–90 of 118 posts
So the tutorial requires me to login with github? Sorry, not gonna happen.
Maybe it's to generate leads? Leads which can be converted to paying customers? This why this whole thing shouldn't be on HN, this thing is conflicted from the ground and driven by commercial interests.
Next.js is an awesome framework, but dynamic routing is still a mess, and clean URL masking [0] is unnecessary complicated: you have to add a route handler to Express.js, and you have to use 2 different props to your components to make it work. The Next team explains it because they don't want to solve this problem by shipping a definition of all the route of the app [1] because it does not scale. But while it is tru…
> they started to rewrite the core of Next.js This is such an important piece of information. Imagine you opt for Next and have to rewrite your app soon. I know, APIs can be backwards compatible and Next's next version will be backwards compatible but there is always something which doesn't work, sending you down the rabbit hole...
Your apps should not be affected at all.
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’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.…
I respect your experience and knowledge but people in this thread say exactly the opposite: Next.js' routing is actually not helping you.
Earlier quoted context omitted.
> they started to rewrite the core of Next.js This is such an important piece of information. Imagine you opt for Next and have to rewrite your app soon. I know, APIs can be backwards compatible and Next's next version will be backwards compatible but there is always something which doesn't work, sending you down the rabbit hole...
The core stays the same, they are only adding static types. I am certain they will make sure nothing meaningful will change in the outputted JavaScript, except for potential bug fixes uncovered by the types! Your apps should not be affected at all.
The parent says something different and if it were just about adding types then you need just to add a file to DefinitelyTyped which I guess happened already.
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?
For me, the biggest reason to use React & Next.JS over any other template language was how enjoyable the JavaScript ecosystem is to work with once setup. React just happens to be the modern day JQuery & is leading the pack. I also prefer its XML/JSX type syntax.
The ability for us to write code that would work on the SSR portion & front end was also a big plus.
Also Storybook isn't a React only thing, but it is a JS thing. Allowing our designers to create components with mock API calls & having Webpack update the component (without reloading) on save is an amazing time saver & productivity gain. I know of no other language that has a component template system that is close to JavaScript, Storybook & Webpack. As WASM matures, I hope to see other languages match it.
Next.js is an awesome framework, but dynamic routing is still a mess, and clean URL masking [0] is unnecessary complicated: you have to add a route handler to Express.js, and you have to use 2 different props to your components to make it work. The Next team explains it because they don't want to solve this problem by shipping a definition of all the route of the app [1] because it does not scale. But while it is tru…
Not sure if you've seen this guide here, but there is a way to setup dynamic routing with clean URLs that doesn't require adding your own server handler if you use Now v2 for deployments:
https://zeit.co/guides/custom-next-js-server-to-routes/
Also, I recently wrote about how I locally develop Now v2 apps with an example of SSR dynamic routes:
https://medium.com/digital-surgeons-engineering/how-to-set-u...
Earlier quoted context omitted.
The core stays the same, they are only adding static types. I am certain they will make sure nothing meaningful will change in the outputted JavaScript, except for potential bug fixes uncovered by the types! Your apps should not be affected at all.
> they are only adding static types. The parent says something different and if it were just about adding types then you need just to add a file to DefinitelyTyped which I guess happened already.
Earlier quoted context omitted.
This. I started out with a similar framework called nuxt.js but found the routing to be too limiting. It's a nice way to get started quickly, but once things become more complex you hit too many hurdles. In the end it pays to do the project setup yourself, which also helps a ton in debugging issues along the way.
Can you share what you found limiting with nuxtjs routing? Genuinely curious.
Earlier quoted context omitted.
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 pe…
Next.js is some over-engineered thing without a proper use case. If Next.js was good in SEO, nextjs.org would rank well on the search query 'react ssr' but you know what, it couldn't even rank within the top 10. There's nothing, no nextjs dot org, just a Medium article below the fold. Just want to see your face after you convinced your management and your entire team to move to Next and facing how your organic search…
What kind of argument is that? They're not in the business of SEO. If they were SEO consultants, you might have something there but SEO has nothing to do with their business model.
Also, Next.js isn't "good" at SEO, it allows you to server-side render your app, which is required for good SEO.
Sounds like you just have it out for Next.js, or the Zeit team altogether.