8 ms·

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 ul

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 https://news.ycombinator.com/item?id=35718417.

stopachka 3y ago
It's interesting to hear about the move away from NextJS. How does your express api look?
- emilos 3y ago
  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.
  - qudat 3y ago
    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 https://github.com/neurosnap/starfx
lf-non 3y ago
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.
- SwiftyBug 3y ago
  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 https://twitter.com/jhooks/status/1757086865348522109
  - lf-non 3y ago
    Interesting. Thanks for sharing.
- OJFord 3y ago
  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/javascript/dynamic-rendering 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_considerations https://web.dev/articles/rendering-on-the-web#seo_considerat...

stopachka 3y ago

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

emilos 3y ago
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.
- qudat 3y ago
  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 https://github.com/neurosnap/starfx

lf-non 3y ago

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.

SwiftyBug 3y ago
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 https://twitter.com/jhooks/status/1757086865348522109
- lf-non 3y ago
  Interesting. Thanks for sharing.
OJFord 3y ago
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/javascript/dynamic-rendering 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_considerations https://web.dev/articles/rendering-on-the-web#seo_considerat...