This is something I've been thinking about myself lately. I'm working on a side project right now that is extremely JS heavy on the client side. I eventually found myself saying screw it, and am now in the process of rewriting the client side using backbone. Django is more or less becoming a restful endpoint for me that communicates to my various datastores.
In my professional life this is pretty much the same, start with django / jinja templates and then once the jquery gets crazy, move to a real client side framework (such as backbone, angular, ember, etc). The next app we build is going to be backbone from the ground up on the client side. For anything much more complicated than some calender widgets this is going to be the pattern. For this app, we see something like 45% of our traffic coming from phones and other mobile devices, so creating views in django that are more rest based than page based makes a lot of sense and just let the client decide what to draw on the page, rather than the server. I think in the next year or two we will be talking about a MV > MVC paradigm. Where the MV is django / rails / flask / node and where the MVC is the client side. Right now the only MVC client side frameworks are written in javascript because the only way to manipulate the DOM is with JS. Therefore, if you are a startup or even an established company and you need to go out and hire some resources, it's more cost effective in the beginning to hire one person who knows javascript will and through them into node.js and backbone (or whatever). That said, this doesn't really conflict with django's mission to "receive an http request and send an http response". Templating in Django has always been more of a batteries included feature more than a core feature, at least for me. That said, right now node and js in general just aren't there yet to replace django / python or rails / ruby as a full on server side language for anything more complicated than ToDoMVC in my opinion. Considering in django it's easy for me to hook up to mysql, postgres, memcached, mongo, elasticsearch and rabbitmq all in the same app, and usually not much more config than a single line and pip install xyz. To my understanding, you don't get much of this in node. That could change in the future of course, but at the end of the day, JS is not a pure OOP language while python and ruby are, even though it does a good job at trying to get most of the way there via prototype. What's more, I just don't think there is a way to do serious numerical heavy lifting in server side JS like I can get with numpy / scipy - and be performant by modern web standards. I think the Dart project is interesting to give JS some competition on the client side, but I don't know a single dev who uses it in production. I didn't know about the mozilla project with python, but that sounds interesting. Maybe some day we will talk about dart being used on the server and client at the same time. For now, I don't see python or ruby going very far for serious server side development. For simple ecommerce stuff or blog like apps, node might gain some share. On Monday, January 27, 2014 5:44:12 PM UTC-5, [email protected] wrote: > > Hi, > > I would like to know if this community is somewhat worried about the > future relevance of Django (and other purely server-side MV* Python web > app frameworks such as web2py for that matter) given the current momentum > of JavaScript (JS) everywhere? > > There are many competing architecture patterns for a WHOLE web app today > ranging: > a) from client-heavy SPA with a client-side MVC framework synching its > models via a REST API with a server-side reduced to a database access layer > > b) to light client apps with a server-side MVC frameworks and very little > or no Ajax > > c) and everything in the middle. > > I guess it is not too controversial to say that which is best (or even > merely adequate) depends on the generally moving target of the app > requirements (especially the non-functional ones) and thus a long > lifecycle app can be expected to have to change pattern at some point. > > > Given that: > 1) full web apps following any pattern can today be developed exclusively > with JavaScript (JS) frameworks on both sides who have incorporated most > (if not all) great design ideas from Django (and Rails) > > 2) IDEs ranging from Visual Studio to browser-based ones are available to > support such development > > 3) Python in the browser projects do not yet provide productive debugging > support (and will they ever without support from a tech giant?) > > 4) Cloud giants (Amazon, Google, Heroku, Microsoft) all offering JS framework > running servers > > are the productivity gains from the more legible, concise and abstract > Python code as compared to JS code really compensate the productivity > loss of having to port part of the app from one language to other every > time it must be pushed from one side (say server) to the other (say > client), or even to maintain a code base in two languages instead of one? > > Why then adopt Django (or web2py) for a new project today, instead of > going pure JS? > > I am a big Python fan in terms of design and principles, but I am fearing > that it has started to lose the popularity/adoption/community size battle > against JS, which, from a pragmatic productivity standpoint is relevant > and thus potentially snowballing after a tipping point is reached. Trends > are deadly fast in web development, cf. how quickly J2EE+static HTML, then > J2EE+Flash and .NET+Silverlight have fallen from grace. > > Any thought on this? > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b08612d1-84b7-47ef-aafc-9b85bda272a3%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
