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
>
> 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/52E79F27.20105%40dewhirst.com.au.
For more options, visit https://groups.google.com/groups/opt_out.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment