Reahl: The Python-only web framework
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Vosloo, Iwan
Iwan Vosloo - Reahl: The Python-only web framework Reahl is a full-featured web framework with a twist: with Reahl you write a web application purely in Python. HTML, JavaScript, CSS and all those cumbersome web technologies (and a few other lower level concerns) are hidden away from you. As far as web frameworks go this is truly a paradigm shift: away from the cobwebs of all the different web technologies, template languages and low-level details - towards being able to focus on the goals at hand instead, using a single language. In this talk I will give you a brief idea of what Reahl is all about: why it is worthwhile doing, how it works, where we are and what still needs to be done. I hope to convince you that this is an important direction for web frameworks, and of how unique Reahl is. Developing such an abstract framework is an ambitious goal. I'd like to convey the message that what we have achieved so far, and the strategy lessons learnt along the way demonstrate this goal to be realistic and practical.
 Thank you, Yurki. I'm delighted to be here today. It's interesting. One always thinks that we know that the Python community is what makes it what it is today, really, the whole ecosystem. But when you hear, you sort of see up close that it's all the individuals that had their little bit of goodwill to make it. So it's really nice to be able to see that. Before I start a couple of words about myself, I come from far away, South Africa, where I've spent my entire career either programming or working very close to it. Most of that happened in the financial industry. And about 15 years ago, I met Python for the first time. Not long after that, I was part of a team who developed quite a complicated financial system user interface using the first Zope. I don't know if anyone worked with that. At any rate, that sparked my interest in web frameworks. And I started wondering about how things ought to be done and had very idealistic ideas. I started investigating these things. A little while later, I was lucky enough to get a paper published in an academic journal about where I surveyed 80 different web frameworks and tried to see how one can decide what the differences are and the similarities, etc. A little bit while after that, a colleague joined me, Craig. And since then, we've been working on making those idealistic ideals a reality. And that's what I'm going to present to you today. The last version was just over 26,000 lines of code of which 40% are tests, if that's interesting to anyone. Of course, anything like this needs to be funded because you don't really make money from open source software, right? How I do that from my side is I'm lucky enough in the financial industry, what you see is these huge big systems that live for many, many years and grow many thousands of lines of code and become very complicated for people to deal with. So I basically consult on a part-time basis back to some of these companies who allow me to then sit down with teams of programmers and help them to try and improve some of these designs so that these guys can actually deal with them. It's a tricky job, but it's given me kind of a feel for small design issues that over time can become a big problem. And I really like that. Of course, the knowledge that I get there, I try to work into real. And similarly, the knowledge I get in real, where we have complete freedom to do what we want to do, I work back into those environments. Quick overview. I'm going to try and tell you what real is, how it works and why you should care. Those are the important things. Of course, I can't get into too much technical detail. But I'm going to try my best. Please ask me. I think there's a mixed audience here. So if there's something that you don't know, come and talk to me. I am one of those introverted people. So if I'm at a conference like this and I stand outside at a coffee break, I have to work really hard at meeting people. So you will be doing me a favor. I also want to talk a little bit about strategy and our status. And I hope I'm going to do this quickly enough to give us some time for questions, as long as they're simple ones. So what would you expect from a web framework these days? You probably would know that an HTTP request will come in and that the framework must do something to map this to some of your code that's going to execute, where you'll do something like read from a database and eventually use a template language to produce HTML that you send back. On top of this, there's probably all kinds of odds and ends that get added to be able to reuse bits of templates, for example, to be able to deal with CSS. And there's now a big ecosystem in the JavaScript and CSS world, more tools and tools to help you deal with that. What strikes me about this is that it has very much a technology focus. It's almost as if the tools target particular layers of technology that we use. And I don't want that. That's what I would like to change. What if you could take all of these layers of technology and push it down, and indeed, a layer of Python that allows you to actually just think in terms of and focus on what you're actually building and not on all the different bits of technology that's getting you there? How we think that one ought to do this is, firstly, you need to be able to focus on the different views that your user will have in this application. Also, on the particular user interface elements that are on these pages, and how the user gets to move in between the different views. And something like the button that I've got in here is we will take care of that by implementing behind that Python clause a vertical slice of all these technologies just for that button. I hope to explain that a little bit better. Firstly, so there's no template language in real at all. So what is a page then? Well, a page is a widget. And how you will build it is you will compose your own page, your own widgets, by adding other widgets to it as children, just like they do in GUI frameworks most often. There's another trick to this that I won't have time to talk about though, and that's layout, because you also want to add them in particular places and be responsive and all of that. We do care about that. But here's a simple, very, very simple example of how you can compose widgets or a more complicated widget from a simple one. Our most simplest widgets are actually one-to-one corresponding to HTML elements. And in this example, we create a div, and we add a child to it, which is a paragraph, and you see what it will result in what you would probably expect in a browser, right? But simple examples like that can confuse you, because widgets are very, very much not HTML. There are a lot more. This example shows what we call a sliding panel. It's actually three different divs. And it only shows one at a time. We've zoomed in quite a lot, so the controls are quite big. What happens, obviously, in JavaScript, it switches between different panels, and if you click on those controls, you can control when it switches and in what direction, et cetera. Just take a moment to think what it would take you to build something like this. You'd probably build some HTML. You'd probably get a JavaScript plug-in. There are a couple of different things that you're going to have to think of. Here's what it will look like in real. So you create a sliding panel class, because that's what you want on your screen, right? And you add a div to it as a panel. All our add methods actually return what they added, so it just makes it easy to write one line is like that, assign it to a variable, and then you add a div to it. It's a variable, and then we can add other widgets to that thing, and that's all there is to it. The rest can just happen for you. There's actually more to it than that, though, because look at this example. It's still the same thing, but what we've done here is we have switched JavaScript off completely, and it's still working. Obviously, it's degraded a bit. Nothing happens automatically, but you can still click on those controls to make it move. To make something like this work, you can probably guess that, oh, you just add a query string to the URLs, the H raves that are behind those controls. But if the user now clicks on one of these things, it's obviously going to run to the server, and the server must now have logic that will allow it to render the HTML differently with a different div showing. So there's some server-side logic necessary for this to happen. That's what we can do. On top of the technologies, we've also added ways for us behind a Python class, like sliding panel that you can see there, to do other things, like add URLs to your app. Doesn't matter on which view you're actually using these widgets. To add query string parameters. To add server-side logic that happens. Of course, building a complicated widget that uses those things is something other people could also use, but we haven't documented things up to that level yet. So for now, we just like hiding it. Something that you that's probably might throw you, if you don't know about this, has to do with how long widgets live. I just want to show you one example. The red area there, we've decided when we built this particular example that that is a widget, the heading with all the addresses in it. And we called it address book panel. I want to show you what that code looks like. So an address book panel is a div. And in its init method, we add children to it. We add a heading, we query the database, and we add an address box for each address that we find in the database. This should get you thinking, what if the database changes? How does this widget actually change? And the answer is it doesn't, because it doesn't live long enough for it to matter. Widgets are created when a user requests a page in the beginning of the request. They do their job, whether it's rendering or doing server-side logic, and they kill at the end of the page again. That's really all there is to it. The other two things that I said we want to focus upon, firstly, is what views there are in your application. And secondly, how a user moves around between these things. Let's look at how you define a user interface. A user interface is an application in real. In this case, you'll inherit from user interface. You'll have a special method called assemble, in which you can define all the views and execute all kinds of code. In this case, we have two views. You'll see the first one gets defined on slash with the title, and we set a particular widget as its page. There are other ways to do this, but I wanted to show you only the simplest examples. Homepage is a widget like any other. Funny thing, though, we don't construct the widget here. We create a factory for it, because we want the framework only to create all these widgets, depending on which view you're going to be visiting. So the creation is a little bit delayed. The other thing is the last bit of code there is to say how the user gets transitioned between these different views. Well, what it basically says is that if you are on the add view and the user clicks on a button that triggers the save event on the server, then the user will be moved to the Addresses view again. So that's what we wanted to make clear in our code. I'm going to change gears quickly and spend a little bit of time trying to convince you that you should care about this. I can talk for days about this, right? So these are the things that I thought are important. First of all, if you can forget the technical details, then you can actually focus on the menus and the layouts and the stuff that you really care about in your application. And I think this makes a difference in the quality of what you can build. It's also a lot of stuff that you don't need to know. And I'm lazy, so I want to know as little as possible. And that's why I try to build this. The other thing is Python classes. All those words you see up there are Python classes. They're a wonderful unit of re-use. It's probably much, much better than anything you can do with template languages and includes and macros and things. We try to leverage that as much as we possibly can. And because we can do that, we can actually deal with other subtle problems that sometimes crop up. For example, and we haven't done this one yet, but we will, there's this small little issue of someone who double clicks on a button instead of clicking on it. And then your server receives two post requests. Have you ever dealt with something like that? How do you sort that out? Do you really need to worry about that yourself? Or can you just create a button and have it be happening? There are also a couple of complicated requirements that are difficult to do in a reusable way otherwise. What you see here is a table. It's got a list of all the speakers at EuroPython. There are, I think, just over 200 of them. And in this particular example, we wanted to display only three of them at a time in this table. Obviously, you don't want to actually get all the speakers, info, all 200 of them, to be able to do everything that you see here in JavaScript. The only way for you to be able to only get three at a time, for example, would again be to have some server-side logic. And here, we can package it in one thing, a Python class that has the server-side logic and it has the JavaScript and even the styling. In this particular example, we can actually sort as well. And when we sort this table, it's sorted server-side. So it's the entire table that gets sorted, not just what you see there. You guys have to help me create a new buzzword today. I've searched Google and I don't find the word no HTML. And there's a word no SQL. I thought, please do something, tweet, create a word for us here. There are quite a couple of frameworks that are playing with this idea that they want to get away from HTML. They've got different focuses, different ways of doing it. The only thing that I saw that's sort of similar between all of them is that they all have funny names. But when I talk about strategy, I need to think about how to differentiate real from all these others. So I'm going to tell you a couple of things about strategy with that hat on. Real also, if you sort of get into the details of how it works, you'll see that it actually works quite a lot more than like the mainstream frameworks that you're used to, as opposed to these other guys. They generate a lot of code. We don't. Things like that. So firstly, we like to maintain the web semantics. We're writing a web framework. We're not writing a GUI framework. And we like certain things about web interfaces, like you have tab browsing, bookmarks, things like that. We also want to support the ideals of the web, things like the fact that if someone switches off the JavaScript in the browser, that your framework will still continue working. You might think this is not a big deal, but it helps a lot with bots and crawlers, for example. But there are other usages for it as well. Things like device independence, responsive designs, accessibility, stuff like that. There's a whole lot of knowledge out there about these things. The other thing that we are quite adamant about is if you look at the web world, the platform that the web gives you, it's a lot different to what GUIs look like. We've got multiple servers to balance load. We've got multiple clients that serve at the same time. We've got distributed execution, some of it happening on the service, some of it happening on the clients, different devices. So it's quite a different ballgame from, say, your traditional graphical user interface platform. And we think it's not a good idea to take an existing graphical user interface framework API and pretend to do exactly that on the web. We rather want to grow from the bottom up in this environment and provide you with an abstraction that's very high level, but grown in this particular environment so that we can learn from it. We also aim for higher level issues, like this particular one, which already is implemented. You can actually mark a particular method on a class and give it some code by which it can decide whether the current user is allowed to execute this method or not. And the framework will automatically figure out, if I'm not able to execute that method, that the button it's attached to should be grayed out or not visible, things like that. Because we don't generate code, we can actually use all the methods that have grown over time with current web frameworks. And this is a nice example of that. On the left side, you see what we currently have, an example that we've got there. And you see that we've cobbled together some styling there all by ourselves. On the right is the version that will come out next, which makes use of Bootstrap. And you can see the difference. It's different when you have professionals who focus on something and you can make use of their tools and you can make use of their knowledge about what sort of widgets should exist in the world and how things should be displayed. We try to use that as much as possible. A quick word on status. You know, many years ago, we had this idea, this dream. And a dream is a funny thing. It's sort of you see it from afar. It's like a place you want to get to far away on a mountain. It's difficult to describe to other people. You don't see it clearly. You don't know how you're going to get there. You don't know what obstacles await. It's not as if you can just create a project plan and do it and get there, right? There's a lot of risk involved. And I think what we have accomplished up to now is we've built a foundation that shows you that this is not idealistic. It's not impossible. We've implemented all the important features. The risk has gone down very, very much. And we've got something concrete that you can play with so that you can get an idea for what this dream was about and what we're heading towards. Of course, the road is not quite finished yet. We've got a lot still to do. There are a couple of things you won't be able to do with real that you could currently do with other web frameworks. We need to work on it to get those things done as well. We need to add more widgets with bells and whistles, things like that. But we also need to get people interested and build a community because this thing is too big for us. Or let me say, our dream for how big it could get is much bigger than the resources we have available. So that's why I'm here today to get some of you involved. So this is a dream and you're invited. There are a couple of things you can do. First of all, what I've given you here today, you probably need a lot more details and meet. Go look at the examples. They're on the website. Join our mailing lists. We have one that's on which we will only announce new releases. So if you don't want to be bothered and only want to know when something new happens, please go and join that. It's a little bit more effort, I suppose, to install something. But please go for it. Play with it. If you've installed it, you can follow our tutorial. We will be very, very glad to help anyone who struggles with whatever. And in that tutorial, we really explain a lot more detail and a lot of the flexibilities and more complicated use cases. And of course, we need people to help. And there are many different ways people can help. We need marketing people. We need programmers. We need all sorts, because we're going to have to grow up from where we are now into the future. That's all. Thank you. Couple of contact details there for anyone. Any questions? Hi, thanks for the talk. Just this morning, I saw the keynote about education. And that's probably an aspect that you didn't consider at all. It somehow jumped to me just a minute ago, because focusing on only one technology, on only Python, might make it especially easy for beginners to grasp also web technologies. So do you think that maybe on the education level, this could have a go? I'm not quite sure. Do you think that are you asking whether it would be easier for beginners to write websites? Or do you feel that because we're hiding so many things, they won't get a chance to be exposed to what we're hiding? Just repeat, please. Well, I think the first thing that you said was a good thing, because there is a lot hidden. The HTML probably is produced at some point, and the CSS is produced. And because of hiding that, I do feel that it is easier to start up. I can imagine that maybe for, I don't know, 15-year-old using just one technology from one tutorial would be easier than going through a Django tutorial and having to write HTML and CSS as well. OK, I understand. Yes, it's not something we really considered, but we want to make things easy for ourselves as well. Thank you. Hi, thanks. How easy it is to plug in like CSS or something to style the website that you're generating? At the moment, what we're working on, the next version that we'll release will make use of Bootstrap. And what we want to do is more and more allow you to customize the Bootstrap, that whole JavaScript environment with the tools that have evolved there, like less and sass and grunt and all of that. So that's how we want to make it customizable. So is it easy, are there a lot of examples on how you can do this? At the moment, we don't have that. At the moment, if you want to customize CSS, we basically just say, here's how you add a link to your own CSS, and then you write your own CSS. But that's what we want to do with the next release, to make it based on Bootstrap. And I don't know if you know Bootstrap at all. There, it's pretty easy to change things because you just set a lot of variables, and it looks different. OK, thanks. I'm just going to stop on the way here. Hi, you mentioned some things you couldn't do with really yet, which can be done with other web frameworks. Can you give an example for that? The most important one for me, there's a book. It's been on the internet for a while called Web User Interface Design Patterns. I don't know if you know that. We want to try and follow those design patterns. One of them is called Responsive Disclosure in this book. It's when you have a form, and you select something, and based on that selection, more of the form appear, and so on. At the moment, you won't be able as a user to do that. That's actually the very first one we want to target, because we feel that's a very important thing. So we sort of have an idea how we're going to get there. But currently, as a user who don't know much about the framework, you won't be able. So I'm not really aware of much else. Obviously, we don't have zillions of plugins and things like that, but we're taking it one step at a time. OK, my question would be that there's been some discussion about the performance of different template rendering engines that's been going on. And you're not really doing the same thing, but have you looked at performance? How long does it take to speed out the actual HTML from your objects? You know? My stance on performance might shock you a little bit, because I feel that you have to first optimize, and then you can optimize. First, not optimize, profile, and then you can optimize. And I think you can do that best when the actual model of how this thing works is better fleshed out. So we want to concentrate on that. There are some things that we have done for performance, and they usually mean that things that are dynamically generated get cached. But you must understand, think of something like assembly language. It's really, really fast. OK, but you do prefer Python. So there's a trade-off. Sure. Any more questions? Does all computation are done on the server side? Because you show examples, for instance, with the sliding window. Each time the view and the reposal change, is there a request to the server? When we do Ajax, usually there is a request to the server, because we would like for the HTML to only be generated on the server using the same stuff. If we do Ajax, for example, we won't reload the entire page, but we'll just render one widget server side and come back. OK, now I have another question. Do you plan to be able to execute things on the client by compiling a Python code to GES? You know, there's a lot of exciting stuff happening there at the moment with Asm.js and all sorts of things. I think that's too far in our future to worry about now. It would be nice. Like regular expressions in Python are different to regular expressions in JavaScript. And it's difficult to deal with that sometimes. But it's certainly something one needs to think about, but not right now. Do we have any more questions? No? All right. Thank you, Ivan. Thank you.
 Thank you, Yurki.  I'm delighted to be here today.  It's interesting.  One always thinks that we know that the Python community is  what makes it what it is today, really, the whole ecosystem.  But when you hear, you sort of see up close that it's all  the individuals that had their little bit of goodwill to make it.  So it's really nice to be able to see that.  Before I start a couple of words about myself,  I come from far away, South Africa, where I've spent my  entire career either programming or working very close to it.  Most of that happened in the financial industry.  And about 15 years ago, I met Python for the first time.  Not long after that, I was part of a team who developed quite a  complicated financial system user interface using the first  Zope.  I don't know if anyone worked with that.  At any rate, that sparked my interest in web frameworks.  And I started wondering about how things ought to be done and  had very idealistic ideas.  I started investigating these things.  A little while later, I was lucky enough to get a paper  published in an academic journal about where I surveyed 80  different web frameworks and tried to see how one can decide  what the differences are and the similarities, etc.  A little bit while after that, a colleague joined me, Craig.  And since then, we've been working on making those idealistic  ideals a reality.  And that's what I'm going to present to you today.  The last version was just over 26,000 lines of code of which  40% are tests, if that's interesting to anyone.  Of course, anything like this needs to be funded because you  don't really make money from open source software, right?  How I do that from my side is I'm lucky enough in the  financial industry, what you see is these huge big systems  that live for many, many years and grow many thousands of  lines of code and become very complicated for people to deal  with.  So I basically consult on a part-time basis back to some  of these companies who allow me to then sit down with teams of  programmers and help them to try and improve some of these  designs so that these guys can actually deal with them.  It's a tricky job, but it's given me kind of a feel for small  design issues that over time can become a big problem.  And I really like that.  Of course, the knowledge that I get there, I try to work into  real.  And similarly, the knowledge I get in real, where we have  complete freedom to do what we want to do, I work back into  those environments.  Quick overview.  I'm going to try and tell you what real is, how it works and  why you should care.  Those are the important things.  Of course, I can't get into too much technical detail.  But I'm going to try my best.  Please ask me.  I think there's a mixed audience here.  So if there's something that you don't know, come and talk to  me.  I am one of those introverted people.  So if I'm at a conference like this and I stand outside at a  coffee break, I have to work really hard at meeting people.  So you will be doing me a favor.  I also want to talk a little bit about strategy and our status.  And I hope I'm going to do this quickly enough to give us  some time for questions, as long as they're simple ones.  So what would you expect from a web framework these days?  You probably would know that an HTTP request will come in  and that the framework must do something to map this to some  of your code that's going to execute, where you'll do  something like read from a database and eventually use a  template language to produce HTML that you send back.  On top of this, there's probably all kinds of odds and  ends that get added to be able to reuse bits of templates,  for example, to be able to deal with CSS.  And there's now a big ecosystem in the JavaScript and CSS  world, more tools and tools to help you deal with that.  What strikes me about this is that it has very much a  technology focus.  It's almost as if the tools target particular layers of  technology that we use.  And I don't want that.  That's what I would like to change.  What if you could take all of these layers of technology  and push it down, and indeed, a layer of Python that allows  you to actually just think in terms of and focus on what  you're actually building and not on all the different bits  of technology that's getting you there?  How we think that one ought to do this is, firstly, you need  to be able to focus on the different views that your  user will have in this application.  Also, on the particular user interface elements that are on  these pages, and how the user gets to move in between the  different views.  And something like the button that I've got in here is we  will take care of that by implementing behind that Python  clause a vertical slice of all these technologies just for  that button.  I hope to explain that a little bit better.  Firstly, so there's no template language in real at all.  So what is a page then?  Well, a page is a widget.  And how you will build it is you will compose your own page,  your own widgets, by adding other widgets to it as children,  just like they do in GUI frameworks most often.  There's another trick to this that I won't have time to talk  about though, and that's layout, because you also want to  add them in particular places and be responsive and all of  that.  We do care about that.  But here's a simple, very, very simple example of how you  can compose widgets or a more complicated widget from a  simple one.  Our most simplest widgets are actually one-to-one  corresponding to HTML elements.  And in this example, we create a div, and we add a child to  it, which is a paragraph, and you see what it will result in  what you would probably expect in a browser, right?  But simple examples like that can confuse you, because  widgets are very, very much not HTML.  There are a lot more.  This example shows what we call a sliding panel.  It's actually three different divs.  And it only shows one at a time.  We've zoomed in quite a lot, so the controls are quite  big.  What happens, obviously, in JavaScript, it switches between  different panels, and if you click on those controls, you  can control when it switches and in what direction, et cetera.  Just take a moment to think what it would take you to  build something like this.  You'd probably build some HTML.  You'd probably get a JavaScript plug-in.  There are a couple of different things that you're  going to have to think of.  Here's what it will look like in real.  So you create a sliding panel class, because that's what  you want on your screen, right?  And you add a div to it as a panel.  All our add methods actually return what they added, so it  just makes it easy to write one line is like that, assign it  to a variable, and then you add a div to it.  It's a variable, and then we can add other widgets to that  thing, and that's all there is to it.  The rest can just happen for you.  There's actually more to it than that, though, because look  at this example.  It's still the same thing, but what we've done here is we  have switched JavaScript off completely, and it's still  working.  Obviously, it's degraded a bit.  Nothing happens automatically, but you can still click on  those controls to make it move.  To make something like this work, you can probably guess  that, oh, you just add a query string to the URLs, the H  raves that are behind those controls.  But if the user now clicks on one of these things, it's  obviously going to run to the server, and the server must  now have logic that will allow it to render the HTML  differently with a different div showing.  So there's some server-side logic necessary for  this to happen.  That's what we can do.  On top of the technologies, we've also added ways for us  behind a Python class, like sliding panel that you can  see there, to do other things, like  add URLs to your app.  Doesn't matter on which view you're actually using these  widgets.  To add query string parameters.  To add server-side logic that happens.  Of course, building a complicated widget that uses  those things is something other people could also use, but  we haven't documented things up to that level yet.  So for now, we just like hiding it.  Something that you that's probably might throw you, if  you don't know about this, has to do with how long  widgets live.  I just want to show you one example.  The red area there, we've decided when we built this  particular example that that is a widget, the heading with  all the addresses in it.  And we called it address book panel.  I want to show you what that code looks like.  So an address book panel is a div.  And in its init method, we add children to it.  We add a heading, we query the database, and we add an  address box for each address that we find in the database.  This should get you thinking, what if the database changes?  How does this widget actually change?  And the answer is it doesn't, because it doesn't live long  enough for it to matter.  Widgets are created when a user requests a page in the  beginning of the request.  They do their job, whether it's rendering or doing  server-side logic, and they kill at the end of the page  again.  That's really all there is to it.  The other two things that I said we want to focus upon,  firstly, is what views there are in your application.  And secondly, how a user moves around between these things.  Let's look at how you define a user interface.  A user interface is an application in real.  In this case, you'll inherit from user interface.  You'll have a special method called assemble, in which you  can define all the views and execute all kinds of code.  In this case, we have two views.  You'll see the first one gets defined on slash with the  title, and we set a particular widget as its page.  There are other ways to do this, but I wanted to show you  only the simplest examples.  Homepage is a widget like any other.  Funny thing, though, we don't construct the widget here.  We create a factory for it, because we want the framework  only to create all these widgets, depending on which view  you're going to be visiting.  So the creation is a little bit delayed.  The other thing is the last bit of code there is to say how  the user gets transitioned between these different views.  Well, what it basically says is that if you are on the add  view and the user clicks on a button that triggers the save  event on the server, then the user will be moved to the  Addresses view again.  So that's what we wanted to make clear in our code.  I'm going to change gears quickly and spend a little bit  of time trying to convince you that you should care about  this.  I can talk for days about this, right?  So these are the things that I thought are important.  First of all, if you can forget the technical details, then  you can actually focus on the menus and the layouts and the  stuff that you really care about in your application.  And I think this makes a difference in the quality of  what you can build.  It's also a lot of stuff that you don't need to know.  And I'm lazy, so I want to know as little as possible.  And that's why I try to build this.  The other thing is Python classes.  All those words you see up there are Python classes.  They're a wonderful unit of re-use.  It's probably much, much better than anything you can do  with template languages and includes and macros and things.  We try to leverage that as much as we possibly can.  And because we can do that, we can actually deal with other  subtle problems that sometimes crop up.  For example, and we haven't done this one yet, but we will,  there's this small little issue of someone who double clicks  on a button instead of clicking on it.  And then your server receives two post requests.  Have you ever dealt with something like that?  How do you sort that out?  Do you really need to worry about that yourself?  Or can you just create a button and have it be happening?  There are also a couple of complicated requirements  that are difficult to do in a reusable way otherwise.  What you see here is a table.  It's got a list of all the speakers at EuroPython.  There are, I think, just over 200 of them.  And in this particular example, we wanted to display only three  of them at a time in this table.  Obviously, you don't want to actually get all the speakers,  info, all 200 of them, to be able to do everything  that you see here in JavaScript.  The only way for you to be able to only get three at a time,  for example, would again be to have some server-side logic.  And here, we can package it in one thing, a Python class  that has the server-side logic and it has the JavaScript  and even the styling.  In this particular example, we can actually sort as well.  And when we sort this table, it's sorted server-side.  So it's the entire table that gets sorted,  not just what you see there.  You guys have to help me create a new buzzword today.  I've searched Google and I don't find the word no HTML.  And there's a word no SQL.  I thought, please do something, tweet,  create a word for us here.  There are quite a couple of frameworks  that are playing with this idea that they want to get away  from HTML.  They've got different focuses, different ways of doing it.  The only thing that I saw that's sort of similar  between all of them is that they all have funny names.  But when I talk about strategy, I  need to think about how to differentiate real  from all these others.  So I'm going to tell you a couple of things about strategy  with that hat on.  Real also, if you sort of get into the details of how it works,  you'll see that it actually works quite a lot more than like  the mainstream frameworks that you're used to,  as opposed to these other guys.  They generate a lot of code.  We don't.  Things like that.  So firstly, we like to maintain the web semantics.  We're writing a web framework.  We're not writing a GUI framework.  And we like certain things about web interfaces,  like you have tab browsing, bookmarks, things like that.  We also want to support the ideals of the web,  things like the fact that if someone switches off  the JavaScript in the browser, that your framework will still  continue working.  You might think this is not a big deal,  but it helps a lot with bots and crawlers, for example.  But there are other usages for it as well.  Things like device independence, responsive designs,  accessibility, stuff like that.  There's a whole lot of knowledge out there about these things.  The other thing that we are quite adamant about  is if you look at the web world, the platform  that the web gives you, it's a lot different  to what GUIs look like.  We've got multiple servers to balance load.  We've got multiple clients that serve at the same time.  We've got distributed execution, some of it  happening on the service, some of it  happening on the clients, different devices.  So it's quite a different ballgame  from, say, your traditional graphical user interface  platform.  And we think it's not a good idea to take an existing  graphical user interface framework API  and pretend to do exactly that on the web.  We rather want to grow from the bottom up in this environment  and provide you with an abstraction that's very high  level, but grown in this particular environment  so that we can learn from it.  We also aim for higher level issues,  like this particular one, which already is implemented.  You can actually mark a particular method on a class  and give it some code by which it  can decide whether the current user is  allowed to execute this method or not.  And the framework will automatically  figure out, if I'm not able to execute that method,  that the button it's attached to should be grayed out  or not visible, things like that.  Because we don't generate code, we  can actually use all the methods that have grown over time  with current web frameworks.  And this is a nice example of that.  On the left side, you see what we currently  have, an example that we've got there.  And you see that we've cobbled together some styling there  all by ourselves.  On the right is the version that will come out next, which  makes use of Bootstrap.  And you can see the difference.  It's different when you have professionals who focus on something  and you can make use of their tools  and you can make use of their knowledge about what sort of  widgets should exist in the world  and how things should be displayed.  We try to use that as much as possible.  A quick word on status.  You know, many years ago, we had this idea, this dream.  And a dream is a funny thing.  It's sort of you see it from afar.  It's like a place you want to get to far away on a mountain.  It's difficult to describe to other people.  You don't see it clearly.  You don't know how you're going to get there.  You don't know what obstacles await.  It's not as if you can just create a project plan  and do it and get there, right?  There's a lot of risk involved.  And I think what we have accomplished up to now  is we've built a foundation that shows you  that this is not idealistic.  It's not impossible.  We've implemented all the important features.  The risk has gone down very, very much.  And we've got something concrete that you can play with  so that you can get an idea for what this dream was about  and what we're heading towards.  Of course, the road is not quite finished yet.  We've got a lot still to do.  There are a couple of things you won't be able to do with real  that you could currently do with other web frameworks.  We need to work on it to get those things done as well.  We need to add more widgets with bells and whistles,  things like that.  But we also need to get people interested  and build a community because this thing is too big for us.  Or let me say, our dream for how big it could get  is much bigger than the resources we have available.  So that's why I'm here today to get some of you involved.  So this is a dream and you're invited.  There are a couple of things you can do.  First of all, what I've given you here today,  you probably need a lot more details and meet.  Go look at the examples.  They're on the website.  Join our mailing lists.  We have one that's on which we will only announce new releases.  So if you don't want to be bothered  and only want to know when something new happens,  please go and join that.  It's a little bit more effort, I suppose,  to install something.  But please go for it.  Play with it.  If you've installed it, you can follow our tutorial.  We will be very, very glad to help anyone who  struggles with whatever.  And in that tutorial, we really explain a lot more detail  and a lot of the flexibilities and more complicated use cases.  And of course, we need people to help.  And there are many different ways people can help.  We need marketing people.  We need programmers.  We need all sorts, because we're going  to have to grow up from where we are now into the future.  That's all.  Thank you.  Couple of contact details there for anyone.  Any questions?  Hi, thanks for the talk.  Just this morning, I saw the keynote about education.  And that's probably an aspect that you didn't consider at all.  It somehow jumped to me just a minute ago,  because focusing on only one technology, on only Python,  might make it especially easy for beginners  to grasp also web technologies.  So do you think that maybe on the education level,  this could have a go?  I'm not quite sure.  Do you think that are you asking whether it would be easier  for beginners to write websites?  Or do you feel that because we're hiding so many things,  they won't get a chance to be exposed to what we're hiding?  Just repeat, please.  Well, I think the first thing that you said was a good thing,  because there is a lot hidden.  The HTML probably is produced at some point, and the CSS is  produced.  And because of hiding that, I do feel that it is easier  to start up.  I can imagine that maybe for, I don't know, 15-year-old using  just one technology from one tutorial would be easier  than going through a Django tutorial and having  to write HTML and CSS as well.  OK, I understand.  Yes, it's not something we really considered,  but we want to make things easy for ourselves as well.  Thank you.  Hi, thanks.  How easy it is to plug in like CSS or something  to style the website that you're generating?  At the moment, what we're working on,  the next version that we'll release  will make use of Bootstrap.  And what we want to do is more and more  allow you to customize the Bootstrap, that whole JavaScript  environment with the tools that have evolved there,  like less and sass and grunt and all of that.  So that's how we want to make it customizable.  So is it easy, are there a lot of examples  on how you can do this?  At the moment, we don't have that.  At the moment, if you want to customize CSS,  we basically just say, here's how you add a link to your own CSS,  and then you write your own CSS.  But that's what we want to do with the next release,  to make it based on Bootstrap.  And I don't know if you know Bootstrap at all.  There, it's pretty easy to change things because you just  set a lot of variables, and it looks different.  OK, thanks.  I'm just going to stop on the way here.  Hi, you mentioned some things you couldn't do with really  yet, which can be done with other web frameworks.  Can you give an example for that?  The most important one for me, there's a book.  It's been on the internet for a while called Web User  Interface Design Patterns.  I don't know if you know that.  We want to try and follow those design patterns.  One of them is called Responsive Disclosure in this book.  It's when you have a form, and you select something,  and based on that selection, more of the form appear,  and so on.  At the moment, you won't be able as a user to do that.  That's actually the very first one we want to target,  because we feel that's a very important thing.  So we sort of have an idea how we're going to get there.  But currently, as a user who don't know much about the  framework, you won't be able.  So I'm not really aware of much else.  Obviously, we don't have zillions of plugins and  things like that, but we're taking it one step at a time.  OK, my question would be that there's been some  discussion about the performance of different  template rendering engines that's been going on.  And you're not really doing the same thing, but have you  looked at performance?  How long does it take to speed out the actual HTML from  your objects?  You know?  My stance on performance might shock you a little bit,  because I feel that you have to first optimize, and then  you can optimize.  First, not optimize, profile, and then you can optimize.  And I think you can do that best when the actual model of  how this thing works is better fleshed out.  So we want to concentrate on that.  There are some things that we have done for performance,  and they usually mean that things that are dynamically  generated get cached.  But you must understand, think of something like  assembly language.  It's really, really fast.  OK, but you do prefer Python.  So there's a trade-off.  Sure.  Any more questions?  Does all computation are done on the server side?  Because you show examples, for instance, with the sliding  window.  Each time the view and the reposal change, is there a  request to the server?  When we do Ajax, usually there is a request to the server,  because we would like for the HTML to only be generated on  the server using the same stuff.  If we do Ajax, for example, we won't reload the entire page,  but we'll just render one widget server side and come back.  OK, now I have another question.  Do you plan to be able to execute things on the client by  compiling a Python code to GES?  You know, there's a lot of exciting stuff happening  there at the moment with Asm.js and all sorts of things.  I think that's too far in our future to worry about now.  It would be nice.  Like regular expressions in Python are different to  regular expressions in JavaScript.  And it's difficult to deal with that sometimes.  But it's certainly something one needs to think about, but  not right now.  Do we have any more questions?  No?  All right.  Thank you, Ivan.  Thank you.
Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_0_383.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_384_671.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_672_995.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_996_4787.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_4788_5255.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_5256_5375.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_5376_5507.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_5508_5939.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_5940_7175.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_7176_7595.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_7596_9215.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_9216_9911.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_9912_10703.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_10704_10883.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_10884_11087.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_11088_11135.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_11136_11399.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_11400_11987.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_11988_12479.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_12480_12911.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_12912_13187.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_13188_13367.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_13368_13703.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_13704_13967.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_13968_15479.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_15480_16151.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_16152_17351.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_17352_17627.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_17628_19823.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_19824_19919.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_19920_20099.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_20100_22451.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_22452_25727.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_25728_26123.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_26124_28583.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_28584_29459.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_29460_30671.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_30672_35219.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_35220_35567.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_35568_41639.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_41640_42335.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_42336_43439.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_43440_45143.png Iwan_Vosloo_-_Reahl__The_Python-only_web_framework_45144_46872.png