Slide 1

Slide 1 text

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:

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

whoops

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

$ git push heroku master We thought that was pretty amazing.

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

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:

Slide 10

Slide 10 text

1. Build the backend yourself

Slide 11

Slide 11 text

1. Build the backend yourself 2. Get someone else to do it

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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:

Slide 14

Slide 14 text

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?

Slide 15

Slide 15 text

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 ]

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

$('.something').addClass('blah'); Why does signing up a user have to be more difficult than changing a DOM element with jQuery?

Slide 18

Slide 18 text

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:

Slide 19

Slide 19 text

hoodie.account.signUp('username', 'password'); And here's our elevator pitch:

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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:

Slide 22

Slide 22 text

$ 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:

Slide 23

Slide 23 text

var hoodie = new Hoodie(); That‘s your backend setup done.

Slide 24

Slide 24 text

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:

Slide 25

Slide 25 text

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:

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

hoodie.sendEmail({ subject: "Your current to do list", text: currentTodoListToText(), html: currentTodoListToHTML(), to: "[email protected]", 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.

Slide 32

Slide 32 text

hoodie.store.find('todo', 'abc4567').publish() Want to make a specific bit of the user's data public?

Slide 33

Slide 33 text

hoodie.store.findAll('todo') .share() .then ( function (share) { share.grantReadAccess('[email protected]'); }); Want to share all of a user's todo items with another user?

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

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.

Slide 37

Slide 37 text

Frontend Backend localStorage hoodie.store App .add() .find() .on() Sync CouchDB Modules Users Shares Emails Payments … REST

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

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.

Slide 43

Slide 43 text

HOOD.IE Wan to try it? Installation instructions, docs and everything at hood.ie

Slide 44

Slide 44 text

THANK YOU!

Slide 45

Slide 45 text

ANY QUESTIONS?