Open hamoid opened 7 years ago
+1. This could be fixed whilst also fixing #146 I guess?
I'm not sure this is easily fixable short of rewriting the whole docs generation system. The rendering of the docs rely on backbone.js and the data for the docs itself are generated each time with yuidoc as a JSON file. All the backbone.js parts need be to rewritten in the backend to render on the backend for this to work...
That's a pity. Doesn't that make it hard for search engines to index the reference? It's also not possible then to download reference pages from the command line (using curl or wget), or?
If some day the rendering system is changed, I can recommend hugo for generating a static website. It takes about 1ms per page to render a site, and you can run it in watch mode, so you see website updates "live" when you save your changes to any content file. It is open source, written in go.
The problem with search engines are pretty much a non issue now as major search engines understand that front end rendering is a thing and would generally render the page before indexing them (Google made angular.js so they must figure out how to index that or nobody would use it...), you can try by just googling "p5.js reference ellipse" and there should be a link directly to ellipse's docs.
Downloading with curl or wget will probably not give you anything useful and would probably still give something messy even when rendered on the backend, it is meant to be viewed on a browser after all. However, if you are looking for an offline version of the reference that you can download, you can get it here (still runs on the same rendering system though, just works offline). If you are thinking of a basic mostly text only reference, I think it would make for a good PR.
Personally, I feel this has wider benefits: The docs are a bit slow to load (Even when developing locally) and have no indication whether the load has failed or not which is not great when changing documentation. Also, looking at the output files, the current system produces a bunch of duplicates of the index page in classes
, files
and modules
folders - which implies to me some back-end rendering is happening (Or at least trying) anyway... Why not just render everything in the back end?
I'm not opposed to changing the rendering to render on the backend. I tried to pare down the download size of the reference page awhile ago and it still is rather big, especially the JSON file that includes all the data.
The backend do render the pages and it's just the reference that is rendered on the front end, so it isn't impossible, just some work need to be done to both move the backbone.js logic to the backend and to switch the templating from the ejs style backbone.js uses to handlebars (unless it is preferred to render with ejs still but I prefer to keep it consistent).
Hi! It would be nice if the documentation was available even if JavaScript was off.
That's how it works for the Processing reference and the OpenFrameworks documentation.
Using JavaScript to improve how the documentation behaves is nice, but having it hidden by default adds a possible failure point, maybe some latency and a requirement that's not really necessary.