This is really nice if you're using and developing OxJS locally. On oxjs.org, it's definitely a waste of resources, and we will eventually cache the documentation data.
As a perspective user for this library, the site being excruciatingly slow leaves a very bad impression of the library itself. Whether it's the libraries fault or just the implementation of this particular site is irrelevant to the impression given.
Using myself as a singular datapoint I spent about 15 minutes messing around on the site. About 60 seconds were spent looking at the actual library while the rest of the time was spent being fascinated by how such a simple site could be so slow. That isn't what you want developers doing when considering using a new library.
The readme is fine, it appears to load the content only when the page is accessed.
The examples section is OK, _after_ it loads, since the first time you click on examples it loads all of them for some reason, another 56 requests and several seconds. Some the examples do render slowly which is actually the most concerning issue since all the data has already been pulled to the client (minus a couple tiny SVG files which are cached), thus any slow down you see there is from the JS rendering the view and its not quick.
The documentation load time is terrible, 140 requests as it literally loads _every_ components JS file individually when you first hit the page. Again despite all the data being there already, switching between component documentation views is not snappy in many cases. Clicking on 0x.image for instance spikes CPU usage and takes over a second to render.
The two stand out issues are:
1) loading a ton of JS and nodes into the DOM when it isn't yet needed.
2) slow client side rendering of the views, it shouldn't take a second to render a view when all the data is already client side. It could have just pulled a pre-rendered view from the server in that time.
[1] https://developers.google.com/chrome-developer-tools/docs/he...
If you care to provide a few more details (via e-mail, or using our bug tracker), we're definitely going to look into it.
But what you're looking at is just the HTML/JS that comes with OxJS, and it is intended to be used locally, for development. There is no server backend. You can just put it on your local web server, and it works the same. Generating documentation, tokenizing JS, running tests, etc. all happens live, on the client. (Sooner or later, we'll put pre-generated documentation on oxjs.org. But if you're running the site locally, it's really convenient to not need any build steps.)
The examples currently reference the development version of OxJS, and explicitly don't use cached files. Again, this is nice if you're making your own changes to OxJS, and want to see how they affect a particular example. But for someone just browsing oxjs.org, it's definitely overkill, and we'll fix it ASAP.