91–100 of 118 posts
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…
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?
It's the same reason why Electron is so popular for desktop apps. On just about every measure, there's a better alternative available for that sort of thing -- native apps if you want speed and great integration with the host environment, Qt if you're willing to sacrifice on those fronts to get a single cross-platform solution. But Electron has one thing those alternatives don't, namely that if you're a Web developer you don't have to learn any new languages, toolkits, etc. to be productive with it. And it turns out that, for an awful lot of developers, "I don't have to learn anything new" beats just about every other consideration.
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…
We are using `next-routes` and they are working really well for us.
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.…
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.
Earlier quoted context omitted.
How long is the first page load of your react SPA?
This is the wrong question. I use React for SPA use cases and then initial loading time is secondary but I tell you something, my stock React SPA with tons of js and assets has following loading times: DOMContentLoad: 1.08sec, Load: 2.26sec and let's look at nextjs.org: DOMContentLoad: 1.09sec, Load: 2.31sec I mean this comparison doesn't make sense because you don't know my SPA and I could write anything here but te…
Unless you MUST have the absolute best SEO, I'm not sure that it really matters having SSR for most people/apps. I don't know how much traffic is really driven from search engines depending on the site, and I really don't know how much you get penalized for having an SPA anymore. I mean if your initial load is under 2-3s and in-site navigation is fast, you'll probably be fine.
The past few sites/apps I've consulted on got the majority of their traffic from outside SEO.
SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes.
[...]
Using Pre-Rendered CRA addresses both the SEO and performance concerns around using CRA without the complexity that Next.js introduces
[1] https://codeburst.io/next-js-ssr-vs-create-react-app-csr-745...
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?
I'm okay with SSR, but often you get to a point where you want to mix in dynamic functionality on the client that just becomes more difficult with it. I think that Vue, React and others can be integrated into SSR, but doing SSR of React makes for a nice application development as a whole imho.
In the end, it's up to the developer. I will say with JS client and direct server there's less disconnect for most development, and the lack/reduction of context switching can be a huge productivity boost. I'm usually a proponent of a JS client talking to/through a JS API, that can talk to other things. SSR with that server platform just makes it a bit more coupled, which isn't in itself a bad thing.
YMMV.
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?
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?
Because they already know React, and they don't know Rails, Pug, Django, Laravel, et al . And using the skills they already have is easier than learning new ones. When all you have is a hammer, everything looks like a nail. It's the same reason why Electron is so popular for desktop apps. On just about every measure, there's a better alternative available for that sort of thing -- native apps if you want speed and gr…
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).