7 ms·

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

by midway 8y ago

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?

sshine 8y ago
SPA? SSR?
- mcescalante 8y ago
  They stand for Single Page Application (client side) and Server Side Rendering (which makes a JS app render more like a normal server side page for the client) respectively.
- tunesmith 8y ago
  single-page-app, server-side-rendering
- nfriedly 8y ago
  SPA = Single Page App SSR = Server Side Rendered 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.
  - nailer 8y ago
    The term 'SPA' is a little outdated - since HTML5 history (which is nearly a decade old now) most 'SPAs' are actually multiple pages. 'web apps' is better.
rymate1234 8y ago
I don't think it's any better or worse, it's just an additional way of writing SSR sites where React is a templating language. React is just another option for a stack - similar to express with pug, you can have express with React, without having to learn a new templating language if you already know React. And with things like TypeScript, you can have type checking into the mix too
icemelt8 8y ago
react templating language is better than Django templates
Illniyar 8y ago
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.
- 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.
nfriedly 8y ago
Next.js is a SPA with that loads a little faster and is more SEO-friendly.
- midway 8y ago
  > Next.js [...] loads a little faster IDK, my dockerized express site loads much faster. At 20ms without network time (and this w/o caching). My real React SPA give you instant (0ms) page loads. Nextjs.org initial load is at 580ms and the doc came at whopping 1.38sec (oh yeah) and page loads are not instantly... this thing doesn't make sense (for my use cases). If the only thing I know is React and JSX, then maybe but routing with express is much easier. => you want make serious money with SEO => get some real SSR environment => you want a great SPA, buttersmooth, interactive, maintainable code => React or other popular SPA libs
  - nfriedly 8y ago
    How long is the first page load of your react SPA?
    - midway 8y ago
      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 test it yourself. I just don't see a clear use case for Next.js. Just make an example, you sell some SaaS. Make the web product as React SPA but the marketing landing pages as normal express/pug site. Both the web product and the landing pages have different use cases: one needs to create leads and the other one has to increase customer satisfaction. These are different goals, so maybe you should also use different tools.
      - andrethegiant 8y ago
        DOMContentLoaded isn't as relevant with SSR, because the markup and styles come rendered on the first response, so you never see an initial blank white page. More relevant metrics are TTFB (time to first byte) and TTI (time to interactive). I wouldn't want to implement a marketing site in express/pug. I want the flexibility of components and all the other benefits that React offers.
mikl 8y ago
With frameworks like Next.js, it's no longer either/or, the explicit goal is to have the best of both worlds. The first page is delivered with SSR (for speed), then it boots React in the browser and works as an SPA.
lilactown 8y ago
I still think that you should endeavor to server-render anything you can get away with. Because of that, we have invested heavily in React SSR. The biggest value-add of using React on the server is being able to share our design library and business logic with our front- and back-end. We can develop the structure, style and behavior of our website as React components and deploy them server side or client-side. In general, our team has found that the component model is far more composable than templates like pug, PHP, etc.
mattferderer 8y ago
I selected React & Next.JS for our templating framework to use with an API driven website. There are hardly any SPA features incorporated into the website, though we set that as a possible down the road feature. 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.
smacktoward 8y ago
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 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.
- deleted 8y ago
  [deleted]
tracker1 8y ago
React's constraints aren't particularly bad... the context bases for controls in a single file, better with React-JSS imho make it much easier to write against. SSR with React is sometimes a PITA, but that's rarely required imho. 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.
atombender 8y ago
> And If you go for latter then you can choose any stack, e.g. Rails You suggested Rails, but a big reason people like Next is exactly because it's an opinionated, batteries-included framework like Rails. The "vendor lock-in" situation, which seems to be one of your main arguments, is exactly the same time. If you don't like vendor lock-in, I don't know why you'd propose Rails.

by midway 8y ago

sshine 8y ago

SPA? SSR?

mcescalante 8y ago
They stand for Single Page Application (client side) and Server Side Rendering (which makes a JS app render more like a normal server side page for the client) respectively.
tunesmith 8y ago
single-page-app, server-side-rendering
nfriedly 8y ago
SPA = Single Page App SSR = Server Side Rendered 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.
- nailer 8y ago
  The term 'SPA' is a little outdated - since HTML5 history (which is nearly a decade old now) most 'SPAs' are actually multiple pages. 'web apps' is better.

rymate1234 8y ago

I don't think it's any better or worse, it's just an additional way of writing SSR sites where React is a templating language. React is just another option for a stack - similar to express with pug, you can have express with React, without having to learn a new templating language if you already know React. And with things like TypeScript, you can have type checking into the mix too

icemelt8 8y ago

react templating language is better than Django templates

Illniyar 8y ago

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.

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.

nfriedly 8y ago

Next.js is a SPA with that loads a little faster and is more SEO-friendly.

midway 8y ago
> Next.js [...] loads a little faster IDK, my dockerized express site loads much faster. At 20ms without network time (and this w/o caching). My real React SPA give you instant (0ms) page loads. Nextjs.org initial load is at 580ms and the doc came at whopping 1.38sec (oh yeah) and page loads are not instantly... this thing doesn't make sense (for my use cases). If the only thing I know is React and JSX, then maybe but routing with express is much easier. => you want make serious money with SEO => get some real SSR environment => you want a great SPA, buttersmooth, interactive, maintainable code => React or other popular SPA libs
- nfriedly 8y ago
  How long is the first page load of your react SPA?
  - midway 8y ago
    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 test it yourself. I just don't see a clear use case for Next.js. Just make an example, you sell some SaaS. Make the web product as React SPA but the marketing landing pages as normal express/pug site. Both the web product and the landing pages have different use cases: one needs to create leads and the other one has to increase customer satisfaction. These are different goals, so maybe you should also use different tools.
    - andrethegiant 8y ago
      DOMContentLoaded isn't as relevant with SSR, because the markup and styles come rendered on the first response, so you never see an initial blank white page. More relevant metrics are TTFB (time to first byte) and TTI (time to interactive). I wouldn't want to implement a marketing site in express/pug. I want the flexibility of components and all the other benefits that React offers.

mikl 8y ago

With frameworks like Next.js, it's no longer either/or, the explicit goal is to have the best of both worlds. The first page is delivered with SSR (for speed), then it boots React in the browser and works as an SPA.

lilactown 8y ago

I still think that you should endeavor to server-render anything you can get away with. Because of that, we have invested heavily in React SSR. The biggest value-add of using React on the server is being able to share our design library and business logic with our front- and back-end. We can develop the structure, style and behavior of our website as React components and deploy them server side or client-side. In general, our team has found that the component model is far more composable than templates like pug, PHP, etc.

mattferderer 8y ago

I selected React & Next.JS for our templating framework to use with an API driven website. There are hardly any SPA features incorporated into the website, though we set that as a possible down the road feature. 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.

smacktoward 8y ago

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

deleted 8y ago
[deleted]

tracker1 8y ago

React's constraints aren't particularly bad... the context bases for controls in a single file, better with React-JSS imho make it much easier to write against. SSR with React is sometimes a PITA, but that's rarely required imho. 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.

atombender 8y ago

> And If you go for latter then you can choose any stack, e.g. Rails You suggested Rails, but a big reason people like Next is exactly because it's an opinionated, batteries-included framework like Rails. The "vendor lock-in" situation, which seems to be one of your main arguments, is exactly the same time. If you don't like vendor lock-in, I don't know why you'd propose Rails.