Hoodie Presentation at HH.JS

Slides with notes for my talk about http://hood.ie at the Hamburg Javascript usergroup in June 2013.

Video is here: http://lecture2go.uni-hamburg.de/veranstaltungen/-/v/15107

Transcript

1. HH.JS / 17.06.2013 Hey everyone, my name is Alex, I'm 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:
2. Alex @espylaub Caolan @caolan Gregor @gr2m Jan @janl Lena @ffffux 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
3. ? Anyway, today I'd like to introduce you to Hoodie, but before I tell you what it is, let me tell you why it is. So, I don't know if you remember this, but backend work used to be pretty annoying.
4. If you were doing anything remotely complex, you'd eventually need help from someone who spoke vi and had a favorite linux distribution. But then things changed.
5. whoops
6. A couple of years ago, life got pretty great for 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.
7. $ git push heroku master We thought that was pretty amazing.
8. This is smart: turning a profession into a service. The 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.
9. We're probably mostly front-end people, and there's been some great 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:
10. 1. Build the backend yourself
11. 1. Build the backend yourself 2. Get someone else to do it
12. 1. Build the backend yourself 2. Get someone else to 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.
13. Look at that. We could deal with these things. But 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:
14. I simply don't want to. It‘s not my job. It‘s not my expertise. I don‘t enjoy it. And really, what do I need?
15. 1. Sign up users 2. Be able to admin them 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 ]
16. 1. Sign up users 2. Be able to admin them 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.
17. $('.something').addClass('blah'); Why does signing up a user have to be more difficult than changing a DOM element with jQuery?
18. account.signUp('username', 'password'); Why can't you just do this in the browser? It's 2013. And you can. We're building it, and it's called Hoodie:
19. hoodie.account.signUp('username', 'password'); And here's our elevator pitch:
20. 1. Build a data-driven web app over a weekend 2. With a library that's as simple to use as jQuery 3. Start charging on Monday 4. Don't worry about the backend
21. Developing with Hoodie So, what Hoodie does is abstract away all the boring boilerplate backend stuff into a client-side JS API. Imagine we're building the stereotypical todo app. Here we go:
22. $ hoodie new todolist $ cd todolist $ hoodie start 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:
23. var hoodie = new Hoodie(); That‘s your backend setup done.
24. hoodie.account.signUp('username', 'password'); I just showed you how to sign up 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:
25. hoodie.store.add('todo', { title: "Try hoodie", completed: false }); Notice something? 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:
26. hoodie.store.findAll('todo').done( function(todos){ // put all the todos in the DOM } ); Simple enough. Want to get a specific one? Use .find instead of .findAll and pass it an ID. Easy.
27. DATA STORE EVENTS Hoodie does another very cool thing: You 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.
28. hoodie.store.on('add:todo', function(todo){ // Add the new todo to the DOM } ); 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.
29. OFFLINE BY DEFAULT I just mentioned "stuff always being in 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.
30. THE NEAR FUTURE That's the current state of Hoodie. You have user management and private data, and we're working on a couple of additional things.
31. hoodie.sendEmail({ subject: "Your current to do list", text: currentTodoListToText(), html: currentTodoListToHTML(), to: "hey@wow.com", attachments: [ convert( $ ("ul.todoList") ).to("invoice.pdf") ] }) Want to send multi-part e-mails with attachments? This already works, it's not quite ready yet, though.
32. hoodie.store.find('todo', 'abc4567').publish() Want to make a specific bit of the user's data public?
33. hoodie.store.findAll('todo') .share() .then ( function (share) { share.grantReadAccess('joe@example.com'); }); Want to share all of a user's todo items with another user?
34. hoodie.share('shareId').subscribe(); Want to subscribe to someone's shared data? These three are our next priority, after that, we want to implement payments, and make them just as easy as all the other things.
35. DEPLOYMENT You can already deploy your Hoodie apps to nodejitsu, 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.
36. EXTENSIBILITY Now you're probably thinking: "that's nice, but a bit 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.
37. Frontend Backend localStorage hoodie.store App .add() .find() .on() Sync CouchDB Modules Users Shares Emails Payments … REST
38. MODULES What this means is that anyone can write a 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.
39. YEAH So that's our proposal. An extensible, modular, document-based, offline-by-default, frontend first app development framework that lets you forget about the backend, if you want to.
40. Hoodie is Open Source (Apache 2) github.com/hoodiehq Hoodie is open source, and lives on github. and you can get it for OS X, Linux and windows
41. Hoodie is a developer preview It's a developer preview, some 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.
42. VERY FAST WEB APP DEVELOPMENT We think Hoodie has all 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.
43. HOOD.IE Wan to try it? Installation instructions, docs and everything at hood.ie
44. THANK YOU!
45. ANY QUESTIONS?