Do you think Django's future is threatened by JS frameworks in both client & server?

[damond...@gmail.com]

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?

[Tim Chase]

On 2014-01-27 14:44, damond...@gmail.com wrote:
> 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,

If you like JS as a language, then it makes sense to do everything in
JS. However, I prefer Python by VAAAAAAAAAST measure over JS, so
will always prefer to do the majority of my server-side code in a
language that makes my life easier with things like iterators,
generators, real OOP, indentation-based blocks, and a standard
standard-library (with standard importing semantics).

-tkc

[Brad Moore]

The tech giants are pushing JavaScript more than Python these days.  JavaScript is said to be the future language for enterprise applications. I think Python will be around but will play a third place role behind JavaScript and PHP. Yes, I said PHP and I apologize but its true just look at the cloud support that is quietly being offered for PHP. I have used PHP extensively and it can be very good and very bad depending on the developer. .NET is terrible I almost quit an IT career before it started because we were forced to use Visual Studio and Microsoft technologies for web development in college. My opinion as long as good design principles are followed using an MVC approach all three are good choices. Python is not going to go away because it is being used to teach the next generation of computer scientists throughout the world. Get used to { } all over the place or just stick with Python and Django it will not matter.  

[Avraham Serour]

you will eventually need to keep a couple of different codebases in some different languges.

Say you get popular enough and now you need to launch a desktop app, android and iphone.

Take dropbox for example, they have a web version, desktop, android and iphone (did I miss any platform?)

For desktop you can still use python and I don't think it is possible to make a desktop application with js.

For android you'll need to use java and eventually you might use C++

For iphone you're stuck with objective-c (which I hate it more than js btw)

For mobile you could still use something like phonegap if you really love js.

Django always took an agnostic approach to client side, in my opinion this needs to change so not to risk becoming obsolete, but no need to rush.

And as you said these trends come and go fast, server side js is trendy right now and is relatively new, maybe it will stick around and maybe it will go away, python is getting popular but is not so trendy, I believe is has a more solid base.

Also I don't believe you need to be in such a hurry to jump on the server js train, this is new, meaning there are still few libraries around, and honestly I would first check the quality of the code of the libraries and frameworks, as php js has a low entry level, many people without much idea on what's going on are writing libs and releasing, this is good, people are learning, but be careful before using any code you see on the internet, I've seen too many spaghetti code and hacks in popular php frameworks.

best regards

Avraham

--
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 django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
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/02a3d0f6-2304-422e-acc5-083d4af7d219%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Chris Hinds]

Coffeescript.org makes some of those things better, but it's no Python.

C.

> --
> 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 django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> 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/20140127175630.5310edba%40bigbox.christie.dr.

[Mike Dewhirst]

On Monday, January 27, 2014 5:44:12 PM UTC-5, damond...@gmail.com 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?

Things do change but some things stay the same. Javascript will continue
to be hated by lotsa people.

You wanted opinions about client-side and server-side being more or less
integrated and you do hedge somewhat saying "depends on the ... app
requirements". I think while there is a performance edge to be gained by
separate frameworks they will persist.

Large scale apps ought to be funded well enough to hire the best
technologists who will obviously choose the best technologies for the
specified requirements. For server-side the Django ORM does it for most
apps while SQL rules. For client-side we'll just have to hire
javascript/CSS/HTML5 resources.

Mozilla is working on Python in the browser built on top of the js
engine. If that works, it is a very small step to an abstraction layer
in all browsers so we js-haters can avoid Javascript altogether.

As soon as we can manipulate the DOM with Python there will be a
plethora of client-side Python frameworks which integrate with
server-side Django.

Then we'll have Python everywhere :)

... and they can do what they like with js

[graeme]

On Tuesday, January 28, 2014 1:00:31 PM UTC+5:30, Avraham Serour wrote:

you will eventually need to keep a couple of different codebases in some different languges.

Say you get popular enough and now you need to launch a desktop app, android and iphone.

Take dropbox for example, they have a web version, desktop, android and iphone (did I miss any platform?)

For desktop you can still use python and I don't think it is possible to make a desktop application with js.

There are javascript bindings for GTK and QT.

 

For android you'll need to use java and eventually you might use C++

 

For iphone you're stuck with objective-c (which I hate it more than js btw)

 

For mobile you could still use something like phonegap if you really love js.

 

Which mean means you *can* keep everything in JS.

 

Django always took an agnostic approach to client side, in my opinion this needs to change so not to risk becoming obsolete, but no need to rush.

And as you said these trends come and go fast, server side js is trendy right now and is relatively new, maybe it will stick around and maybe it will go away, python is getting popular but is not so trendy, I believe is has a more solid base.

Python is much nicer to develop in. JS is horrible in some ways (e.g. variables are global inless specifically declared local) that are hard to fix without breaking backward compatibility. Things like coffee script may help.

Unless you have a lot of code shared between the front end and backend, I do not see what advantage JS has.

[James]

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, damond...@gmail.com wrote:

[Cal Leeming [Simplicity Media Ltd]]

It makes for an interesting debate and food for thought.

Python has a lot of libraries and user contributions which can speed up development, but like every language, has it's good sides and bad sides.

Django holds a strong position, libraries such as south, pipeline, mongoengine, uWSGI and the Django ORM itself make it incredibly easy to get clean code quickly out the door.

Personally I think the biggest risk to Django's future is lack of public contributions (separate debate), and evolution being held back for backwards compatibility reasons (again, separate debate), rather than any threat from new kids on the block. I would be quite surprised if NodeJS (as an example) overtook Django in terms of functionality and popularity.

Disclaimer: I'm +1 python and -0 JS, and thus slightly biased. 

Cal

--

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 django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
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/f01c1f78-aac4-467c-a777-a70ecd0de61e%40googlegroups.com.

[James Turley]

I'm not sure I buy this stuff about JS taking over everything. The reason is that client and server are different domains, and we might reasonably expect - even in a pure JS-only shop - people to specialise anyway. Apart from the tiniest start-ups, there isn't really an evolutionary advantage to having the same language on both ends. Rather than people who know x language, you primarily want people with familiarity with the domain-specific problems.

It's worth noting that the JS hype is not the only thing at the moment: among functional programming evangelists, there is a sense that "their time has come" after years on the CS-boffin fringe. The theory goes like this - nowadays, major web apps are deployed on enormous server clusters, sometimes with enormous numbers of virtual or real CPU cores, database sharding and so forth. The key problems facing server-side dev work - at least at the top end of the web - have to do with handling all this, parallelism, async, race conditions and so forth. A relatively 'pure' FP language like Haskell, with its divine commandments against mutable state and focus on pure functions, has a headstart on OOP languages like Python & Ruby in this domain. 

JS is sort of an FP language, and can be used to write pure code, but has hitherto been used almost exclusively as a simple interface to that great clump of mutable global state called the DOM; it certainly does not enforce good FP practices or anything like that. The Node model of event-driven IO is obviously directed at this group of problems, but it's very much a work in progress, despite all the hype. (This is also a problem I have with client-side MV* frameworks, BTW: I'm promised that picking up Ember is a breeze, but major parts of the API change so frequently that it gives me actual nightmares.) 

Meanwhile, we've got the Async IO library coming in Python 3.4; and, as others have pointed out, a headstart on big data crunching thanks to Python's excellent math/science ecosystem. I'm sure the Ruby people have tricks up their sleeve. And there's Go. And Scala. And Clojure. And ...

The point is: there's an enormous explosion of new tools around, plus serious improvements in old favourites. Devs who know what's good for them will use the correct tool for the job at hand; the cognitive convenience of working in one language only is a part of that decision, but only a part.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHKQagGvjtxt9wL727rKYpV2_QJWuYP0%3DAhY7xE7uZ%3D7gjwC4g%40mail.gmail.com.

[Cal Leeming [Simplicity Media Ltd]]

+1 well said.

Cal

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAb4X%3Dx%2BtKWsnA1Lq1P%2B02AOZgkShkmrqC7VTq%3D%2BX0BXkRoNwg%40mail.gmail.com.

[bobhaugen]

I think I agree with James (below). I'm about to graft a javascript MVC library or framework on top of a Django server, to make up for some problems with Django templates and forms. Haven't done it yet, but need to do something different. So I may come back here and repent...;)

I have worked on server-side javascript before the current trend (e.g. before node.js). I liked it, but it was still clear that the server and the browser were different domains, and they still have an impedance mismatch.  Just using the same language did not hide it, or when it did, it was a leaky covering.  Apparently Meteor thinks they have solved that mismatch.  Anybody tried it? But I do *not* want to develop single-page apps or use a NoSQL db, so they have quite a few assumptions that don't work for me. So I'll stick with Django on the server.

[Toran Billups]

I just shipped my first commercial web application and found that writing the backend with django was still a big win because the platform is so stable and feature rich.

Authentication out of the box
REST api with django rest framework
ORM / migrations / etc with core django and south
mod WSGI + apache + postgres (well documented and makes for a solid production environment to run your django web app)

I decided to use ember.js and ember-data for the frontend and really enjoyed the framework after I got over the learning curve/ cliff

I found this separation made it easier to test / reason about / maintain because the first time around Selenium was really my only option for full stack GUI tests (as half of it was rendered server side / but then jQuery soup would take over and manipulate the dom at certain points). And after you get a few of these tests written you realize how slow the feedback cycle is **then suddenly you're not doing TDD anymore -QA like feedback (and this is not what developers need for GUI development)

Having the client GUI code be 100% JS gave me the testing story I've been looking for -speed + a nice api for writing integration tests.

The only challenge was learning all the tech required to build this (both client / server side). I work with django daily and found writing REST apis is almost no code so the bulk of my learning was on the frontend. But for a developer just out of school this might seem like a HUGE amount to learn before you can be productive (the reason a single shared JS codebase would be an advantage obviously). That said, I still think django + ember (or something else) is a great platform to build web products with.

[Chris Hawkes]

As a business owner and full time Developer using C# and Visual Studio I do all of my website building at home in Django.  It's an amazing framework that is far above anything else I've tried which includes, ASP, Node.js, CodeIgniter, Yii and any other Python frameworks out there.  (I'll admit I've never gone with Ruby because I see no reason over Python)

The support is not going anywhere.  If you check job trends on indeed.com Django is far above most other frameworks out there regarding growth over the last five years.  

I would argue there are more impressive large sites using Django than Ruby on Rails or Node.js.  

All this being said, there is definitely a trend towards SPA's.   But there is no reason why I wouldn't want to use Django to serve SPA's from within the application.  That's what I plan on doing with the latest site I'm working on now.  It will be truly awesome.  

Let's be honest, debugging in JavaScript is a nightmare.  The tools are getting better but I personally don't see any reason to use Node.js unless I'm building a chat service or something of that sort.  Ultimately Node.js will eventually have to read a database or do something more than I/O which it won't do any better than Python or Ruby.  

If any framework seems to be losing it's luster I would say it's Node.  The hype was great but after starting with it, I'm thinking why am I using this?   

ASP.NET/MVC, Django and Ruby on Rails are by far the most reliable frameworks out there at the enterprise level. 

[Glen Jungels]

I have to agree that debugging javascript does stink.  However, the javascript frameworks (Node, Angular, etc) differ in that the execution is done client side whereas for Django, any PHP framework and Microsoft ASP/C#, the execution is backend on the web server.  Depending on the circumstance, the technologies can be complementary.  For example, I was doing some experimenting with Angular (simple stuff show/populate a listbox) that got data by way of a PHP webservice that pulled data from a remote postresql database, transformed it to JSON and provided it to Angular.

--
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 django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
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/ba05d66c-f10c-4ae9-988b-70d92a223c69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Javier Guerra Giraldez]

On Wed, Oct 29, 2014 at 1:11 PM, Glen Jungels <glenj...@gmail.com> wrote:
> the javascript frameworks (Node, Angular, etc) differ in that the execution
> is done client side

Node.js is a server framework.

--
Javier

[bobhaugen]

On Wednesday, October 29, 2014 12:26:01 PM UTC-5, Chris Hawkes wrote:

All this being said, there is definitely a trend towards SPA's.  

Does anybody else besides me hate the SPA trend?  I much prefer apps that are separated into logical components where each component has its own URL, rather than an a seemingly-infinite scroll.

[Tom Evans]

SPAs can (should) be separated into logical components that have their
own URLs - the fact that those distinct URLs load an SPA in to
specific states is desirable.

The trouble with SPAs is that people get tempted to do "un-webby"
things - SOLR's web interface springs to mind, the "application"
regularly polls the server to see if it is still there. If it is not,
it shades the page, making everything on the page unselectable and
says "instance gone away". All you can do then is reload the page when
it comes back, which loses anything input to that page.

OTOH, gmail is a SPA with deep links that work correctly and don't
ever cause problems. It does paging instead of infinite scroll.

Cheers

Tom