Ask HN: Drupal or Django for my startup? and why
27 comments
It sounds like you're not the technical founder because those two frameworks are completely different in nature and if you were you'd have a clear answer. I don't have professional experience with either. I do have experience with failed startup ideas because I started with a focus on technology and not problem. Btw, I am also Bulgarian so that's probably what we have in common. There are tens of technology stacks that can create a technical solution. However, there are very few founders that can create a strategy and build a business to topple an existing player. Just remember that. The technology should be the easy part to figure out.
Just my 2c.
Just my 2c.
Wrote a 100k line of code financial app in Drupal 7. It's not compatible with D8, and expect the same with D9.
Testing is less than an afterthought in the community, docs in D8 are usually empty pages when you dig in, the technology is loosing mindshare and not many are hiring. These are all red flags for a startup. It can be used to build apps but I would stay away.
Go with Django. Python is a more productive and clear language. Django is excellent at ensuring an upgrade path, provides great docs.
If you have well defined services, it sounds like you do, then make them apis. You could have separate Djano apps or use Flask, a great micro framework.
Overall my experience with Python and the community for building web apps has been great.
Go with Django. Python is a more productive and clear language. Django is excellent at ensuring an upgrade path, provides great docs.
If you have well defined services, it sounds like you do, then make them apis. You could have separate Djano apps or use Flask, a great micro framework.
Overall my experience with Python and the community for building web apps has been great.
> Wrote a 100k line of code financial app in Drupal 7. It's not compatible with D8, and expect the same with D9.
Actually D9 will not be a hard compatibility break for D8 thanks to the significant changes in Drupal 8: https://www.drupal.org/blog/making-drupal-upgrades-easy-fore...
I agree D8 has had a documentation problem but this change has a chance of helping with that too since developer attention won't be in trying to make a huge amount of sweeping changes all at once anymore.
> Testing is less than an afterthought in the community
Virtually every core patch has to provide tests in order to get accepted. There's better testing coverage of Drupal core than there's been ever before. Significant amount of work has gone into improve the way testing is done as well. There's definitely more to do since tests probably used to be less than an afterthought and the codebase has a long history but that statement isn't accurate at all.
What do you base "not many are hiring" on? Has seemed like the opposite is true to me.
Actually D9 will not be a hard compatibility break for D8 thanks to the significant changes in Drupal 8: https://www.drupal.org/blog/making-drupal-upgrades-easy-fore...
I agree D8 has had a documentation problem but this change has a chance of helping with that too since developer attention won't be in trying to make a huge amount of sweeping changes all at once anymore.
> Testing is less than an afterthought in the community
Virtually every core patch has to provide tests in order to get accepted. There's better testing coverage of Drupal core than there's been ever before. Significant amount of work has gone into improve the way testing is done as well. There's definitely more to do since tests probably used to be less than an afterthought and the codebase has a long history but that statement isn't accurate at all.
What do you base "not many are hiring" on? Has seemed like the opposite is true to me.
The older I get the more I realize that language/framework decisions at many companies is a function of 1) what your existing team knows already and 2) the business requirements of your company. Furthermore I believe the goal of a founder is to solve problems with people (like fundraising, hiring, etc.) and not computers (by coding).
Good point, though not on point ;)
Background: I work at a Fintech startup where the backend is built with Django. I have about 4 years of experience with it, and have worked on Django projects from several different industries, from education to ecommerce. I absolutely recommend that you go with Django. Your project sounds like will deal with many different types of problems, and using Django and Python will allow you to take advantage of the huge ecosystem of third-party libraries that will save you a ton of time. CMS systems like Drupal are great if your main activity is publishing content, but anything past that will leave you fighting with its internals while you should be writing business logic.
Interesting. I am not arguing, just sharing: people say that Drupal now is a framework and you an actually write custom stuff, not just stack modules. Can that be, what do you think?
Yes - that is what is being said about Drupal 8 but I see it more of a shoehorning a CMS into a framework. Custom modules can be written - but doing the same in Django is much easier.
One approach that you can also look at is build the platform as an API in Django and build the wrappers / customizations for the sites in Drupal.
One approach that you can also look at is build the platform as an API in Django and build the wrappers / customizations for the sites in Drupal.
Actually it's always been a framework, it's just there's lots of shoehorning of CMS functionality. And it's less of shoehorning, it's just where the $s are flowing, I work with a team who do a lot of native CRM & BPM with Drupal it's just they haven't got $m so you haven't heard of them.
Drupal's fundamentally different than Django as not only are you able to code less due to the sharing of modules but you're also collaborating with thousands of others.
So with Django where you're coding coding coding, i.e. creating technical debt, the idea with Drupal is you only need to code what business logic hasn't already been built over the last 16 years. You're leveraging code and community, so you can focus on what you're good at and collaborate with thousands of others to fill the gaps.
Drupal's fundamentally different than Django as not only are you able to code less due to the sharing of modules but you're also collaborating with thousands of others.
So with Django where you're coding coding coding, i.e. creating technical debt, the idea with Drupal is you only need to code what business logic hasn't already been built over the last 16 years. You're leveraging code and community, so you can focus on what you're good at and collaborate with thousands of others to fill the gaps.
I currently work for a large eCommerce site that uses Django/Python. Before that I worked with a large PHP CMS, though not Drupal. Some non-obvious, and practical things that Django does well:
* Dependency management is way easier with Python, so upgrading and deploying is less error prone
* Django scales really well thanks to excellent caching with e.g. Redis. Adding caching to views (pages) is child's play, and super easy to debug/purge.
* Speaking about scaling, writing a REST API or consuming a REST API is much easier in Django (django-rest-framework and requests, respectively)
* The Django ecosystem is great. If you have a problem you want to solve, someone has probably done it already and published a package
* The Drupal middleware is awful compared to Django middleware
* Testing
* The Django admin interface is amazing [0], and at least as good as any off-the-shelf CMS. It does permissions and custom actions. Your sales team needs to upload a CSV file of suppliers? No problem, just add it right in there.
* Debugging. The Django shell and pdb/ipdb are great tools.
Finally, thanks to some non-obvious pitfalls in PHP, you have to take more care when writing PHP to make it secure. Apart from the flame-wars, the only practical issue is when hiring. You need to make sure you hire PHP candidates who know the language inside out. With Django/Python, you can be a bit more lax - there's far fewer non-obvious pitfalls, especially with the templating system and ORM of Django. It also takes devs less time to do a thorough code review. IMO, it's easier to grow a Django team.
[0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
* Dependency management is way easier with Python, so upgrading and deploying is less error prone
* Django scales really well thanks to excellent caching with e.g. Redis. Adding caching to views (pages) is child's play, and super easy to debug/purge.
* Speaking about scaling, writing a REST API or consuming a REST API is much easier in Django (django-rest-framework and requests, respectively)
* The Django ecosystem is great. If you have a problem you want to solve, someone has probably done it already and published a package
* The Drupal middleware is awful compared to Django middleware
* Testing
* The Django admin interface is amazing [0], and at least as good as any off-the-shelf CMS. It does permissions and custom actions. Your sales team needs to upload a CSV file of suppliers? No problem, just add it right in there.
* Debugging. The Django shell and pdb/ipdb are great tools.
Finally, thanks to some non-obvious pitfalls in PHP, you have to take more care when writing PHP to make it secure. Apart from the flame-wars, the only practical issue is when hiring. You need to make sure you hire PHP candidates who know the language inside out. With Django/Python, you can be a bit more lax - there's far fewer non-obvious pitfalls, especially with the templating system and ORM of Django. It also takes devs less time to do a thorough code review. IMO, it's easier to grow a Django team.
[0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
So I've experience of working with both and technically you are comparing apples to oranges. Drupal is a CMS built in PHP while Django is a Python framework to make web-apps (one of them being a CMS).
* A framework works at a lower level compared to a CMS. So if you have lot of customizations to be done which is not limited to how it looks - a framework is better * If most of the work needed is to change how a site looks and content only, a CMS might be a good fit * From your point it looks like there is a need for a strong platform * Which language are you programmers comfortable with (if you already have a tech team)?
For the company I was working in earlier, Drupal 7 was being used.
For my own startup I am using Django.
* A framework works at a lower level compared to a CMS. So if you have lot of customizations to be done which is not limited to how it looks - a framework is better * If most of the work needed is to change how a site looks and content only, a CMS might be a good fit * From your point it looks like there is a need for a strong platform * Which language are you programmers comfortable with (if you already have a tech team)?
For the company I was working in earlier, Drupal 7 was being used.
For my own startup I am using Django.
You should compare something like laravel(https://laravel.com/) or symfony(https://symfony.com/) against the djangoproject(https://www.djangoproject.com/). I think this is a more appropriate choice. If you are not sure about the dev-performance of your team with a naked framework, you should consider something like the Oro-Platform(https://github.com/orocrm/platform) or Odoo(https://github.com/odoo/odoo). You can also work with a e-commerce/shop system like oscar(https://github.com/django-oscar/django-oscar) or shuup(https://github.com/shuup/shuup) as a base.
I've been Drupaling for 13 years, before that I was J2EEing, before that I was AS/400 RPGing. Before that I was PASCALing at college, BASICing and Assemblering at home. I've seen all kinds of businesses and startups, and I've seen what works and what doesn't.
My advice to you is to use Drupal because you can get far fast. Use lean methodology (lean canvas etc.) and get your MVP out as fast as possible and start making money. Don't try and build lots of functionality that you don't know works, and by works I mean makes a profit.
Watch GaryV, as he says - the market is always right. Focus on selling cars or vin checking or whatever it is you're doing, nobody apart from techies give a hoot what your site is built on. Some of the biggest sites in the world are built on PHP, e.g. Facebook. Some of the biggest sites are built on Drupal, e.g. Weather.com (the most personalised site as every visitor sees a different output, and delivers data to mobile apps).
Your code won't help your business succeed, selling will.
My advice to you is to use Drupal because you can get far fast. Use lean methodology (lean canvas etc.) and get your MVP out as fast as possible and start making money. Don't try and build lots of functionality that you don't know works, and by works I mean makes a profit.
Watch GaryV, as he says - the market is always right. Focus on selling cars or vin checking or whatever it is you're doing, nobody apart from techies give a hoot what your site is built on. Some of the biggest sites in the world are built on PHP, e.g. Facebook. Some of the biggest sites are built on Drupal, e.g. Weather.com (the most personalised site as every visitor sees a different output, and delivers data to mobile apps).
Your code won't help your business succeed, selling will.
Furthermore, use the Drupal Commerce modules for Drupal 8, releases are coming out thick and fast now. Commerce for 8 is awesome, you can have multiple stores (so like people have on eBay), product options are much easier than Drupal 7 to set up, and it's truly flexible so if when you A/B test or whatever you can easily alter the way your site works.
We migrated from Drupal to Django a few years ago and haven't been happier. Sites have become easier to maintain, new features are developed faster and designers find Django templates easier to work with.
We found Drupal's hooking system a pain to work with and it made debugging incredibly difficult.
We were using Drupal 6 at the time, not sure what has improved since then.
We found Drupal's hooking system a pain to work with and it made debugging incredibly difficult.
We were using Drupal 6 at the time, not sure what has improved since then.
Hooks are going away in favor of a fully object-oriented architecture. Some hooks remain in Drupal 8, but they'll get replaced in time. It also uses a templating system called Twig that is similar to Django's.
Django. Stay away from php
Why do you say that?
It's a few years old now, isn't PHP supposed to be better there days? (I am saying that as a Django dev).
I wrote this back in 2009 so it's a bit long in the tooth at this point, but still mostly accurate (and I'm still going strong with Django in 2017):
Drupal or Django? A Guide for Decision Makers http://blog.birdhouse.org/2009/11/11/drupal-or-django/
Drupal or Django? A Guide for Decision Makers http://blog.birdhouse.org/2009/11/11/drupal-or-django/
moine,
imho ... i worked with both of them :)
simplified
* drupal is a really nice, secure and extensible portal-system which can be enhanced with plugins written in php
* python-django is a web-framework based on common design-patterns
whats better for you!? it depends what you want to achive, but i think for a startup - and a maximum of flexibility + scalability - i would prefere python-django.
why? as a "general" webframework its more flexible than the portal/plugin approach of drupal + i would prefer python over php.
imho ... i worked with both of them :)
simplified
* drupal is a really nice, secure and extensible portal-system which can be enhanced with plugins written in php
* python-django is a web-framework based on common design-patterns
whats better for you!? it depends what you want to achive, but i think for a startup - and a maximum of flexibility + scalability - i would prefere python-django.
why? as a "general" webframework its more flexible than the portal/plugin approach of drupal + i would prefer python over php.
Even though my experience is from a few years back, I absolutely cannot recommend Drupal for complex, custom applications. See my write-up here: https://github.com/rshekhtm/VentureTap/blob/master/README.md, especially the Lessons Learned section.
So much has changed from Drupal 5 that I don't think your experience is all that relevant when assessing Drupal anymore. Just as one example, Drupal 8 now does use object-oriented PHP extensively.
I started with Drupal when it was 4.7, shortly to move to 5.x. We had a group blog, and it did the job pretty well, and it felt good to take advantage of things like maps modules and tagging. But niggling pains were there. Having to add extra modules to deal with duplicate pages ending in /, and while views was pretty simple point-and-click at the start, it seemed like it could do a lot more.
As time progressed, we added voting, rss aggregation, quizzes, and started extending views with URL arguments, relationships, fancy combinations of filters, login was via OAuth, and we were at 7.x by now. It was feeling unwieldy. Always aggressive in theming, what we wanted to do was taking an increasing amount of time, both in function and appearance.
A new project came along, and I thought, eh, Drupal can do that. And it surely could, seeing a nail, Drupal is a hammer that can do anything.
But it does it in a way where maintenance, or getting things exactly the way you want become incredibly time-consuming, and the code is a maze unless you're in it 24/7, and we had chosen Drupal not to be in code 24/7.
My background is not as a developer, but finance where using technology is an important skill. I can Bash, Ruby, JS, VBA/.Net, Python, R, and a few others to varying levels.
I shuddered a little when seriously considering Drupal as a solution to this new problem, mapping out the edge cases and exactly how many modules were needed (60+).
I ended up taking a week off learning NodeJS and using hapi as a framework. Just because I wanted a fresh start, not that I was enthralled with Node, but as so many others were using it, surely something was there.
This freshness gave some time to think about what I actually wanted, and to back-track from there, focusing on simplicity and well, simplicity. How to make everything as simple as possible, which is what a high level code framework offers.
You don't sound that technical, and I don't have experience with Django, however I recommend taking a code-approach, even if you don't want or need to be sitting in code, as you'll have access to and know how everything really works, not a pre-written GUI one where you're clutching at straws. Most web challenges are about the idea, the code implementation for what you sound like your doing, at an initial stage, is probably that not complex, and if you have success with the core idea, get technical talent onboard to optimise or do the things you find too hard.
A word of warning, however: Focus on making things simple. That will stop you going into a rabbit warren filled with code spaghetti.
tl;dr
Drupal is an excellent tool for publishing, and accommodates some complex publishing workflows that need multiple authors or layers of editing or approval. Core modules like comments or maps compliment this, but that's it. If your core need is greater than publishing (I suppose marketplace is publishing, and there are eCommerce modules), Drupal is a quick solution, but if your long-term roadmap means doing something remotely unique technically or in UX, roll your own using a framework to prevent re-inventing the wheel (and ending up with security nightmares). Bring on technical talent at an early stage when your idea seems proved. If you have funding, do this right away.
As time progressed, we added voting, rss aggregation, quizzes, and started extending views with URL arguments, relationships, fancy combinations of filters, login was via OAuth, and we were at 7.x by now. It was feeling unwieldy. Always aggressive in theming, what we wanted to do was taking an increasing amount of time, both in function and appearance.
A new project came along, and I thought, eh, Drupal can do that. And it surely could, seeing a nail, Drupal is a hammer that can do anything.
But it does it in a way where maintenance, or getting things exactly the way you want become incredibly time-consuming, and the code is a maze unless you're in it 24/7, and we had chosen Drupal not to be in code 24/7.
My background is not as a developer, but finance where using technology is an important skill. I can Bash, Ruby, JS, VBA/.Net, Python, R, and a few others to varying levels.
I shuddered a little when seriously considering Drupal as a solution to this new problem, mapping out the edge cases and exactly how many modules were needed (60+).
I ended up taking a week off learning NodeJS and using hapi as a framework. Just because I wanted a fresh start, not that I was enthralled with Node, but as so many others were using it, surely something was there.
This freshness gave some time to think about what I actually wanted, and to back-track from there, focusing on simplicity and well, simplicity. How to make everything as simple as possible, which is what a high level code framework offers.
You don't sound that technical, and I don't have experience with Django, however I recommend taking a code-approach, even if you don't want or need to be sitting in code, as you'll have access to and know how everything really works, not a pre-written GUI one where you're clutching at straws. Most web challenges are about the idea, the code implementation for what you sound like your doing, at an initial stage, is probably that not complex, and if you have success with the core idea, get technical talent onboard to optimise or do the things you find too hard.
A word of warning, however: Focus on making things simple. That will stop you going into a rabbit warren filled with code spaghetti.
tl;dr
Drupal is an excellent tool for publishing, and accommodates some complex publishing workflows that need multiple authors or layers of editing or approval. Core modules like comments or maps compliment this, but that's it. If your core need is greater than publishing (I suppose marketplace is publishing, and there are eCommerce modules), Drupal is a quick solution, but if your long-term roadmap means doing something remotely unique technically or in UX, roll your own using a framework to prevent re-inventing the wheel (and ending up with security nightmares). Bring on technical talent at an early stage when your idea seems proved. If you have funding, do this right away.
Rails!
Drupal 6 and 7 use Drupal crap function-based programming (not functional programming) style which over time leads to maintenance mess as you have tangled interdependencies of modules which are not 100% in terms of test coverage or quality. Drupal 8 bootstraps on top of that mess OOP. Drupal is engineered as garbage and gets unwieldy pretty quickly if you are going to be doing custom programming and straying away from the main modules. However for your case it's foreseeable you could stick to views and content types, and templates to customize those and not have to stray too much into actually writing custom code, however the UX of that sort of thing in Drupal is still shit and trying to customize that makes you do it the Drupal way which is often ugly and complicated. PHP 7 is a modern language I recommend a modern PHP framework or a modern Python framework like Django. In the end use what your technical founder knows best. Drupal makes it seem as if it's going to cut down on work, in the end it leads to more work to maintain, scale, and keep adding features and creating a better UX experience which users have come to expect. These days I would probably use some language for the backend and make the frontend with a responsive javascript framework like Angular, React, etc.
I wanted to know which choice is wiser - try to save up money with a CMS like Drupal or go with a flexible framework like Django or asp.NET
The project is a startup for cars that includes: - marketplace cars and all kinds of other vehicles - marketplace for autoparts - marketplace for tires - marketplace for all kinds of services around car - washing, repairing, etc - booking - vin checking versus 3rd party databases - chat/messaging systems - ratings - statistics - owner tools - my garage - where you put data about your own car - promo codes/vouchers etc. - ...
...in other words, it is huge. It is not the classical startup of 2 people in a garage, but instead a business with funding that aims to topple the leader of car selling in Bulgaria (small country).
It would be tremendously helpful to state what your experience is (how good you are at either), have you had specific experiences you didn't like with either and what other specific things might be a problem for one or the other.
Any thoughts or guidelines will be super helpful, so thanks in advance.
pp