Well, the point of Unhosted modules and being explicit about your data schema in modules is so that other developers can reuse them, to make it possible for users to switch between frontend apps that consume the same kinds of data.
Well, duh*.
But there seem to be loads of people making the same kinds of apps over remoteStorage (mostly todo apps or notetaking kind of things) and making their own modules every time!
If one module doesn't offer everything a dev needs for their new app, they should hook in anyway and extend it with their own module on top. That should be pretty straightforward.
So I love LiteWrite, but for notetaking maybe I need a few more organisational facilities. McNotes looked awesome and I was poised to start using it. Then I saw Laverna offers remoteStorage support and that is pretty much a straight up port of Evernote (but ten times as sexy), with tags and notebooks and everything!
When I switched from Evernote to something to something to Springpad (the ones in between didn't do the job, and I've since forgotten what they were) I had all kinds of mess importing my Evernote data, and a lot of it was done manually due to limitations of the various importers. If I'd actually started storing anything useful in LiteWrite, and wanted to move to McNotes and then to Laverna I would have gone through the exact same process... which is a horrible thought, because that's one of the problems remoteStorage is supposed to solve.
So, please, if you're making an app over remoteStorage, look at the other modules that exist first, and use them. And if you're making a new module, please publish it! Otherwise we're missing a butt-ton of opportunities for giving users choices about their UIs, and for mashing things up in amazing ways.
(On that note, I'm keeping a list of Unhosted mashup ideas).
* Although this is kind of obvious, I explicitly came to this realisation after it occurred to me, when trying to work out how to make schema definitions conform to proper JSON-LD, that you go to all the trouble of defining your data schema in your module, but then there's nothing to stop you just storing any old object. You can validate an object against a schema, but there's nothing to do this by default. So I thought why then do I need to bother with this JSON-LD schema faff if I can just store prefixes at object creation time? Then I remembered other people, and reuse and stuff. It took a surprisingly long time (like an hour of frowning) to get to that though. Especially surprising given that all I've been thinking about this evening is Linked Data. Clearly all this JavaScript is obscuring coherent thought.
Well, duh*.
But there seem to be loads of people making the same kinds of apps over remoteStorage (mostly todo apps or notetaking kind of things) and making their own modules every time!
If one module doesn't offer everything a dev needs for their new app, they should hook in anyway and extend it with their own module on top. That should be pretty straightforward.
So I love LiteWrite, but for notetaking maybe I need a few more organisational facilities. McNotes looked awesome and I was poised to start using it. Then I saw Laverna offers remoteStorage support and that is pretty much a straight up port of Evernote (but ten times as sexy), with tags and notebooks and everything!
When I switched from Evernote to something to something to Springpad (the ones in between didn't do the job, and I've since forgotten what they were) I had all kinds of mess importing my Evernote data, and a lot of it was done manually due to limitations of the various importers. If I'd actually started storing anything useful in LiteWrite, and wanted to move to McNotes and then to Laverna I would have gone through the exact same process... which is a horrible thought, because that's one of the problems remoteStorage is supposed to solve.
So, please, if you're making an app over remoteStorage, look at the other modules that exist first, and use them. And if you're making a new module, please publish it! Otherwise we're missing a butt-ton of opportunities for giving users choices about their UIs, and for mashing things up in amazing ways.
(On that note, I'm keeping a list of Unhosted mashup ideas).
* Although this is kind of obvious, I explicitly came to this realisation after it occurred to me, when trying to work out how to make schema definitions conform to proper JSON-LD, that you go to all the trouble of defining your data schema in your module, but then there's nothing to stop you just storing any old object. You can validate an object against a schema, but there's nothing to do this by default. So I thought why then do I need to bother with this JSON-LD schema faff if I can just store prefixes at object creation time? Then I remembered other people, and reuse and stuff. It took a surprisingly long time (like an hour of frowning) to get to that though. Especially surprising given that all I've been thinking about this evening is Linked Data. Clearly all this JavaScript is obscuring coherent thought.
Post a Comment