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.
On Monday, January 27, 2014 4:44:12 PM UTC-6, damond...@gmail.com wrote:
-- 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.
On Monday, January 27, 2014 4:44:12 PM UTC-6, 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?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 layerb) to light client apps with a server-side MVC frameworks and very little or no Ajaxc) 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 development3) 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 serversare 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/f72ab156-0687-4636-8e3a-75188b772f8c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment