$30 off During Our Annual Pro Sale. View Details »

I have a dreamcode: build apps, not backends –Side View 2013

Alex Feyerke
November 09, 2013

I have a dreamcode: build apps, not backends –Side View 2013

Presented at Side View in Brighton, November 9th, 2013

The way frontend coders work with data is still very much determined by historical technical necessities and sentiments instead of by how they would like to work. We’re proposing a friendlier, more frontend-centered approach to building data-driven applications, where the backend adapts to the frontend developer’s dream code. At the end of this lies the wish many frontend devs have: “I wish I wouldn’t have to worry about the backend anymore.” Well, your time is coming. Plus a lot more.

Alex Feyerke

November 09, 2013
Tweet

More Decks by Alex Feyerke

Other Decks in Programming

Transcript

  1. NO
    BACKEND
    SIDE VIEW 2013 – BRIGHTON
    Alex Feyerke - @espylaub
    Hi everyone!
    My name's Alex, I'm a freelance web developer in Berlin.
    First off, thanks to the the sharps for having me here,
    and thanks to all of you for your interest. Brief disclaimer
    before we start: I work on a noBackend project called
    Hoodie

    View Slide

  2. HOOD.IE
    so this is all very close to my heart, and the few code
    examples I do have come from this project. But it's not
    going to be a code-heavy talk or lots of hoodie
    promotion, don't worry. If you want hoodie promotion,
    come talk to jan or me later.
    Anyway.
    Today I want to start with an anecdote.

    View Slide

  3. I used to do AS3 development. A couple of years ago, I
    decided that that ship was not only sinking, it was also
    on fire, and so I abandoned it. JS looked good, so I
    thought I‘d build something with it, just to get the hang
    of it.
    At the time, I had the following train of thought:

    View Slide

  4. 1. tumblr is full of amazing music
    2. tumblr is terrible for listening to music
    3. I can do better

    View Slide

  5. So I built a thing called Whiskie, and all it did was show
    you nothing but the music posts from all the tumblrs you
    followed.

    View Slide

  6. And because tumblr is an incessant torrent of stuff,
    Whiskie let you favourite stuff and never lose it again.
    But oh.
    This meant: data storage. Any I was clueless. I‘d never
    written a database query before. So naturally,I wanted to
    do this in the simplest possible way. Now, all users had
    to oAuth with tumblr because I needed to read their
    dashboards, which meant I also had write access for
    their tumblr accounts…

    View Slide

  7. I had a cunning plan:

    View Slide

  8. TUMBLR AS A BACKEND
    I ended up using one tumblr draft per user as a JSON
    store. Worked wonderfully, until I wanted to implement
    public faves, which drove me towards more PHP and
    MYSQL. But I‘d gotten a taste of what I wanted, I just
    couldn‘t formulate it back then:

    View Slide

  9. NO BACKEND
    BACKEND AS A SERVICE
    And now, years later, these things exist, and that‘s what
    I‘m here to talk about

    View Slide

  10. DON‘T WORRY ABOUT
    THE BACKEND
    Building full-featured web applications on the browser
    side and not worrying about what goes on on the server.
    Now I don't know about you, but to me, this sounds very
    desirable.

    View Slide

  11. I'm primarily a frontend developer. But in practice, I'm
    not. I'm a both-end developer.

    View Slide

  12. Many of us probably are. Not by choice, mind you, but
    because I don't have any alternatives. At some point, 95%
    of my projects require some sort of data storage or user
    authentication. This leads us to these old friends:

    View Slide

  13. Look at that. I could sit down and work 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 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:

    View Slide

  14. I simply don't want to.
    It‘s not my job.
    It‘s not my expertise.
    I don‘t enjoy it.
    I would probably find a way to make some terrible
    security mistakes.
    And really, what do I need?

    View Slide

  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 outlandish. This is extremely basic stuff. It‘s
    actually quite boring

    View Slide

  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
    People have been doing these things for ages. It's not
    new. It's not interesting.
    It‘s not exactly rocket science.

    View Slide

  17. Rocket science is dictated by the natural world. Building
    stuff on the web is more or less arbitrary. The rules
    aren‘t god-given, set in stone or otherwise immutable.
    They‘re agreements between humans. If we want to
    change the web, we can. We don‘t even have to ask for
    permission.
    So, again:

    View Slide

  18. 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
    Why is this so hard?
    It shouldn‘t be difficult.
    It should, in fact, only take minutes.

    View Slide

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

    View Slide

  20. account.signUp('username',  'password');
    Why can't you just do this in the browser?
    That's where the noBackend idea comes in. It makes this
    possible. noBackend is essentially about delegation. It
    turns something that is difficult and full of pitfalls into a
    commodity, where the tricky and/or dull bits are handled
    by other people who are better at it than you. And this
    makes sense, we do it all the time, in all aspects of life:

    View Slide

  21. Distributed version control!

    View Slide

  22. Plumbing!

    View Slide

  23. And other dirty work.
    So:

    View Slide

  24. Why not with backends?
    Backends are hard, they're made up of a lot of different
    components that all have to interact with each other,
    there's a variety of languages and syntax in even the
    simplest setup, there are arcane conventions and layers
    upon layers of obtuse, compounded weirdness that take
    years of experience to wrangle with confidence. And
    that's before you start scaling.
    Sounds like the first thing I'd want to get rid of.

    View Slide

  25. Well, you can get rid of it. There are architectures and
    services that let you more or less forget about the
    backend, and just build complete, data driven web
    applications from the client side, all in JS. Some of them
    even throw in real-time data binding and offline
    capability.
    Essentially, your backend is a black box with an API. So
    noBackend is a bit of a misnomer, of course there's a
    backend, it's just not something you have to worry about
    if you don't want to.

    View Slide

  26. account.signUp('name',  'pw');
    Let's look at some examples. I showed you this a minute
    ago:
    That's noBackend code. It runs in the browser, and it
    does exactly what it looks like it does. You can do that a
    few seconds after you've generated the app's scaffolding
    with a command line tool. It's a real thing, you can use it
    today, and it creates a proper user account and
    authenticates the new user. Want to store some data?

    View Slide

  27. store.add('todo',  {
       title:  "Not  panic",
       completed:  false,
       due:  1378806388
    });
    No setting up a database, no schemas, no config. Want
    to store some data? Go ahead, store some data. The
    infrastructure gets out of your way. Want to send a
    multi-part email from the browser? Go ahead, it's 2013:

    View Slide

  28. sendEmail({
       subject:  "Your  current  to-­‐do  list",
       text:  currentTodoListToText(),
       html:  currentTodoListToHTML(),
       to:  "[email protected]"
    });
    This is a nice example of the noBackend philosophy. It’s
    all about the API, it’s frontend centric, user centric. The
    actual implementation might or might not be complex,
    why should you care?

    View Slide

  29. NOBACKEND
    is a design paradigm for architectures/
    frameworks that abstract complex
    backend operations and technology into
    a simple to use REST API.
    So there is a backend, but delving into it is optional. Of
    course, these things are usually extensible in some form
    or another, so you can add functionality with plugins or
    packages. And that‘s a pretty good setup, in my opinion.
    Right, I think you got the idea. That's all the code you're
    going to see from me today.
    First, I'm going to tell you why this is cool. Then I'm
    going to tell you why it's important.
    What's cool:

    View Slide

  30. SIMPLICITY AND
    ACCESSABILITY

    View Slide

  31. · Service or an installable package (runs
    server, DB, everything)
    · Ideally: One language, one data format
    · Simple, built-in deployment
    · Very quick to get going
    - NoBackend solutions typically come as a service or an
    installable package that includes the entire
    infrastructure: quick setup, very low barriers to entry
    - Where you used to have a tech stack with multiple
    languages, data formats, databases, query languages,
    server configurations etc., you now potentially have one
    language, one data format, and barely any contact to the
    server, unless you want to
    - very simple, built-in deployment mechanisms

    View Slide

  32. SPEED

    View Slide

  33. · Very little config and boilerplate, build
    significant things immediately
    · Additional perks: offline modes, live
    sync, reactive views etc.
    · Perfect for rapid prototyping with real
    data, behaviours and devices
    - Very little config, very little boilerplate code to write.
    You can start doing substantial things almost
    immediately, there's nothing standing in the way of your
    ideas and the interesting problems of your app, which is
    what the user does with it
    - Different solutions offer different built-in perks which
    save lots of development time, such as offline capability,
    live sync across devices, real-time data binding etc. And
    that's all just there, no additional effort
    - Perfect for extremely rapid prototyping and user
    testing with real data and behaviours on real devices

    View Slide

  34. FOCUS
    - Start development in the browser, near the user, where
    the unique aspects of your app are. Build the user-facing
    features quickly, validate or dismiss them, experiment
    and pivot at will without worrying about infrastructure or
    data schemas. Find out whether the idea is actually
    worth spending time on.

    View Slide

  35. FLEXIBILITY
    Many solutions let you host wherever you like (as they
    should), which includes a box in the corner of your
    office. You could have auto-updating, self-hosted and
    secure, device-independent enterprise software
    packages running on a small noBackend-Server. Setting
    that server up is just as simple as running the noBackend
    stuff on your own machine.

    View Slide

  36. We spend so much time on
    the internet that we should all
    have our own digital home
    online. So far we are only
    guests in a couple of gigantic
    hotels with barb wire around
    them.
    —Bastian Allgeier
    The Future of the Web — A Draft

    And there are developments in this direction. Of course
    you can cobble together a bunch of open source projects
    on a mac mini, but better, more user friendly alternatives
    are appearing:

    View Slide

  37. here‘s a small german company called protonet building
    servers for small businesses:
    That‘s a server. It has one button. You press it, and you
    get a self-hosted environment for chat, filesharing and
    groupware. Why should this be any more difficult?
    But we were talking about flexibility, and that takes other
    forms as well:

    View Slide

  38. Backends as swappable commodites
    unified by a consistent interface
    noBackend potentially makes the backend part of an app
    a swappable commodity. As long as the API is the same,
    what goes on behind it doesn‘t matter, what it‘s
    implemented in doesn‘t matter. And that means you can
    switch at will.
    But noBackend offers some new approaches to old
    problems, too

    View Slide

  39. ONE BACKEND
    PER USER
    You build your app as static HTML (hosted on gitHub
    pages, for example), the users host their data
    themselves, on Dropbox, google drive or with
    remotestorage.io or similar.

    View Slide

  40. · Scales easily
    · Data privacy is easier to guarantee
    · Multiple apps could access the same
    user store
    Each user only has one calendar, one address book, one
    todo list, that all apps can access and work with.

    View Slide

  41. SPIFFY!
    So noBackend brings a large increase in simplicity and
    comfort for people like us, but it can also do a lot more.
    I think we can all agree that the internet isn‘t doing so
    well at the moment: huge, centralized services, ads,
    bullshit startups, ubiquitous surveillance… not good. But
    noBackend might be able to help a bit.
    Let‘s go back in time for a second:

    View Slide

  42. Now, you should all know this: The Internet has its
    origins in Arpanet…

    View Slide

  43. …a military network created to facilitate more efficient
    use of geographically distributed computing resources.
    The "survive a nuke"-aspect was actually never a design
    goal, but more generally avoiding single points of failure
    was. Equipment and connections were unreliable
    enough, even without Soviet Russia throwing ICBMs at
    them.
    So we got packet switching and TCP/IP, and we also got
    this image:

    View Slide

  44. Now, on a technical level, this is still somewhat accurate,
    that's how the web works. In practice, the individual
    nodes aren't of equal size, some are veritable
    supernodes:

    View Slide

  45. The big ones are what you'd expect: many of them are
    google sites, the second largest one is facebook, then
    yahoo.com, apple.com etc.
    These are pretty significant points of failure now. Not
    necessarily in an reliability/uptime sense, but in a more
    general security sense. If an antagonistic third party can
    access anyone's data in these large nodes, they must be
    considered broken. As we know, this is the case.
    So, ideally, the web, even the social web, is properly
    distributed, to avoid these kinds of things in the future:

    View Slide

  46. We must make […] what I
    call “social machines”, in
    which people can collaborate
    together, but do it in a way
    that’s decentralised, so it’s not
    based on one central hub.
    —Tim Berners-Lee
    And I think we can all agree with that.
    But how would that work? Well, here‘s a popular idea:

    View Slide

  47. I dream of a future where
    everybody has their own
    server – just not the one you'd
    think of.

    View Slide

  48. It could be your computer at
    home, a little box next to your
    TV, maybe a gaming console
    or a small server somewhere
    in a data center.

    View Slide

  49. That's not important. It would
    be like having a mobile
    phone – it might even be your
    mobile phone.

    View Slide

  50. Your own server would be so
    easy to use and easily
    integrated with your existing
    devices that even your granny
    would have one.
    —Bastian Allgeier
    The Future Of The Web — A Draft
    That orange protonet box is a very small step in that
    direction.
    So let‘s see what noBackend can do to help. It can:

    View Slide

  51. · Redistribute data and services
    · Enhance data security and sovereignty
    · Provide infrastructural independence
    · Empower people to build and run their
    own software
    · browser-based applications + locally
    installed software = <3
    - redistribute apps and user data away from central
    nodes and single points of failure (either through 1
    backend per user or by enabling more people to do their
    own thing)
    - decrease the number of enormous data silos that can't
    talk to each other
    - through this, enhance data security and sovereignty
    - provide infrastructural independence from large,
    compromised services with their own agendas by turning
    them into swappable commodities
    - empower people to build and/or run their own
    localized tools and solve their own problems
    - bring together the best parts of browser-based
    applications and locally installed software

    View Slide

  52. DECENTRALIZE.IT
    Bastian, who I just quoted, is forging ahead with this,
    publicly working on a concept for a platform that could
    do all of these things. So check it out at decentralize.it!
    I‘m a big fan of this idea, because it‘s keenly aware of
    the problems, one of them being: security and
    decentralization aren‘t actually selling points for non-
    nerds. We have to make platforms so compelling on
    other fronts, because privacy isn‘t sexy.

    View Slide

  53. THE CRUX
    And that‘s the crucial point, isn‘t it? The self hosting, the
    app developing, the one backend per user, it all has to
    compete with the incredibly polished products of
    enormous companies.

    View Slide

  54. It has to compete on the levels of functionality, user
    experience, design, critial user mass and convenience,
    all of which are perceived as more important than
    security and integrity. It's a hard sell, and we're not
    going to get there by continuing to building stuff by
    nerds for nerds.
    I don‘t know how many UX people FB has, but they have
    UX people. Most open source projects don‘t even have a
    designer. And if they do, it‘s usually as an afterthought.
    „Hey you: Make this look nice„
    But that‘s nowhere near enough:

    View Slide

  55. Design is not just what it looks
    like and feels like.
    Design is how it works.
    —Steve Jobs
    So design has to be part part of the entire process. And
    what this means, to put it very bluntly, is that OS
    generally isn't for normal people. OS is for people who
    think this ->

    View Slide

  56. represents an exciting opportunity. That's not a majority
    opinion. The majority wants an iPhone. And that doesn't
    make the majority stupid or wrong. They just want a
    good experience. They want to be empowered, not
    encumbered.

    View Slide

  57. We need to make it easy,
    convincing and enjoyable to
    move our personal data away
    from the big players.

    View Slide

  58. We need great self-hosted
    applications, which we can
    use to manage our emails,
    personal pictures, documents,
    private messages with friends,
    blog posts, etc.
    —Tom Dale
    Progressive Enhancement is Dead
    We've got to build better tools. And not only tools to use
    on the web, tools to make the web, too. Simpler tools
    that make general purpose computing more accessible.
    And yes, this is our job as frontend people, because

    View Slide

  59. The browser transformed from
    being an awesome interactive
    document viewer into being
    the world’s most advanced,
    widely-distributed application
    runtime
    —Tom Dale
    Progressive Enhancement is Dead
    We need to empower people to code and produce things
    they can actually use in a modern world, in their world,
    on __any device with a browser__, just like the apps they
    use everyday.
    So back to making the web: noBackend removes the high
    barrier of entry to producing what I now consider the
    most generally useful realm of programming: web
    applications. And the barrier is high:

    View Slide

  60. ANIMATED GIF OF DOG
    JUMPING INTO HEDGE
    AND BOUNCING OFF
    HILARIOUSLY
    The simplest form of traditional web application a
    beginner might be able to deploy requires you to write
    HTML, CSS, probably JS, PHP and MYSQL. People work
    highly paid, full time jobs just doing the first two. This
    may not seem so bad to us, but to most people, this
    might as well be actual rocket science. Just getting
    everything set up locally and remotely is a task that will
    deter, if not defeat many beginners.
    (the dog gif is here: http://gifeye.com/3805)

    View Slide

  61. And, like water and electricity, people in general tend to
    follow the path of least resistance, and that path is to get
    someone else to solve their problems instead of learning
    how to run MAMP (which is supposed to be simple
    already!) and write a SQL query.
    And that‘s a problem. Making the web is still too hard.
    Using the web used to be hard, too, but it‘s been made a
    lot more convenient and simple, by the wrong people,
    regrettably, but hey. But by and large, the web is made
    by professionals.

    View Slide

  62. But that's not the point of the web, is it? It‘s not TV, it‘s
    not there to be consumed passively. And yes, people
    upload immense amounts of photos, video and audio per
    day, but that‘s not making the web. We‘re the ones
    making it. But…

    View Slide

  63. The web is not just for web
    developers!
    —Adam Brault
    Enough is enough
    He's right! The web is an amazing system that can do so
    much for so many, and yet to most people it's just a
    photo scrapbook where they tell the government where
    they are and who they're with. We're letting one of the
    greatest feats of human ingenuity degenerate into an
    interactive lifestyle magazine that spies on you.
    One way to remedy this is to put creative power back
    into the hands of individuals. That was the point of the
    web all along:

    View Slide

  64. This is for everyone.
    —Tim Berners-Lee
    2012 Olympics opening ceremony
    And when he says everyone, he means everyone: Not just
    professionals and corporations, everyone. And there are
    notable precedents for efforts to put computing power
    into the hands of amateurs. Back in the 1980s, Apple
    gave us HyperCard

    View Slide

  65. View Slide

  66. Both Danny Goodman and
    Bill Atkinson have stated
    publicly that they got
    programming questions from
    every kind of person: small
    business owners, school
    teachers, ski bums, taxi
    drivers, etc.

    View Slide

  67. Hypercard let non-
    programmers build simple
    apps, and so a lot of apps
    were created that would
    never have been created if
    app-creation was left in the
    hands of professional
    programmers.

    View Slide

  68. And many of those little apps
    were tailored to what the
    creator needed at that
    moment, in a way that could
    never happen if a
    professional programmer
    drew up some spec.
    —lkrubner
    Hacker News thread on Hoodie
    …or listened to market reasearch. HyperTalk is
    apparently what inspired Brendan Eich when writing
    JavaScript. There were even hardware add-ons for
    HyperCard that could exchange signals with external
    devices, much like ->

    View Slide

  69. …Arduino shields…

    View Slide

  70. or the Tessel, which just got funded recently.

    View Slide

  71. In the 70s, there was SmallTalk, which was similarly
    appealing to all sorts of people (provided you had access
    to the hardware). At a glance, it looks a tiiiiny bit like
    CoffeeScript, with its pleasant lack of curly braces and
    semicolons. It's easy to learn, has an integrated editor/
    debugger/execution view setup (*cough* browser) and
    thus a very low barrier of entry.
    Smalltalk and HyperCard were interesting because they
    made programming accessible, people from all walks of
    life could write useful little things with them and take
    advantage of the new powers digital technology brought
    them. Except back then, nobody had the hardware.

    View Slide

  72. Where's the equivalent of that today? I'd say the closest
    thing is JS and frontend web tech. You can write, run,
    debug and use your code in one place, the browser, and
    you can modify the code while it's running, too. Plus, it's
    platform independent and networked, and you can put it
    on the web, from where it can be run by practically
    anyone who can find it. You can also fly drones and
    control other hardware with it. That's an extremely
    powerful tool.
    So what we should do is: make powerful tools accessible,
    easy to set up, quick to get started, and delivered with
    encouragement instead of kept to ourselves with
    monkish elitism:

    View Slide

  73. Learning to program should
    be about play, it should be
    getting things up and running
    in an afternoon and seeing
    what happens, it should really
    just be about poking things.
    —Tef
    Programming is terrible
    Again, I think noBackend tech can be hugely helpful in
    this regard. So helpful, in fact, that it's one of Hoodie's
    design goals to make its use attractive and intuitive to
    beginners and non-professionals. And we came up with
    a process to help us achieve this.

    View Slide

  74. DREAMCODE
    Hm, that doesn‘t really do it justice…

    View Slide

  75. DREAMCODE!
    At Hoodie, we call the process dreamcode. When we
    designed the initial API, we sat down and each wrote
    hypothetical apps that worked with a fictional noBackend
    API, which reflected what we thought were the most
    intuitive, simple and sensible ways of working from the
    frontend. We didn't start with the system's capabilites
    and simply exposed them to the users, we started with
    the users' requirements and built backwards from there.
    We wanted people to have a good experience with it.

    View Slide

  76. Dreamcode is essentially user centered design for APIs.
    For us, this was crucial, because our target audience for
    1.0 isn't developers like us. We're aiming for non-
    developers, non-professionals. We want the beginners
    and amateurs, the people who'd usually shy away from
    code. We've made data driven app development so much
    simpler and more convenient, and it would be a great
    waste to not expose all that to a greater audience. We
    want the power, simplicity and accessibility of smalltalk,
    hyperCard, even Excel, in the web realm.

    View Slide

  77. WE ARE
    DESIGNERS
    To do this, we (as in: developers) need to know the
    fundamentals of design process and design thinking. Not
    because we need a sweet website for our project or a
    nicely typeset docs page, but because using what we
    build, from finding it, to learning about it, to getting it
    running, to working with it, to failing with it, to asking
    for help for it, to succeeding with it: all of that is user
    experience.

    View Slide

  78. WE ARE EXPERIENCE
    DESIGNERS
    And it pays off to design towards that experience,
    because that's what google and apple and facebook do,
    and what developers, left to themselves, tend to forget.
    How many brilliant engineering projects on the web go
    underused and ignored because the engineer thought: "I
    didn't have a three-point getting started guide, why
    should anyone else?"
    So we are experience designers ->

    View Slide

  79. WHETHER WE LIKE IT
    OR NOT
    As programmers, what you produce needs to be
    designed to the users' needs, and how you present it
    needs to be tailored to the intended audience, which is,
    far too often, exactly one person, the author. And it
    needs to offer a good user experience, even if it's just a
    snippet of code. And that's just a matter of economy:
    every time a developer saves time by leaving something
    obtuse and complicated in their code, that time gets
    wasted many times over by every user who has to figure
    it out first.
    So, in short: Don't believe in this open source mantra of
    trickle-down technology:

    View Slide

  80. In technology, some of us
    share a similar philosophy to
    trickle-down economics.

    View Slide

  81. We believe that when a
    technically-savvy elite of
    enthusiasts build tools and
    technologies for themselves,
    that technology will eventually
    trickle down and help less
    technically-savvy members of
    society.

    View Slide

  82. And, just like trickle-down
    economics, it doesn’t work.
    —Aral Balkan
    Trickle-down technology
    Calling it the open web is all well and good, but at the
    moment it's more like an open window in the second
    storey and you have to bring your own ladder. It‘s not a
    welcoming, open door.
    noBackend is a great opportunity to help more people
    shape the web. And don't worry about your job and your
    status: It's not a complete replacement for all tech stacks
    ever. It's not a magic solution that aims to make backend
    devs obsolete overnight. Yes, of course traditional
    setups still have their place, if you're a high-traffic web
    app that uses six different types of databases noBackend
    isn't going to make your engineering team vanish. It's
    just one more solution that brings a number of
    promising benefits that are good for the web, good for
    us, good for everyone.
    So, in closing:

    View Slide

  83. WHAT IS NO BACKEND?

    View Slide

  84. WHAT IS NO BACKEND?
    Tech that brings speed, simplicity and
    flexibility to web app development, for
    us and everyone else.

    View Slide

  85. WHAT IS NO BACKEND?
    Tech that liberates and empowers by
    simplifying and lowering barriers of
    entry

    View Slide

  86. WHAT IS NO BACKEND?
    Tech that distributes applications and
    kills data silos

    View Slide

  87. WHAT IS NO BACKEND?
    Tech that can make the web the platform
    for entry-level general purpose
    computing and learning about code

    View Slide

  88. WHAT IS NO BACKEND?
    Tech that requires us to think more like
    product managers and designers, so we
    can build good experiences for other
    humans
    All of these things are good things.
    It is our job to make making the web more accessible to
    more people. That is our power. There is no-one else. If
    we can help people understand it, they can make the
    web. If they make the web, they will care about the web.

    View Slide

  89. The more people care
    about, understand and
    make the web, the better
    off we'll all be.
    The more people care about, understand and make the
    web, the better off we'll all be. Because, as Jeremy Keith
    said yesterday: The web is good for our species. And we
    have to take good care of it.

    View Slide

  90. THANKS!
    Alex Feyerke – @espylaub
    Thank you for your time.

    View Slide