Here are my reasons for planning out a longer-term project and writing a "bookreader" to the IIIF spec using Backbone as the framework and the current BookReader as a guide:
The IIIF Presentation API 2.0 Spec models content in a flexible way, however, it has an ontology unto itself. While concepts can be "mapped" to each other (canvas = leaf = page) during implementation, it makes more sense to use the vocabulary and models defined in the spec -- for clarity's sake, if for nothing else.
2.The IIIF Presentation API is written with a strong bias towards client-server implementations (Single-page JS frontend with RESTful backend, delivering JSON). The BookReader, on the other hand, simply takes a list of images as its pages with no additional information. For the time being, I'm just developing with local storage since Backbone's Sync API allows one to seamlessly go from local storage to a wide array of REST-based server storage options. As for Node.js, I was thinking of spinning up a sample REST API with Node, Express and MongoDB. I think the fact that MongoDB stores objects as JSON and the IIIF Spec assumes JSON and the app is Javascript will allow at least a few less headaches.
The Backbone framework is, as I said, lightweight. A complete annotated source code is available, which is not the case with the other frameworks, and it's important for me to be able to "dispell the magic" if I need to. It is built to be used as a front-end client to a RESTful API. I think that it's structure would alleviate a lot of the "Frankenstein" effect, and provide a starting point for others to be able to contribute and extend.
In order for the BookReader to be more than just a "reader", but perhaps an editor and discovery tool as well, I think we need to be able to build it with or without certain dependencies. We need to break code out into modules, and allow for minimal (and lightweight) use as well as more robust use. It should be as easy to implement as a jQuery plugin (at least in its most minimal manifestation).
Essentially, all of this leads up to taking account of the changes that have been taking place in front-end development since the BookReader was implemented (build tasks, linting, dependency management, unit testing, etc.). The amount of refactoring adds up to rewriting/reinvention anyway, so I think it might be better used as a guide, rather than a vehicle.
That said, I like that the BookReader is pretty much pure JS and jQuery (there are many more things I like about the BookReader). I want to know what's going on at every level of the code. I feel like Backbone is a pretty good compromise.
Here are my reasons for planning out a longer-term project and writing a "bookreader" to the IIIF spec using Backbone as the framework and the current BookReader as a guide:
That said, I like that the BookReader is pretty much pure JS and jQuery (there are many more things I like about the BookReader). I want to know what's going on at every level of the code. I feel like Backbone is a pretty good compromise.