+1 well said. Cal
On Tue, Jan 28, 2014 at 4:59 PM, James Turley < [email protected]> 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] < > [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. > -- 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/CAHKQagGR1UDps7M%3DMPh09U-cKAumdDcWw86gr6t-ZBK4TRMf8Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
