 Dankjewel, Jurke. 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. The financial system user interface is in the first zone. I don't know if anyone worked with that. At any rate that sparked my interest in web frameworks. 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 how I surveyed 80 different web frameworks and tried to see how one can decide what the differences are and the similarities, et cetera. 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. 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 en become very complicated for people to deal with. 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. A 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 are 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 or 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, right? 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 a 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 so that's what I would like to change. What if you could take all of these layers of technology and push it down underneath 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. 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, there's no template language in real at all. 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 widget 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 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? 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 clause 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-liners like that to sign it to 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 hrefs 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. And 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 it's building a complicated widget that uses those things as 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 it's method we add children to it, right? 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. A few 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 en 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. Home page 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. The creation is a little bit delayed. The other thing is the last bit of code there is to say how the user gets transition 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 address's 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. There's also a lot of stuff that you don't need to know. 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 are a wonderful unit of re-youth. It's 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 so 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 sequel. 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 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 ball game from say your traditional graphical user interface platform. 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. 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 too 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 in building a community because this thing is too big for us or let's 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 in Meet go look at the examples, they're on the website join our mailing lists we have one that on which we will only announce new releases so if you don't want to be bothered I 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 a couple of contact details there for anyone any questions 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 for a jungle tutorial and having to write HTML and CSS as well 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 you know with the tools that have evolved there like license and grunt and all of that so that's how we want to make it customizable okay 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 you 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 okay 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 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 to so I'm not really aware of much else obviously we don't have zillions of plugins and things like that but we taking it one step at a time okay 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 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 right 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 hey 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 example for instance the sliding window each time the view and the proposal 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 next question do you plan to be able to execute things on the client by compiling a python code to gs you know there's a lot of exciting stuff happening there at the moment with asmjs 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 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, alright, thank you even thank you