9 ms·
Perhaps this comment is about to be an example of the classic "why not just rebuild XYZ technology to solve a simple problem already solved 100 times?" trope am
by methodical 3y ago
Perhaps this comment is about to be an example of the classic "why not just rebuild XYZ technology to solve a simple problem already solved 100 times?" trope among engineers, but having used Hugo and a few other markdown-based documentation builders like this, why not just build a react site and build it to static HTML[0]? I think this is the approach I'll take in the future, it always seems like just as much if not more work to learn some new SSG framework and build components for it, and seems much more complicated to add complex functionality than the usual HTML/CSS/JS we're all familiar with. If anybody has taken this approach before, I'd be curious to know your reasoning on why and/or why not this is a good idea.
[0] https://react.dev/reference/react-dom/server/renderToStaticMarkup https://react.dev/reference/react-dom/server/renderToStaticM...
- newusertoday 3y agoif you have large number of pages i.e. 1000+(its not that far fetched with documents) most of react/vue based solutions struggle in generating them in the sense that it takes long time to see output for any change you make. Its question o familiarity if you are not aware of react than it would take even more time for you to learn it and use it than ssg frameworks. you can still use your familiar html/css/js if you want to without learning whole ssg almost all ssg frameworks provide a way to code html/css if required. ssg's are battle tested when it comes to myriad seo features like twitter cards/og/json-ld/schema etc. which are proven to be working in the field. When you go for rolling out on your own you will end up in solving lot of edge cases that different platforms(twitter/fb/google) have that would result in cover image not being displayed properly to site not appearing in google etc.