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

+1 well said.

Cal

On Tue, Jan 28, 2014 at 4:59 PM, James Turley <jamesturley1905@googlemail.com> wrote:

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.

On Tue, Jan 28, 2014 at 4:27 PM, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> wrote:

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

On Mon, Jan 27, 2014 at 10:44 PM, <damondeville@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?

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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@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.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@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/CAHKQagGvjtxt9wL727rKYpV2_QJWuYP0%3DAhY7xE7uZ%3D7gjwC4g%40mail.gmail.com.

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

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@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/CAAb4X%3Dx%2BtKWsnA1Lq1P%2B02AOZgkShkmrqC7VTq%3D%2BX0BXkRoNwg%40mail.gmail.com.

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

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@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/CAHKQagGR1UDps7M%3DMPh09U-cKAumdDcWw86gr6t-ZBK4TRMf8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.