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] < [email protected]> 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, <[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/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 [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/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 [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/CAAb4X%3Dx%2BtKWsnA1Lq1P%2B02AOZgkShkmrqC7VTq%3D%2BX0BXkRoNwg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
