Show HN: OxJS - a JavaScript Library for Web Applications | Hacker News Reader

Show HN: OxJS - a JavaScript Library for Web Applications

oxjs.org

44 points0x006A35 comments

I genuinely think any new JS web application framework needs to answer several key questions on the front page, above the fold - for starters:

- How is this different to Backbone.js/underscore.js, Spine.js, Sproutcore, etc.?

- Who's using it? (I realise the list will be short for new projects)

- Why should I learn a new framework when my other tools seem to be working just fine?

- What are its dependencies, and what templating libraries does it use/support?

There are probably more (chime in if you have any!) but if you can answer these without resorting to impressive demos or long lists of (expected) features, I'd consider trying it out for a low-risk project and hope it saves me some time/hassle...

Hey, thanks for your feedback. You're reading introductory blurb v0.1, so there's definitely room for improvement.

To answer your questions:

- The core library (Ox.js) is somewhat similar to underscore, while the UI module (Ox.UI) is more like YUI or Ext JS. Unlike backbone, OxJS comes with actual widgets, and it doesn't suggest a strict MVC model. Even though you may end up writing code that follows the MVC paradigm rather closely.

- So far, the only major project using OxJS is pan.do/ra (https://pan.do/ra). But then, OxJS has just been made public.

- In case the tools you're currently using give you the right abstractions and objects to build big applications (like pan.do/ra), then my suggestion would be to stick with them. Maybe try out OxJS for a small side project.

- Ox.UI wraps jQuery, but other than that, there are no dependencies. You can bring any third-party templating library, but the idea is that you won't need one. The UI widgets are your "views", and that's it.

Other questions one might answer:

- Were other libraries (YUI3, Backbone, Ember, ...) evaluated and if so, what were their weaknesses and how does this improve on that?

- What are the core strengths of the framework?

This library requires an HTML5 compliant browser but does not use HTML5 features? When looking at form elements example [1], I see that new input types (e.g. date, color, range, datalist...) are totally reinvented. What's the point?

[1] https://oxjs.org/#examples/form_elements/live

I would prefer to have custom widgets instead of standard sophisticated HTML5 inputs because I can customize and extend them, e.g. standard color input does not provide alpha slider, range input does not support logarithmic scales.

I would initially argue compatibility on this one, but it doesn't appear like IE7 is supported (my only non-HTML5 browser I have available at the moment).

Perhaps they intend do go that route at some point?

(One of the authors here.) Correct - for input widgets that have a clear equivalent, we're planning to switch to HTML5 form elements eventually.

silly op, J and S aren't hexadecimal digits.

Edit: Also, cripes, I get that you're trying to show off your amazing web app framework, but whatever happened to degrading gracefully?

Also, the domain doesn't use a 0, as I would have expected.

On a 2012 MBA, Chrome 20 and a 30Mbit broadband connection:

Initial loading: 46 requests, 200KB, 4s load

Clicking documentation button: 140 requests, 400kb, ~5s load

The timeline in chrome dev tools for this site is terrifying, all I can say is 'wow'. Worst part is that the vast majority of resources don't appear to have cache headers set.

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.

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.

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.

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.

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...

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/he...

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.

No I was refering to your examples. I sent you a mail to show you how to reproduce the problem.

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.

Looks really cool! Load times are really high even on Chrome though.

Just a heads up, the live demos took a bit to load (the network here is poor), but there was no indication they were loading. An indicator would be nice.

The network here is slow too (Peru) so I'm used to sites loading slowly. However, this site felt extra slow even to me.

The interface for annotated examples is quite cool: http://oxjs.org/#examples

Looks a bit like Docco: http://jashkenas.github.com/docco/

Reminded me a lot of uki.js: http://ukijs.org/

Also, ExtJS comes to mind: http://www.sencha.com/products/extjs/

Looked nice until I saw this example: https://0xDB.org/ . I thought the idea of using Windows-style menus and windows in the browser was pretty much dead? I don't like it at all.

I think you are missing the point as this framework doesn't intend to handle all those simplified webpages but obviously tries to make complex interfaces possible within web browsers. Taking a well-known GUI metaphor and UI architecture makes sense in this case, IMO.

I understand what it tries to do. I just don't consider it worthwhile. Having a menu bar inside the browser chrome along with non-native windows is confusing at best if not outright broken. It tries to emulate a user experience that does not fit the browser and should better be implemented as a native app.

I get your point, but I don't think it's necessarily a browser vs. desktop thing, especially since that line is going to blur even more in the future.

I guess it rather depends on the type of application you're building. For anything complex and truly feature-rich (think a good e-mail client, or professional photo/video management software), the big advantage of a menu bar is that it makes functionality discoverable, using a well-known paradigm. Keyboard navigation + shortcuts are a plus, and OxJS provides that.

I definitely see a need for desktop-like JavaScript UI toolkits. But of course, one has to use them wisely. Non-native dialogs have become quite common, and I think they make sense for login, notifications, warnings, and so on. On the other hand, it's unlikely that a whole layer of stacked "windows" (inside a tab, inside a browser window) is a good idea.

EDIT, forgot to mention: The main reason menus or dialogs as elements on a website may seem confusing or broken could be that most existing JavaScript implementations are actually confusing and broken.

I didn't think it resembled Windows-style controls at all; I thought "iTunes" immediately instead.

That said, I haven't used Windows in quite some time so I could be way off.

Don't know if anyone will read this. Requiring to enable JavaScript was expected, but enabling images too? I rarely see web pages that don't even try to work at all with images disabled.

a little bit of this, a little bit of that... I can't get the idea behind this "framework"... what do image steganography and web cartography have in common? Should a framework really cover these two orthogonal topics? Besides that, 0x.js could have been a nice name for a js binary manipulation lib.

There's a JS library called OxJs[1] for binary manipulation.

[1] https://gist.github.com/674212

When I saw My.MAGIC_CONSTANT I closed the tab. Too PHPish for me.

That was in the example of the documentation frame-work, I believe - https://oxjs.org/#examples/oxdoc_tutorial - while highlighting how commenting / documentation works and the code there was purely example and not at all how the development style for the library is.

Reply on news.ycombinator.com