21–30 of 118 posts
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?
SPA? SSR?
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?
SPA? SSR?
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 JS loads to render subsequent pages.
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?
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.
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 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…
Earlier quoted context omitted.
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.
Great answer from Tim [1], the lead maintainer of Next on the difference of the 2 (the whole thread is great). I've never used Gatsby so I can't really judge, but my understanding has always been that Gatsby is mostly focused on static sites. It can definitely do dynamic apps but it being not focused on this would concern me for support / experience of more complex things. [1] https://www.reddit.com/r/reactjs/comment…
https://github.com/jaredpalmer/razzle
> Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or react-server, fork a boilerplate, or set things up yourself. Aiming to fill this void, Razzle is a tool that abstracts all complex configuration needed for SSR into a single dependency--giving you the awesome developer experience of create-react-app, but then leaving the rest of your app's architectural decisions about frameworks, routing, and data fetching up to you. With this approach, Razzle not only works with React, but also Reason, Elm, Vue, Angular, and most importantly......whatever comes next.
Sounds like a really nice alternative to Next.js and Gatsby. Does anyone have any experience with 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…
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.
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?
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.
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.
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…
The reason we actually went with Next is because it's relatively easy to drop if our needs diverge.