Secure: Django has built-in state-of-the-art security.
Efficient: Django has some of the best scaffolding tools to build web applications fast and efficiently (ORM including fully automated database migrations, admin interface, form generation, user authentication, management and permissions, REST API support, and much more). This means that applications can be developed quicker and more cost-efficiently, and the maintenance cost is lower in comparison with other web frameworks.
Popular: Django is very popular and has a huge community. Looking at Google Trends, Django emerges as a top-three web framework next to Spring and Laravel. Being so popular, Django has tons of well-maintained modules. These modules are well organized – check it out at https://djangopackages.org/.
By the way: Django also has very good Content Management (CMS) support via projects like Django CMS or wagtail.
Why Django CMS? Django CMS is a good choice for companies that depend on their website to drive business and generate user value.
For Editors and Marketing Managers: Django CMS empowers editors to select from custom-made page templates and content elements without any dependency on developers. Watch the video below:
django CMS is user friendly and has a very intuitive drag and drop interface. It’s built around the needs of multi-lingual publishing by default, not as an afterthought: all websites, pages and content can exist in multiple language versions
Modular Content Management. Editors can choose from…
content elements (plugins)
templates for a whole page
templates for just parts of a page (sections)
Full Multi-Language Support
Simple publishing process (draft / published)
Multi-Site Support (manage different sites with different domains in the same project)
Support for all aspects of SEO and Social Media cards / integrations
Full-fledged admin interface and site settings
different levels of permissions for editors
Undo / Redo / Revert to published version for editors
… and more
For Developers: Developers can use the full power of Django, a top-three open-source web framework which is also at the core of Django CMS, to build state-of-the-art applications (such as an online course booking tool) that integrate smoothly with the rest of the website. Moreover, developers can include CMS functionality in their applications, creating a perfect blend between application logic and manageable content.
The demo theme consists of standard components. It allows you to build your own page templates. Components include image sliders, text and images in one or multiple columns, tabbed content and much more.
First Steps: In Django CMS, all content can be edited right on the website itself. Append ?edit to the current URL and hit enter. Now you should see the admin bar where you can log in with the admin username and password that you received (or if already logged in, just hit the ‘Edit’ button). Then try double-clicking on a text anywhere on the page and an editor window will open.
The goal: What the app marketer would like to do: Prepare links with Google Analytics utm parameters that lead the user to the app (either via download & install through the app store or directly to the installed app) and then use these links in online marketing campaign across the board (email marketing, social media marketing, search engine marketing, display advertising, etc.)
The Solution (experimental): Firebase Dynamic Links
Dynamic Links work across app installs: if a user opens a Dynamic Link on iOS or Android and doesn’t have your app installed, the user can be prompted to install it; then, after installation, your app starts and can access the link.
When a user opens one of your Dynamic Links, if your app isn’t yet installed, the user is sent to the Play Store or App Store to install your app (unless you specify otherwise), and your app opens. You can then retrieve the link that was passed to your app and handle the deep link as appropriate for your app.
There are some comparisons out there on the web, but they appear to be shallow. Most of them just cover performance (Django wins), security (Django wins), learning curve (Django wins) and API (django loses, even though there is excellent API support in the form of a well maintained package called Django Rest Framework).
Let’s try to find out the real differences by looking at the different steps needed to build a simple blog application.
Disclaimer: I know Django quite well and Laravel not at all. Which means I am biased. Please collaborate via firstname.lastname@example.org to improve the Laravel part of the comparison.
Django provides a huge community and a very strong open source code base. It is probably safe to say that the underlying programming language Python has everything. There are many Python libraries that are well tested and ready for production.
Pypi is a very strong package manager with very good conflict management and dependency resolving. It is straightforward to use a virtual environment to create local, customized environments for different projects (similar to NPM and node modules) but in a less crazy way.
Django itself has a huge package directory with very useful comparison pages like https://djangopackages.org/grids/g/cms/ – it is simple to see which packages should be chosen for a specific job.
IDEs are readily available for example Pycharm including break point debugging and full inspection out of the box. Django has its own development server that runs as a CLI command out of the box. It’s also hasslefree to dockerize a local dev env (including debugging!)
Laravel has a huge community and a pretty strong open source code base. The underlying programming language goes back to Adam and Eva. There are many libraries. Dependencies are handled in composer. Finding a package appears to be a bit of a hassle as https://packagist.org/ doesn’t have browsable categories or comparison grids.
Laravel can be run in development mode locally via CLI command php artisan serve out of the box.
Django lets you define a model with different fields. Then it provides a CLI command to create migrations automatically. ./manage migrate will then apply the new model or any subsequent changes to the database. Upon changing the model, i.e. altering the properties of a model field, Django will detect this change and generate a corresponding migration.
Laravel allows you to create a migration file but its empty. You have to fill it with things you want to migrate yourself. Laravel does not support creating database migrations from the modal automatically. This means that your model code lives in two places (1. migrations, 2. model) and they have to be kept in sync manually.
Django ORM is taking care of all SQL things for the programmer. Query building is chainable like Animal.models.filter(color='black').filter(legs=4).filter(owner__email="email@example.com").distinct(). Its Q class allows to build sophisticated encapsulated queries without touching SQL. Also note the ease with which the query can span foreign relations (owner__email points to the email field of the foreign relation of the owner field, for example a User model)
Laravel has a sophisticated ORM which allows custom queries and managers.
TBD: I was not able to quickly find a simple straightforward solution on how to filter via a foreign key relation’s property like in Django.
An often overlooked feature, Django provides an admin interface out of the box. It has support for translation via 3rd party apps.
It requires zero configuration as it inspects the model definitions. It supports CRUD permissions out of the box per model and has mobile optimized widgets for all fields, including dates, searchable many-to-many relations, searchable auto completion for foreign keys. The django admin package is built on top of Django’s templating system, so its look and feel is extendable, allowing for example DjangoCMS to build its entire customly styled admin interface on top of it, without changing core functionality. Django Admin is configured by extending the package’s classes with properties such as list_display = ('first_name', 'last_name') in the module’s admin.py file, by default, no files are generated into your project.
Laravel has Laravel Nova as the official admin panel, it looks great. It has support for translation via 3rd party apps.
There are also some 3rd party admin packages that offer a lot of functionality, for example https://backpackforlaravel.com/. For example, it is nice to have an image upload widget that allows cropping.
Generally, in Laravel such packages require generating scaffolding code which then lives in your project. Changing admin behaviour requires the programmer to write PHP code, inside the scaffolded code.
Django has its own template language or Jinja2 can be used, both are hierarchical and use the extension strategy. Both are pretty mutch self explanatory. Some programmers dont like the django template language because it is limited (it only supports custom template tags and filters). But in my experience Django Template’s support for include together with with (context) solves it all. Jinja2 has support for components (called macros) and is said to be more powerful, so feel free to switch to jinja2 via some simple configuration in settings.py.
Laravel uses hierarchical Blade templates with the extension strategy. Blade has components which allows to quickly create custom blocks.
Django has no special tools to handle CSS / SASS or JS / TS. In my opinion, that’s a plus, because it forces programmers to use state of the art frontend tools like webpack and keep backend and frontend strictly separated.
Laravel has Laravel Mix which appears to be a laravel-flavoured frontend setup. It’s probably not suitable for professional use (correct me if I am wrong). It doesnt appear to support any built-in chunking though. Vuejs has its own tooling and it’s probably simpler to just use the plain vanilla react or vuejs setup strictly separated from laravel.
Static Files Support
Django has first-class support for static files and media files. Django’s collectstatic command allows to keep static files inside static/ folders within the single modules and apps (possibly inside 3rd party modules) and still be able to serve them from one single static file directory (or S3 bucket). That’s very smart because 3rd party modules dont have to be part of the code base of the project and can still contribute their static files in a fully automated way.
Django does have one more trick up its sleeve: ManifestStaticFilesStorage is a storage driver that automatically hashes all static files. This means, that it is very easy to have webpack build the app.js (and app.css bundle, or also multiple bundles) without hashes and then have them hashed by ManifestStaticFilesStorage so you can have a perfect caching solution with far-future headers enabled on the web server for the static file directory, including all server-rendered images.
From what I see there are no special tools for handling static files in Laravel.
i18n and localisation support
Django has extreme localisation and i18n support out of the box. django admin offers a translation interface for models right out of the box with well tested and widely compatible django-parler support. Also it has number formatting localisation support.
Django has its own wrapper around gettext / .po files (CLI commands makemessages and compilemessages. It allows to translate strings anywhere in Python code or in templates.
Laravel has simple i18n support and no gettext / .po support out of the box. I suspect that i18n might not be very performant.
Laravel has to fall back to third party tools like https://carbon.nesbot.com/ for format localisation. Are there disadvantages? For example how is a date formatted in a template? Does this require additional code in the template?
TBD: How can a model be translated in a laravel admin out of the box?
I find Laravel’s documentation a bit on the minimalistic side. It’s hard to get detailled information about specific configuration properties. A lot is left open to the developer. This doesnt incentivize the developer to follow best practise coding approaches and standards. I dare to say that it’s much easier to write bad code in Laravel than it is in Django.
Django supports mailing, events and caching quite well.
Laravel supports mailing, events and caching quite well.
Task Queues and Scheduling
Django has asyncronous task support via a 3rd party library (Celery). It’s not so easy to set up and requires some ground work and configuration, especially for deployment and monitoring. Monitoring is mostly done via Flower, but it’s a bit outdated and sometimes a bit useless.
Laravel has built in asyncronous task processing built in via its Queues. This looks like a robust, performant and lean solution. The monitoring solution appears to be awesome: https://laravel.com/docs/5.8/horizon
Authentication and oAuth
Django supports oauth (also in combination with the REST API via Django Rest Framework) quite well.
Laravel has Socialite and Passport and appears to support oauth (also in combination with the REST API) quite well and out of the box. This looks like a robust, performant solution.
Django has good support for quick and easy implementation of a full-text search via django-haystack it can connect to powerful search engines like Solr, Elasticsearch, Whoosh, Xapian but also has a simple database driven backend.
Laravel has Scout which appears to support full-text search quite well, quickly and easily and out of the box. This looks like a performant, robust solution.
However projects might require inline js code. That code will execute before the deferred scripts – which might throw errors if the inline js code depends on libraries loaded via deferred script tags. Inline js code can be deferred like described on stackoverflow:
defer was introduced before async. Its execution starts after parsing is completely finished, but before the DOMContentLoaded event. It guarantees scripts will be executed in the order they appear in the HTML and will not block the parser.
As you know, Google Tag Manager is a tool that helps Online Marketing people to set up different kind of user interaction and conversion tracking without the help of developers. This separation of roles is beneficial for both developers (no tedious updates of click events) and marketing staff (no dependency to IT), however it only works if web developers prepare the website according to best practices.
This is a document for developers to understand better the life of an Online Marketing staff that is in charge of setting up and maintaining Google Tag Manager click events.
So what do Online Marketing people want to do with Google Tag Manager?
Here is a typical Google Tag Manager (GTM) use case:
GTM managers would like to set up the tracking of a range of goals in Google Analytics so that business can see interaction and conversion trends and online marketing can optimise their campaigns based on these signals.
GTM managers would like to set this up in Google Tag Manager so that online marketing and business can wire the conversion and interaction signals to their tags and update the wiring quickly and independently from website deployment schedules.
Typical GTM Troubles that Online Marketing Managers have
Below is a list of technical things that sometimes make the life of a GTM manager tough.
1) Link Clicks Triggers don’t fire
Sometimes, GMT managers set up click triggers for buttons and the click triggers don’t fire.
Here is an example of a typical click trigger on a submitt button on a page like /booking?date=2019-01-01:
This is the button:
Here is the markup of the button:
However the GTM manager notices that this click trigger doesn’t fire.
Note: The button click tracking does fire if GTM managers configures the trigger with the button text only (Click Text) == ‘SEND REQUEST’
In this specific case GTM managers would like to be able to use the parent element (button with type == submit) because this is less ambiguous and more bullet proof and simpler to set up and maintain.
Developers can help GTM managers having a simpler and more solid tracking setup by letting click events bubbling up in all cases.
2) No ids or distinguishing classes for important interaction elements
Currently important interaction elements such as buttons are not easily identifiable by business / online marketing staff when working with GTM.
An ID or a class name like “booking-date-time-step-continue” would simplify tracking setup.
Developers can help us simplify tracking by proactively setting ids or identifiable classes on important interaction elements.
3) No dataLayer information for transactional events
For some tracking cases GTM managers would like to measure more than a click. Example: a booking. In this case, it would be safer to get a signal from the backend that the booking has correctly been processed and is valid. This helps us prevent wrong trackings, for example if GTM managers would track the click on the ‘book now’ button, and there were form validation errors, GTM managers would still track a successful booking even if the website would not.
In order to help us track conversions correctly, you can use Google Tag Manager’s dataLayer.push() method.
In recent months, Google has increased efforts to automate many aspects of Google Ads, for example the display targeting. By doing so manual controls have been hidden or removed from Google Ads or default settings have been changed. This is not always in the best interest of the advertiser. Below I will collect cases where Google has started to take decisions over the head of the advertiser, and how advertisers can take back control.
Display Native Apps Exclusion
Many advertisers see little to no return on their ad spend invested on native app placements on the Google Display Network. Meanwhile, for Google it’s a fast growing market as more and more impressions are generated in native apps, mostly free-of-charge games.
In earlier, happier days, all in-app ads could be disabled by excluding the placement adsenseformobileapps.com . Google has phased this convenient possibility out in 2018. This ppchero.com article describes a workaround, but the setting has become harder to find and it’s not possible to exclude all native app placements as one anymore.
Display automatic targeting
If advertisers pay close attention they can see that by default, much of their display ad spend goes into something called Display Automated Targeting. This inflates media spend considerably which is especially misleading in Remarketing campaigns where an advertiser wants to target exclusively users that have visited the website before.