4 ms·

But how many use _just_ React now? There is a whole stack that 90% of YC companies use: Node, pnpm, Next, React, doing SSR by default. Idk about it all. Most of

But how many use _just_ React now? There is a whole stack that 90% of YC companies use: Node, pnpm, Next, React, doing SSR by default. Idk about it all. Most of the time when I ask why they do SSR they can't tell me a valid reason. Their bundle sizes are so big for what the apps do.

landl0rd 1y ago
I've used plain react for a few things in the past few years. I strongly prefer it to next/nuxt/all this other stuff. Preact and an understanding of best practices can make it fairly performant with a more or less drop-in replacement if you're willing to sacrifice compatibility with absolutely all the ecosystem. I still prefer svelte but it's less mature and universally-known. React is still a pretty good choice if you need something that will more or less work and that anyone can write.
- Imustaskforhelp 1y ago
  My issue is opposite. I know svelte/sveltekit and would want to contribute to svelte apps (a good reminder that I should) But there are some projects that I really really want to contribute to / heck even port to sveltekit like cinny and hedgedoc and the likes and so I almost feel pressured by the system to learn react so that I can finally feel confident enough to understand their repositories as they scare me right now... Cinny:https://github.com/cinnyapp/cinny https://github.com/cinnyapp/cinny Hedgedoc:https://github.com/hedgedoc/hedgedoc https://github.com/hedgedoc/hedgedoc
- 0xblinq 1y ago
  Anyone can write svelte. Or solid. Or Angular. I don’t even want to talk to somebody that defines themselves as a “React” developer. Let alone work with them. If you know any of these frameworks, and the basics of web development you can work in any of them. So the hiring part is not an excuse for this.
b_e_n_t_o_n 1y ago
I think most are still using React with maybe React Router. Node and Pnpm aren't really complicated or difficult to use, neither is Vite.
torben-friis 1y ago
>Most of the time when I ask why they do SSR they can't tell me a valid reason. Isn't it mainly about playing nice with crawlers? SEO and the like? (that was my understanding but I'm a backend dev).
- Jcampuzano2 1y ago
  Yes but they obsess over making everything perfectly ssr to the point of both delivering slow and half the time making client side navigations slow as hell after the user is already past the pay walled/marketing material part of your app. Honestly except for the marketing page and blogs and stuff, most apps are fine without server rendering. In fact I'd say many that avoid server rendering actually feel better simply because next.js makes it really easy to screw up your performance doing it.
  - sroussey 1y ago
    Some site have dual pages these days. I guess I should explain… they have a large footprint seo and those pages are static… unless you are logged in, then they are completely different! I see this happening in finance data sites. Say a page about Apple, has stock price, etc. when logged in, same stuff but 10x data so they layout and everything is different.
- fruit2020 1y ago
  Do people really build SPAs that are just websites and not ‘apps’?
  - dhosek 1y ago
    Sadly, yes. Fortunately, most of them are developers’ toys, but not all.
    - byearthithatius 1y ago
      I mean the docs of most of the frameworks are written in that framework even though its just static pages. Didn't even need the framework but not using your own framework for docs feels ... bad I guess?
habibur 1y ago
> when I ask why they do SSR What are the reasons for not doing SSR?
- scrame 1y ago
  want the whole point of Javascript to use client side manipulation? Is it's come back to SSR, then do we need all the JS baggage?
  - twelvechairs 1y ago
    Its a division of responsibilities thing isnt it? "Proper coders" in python or whatever provide up to an API. Past that its basically the web devs domain and they live in JS land
    - byearthithatius 1y ago
      Agree, that is why I am confused by his question to me. Like SSR should be the default. Why does your server by default "hydrate" the client bundle. Why can't the client bundle request data as it needs it (then we can only request what the user needs). Skeleton UI it while you fetch. Then you have great page load time because you just return a static HTML+JS bundle that was non-conditionally built. In SSR it talks to the DB before it even constructs the bundle, that is oof right? So you are faster because you don't even gen the HTML until you talked to the DB? I give the user plain HTML instantly and talk to the DB while I give them a UI indicating its loading. SSR just moved the load time to before initial render. Stupid IMO.
- byearthithatius 1y ago
  Why is it the default for you? You are worrying about hydration complexity and all that when you introduce it, so it better have some benefits. My default is a small page that client then fetches any additional data it needs. If its long load time skeleton UI it. I also have not seen the SEO benefits at all. So again _why would I_ unless I needed to do stuff on the server to make the client bundle, which I don't. A lot of these YC companies doing this could literally just be using a fetch because their backend is dead simple REST.

landl0rd 1y ago

I've used plain react for a few things in the past few years. I strongly prefer it to next/nuxt/all this other stuff. Preact and an understanding of best practices can make it fairly performant with a more or less drop-in replacement if you're willing to sacrifice compatibility with absolutely all the ecosystem. I still prefer svelte but it's less mature and universally-known. React is still a pretty good choice if you need something that will more or less work and that anyone can write.

Imustaskforhelp 1y ago
My issue is opposite. I know svelte/sveltekit and would want to contribute to svelte apps (a good reminder that I should) But there are some projects that I really really want to contribute to / heck even port to sveltekit like cinny and hedgedoc and the likes and so I almost feel pressured by the system to learn react so that I can finally feel confident enough to understand their repositories as they scare me right now... Cinny:https://github.com/cinnyapp/cinny https://github.com/cinnyapp/cinny Hedgedoc:https://github.com/hedgedoc/hedgedoc https://github.com/hedgedoc/hedgedoc
0xblinq 1y ago
Anyone can write svelte. Or solid. Or Angular. I don’t even want to talk to somebody that defines themselves as a “React” developer. Let alone work with them. If you know any of these frameworks, and the basics of web development you can work in any of them. So the hiring part is not an excuse for this.

b_e_n_t_o_n 1y ago

I think most are still using React with maybe React Router. Node and Pnpm aren't really complicated or difficult to use, neither is Vite.

torben-friis 1y ago

>Most of the time when I ask why they do SSR they can't tell me a valid reason. Isn't it mainly about playing nice with crawlers? SEO and the like? (that was my understanding but I'm a backend dev).

Jcampuzano2 1y ago
Yes but they obsess over making everything perfectly ssr to the point of both delivering slow and half the time making client side navigations slow as hell after the user is already past the pay walled/marketing material part of your app. Honestly except for the marketing page and blogs and stuff, most apps are fine without server rendering. In fact I'd say many that avoid server rendering actually feel better simply because next.js makes it really easy to screw up your performance doing it.
- sroussey 1y ago
  Some site have dual pages these days. I guess I should explain… they have a large footprint seo and those pages are static… unless you are logged in, then they are completely different! I see this happening in finance data sites. Say a page about Apple, has stock price, etc. when logged in, same stuff but 10x data so they layout and everything is different.
fruit2020 1y ago
Do people really build SPAs that are just websites and not ‘apps’?
- dhosek 1y ago
  Sadly, yes. Fortunately, most of them are developers’ toys, but not all.
  - byearthithatius 1y ago
    I mean the docs of most of the frameworks are written in that framework even though its just static pages. Didn't even need the framework but not using your own framework for docs feels ... bad I guess?

habibur 1y ago

> when I ask why they do SSR What are the reasons for not doing SSR?

scrame 1y ago
want the whole point of Javascript to use client side manipulation? Is it's come back to SSR, then do we need all the JS baggage?
- twelvechairs 1y ago
  Its a division of responsibilities thing isnt it? "Proper coders" in python or whatever provide up to an API. Past that its basically the web devs domain and they live in JS land
  - byearthithatius 1y ago
    Agree, that is why I am confused by his question to me. Like SSR should be the default. Why does your server by default "hydrate" the client bundle. Why can't the client bundle request data as it needs it (then we can only request what the user needs). Skeleton UI it while you fetch. Then you have great page load time because you just return a static HTML+JS bundle that was non-conditionally built. In SSR it talks to the DB before it even constructs the bundle, that is oof right? So you are faster because you don't even gen the HTML until you talked to the DB? I give the user plain HTML instantly and talk to the DB while I give them a UI indicating its loading. SSR just moved the load time to before initial render. Stupid IMO.
byearthithatius 1y ago
Why is it the default for you? You are worrying about hydration complexity and all that when you introduce it, so it better have some benefits. My default is a small page that client then fetches any additional data it needs. If its long load time skeleton UI it. I also have not seen the SEO benefits at all. So again _why would I_ unless I needed to do stuff on the server to make the client bundle, which I don't. A lot of these YC companies doing this could literally just be using a fetch because their backend is dead simple REST.