from Berlin and I'm part of the Hoodie team. First of all: thanks a lot Martin for inviting me and all of you for your interest, I'm happy to be here. I think you're the perfect crowd for this talk. So, I said team, so here‘s the rest:
Caolan, JS dev from the UK, made async.js, the most depended on library on npm Gregor, brilliant freelance dev and quasi-inventor of Hoodie Jan, one of the CouchDB developers and organiser of jsconfeu Lena, Berlin startup veteran, does Project management and communication Myself, freelance web dev and one of the organisers of Berlin's frontend usergroup up.front
backend developers. Ruby on Rails appeared. Heroku appeared. It suddenly became possible for your average developers to build and deploy projects reliably without a sysadmin or ops person. Simple deployments from the command line, and suddenly your app was just there, in the web, waiting for people to use it. Minimal setup, minimal hassle, no SSH tunnels, no arcane server wizardry.
time it takes you to make the money to pay them is ridiculous compared to the time it would take you to do any of this yourself. They abstract people and their expertise away into APIs and ticketing systems and say: „Don‘t worry, we got this“ Above all, all of this is empowering: it lets more people do better work in less time. But let's look at us.
new tools for us in the past years. SCSS, Compass, Coffeescript, Yeoman, Bower, Grunt… lovely stuff. Again, better tools are empowering: they let more people do better work in less time. But when it comes to anything more involved than a single pager that fetches data from somewhere else, we're faced with an unpleasant choice, because at some point, we do need a backend:
do it 3. Give up If it‘s a big client project, there may already be someone for #2, but if this is a small app idea you‘d like to try out or just something you'd like to build for yourself, 2 is probably out. 3 is depressing. 1 is too much work. But you‘ll probably try anyway.
at the same time, these are jobs. Other people‘s jobs. They make their living with this, and they know it really well. I mean, I could do 1. I can use PHP or Rails, I can find, adapt and use a server-side framework, I can deal with database schemas and I could probably hack something together that would work. But it wouldn't be very good. It would take me ages. And, most importantly:
easily 3. Let them save and load data 4. Let them share it or make it public 5. Maybe send an email or two 6. Let them pay me for the service. My requirements, in fact most people's requirements aren't rocket science: [ read list ]
easily 3. Let them save and load data 4. Let them share it or make it public 5. Maybe send an email or two 6. Let them pay me for the service. This is extremely basic stuff. People have been doing these things for ages. It's not new. It's not interesting. It shouldn't be hard. It should, in fact, only take minutes.
You're good to go. Server, database, optional todolist.dev url, admin panel, database inspector: all up and running. Now, you‘ll have to prepare your app to use Hoodie as its backend:
a user. Let's look at that again. Really, that's it. Sign in, out, resend password, all that is just as easy. Once you have a user, you can let them save data:
We never defined 'todo' or the data structure it takes. It's document based, just give Hoodie any valid JSON to eat and you'll be fine. Oh, and it also takes binaries, btw. You can throw an image in there and later just get it via http. Let's load some data, for example when you load the page, you'll want to get all the todo items of a user:
can listen to data store events. Every time something interesting happens in the database, you can listen for that, like objects being added, deleted or changed. So instead of adding something to the store and then rendering it to a view, you can decouple those two steps from one another. Just save data to the store, and listen to the corresponding store event when you want to update the view.
} ); Why is this cool? It encourages building reactive, data driven templates. Which means you can use this on multiple devices at once, and everything will just work and always be in sync. Later, you might expand your app so users can write each other todo tasks. If you couple your view updates to store events, that will just work.
sync", that's actually a very fundamental feature of Hoodie itself: hoodie is offline by default. It will automatically store any data a user produces locally and sync back up with the server as soon as a connection is available. Always. It's not an extra function you have to use, it applies to everything. You come back online after being on an airplane, open your app, and the new todos you wrote while airborne are immediately synced to the server.
and one of our goals this year is having our own hosting service for Hoodie apps, so people can get going more quickly. One of the cool things you can do thanks to Hoodie's general approach is, for example, host your data-driven app's frontend as a github page, and have it talk to a Hoodie endpoint somewhere else. That also means you can build your app with yeoman and a livereload server, and have that talk to your Hoodie app, which runs somewhere else.
limiting, no? What if I want to do things to the data server-side?", and this is where I explain the underlying structure of Hoodie. The Hoodie core is actually quite tiny, most of the functionality lives in its own modules.
Hoodie module in js, have it listen for new objects and flags in the data store, and react to them as you see fit, just like the email module just did. You'll be able to write your backend modules in the same language as the frontend, and you'll be able to install new Hoodie modules from other people via npm. The custom modules will even be able to have their own UI as part of the standard Hoodie admin panel.
things don't work, some are slow, some are missing, but personally, it's already one of my favourite things to work with, period. We think it's going to be fantastic.
it takes to become the next big simplifying, equalizing, enabling technology for the web. If you can build modern HTML and have some basic JS knowledge, you can now build and deploy complete, data-driven web applications by yourself. If you were proficient in backend tech and therefore capable of this anyway, you can now do it in a fraction of the time.
espylaub
star_zero
manfredsteyer
seyfoyun
hiro_ghap1
dunglas
.jpeg){kind=avatar}
ostk0069
ma_cho29
chobishiba
xosofox
maroon1st
xuwei_k
okuzawats
malarkey
stephaniewalter
destraynor
honnibal
tammyeverts
csswizardry
rasmusluckow
shpigford
panda_program
lauravandoore
eileencodes
bluesmoon
![hoodie.store.findAll('todo') .share() .then ( function (share) { share.grantReadAccess('[email protected]'); }); Want](https://files.speakerdeck.com/presentations/5c7577f0bf000130e3b272d4544c494c/slide_32.jpg){kind=link}
