4 ms·

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 point

by 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

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.