3 ms·

The website you see on oxjs.org is part of OxJS, and what happens when you click the documentation button is that the documentation is generated from the un-cac

by rolux 14y ago

The website you see on oxjs.org is part of OxJS, and what happens when you click the documentation button is that the documentation is generated from the un-cached, un-minified version, live, on the client. 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.

mbell 14y ago
I think your missing the point. 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.
- 0x006A 14y ago
  what pages where slow for you? for me navigating examples or readmes is quite fast, loading some examples can be a bit slow, but those examples also need to load data first.
  - mbell 14y ago
    The about, download and development pages are fine since they appear to be loaded when first hitting the site (non-zero part of why the initial page load takes 4 seconds and 46 requests to complete). They also appear to be injected into the DOM at this time, along with at least the side panel navigation components of the other pages, strangely in p tags. 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.
- rolux 14y ago
  I don't want to dismiss your comment, but for me, the site is actually quite snappy, given that it's on the front page of HN. So I guess we need more data points...
  - gildas 14y ago
    The demo site is also leaking (a lot of) memory. Use the "heap snapshot" in Chrome Dev tools [1] and do some heap comparisons when going from one page to another one (switch between two distinct pages multiple times). [1] https://developers.google.com/chrome-developer-tools/docs/heap-profiling#views_dom https://developers.google.com/chrome-developer-tools/docs/he...
    - rolux 14y ago
      Hey... I assume you're referring to 0xDB.org. That may be a bug in pan.do/ra (the application), rather than in OxJS itself. We fixed some memory leaks recently, but may have missed some. 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.
      - gildas 14y ago
        No I was refering to your examples. I sent you a mail to show you how to reproduce the problem.
  - rolux 14y ago
    mbell - thanks for taking the time to debug this. I'm aware of what you're pointing out -- a lot of requests and rendering steps could be avoided by caching data on the server. 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.

by rolux 14y ago

mbell 14y ago

I think your missing the point. 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.

0x006A 14y ago
what pages where slow for you? for me navigating examples or readmes is quite fast, loading some examples can be a bit slow, but those examples also need to load data first.
- mbell 14y ago
  The about, download and development pages are fine since they appear to be loaded when first hitting the site (non-zero part of why the initial page load takes 4 seconds and 46 requests to complete). They also appear to be injected into the DOM at this time, along with at least the side panel navigation components of the other pages, strangely in p tags. 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.
rolux 14y ago
I don't want to dismiss your comment, but for me, the site is actually quite snappy, given that it's on the front page of HN. So I guess we need more data points...
- gildas 14y ago
  The demo site is also leaking (a lot of) memory. Use the "heap snapshot" in Chrome Dev tools [1] and do some heap comparisons when going from one page to another one (switch between two distinct pages multiple times). [1] https://developers.google.com/chrome-developer-tools/docs/heap-profiling#views_dom https://developers.google.com/chrome-developer-tools/docs/he...
  - rolux 14y ago
    Hey... I assume you're referring to 0xDB.org. That may be a bug in pan.do/ra (the application), rather than in OxJS itself. We fixed some memory leaks recently, but may have missed some. 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.
    - gildas 14y ago
      No I was refering to your examples. I sent you a mail to show you how to reproduce the problem.
- rolux 14y ago
  mbell - thanks for taking the time to debug this. I'm aware of what you're pointing out -- a lot of requests and rendering steps could be avoided by caching data on the server. 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.