 Hi everybody, how you guys doing good nice big lunch How's the food good food amazing, right? I'm stuffed Should have a little aerobics routine before we start this just to get people to shake up a little bit That is Harris people who saw him dance yesterday, but watch for that. Yeah, he's coming good So just a quick poll here. How many people here have heard of or are familiar with class Django web guppy by Excellent. This is great. We've got a large group here of people who are into web So hopefully we'll have a very exciting discussion here passionate discussion One thing I want to mention is since we only have 45 minutes. We've also blocked out Time in the open space on the first floor for four to five So after we finished this discussion, we'll still have time in the open space to sort of dig into more details Or even talk about other frameworks and anything else that we'd like to cover off which may not happen in this 45 minutes So let's just give it another minute. It's almost two and then we'll get started. All right It's two o'clock. I think we're good to get started So guys, let me quickly give you a bit of background about this panel Last year I gave a talk on flask. I don't know it here gave a talk on Django we both had a number of questions around flask and Django and choosing the frameworks and choices and We thought it'd be interesting to have a healthy debate discussing a few of these frameworks and to understand some of the different trade-offs that are involved now many of us are passionate about these frameworks in different ways, although ultimately a tool is a tool It's good to understand the nuances a little better. So we have structured this discussion in a debate format and I'd like to introduce the three panelists that I have here with me First year, this is Kiran who is well known around here Kiran spoke earlier today Kiran is going to be representing an evangelizing flask Kiran that has geek has been using flask for the last several years now and K-tring to a fairly large user base. He's also been having a bit of a midlife crisis at flask So he's going to be sort of bringing up a few points where he's not as happy with flask as well So you'll hear a bit of that as well today and then there's Arum who's all about Django He's Mr. Django. He spoke about Django last year. He spoke about Django's advanced patterns this year and he's an industry recognized expert in Django He's coming out with a book which is going to be published soon on Django advanced patterns So we're again fortunate to have him here Representing Django on this panel and finally we have our own Anand Anand is representing WebDoc PY. Some of you who were here yesterday evening might have attended the video on Aaron Schwartz, the story of his life So WebDoc PY is roots and I'll let Anand that I want to steal his thunder here But Anand is a co-author of WebDoc PY and he's collaborated from the early days with Aaron Schwartz So here's a story I think we'll hear from someone who's been there from the early part as a co-author of WebDoc PY and currently being a Maintainer as well as WebDoc PY. He collaborated with Aaron Schwartz on the infogami and open library So that's a bit about the three of them. I'm RV. I'll be moderating the discussion and With the format we'll go through a series of three rounds of discussion Which will hopefully cater to beginners intermediate and advanced users and like I mentioned earlier beyond that We'll take some discussions over to cover them off in the open space so three frameworks three evangelists three rounds of debate and We'll accommodate time for about three audience questions. Maybe a little more time permitting and I'd encourage you if possible to send in questions via the hash by corn India Twitter hashtag if you can if not This craze and Konark the two of them here have coordinated to set up paper slips over here I think there's some paper slips here and craze are there where else are they kept all the paper slips are kept here So if any of you would like to just put down some questions in the interest of time Just put them down in the paper slips craze and Konark would pick them up and then read out some of the questions During the Q&A so don't hesitate to just come up grab a slip anytime during the discussions and put them down there So with that And just just one last little thing We're going to do a round of voting at the end just a little fun session of voting where I miss call voting app You see a bit more of that at the end So the first round of discussion is going to be around This question that I often hear from beginners, which is I am a beginner Which framework should I start off with which framework should I pick to start off my project? I have a new project or a new thing that I'm trying to take up which one should I choose So I'm going to start off here by asking Anand Why would you endorse web dot py is being the framework that someone should choose for starting off if they're building a new app Yeah, I think of think web dot py is good for beginners because It's the learning curve is very simple. It's very it's not It's not difficult to learn web dot py. So web dot py is a simple Python library So I would say any micro framework is good for beginners Okay, so I think web dot py is pretty good because you can also develop database applications pretty easily using web dot py So Kiran we hear the same answer that Anand is I told us about web dot py about flask all the time. Yes So what's the difference here? Both of them are fairly good to start with I would put flask a slightly better in web dot py for this Although this may have changed recently Earlier web dot py would be much easier to work with you simply import web and then you declare your roots and you declare your functions and You're pretty much done Now one of I have concerns with that approach because it basically treats the web module as a global for the application I believe that's been fixed. It's a It's you not create an application context, which is also what you do with flask The thing that I think flask has slightly better going for it to start with is a decorator based approach to declaring roots In that way you create an array of your roots and the regexes that handle these roots and so on and That can be a little confusing once you go beyond the three or four that the example gives you You know the move point you get to the fifth or sixth one. It's a little unclear how you're supposed to be doing this Flask Visually enough does not use regexes for the routings. It basically uses slash separators So it's able to actually sort them no matter how what order you declare them in it'll enter and sort them to find The proper order and so on and what do you have to say to this? So I think You understand what's going on completely okay, but with flask decorators, but we kind of get confused especially for big nuts They say that some kind of magic. We just have to put that and it works. Okay. That's something. I really don't Okay But especially for big nuts, it's a bit confusing Although I would say that for beginners lots of things tend to be confusing What's important is that you have a consistent API, you know that you know that this is exactly what it happens when you do this And that there is no magic involved in it doing something else unexpected all of a sudden And once you get past that point of comfort then you can start digging under the hood to see how did that actually work? you know and Flask routing is not trivial at all once you get under the hood. It's the URL map that it uses is fairly complex I've been doing flask for about four or five years now, and I still don't understand how it works And I can tell you this because I have a bug report or something broken, but I mean has not been able to fix It's been two years since I reported it So I don't do want to jump in here. I mean, how does Django fit in this world? Surround you Django is like the elephant in the room Staggering to compare that I think Django wins in a lot of areas documentation. It's like the most Well-documented web framework out there Qualify that because everyone here is going to say yeah, we've got the best documentation. I mean let me qualify that so it's going to have In terms of a very good tutorial So most of the time when you ask, okay, I want to learn XYZ Where do you go to for Django? The answer is very easy just go to the official tutorial and you learn it Initially, it was just four parts and I think now it's five parts including test to and design and all that So I think it's very beginner friendly and the community is great In fact, if you ask any question if you just type it on Google, you'll probably get the answer on stack overflow or anywhere else There are about 30 odd books on Django They tend to get outdated very fast. So that's a bit of a problem But people are writing new books all the time including me of course And there is I would say throw this in I mean There is a lot of there are a lot of opportunities for people who learn Django in terms of jobs and stuff That has been increasing over the years and I think there is a clear trend for greater and greater jobs So if you're a beginner and you want to focus on something, probably that's one criteria You can take about it. Yeah, it's interesting someone on Twitter Arunatma said same side goal by Kiran and debate goal for web dot PY So any comments that you want to quickly chime in on with respect to Django? Can you repeat the question? Someone on Twitter Arunatma said same side goal by Kiran and debate goal for web dot PY He basically means that I'm This is you know, bitching about flash quality and there's plenty of bitching about flash coming up So I would like to add one thing is It's back in 2006 or 2007 was really desperately looking to learn the web from Using Python, okay, so went and attended training session on Jope and fly a jope and plow numbers sit. I said to be three days and you couldn't get anything out of it Okay, and then I looked at what else I can do when look at the Django started trying to line Django I mean it takes so long to actually get started on something Okay And then it was that time when Arunatma is web dot PY and it tried writing a problem said, ah, that's so simple to use Okay, that's all I got hooked in web dot PY Great. So what do you guys think? Well confused Well, it felt like they were saying the same things in a few points, but differing a little on different points, right? But so let's just step on a little more and see how things get a little more interesting For people who have been using some of these frameworks for a little bit your code base of all this kind of nice You've got a small micro framework things get harder and things are not opinionated. It gets a little more complex So let's say it's someone who's built slightly complex sites or back-ends, right? And they want to know how do you architect and design your apps as they get more complex? And why is your framework best suited for someone whose app is either gaining complexity or someone who's trying to build a new app? Which is slightly complex and I'm going to start here with Kiran Okay, so one of the things that Flask acquired a slightly more recently is this concept called a blueprint Where you separate out part of your functionality into something that's not quite an app but there's a lot like an app and you can plug it into an app and you can reuse it across modules and so on and I've been using that quite a bit to restructure a lot of my apps into Multi-component pieces that you can optionally turn off a component that you don't want at runtime You know and just say just don't report that if you don't want it So and if you guys have been looking at the last user code since yesterday's talk It's basically built as a collection of three blueprints I like the approach it makes it really easy to modelize your code and the other thing is that Flask is Fairly hands-off when it comes to telling you how to structure your code so you Evaluate your own conventions after a while, you know, I have one I have now a skeleton that I use across all my projects and that's something that is A skeleton I've evolved after Realizing that this works for me and for the kind of apps that I write but this is not a skeleton that Flask gives you It's not like Django where you make a project and the project then has an outline ready made for you you know in this case you do it yourself and You get all the flexibility you want when you're doing something like this Yeah, I'm adding blueprints. We have been having that and Django for a couple of years now. So we call it apps So I'm glad that the flask is catching up To the second point I'd like to say that It's good that you have evolved your own style But how about handing it over to another developer? I mean when it comes to Django projects, it's very easy to find out for example There is an exception at accounts dot views dot something and immediately a Django developer understands that okay accounts is the app views is the model view controller view and There's no need to really explain what it is. So when you roll your own that comes with the problems of you know Understanding what your design decisions work? Yes, and when somebody rolls it for you then you have no control over it And that's even more problematic Okay No, I think It's it's that's a trade-off. We are talking about here. So when you start a Django project It's already built for scale. So it's like you're already talking about models being separated from views being separate from templates I mean, I built a Twitter clone in a bottle and I thought it was great until I started writing hundreds and hundreds of lines of code And it's like a nightmare to you know organize it But it's not really a problem when it comes to Django because you know where things go It's like a kitchen shelf where everything is neatly labeled and you know, you just have to put things in the right place That's all you have to worry about So Anand, do you want to throw the kitchen sink at this? So That's not a framework. It's a library Okay, so it doesn't let you it doesn't ask you how it doesn't tell you how you should do things Okay, there's a way the tools that you want that you can use in writing your own application. Okay, so there's a one thing about Django and slightly transcuss the kind of The ways of doing things you should do Excel is related to why okay, but it's just set of tools that you can use to build your stuff. Okay, so So it's a large application. It's all about your discipline Any thoughts on that you'd like to add Kira. Yeah, it's more about what kind of application you're building if it's like a Web server embedded inside your huge application, then probably you don't need to worry too much about, you know, the model view controller separation and stuff like that So I'll call them toy examples if you like to say it I mean, it's it's more like a simple thing which can fit in couple of lines So in the Ruby on Rails world, they have this thing called Sinatra, which you know, it's it's very easy to read In fact, even the HTML code the CSS everything is a part of one file And if you are really having an application that's just fits two screens or three scheme screens Then you probably would like to go for a library approach. You don't really require a framework Yeah, so I'm not saying that doesn't give you anything. Okay, so it has database module You can keep your database things separately. It has to get engine. Okay, so you have all these things, okay? But it doesn't Unfortunately that you have a V dot pi you have no this or pi you have something and that that's the way you start your code Okay, but you still can start your code in all those ways and it has tools for doing it And Anand, do you want to comment about ORMs? I think this is a very opinionated topic So I should go first before this So I used to use web dot pi before flask and I still have production software running on web dot pi Stop using it because the ORM or the lack of one So, okay, so So I've tried to use SQL I can assume it times and then fail, okay? It's so hard to get something started. At least probably I'm not smart enough to get it but Modesty there Really, I've tried several times and then gave up. Okay, so I find it very hard One thing the second thing is With your pi you write SQL okay You'll talk to database in database language But SQL alchemy you write you talk to database in SQL alchemy language, okay? That's true man. You can write SQL in SQL alchemy. It's perfectly happy to accept it Well, so So I think it would be hard for me to I have to get into SQL alchemy version and then start it file it. Okay, because Yeah, so Once something fails in SQL alchemy, you know, SQL alchemy structures, you don't know what's wrong with your query I'd like to pitch into that Probably SQL alchemy is the best ORM among the three. I mean it can handle multiple databases very well legacy databases very well But it's damn hard to use right. I mean it's a tank. Yeah, it's a tank, right? So Django ORM goes for the middle approach. I mean it doesn't try to do everything for you You'll have to step down to SQL when it comes to complex queries, but for those 80 20 principle people It's the 80% use cases which are handled by the Django ORM very well and for 20% of cases here You always have SQL you can step down to Ross. So on that here the question from Twitter a couple of people have asked Which is how does Django play with no SQL databases because it's often perceived to not play well couple of you Have asked that why don't you answer that I don't yeah, I mean it's not one of its strengths But see the way Django is designed is that it has to have a database built in I mean Specified in the settings. So you can't use a no SQL database there. You have to go with something But having said that there are a lot of Django projects, which uses Redis MongoDB or even the Google Bigtable and things like that So it's not impossible. It's just a matter of Not being the philosophy with which it was built for so it was built then for Relational databases. Yeah, I would say and how's its performance with relational databases. What would you say about that? I mean again, it was built specifically for post-christ SQL, right? so that's where the best performance you'll get extract out of it and Coming to the specific question of performance. It has powered one of the larger sites It it is the back-end behind discuss, which is a real-time commenting engine is the back-end behind Instagram So I don't think you will reach a point where you'll be suffocated by the performance issues And do you guys want to chime in on and then Kiran about performance? I'm not sure that's entirely true because Jacob Kaplan mass is known to use SQL alchemy when Django around doesn't work for him And he's a guy who created Django RM and he admits this publicly So if the creator of Django RM says it's not good enough for him. It certainly is not good enough for the rest of the world Come on Yeah Or is a leaky abstraction, right? There is no perfect orm which can replicate every SQL scenario at the end of the day There will be some 10% scenario where you have to step down to SQL Yes, this is the part where I really like working with SQL alchemy because it's not a framework It's like to use a cliche SQL alchemy. Let's you work at the high level You want to use the ORM user do you want to work draw a SQL user? You want to use SQL constructs as functions and basically build a query out of it You use that and the best part is that internally everything works the same way if you talk to the high-level API internally talks to the low-level API So you can bypass the high-level API talk to the low-level API and you get back your result object exactly as you would if you talk to The high-level API and that's beautiful because it basically means that I do not have to worry about saying I'm going to actually ignore all of this and go talk raw database and then deal with raw data coming back from the database You don't have to worry about that. It comes back the way you expected to even if I'd used a high-level API And that's an advantage that I've not seen any other library That's this is basically what makes SQL alchemy is learning curve so high because There are a lot of times you'll find yourself saying that you want to step down into something little deeper and you'll have to figure out how to get to a deeper part because SQL alchemy's documentation is endless I've never ever had to look at SQL alchemy source code to figure out how anything works Everything that you want to know is in the documentation if it's not in the documentation go to stack overflow Michael Himself will come and answer your question for you And that's remarkable. You know, I've never seen a project owner that open to answering any kind of question that anybody throws him I don't need public forum And in general, there is always an answer which equal alchemy Anand, you've been waiting to say something here sir. Should I take over? That works in theory but not in practice So the issue is It works in theory but not in practice Can't change this mic? Yeah, I'm saying it works in theory but not in practice Because you have to define your table schema So I recently started the SQL alchemy project and decided I want to add a JSON type So since it loads When you do select something on a table It tries to get over a thing So it fails somewhere else because it doesn't know how to convert JSON to something else You can fix the problem You can fix it So the problem is not with SQL So I really want to fail if I fail, I won't fail in SQL and I can fix my query You can fix it as a standard API because this is one of the things that most people stumble upon The first time they use SQL alchemy If you do not want to load a column, you simply do it So would you really say it's beginner friendly? It's not. It's most certainly not beginner friendly That's for sure So one problem with SQL alchemy is it makes you feel stupid Every time it gets something, it feels stupid Because it gets into some trouble over and over Also, have you tried to work with caching in SQL alchemy? Yeah How hard it is It's documented See, it's making me feel stupid So I did a small caching library for an app that I built It took me 4 lines of code, it cached everything, all the latest results Now I'm building an app again I thought let me try using flask in SQL alchemy Now I have no clue how hard it's to build caching for it So it's not obvious how to do this because this is the part where you start to get intimately familiar with SQL alchemy's internals Mind you, without ever reading the SQL alchemy source code, I've never done that There was only one point where I had a moment of weakness and I was trying to figure out something that's not in the API But I wanted to know how it works, so I went and looked at the code And I came in enlightened for that and now I use that pattern in my code as well But in general, I found an answer to any kind of problem I've ever had in SQL alchemy But just looking at the documentation, it's all there, it's just so intense, it's like a book Yeah, it is Just to quickly move on to a couple of the questions that are coming on Twitter A few people have asked about how your frameworks deal with enabling people to build REST-based backends And, yeah, why don't you jump in quickly Yeah, I think Django REST framework is considered to be a gold standard when it comes to how well it models a problem domain Which is like models and it maps very correctly to the API So, at the end of the day, we are all talking about SQL and all that But I think we should talk about Python code And when it comes to Django, they are trying to create as simple Python objects as possible I mean, Python syntax as possible There was a branch called Removing the Magic in which they removed all the magic from Django So I would consider Rails to have a lot of magic but Django is very simple, straightforward Python code If you create a Python class which declares, I mean, declaratively specifies your database schema You are good, you can actually create REST APIs out of it, you can create forms out of it You can create generic views out of it So you are saying Django provides much better support for people building REST APIs It's opinionated in some ways but things are well documented It's very Pythonic Very Pythonic In Ireland, declaratory life has blessed Django Battery included Among the web frameworks, I don't know if his opinion still holds good He said about three years back that Django is the preferred, I mean, Guido prefers Django as the web framework So Anand, what about web.py and REST? How is it? So one of the testimonies of web.py is with Django, you write web application in Django With web.py, you write in Python So it doesn't come on your web, it's just like you import any other Python library You import OSS, you import web and start working I mean, it's as natural as that Yeah, but what about building larger applications? I mean, how does that scale? I think I've been building pretty large websites to prepare, I don't think I have any issues in the sense Okay Because that is one thing I wanted to talk about in the first round I mean, there are a lot of beginners out there who think that it's great to learn a micro framework and start writing code and understand the entire flow So understanding Django, it's not very easy to understand where the flow of control flows Since it's spread out over a lot of files But it actually helps you all the way till the end I mean, building a production site For example, I have struggled a lot with SQL injection problems and all sorts of security problems because I didn't know what the hell I was doing when I was simply getting user input and I was just trying to put in a database by using SQL But it so happens that doing that is a very, very bad thing You should not use user input directly into your database or into your templates So on and so forth So all those good stuff is already baked in So you don't make those mistakes So guys, tell me one thing Something like Django, which has been around for a while, appears to have a sizable community When you're growing your app and you start to have a large team around it There's an argument that with Django, it's easier to find new developers Bring them into a project at any point Plus, there's an existing battery-included platform you're working with Whereas with micro-frameworks like Flask or Web.py, where in your case, Kiran, you built up a lot of boilerplate on top of that to support a bunch of things Then you get a bunch of new people into your team and they have no idea that things are different How do you deal with that with a micro-framework or even a library like you call Web.py? So in general, no matter what you do, you will have an onboarding process for anybody who comes on board And I don't think any of us has a corporate environment where it's onboarding free You have to onboard a new person, not just for the framework but for your own code The code that you have may be IP, may be not public, which is the case for most of us And therefore, you don't even have an option to show them the code and how it works until they come onboard You can't do this before the giant What do you have to say about that? Django really wins on this because it's very easy to get people who are trained on Django as well as understand the source code Unfortunately, there was a lack in when it came to large projects which are implemented in Django But python.org, the official python website, is open source now and it's a Django project So anybody who wants to see how a large Django project is implemented can just go and see that So you'll find that it's very comparable to the initial Django project that you create and the large Django projects which are out there And Anand, in this context, we're talking about a library here, so much more boilerplate on top But the large team, how would you manage that? You don't have an answer for this because I'm not working with any large team with that new I I'll treat that as a white flag being raised there Cool, so with this, I just want to step forward to look at the future Like a few questions that people in the audience have asked us What about Pyramid? What about other frameworks that are out there? So I just want to step forward, and these are the guys out there who are saying No, I'm too cool for these kids using Django and Flask I'm on Pyramid or I'm on Tornado or Twisted You guys are out there, I've seen the tweets, I know it So for you guys out here, I want to sort of just look at the future for a minute here And I'd like you guys to talk through and you don't need to support just your framework We're going to talk about what you think the future might be Which frameworks do you think have the most promising future Given the direction of Python, Async, REST, WebSockets Other things that are happening out there And what else do you see that's out there that's emerging That people might need to start to look out for or watch out for? Inside of Python Inside of Python So with Python, I think if you look at the cleanest architecture for any framework, it's Pyramid It's a pity that not enough people use Pyramid And one of the reasons Pyramid is so good and so complicated is that it's like a secret coming It gives you everything, it's up to you to decide which parts you actually want to use And that's a little too overwhelming for a lot of people to start with But Pyramid is a lot more loosely coupled than Django is In Django, you get a lot of things that you may or may not want to use For instance, Django templates for a very long time were known to be really poor at performance And Django 2 was created by someone very upset at Django templates performance And it's been a while until Django 2 became the standard templating system in Django That's what it is now No, it's not It's an option You can replace it Exactly, so one of the things you deal with when Django is You get all of these parts and you do not always want them And then it's a lot of work taking them out of Django And saying I don't want to use this particular part of it Pyramid on the other hand is very nicely designed It's also, and this is one of the advantages that Pyramid has Is that the person maintaining it, Chris McDowell, does this full time for a living With Flask on the other hand, Armin is not a Flask developer full time He works at a game development studio His life passion at this point is making games, not maintaining Flask And this shows in the maintenance quality of Flask That it may be beautifully designed, but it's got a maintainer Who basically is interested in doing this on his weekends Not as a day job Probably I should say that it was started as an April Fool's joke, so Yes, so for something that started as an April Fool's joke It is remarkably solid It's simply got a maintainer problem People took it seriously, yeah So, what do you think, Armin? Coming back to the problems of Django So there is a real effort to remove all the non-essential parts out of Django So commons have been removed A lot of things which are not essential to Django If you know Django, it's called Contrib So a lot of things will be removed in the future as well The maintainer has explicitly stated that Hopefully not admin, which is considered to be USP But a lot of things which are non-essential Will be removed as external libraries which you can optionally use And the future of Django is more in terms of how people define it I actually wrote an article about I was totally wowed by Meteor and JavaScript So I thought Async is going to be the future of web development So everything is going the Async way And Python has this real problem of Whiskey Which is underlying for all three of us right here So Whiskey is the underlying thing which works in the bottom And Whiskey is not really designed for Async programming But Guido is working really hard on that He is trying to create even Python 3's effort towards that direction So I believe Python web frameworks in general need to start thinking In terms of asynchronous programming Of course for the majority of the sites you get to build They are not the cool sites right? I mean there are the crud sites which are the majority of the work we do And they actually require some kind of synchronous programming Just to keep yourself sane Async programming can get really complex to fit in your brain But most of the time you find that there is a real time application need For every application, for every use case you build Even a social network like Facebook Suddenly when a pop comes up, a notification comes up That makes the experience so much richer And everybody can do that Do you see more people moving away from Necessarily using the delayed worker architecture Which we currently use, the Celery or RQ To maybe using this other assembly language Of the web based framework which lets you do everything Async Is it likely we will... I think web sockets and technologies like that changed everything So earlier it was a polling based technology And everything was synchronous actually behind the hood But now we have real Async So like you rightly pointed out Celery is an asynchronous queue But it's not really happening in the request-response cycle So there needs to be a real rethink from ground up How we can handle the request-response cycle bi-directionally Especially when it's coming back when you actually send something I'm actually interested in seeing approaches like Celery and RQ Given less priority than they have right now Because Celery and RQ can bring in their own Ideasing cases to your project That can catch you by surprise because you don't You're not affected by the monthly on production And then it becomes much harder to figure out what just happened And why did this thing stop working It'll be nicer to have Async within a request-response cycle Instead of pushing it outside because that puts you in a place Where it's much easier to debug when something goes wrong And is it easier to debug? Because if you look at the other side of the world outside of Python Where these guys are running these apps in their assembly language Or the web thing, they constantly have to restart the servers Because of all those issues they have running everything in the request cycle So I would say more than that it's easier to put this into a development environment For a simple reason that I use RQ a lot And to run one of my apps, I need to run at least four processes To deal with the various aspects of this process And that just makes it harder for me to work Because I'm constantly tempted to say If I need to fix something and I'm right now not in my development environment Then I'm going to not bother running all the four servers To make sure that the process might just work I'm just going to assume that I know how to write without writing a typo And push it straight to production and let production deal with the breakdown There's too many moving parts Too many moving parts, I guess sadly And obviously production breaks down because it did make a mistake So just one last question If you're going to place a bet on a framework for the future Which one would it be? It doesn't need to be one that you're endorsing If you had to pick one, or is it something which you think has not yet emerged? I'll let Anand go first, Anand I don't think I have an opinion on that So I'm going to put this as a race between Pyramid and Flask Flask wins because of much cleaner documentation Much easier for anyone to figure out how to do things Pyramid wins simply because it has better maintainers What about you, Anand? I put it on Django obviously Not because I'm talking about it But because of the community Because if you look at what is the success behind Python It's all by no means the best programming language in the world But I believe it as one of the best programming language communities So I think that is a strength behind Django as well So a lot of criticism I didn't address that directly It's directed at what comes with Django But Pyramid goes for the best of breeds approach And Django comes with batteries included But it's not necessarily true, right? You can remove some of the batteries And put in whatever you like It's incredibly flexible that way In fact, at DjangoCon they did that Anand, you were about to add something So it's a nice thing that The good thing about Python is the community But also there's one more nice thing about Python Learning Python is very easy And it's incremental You can start learning at the basics And then you can go deep dive deep as long as you want I think that's true again With your blood profile but not other frameworks So it's pretty hard to get a grip of What actually happening inside With other frameworks But Pyre is very simple to understand What's happening inside And I have to just add in here That I ended up looking at some code The code behind Python Express Which all you guys are familiar with Anand is a vision, is initiative Which you just pushed along I ended up looking at it to push a little I sent in a pull request with a little fix It took me very little time to figure out Anand's code using web.ly and jump in there So guys, impressed yet? Yes? No? Yeah? So ultimately right One thing we want to bring out here is The whole objective of this thing here Is to show you that frameworks are ultimately a tool And to bring out the nuances of the choices And there's no right answer one way or the other I do want to sort of open this out now However for audience voting And these are the three numbers that you can call And hopefully my network is going to hold out And we can see something live here Just a second So I'll just read out the numbers as well Just so you guys can hear me If it's Flask called 0-0-3-0-7-5-2-6-9-1 Last digits 2-6-9-2 for Django And 2-6-9-3 for web.py The phone will ring 3-4 times And it will hang up automatically You will not be charged for this call You're not going to be charged for this call Just in this call The phone will ring 3-4 times And then it will hang up automatically I think we should clarify that Just because you've already checked out something Doesn't mean that you don't want to check it out again I mean just clarifying the question Yeah and I hope the network's... Alright Okay So we'll do one thing I'll just quickly open up the craze to bring up Q&A quickly Meanwhile you guys can continue to vote Craze, do you want to just bring up questions I'll try to fix the network No questions specifically? Cool Yes Sure Go ahead Yeah when you say speed rendering Definitely like Kiran said There are certain template libraries Which are faster than Django's default template library Like Jinja But at the end of the day And when it comes to ORMs It's your... Yeah I'm talking about the ORM overhead So it's not necessarily a big overhead In that But what is generally seen Or what we generally advise to people is The web framework overhead is very minimal It's usually the IO part Which is more intensive Every web application is more IO intensive And that's usually the slowest part And the overhead that the framework gives Is much minimal That's why you can build large sites With a complete framework like Django So to add to that point I would say that the overhead you deal with Are one year ORM How quickly can it load from the database And this comes down to basically your database architecture The cleaner it is, the faster it's going to load And sometimes a clean architecture In your database is not a clean URL Because I for one for instance Never primary keys in the URLs Because I think primary keys are internal Database should never be put out in the public But if you're having something else then Something else has to be looked up in the database And that could be an overhead So there's a design problem that affects your overhead One Second, there's a security problem You want to make sure this person is supposed to see What is supposed to be seen Or supposed to perform an action Now how you design your security architecture Could be an overhead And this is not a framework thing Now this comes down to how you want to do it And the third thing is you template rendering language In which case Flask clearly wins It just got the better one It's a failure The mic's not on Yes Yes Yeah, but you don't have to use that Okay, so let me just be clear with this It does not wrap the API of SQL Alchemy In any way All it does is Links it to the session request So that when the request starts in Flask A session is open in SQL Alchemy That's all it does That's just an input That's an input shortcut It does not do anything to actually Effect the other way SQL Alchemy itself works Yeah, so that extension does not bother me As much as something like the W2 forms extension does Which is not only open in it It also changes the API without warming Okay, so I've had enough pain With that, but I stopped using that one Okay, but the first SQL Alchemy On the other hand is very, very nice Because it solves one very specific problem Which is opening a database correction When the request opens Closing it when the request closes And nothing else It gets out of the way for everything else Okay, just moving on To the last couple of questions from Twitter I've been able to Thank you guys for posting questions where Twitter I think I've been able to weave in most of these questions Into the discussion Which is great I'm just going to quickly cover off the results Unfortunately the net's down But here are the final numbers that I have We have In third place is Webda PY Where 13 votes One-three So guys, please give a hand I think people are going to try So I'm sure you guys are waiting to know Plans versus Django Sorry? Raise hands, raise hands Plans Plans So PHP See, maybe more So, Plans came in at 29 votes Django 48 So guys, just the last couple of questions We have handed most of the questions that came in Where Twitter There's just a last few up here That I'm going to quickly build up So Kush is asking Just using the Django ORM ORM will do too many queries Is it true? Well, again, there's no right answer to that It depends on how you design your queries In case you find that you're resulting in too many queries I didn't understand the question Because one function actually results in a one Actually, when I'm using I can use the Django ORM And then I have to explain Actually, we'll make a database Django ORM and if it's such a Django debug tool Or on, if I might do like 100 No, that is because there are a lot of things Which comes built into Django Sessions or users and things like that That adds to the additional database calls Are those User ORM Sorry? User ORM Yeah, I mean, just Yeah, just eliminate that It's not necessary that you have to Well, it's If you have a powerful weapon, don't blow your leg off Yeah, that's exactly why you SQLize to me I know exactly what it's doing I don't know, I would say That's the reason why I use WebPy database Because exactly how many database calls make Yeah How many times are you going to do a SQL injection attack Checking in WebPy Because it's It's that we passed away Guys, clearly these days could go on and on Now, I was going to mention We're going to continue this To dive into this a little more And talk about other frameworks Maybe we'll, you know, we'll talk a bit about PHP too We'll see We'll talk a little more about parameters with other frameworks 4 to 445 In the open space up on the first floor So those of you interested, if you love this Please stop by at 4 Thank you so much, Kiran, who got volunteered And Arun and Anand Amazing discussion Please give him a big hand Thank you guys so much So, if any of you guys are interested I'd like to show you a code sample And I want to see how you do this In either Django or WebPy Let's see if you can replicate it Yeah, sure