Love it or loathe it, SAAS is here to stay. As developers, we need to be able to create SAAS apps efficiently and quickly. As a company that is very much Clojure based we don’t have a lot of options. In fact, when it comes to SAAS-specific frameworks or libraries we don’t really have any options in the Clojure ecosystem apart from rolling our own. When it comes to more general web apps the picture is a lot sweeter. We have the Xiana framework which we use frequently when creating our apps. This makes creating the back end of an app fast and easy, although it doesn’t have all the features needed for a SAAS app. Most notably, there is nothing there to handle payments from customers.
So…. The decision was taken to find the best tool to quickly create SAAS apps. The primary goal was to find a tool we could use in the short term, even if it meant moving away from Clojure. Secondary to that we would be able to learn what exactly makes a good SAAS framework and work out how we could improve Xiana to compete with the best. Note that this was by no means an exhaustive study. It’s likely we missed some potential candidates when selecting the frameworks. These are the frameworks we selected to try:
- Python – Django
- PHP – Laravel
- JS – UseGravity
- Clojure – Xiana
- Ruby – Bullet Train
For each of these, we selected an experienced developer to attempt to build an app. All the devs were working on the same design and had the same time constraints. This meant that, although we couldn’t avoid differences in abilities and approach, we could get a rough measure of just how effective the frameworks were. Just to be clear, this tells us nothing about how easy each framework/language combination would be to learn from scratch, just how efficient it would be in the hands of an experienced user.
This table gives the details of the task, and just how far each developer got in the limited time they had. Don’t take the rankings too seriously as there were some mitigating factors that just don’t really show in the raw results. (more details to follow)
| Django | Laravel | NodeJs | Xiana | Bullet Train | |
|---|---|---|---|---|---|
| Landing page | ☑️ | ✅ | ✅ | ||
| Notes page | ✅ | ✅ | ✅ | ✅ | |
| Create, edit, delete note | ✅ | ✅ | ✅ | ||
| Markdown display | ☑️ | ✅ | |||
| create note endpoint | ✅ | ✅ | ✅ | ||
| Limit by plan | ☑️ | ✅ | ✅ | ||
| Faq page | |||||
| Terms of service Page | |||||
| Contacts Page | ✅ | ||||
| Profile page | ✅ | ✅ | |||
| Sign Up | ✅ | ✅ | ✅ | ||
| Sign-In/out | ✅ | ✅ | ✅ | ✅ | |
| Forgotten Password | ✅ | ||||
| social logins | ☑️ | ||||
| User Management | ✅ | ✅ | ✅ | ✅ | |
| roles | ✅ | ☑️ | ☑️ | ✅ | |
| Admin page | ✅ | ✅ | ✅ | ||
| Billing, Subscriptions | ☑️ | ✅ | ✅ | ||
| Invoices | ✅ | ✅ | |||
| Stripe Integration | ☑️ | ✅ | |||
| Help/Customer Care | ☑️ | ✅ | ✅ |
UseGravity
Developer: Eduardo Vedes
7 years as a developer, focused on the javascript ecosystem.
Looking at the raw results, UseGravity did very well. Almost all the requirements were covered in the time allowed. The documentation available is excellent. There is a course available that takes the developer through all the stages of building an app. Our developer chose to work through this course and still had sufficient time to complete almost every step required.
There were a number of drawbacks though. By default the side produced is branded as “UseGravity” not as our chosen company. It is possible to change this of course, but it is not available as a setting to change. Altering it means digging into the code and changing it there. Doing this means losing most if not all of the speed advantages and would require a deep understanding of the code underlying the features generated by UseGravity. Also, the user roles are hardcoded. All is well and good if the ones provided are what you want, but lots of work to change this to something finer-grained.
PRO
- quick and easy to get going
CON
- The app is branded as UseGravity
- Offers little or no advantage over plain JS if your app doesn’t fit with the limited abilities provided by the framework.
Xiana
Developer: Fabricio Cozarolla
4 years as a developer
4 years of Clojure/ClojureScript
Given that Xiana is not a SAAS framework as such, our dev managed to get a surprisingly long way in the allocated time. In terms of features implemented, it wasn’t far behind UseGravity. Looking at the code produced it would appear that further development would not be a problem, with no evidence of any blockers. There are some incomplete features in Xiana, the main missing feature being the payment system. We have already implemented this in one of our Xiana-based apps and steps are now being taken to migrate this into the library.
PRO
- Clean and clear code inviting further development
- Clojure based
CON
- Doesn’t give you everything out of the box (yet)
- Clojure based
Laravel
Developer: Eric Santos
20 years of experience in PHP
(Using JetStream, Spark, and Teams.) It was easy for our dev to get started with the automated setup, which creates docker containers for the different components as required. This combination looked promising, all the parts needed appeared to be available. However, they were not able to get everything working in the allowed time. More work would be required to get stripe integration to work correctly. The user roles worked in the simplest of cases, but adapting them to a more complex arrangement is still unknown. Also, the user sign-up flow was best described as quirky, and what would be involved in cleaning that up is also unknown.
PRO
- Everything necessary is available.
- Easy to get started
CON
- Deeper development may be time-consuming.
- PHP
Django
Developer: Lukasz Kozuchowski
13 years as a developer
9 years of experience with Python.
Django provides a lot of useful stuff, and our dev got a long way in the time provided. Things like the user admin are already there and are customisable to some extent. Creating static pages is really easy too. However, if you want to make something more complex then it is not so easy. Our dev described attempting to make user role permissions more granular than those provided as “A headache”. That said the roles provided would cover quite a lot of use cases. The admin pages are useable straight out of the box, and although it is possible to change their appearance to match your own branding, it is not a trivial task to do that.
PRO
- Good facilities provided,
- extension and customisation are possible.
CON
- Not so easy to customise and adapt for more complex applications.
Bullet Train
Developer: Serghei Tsakovski
15 years as a developer
10 years Ruby on Rails
Right from the start our dev had problems, starting with getting it set up. It seems that the standard packages are only available via Brew, which is fine if you happen to be a Mac user, but something of a headache if you use Linux. Although they managed to tick off some of the tasks specified, nothing went according to plan. Many of the required pieces were provided, but actually using them meant lots of debugging and working around incompatibilities. One problem was with stripe integration. This is already available in Rails, but the Rails version didn’t work with Bullettrain and the Bullettrain version was too limited for our use case. We reached the conclusion that this framework was too raw and definitely not a good choice for quickly putting together a SAAS site. It may well be worth watching, as it appears to be trying to cover everything you might need for a SAAS site and the parts that did work well were quite impressive. ie the user creation and admin, which was good out of the box.
PRO
- Good (flexible) user admin
CON
- raw
- poor docs
- brew only installs
Conclusion
Looking at the table of results, ie what was achieved in the deliberately limited time allowed for this challenge, gives a clear picture of what can be achieved with the different frameworks. Most notably, JS with UseGravity comes out top of the list. Our dev ticked almost all the boxes, even after spending a chunk of the allowed time doing the video course available from UseGravity. If you want a simple web app that only needs the provided facilities then this looks like the obvious choice.
However, modifying the provided functionality proved to be quite a different matter, requiring understanding the inner workings of the framework in a way that didn’t appear to be much easier than starting from scratch. If you are starting a potentially large project then this could well lead to an unmanageable level of technical debt. Given that some of the most successful SAAS apps started small and just grew, proceed with caution.
Looking into the code produced tended to support these results. One thing many of us have learnt the hard way is that code has to be clear and simple. Working correctly is never enough if there is a chance that changes and updates will be needed in the future. Changes and updates are ALWAYS needed in the future.
This pattern is repeated to some extent in some of the other frameworks. Getting something up and running is easy enough in Django, and Laravel, and if you only need a simple app that fits well with what is provided they may give you what you want. Laravel may well be a good choice if PHP is your thing and you are prepared to spend a little longer in development. Similarly for Django. Bullet Train also shows promise, but probably best to wait for the next version.
Of all the frameworks tested, there was the only one that didn’t leave us with an uneasy feeling that we would be getting into some serious technical debt if we were to commit to using it for a real-world app, and that was Xiana. It may have been a little behind in terms of implementing all the features, but not by much, and this was more than made up for by the feeling that the path ahead was still clear.
In the end, the clarity, and simplicity, of Clojure produced a clear winner for us.
