Hacker News Reader

Comment by cheeseblubber | Hacker News Reader

Some technical notes: This is actually a fork of Linen.dev, an SEO-friendly Slack alternative for communities. We originally built Linen.dev with Next.js but ultimately found it quite limiting when we wanted to make things fast and responsive and have custom caches. For Linen.team, there wasn’t a need for server rendering since we didn’t need our product to be SEO-friendly. We removed Next.js and replaced it with Vite and Express, which simplified our code quite a bit since we didn’t have the legacy requirements. We also spent quite a bit of time optimizing the performance and query so that it is much faster than the previous version of Linen. Our plan is to open source Linen.team as well; we need to do some repo clean-up first.

Finally, after a year, we actually reduced our client bundle size from 500kb to less than 400kb. You can see our post on bundle optimization here: https://news.ycombinator.com/item?id=35718417.

View on HN

Tangentially related, and agree with the complexity and churn that Next introduces, but curious: If am building a product where SEO matters, does SEO still really suffer in absence of SSR?

Sure TTFB (& potentially other web vitals) are better with SSR, but I still keep hearing SEO friendliness as a primary reason for SSR though prevalent crawlers like Google/Bing can index js loaded content.

This guy from egghead.io learned how much SSR actually matters for SEO:

"""

figured out what ruined egghead's SEO and dropped our monthly traffic 90%...

broken SSR

anybody that tells you search bots don't require SSR is full of shit

"""

https://twitter.com/jhooks/status/1757086865348522109

Interesting. Thanks for sharing.

Google says:

> Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.

https://developers.google.com/search/docs/crawling-indexing/...

and:

> Crawlers may understand JavaScript, but there are often limitations worth being aware of in how they render. Client-side rendering can work, but often not without additional testing and leg-work.

https://web.dev/articles/rendering-on-the-web#seo_considerat...

It's interesting to hear about the move away from NextJS. How does your express api look?

It's a restful api that doesn't hold any state, we use jwt (jsonwebtoken) for auth. It's essentially a collection of routers for different actions. Mostly crud, with few exceptions like webhooks, auth flow. We often use middlewares e.g. for things like validation. Everything is written in ts/tsx so the client/server do share types. We serialize data to use it in a standarized/known format in the UI.

If you like the middleware system in express you might be interested in starfx, which implements the same middleware but for fetching and data synchronization in the FE. It has a simple but powerful state management system and leverages structured concurrency to manage side effects.

https://github.com/neurosnap/starfx

Reply on news.ycombinator.com