4 ms·
It seems most of the content is dynamically rendered (at build time with SSG). What alternative did you have in mind?
by CipherThrowaway 3y ago
It seems most of the content is dynamically rendered (at build time with SSG). What alternative did you have in mind?
- psd1 3y agoI'd rather use Blazor, or Jinja. But I hate react, js, and front end work, so maybe I'm not the target audience. I clicked the link out of morbid horror.
- CipherThrowaway 3y agoI haven't used Blazor, but I shudder at the thought of using Jinja to generate the HTML here. Rendering documents from OpenAPI spec benefits from being able to easily transform data, map, filter and so on - especially if you are displaying the JSON schema for request and response bodies (which docs.mux.com appears to be doing). The experience of doing these transformations in template languages is pretty sub par.
- sodapopcan 3y agoI use Phoenix LiveView and I’m really big on frontend. I also do a lot of backend, though, so I’m one of those “full stack” generalists that no one likes anymore.
- quickthrower2 3y agohttp://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/ styling is sufficient for technical docs. I hate the scroll hijacking and other shenanigans on modern docs sites.
- CipherThrowaway 3y agoI agree re: scroll hijacking and with a preference for minimal styling, while noting that the styling on docs.mux.com is pretty minimal compared to other docs sites. What I'm wondering is what the anti-React folks are recommending for generating HTML and/or DOM itself in the docs use case, since most of it needs to be dynamically generated from OpenAPI definitions.
- Osiris 3y agoStatic file generation. People are suggesting that tooling creates HTML files from templates at compile time and then served as plain HTML.
- CipherThrowaway 3y agoGoing by the response headers, it seems that most if not all of the HTML served by docs.mux.com consists of cacheable static files. As the OP article mentions, using React for static generation is one of the big use cases for RSC and Next. Which templating technology would you recommend for the use case instead? Keep in mind that generating HTML from OpenAPI specs can become complex and will require plenty of maps, filters, recursion and indexing into the data in the course of transforming it into HTML.
- jmull 3y ago> plenty of maps, filters, recursion and indexing into the data Are there a lot of server side template languages that can’t do this? This is straight-forward stuff.
- CipherThrowaway 3y ago> Are there a lot of server side template languages that can’t do this? Did I say there weren't a lot of template languages that can do this? A dead give-away that this subject isn't as "straight-forward" as you think is that, at one sentence in, you've already misidentified the conversation taking place. This isn't about can vs can't, but about the right tool for the job. What template language would you personally recommend for this project?
- jmull 3y agoclassic ASP
- 3y ago
- bowsamic 3y agoI think that's a really motherfucking bad piece of advice. Isn't there a version of that which is actually made by someone with some kind of ideas about readability and design? EDIT: http://bettermotherfuckingwebsite.com http://bettermotherfuckingwebsite.com
- popcorncowboy 3y agoAnd the broken TLS is part of jibe right.
- quickthrower2 3y agoIt is not broken, but non existent. Funny read: https://archive.is/dR1mQ https://archive.is/dR1mQ (need to use this link because it is one of those HN-traffic-hostile sites).
- arcanemachiner 3y agohttp://youmightnotneedhttps.com/ http://youmightnotneedhttps.com/
- quickthrower2 3y agoThese are all satire. The point is to KISS. I doubt doco sites need JS except for say running code snippets type stuff. But not for the UI itself. And a big long page with a default scrollbar cannot be beat for accessibility and searchability.