Panel: Frameworks comparison

Plan:

• Brief introduction to each framework
• Followed by discussion focused on use cases
• Maurits will live blog (thanks!)
• Framework vs. Product - let’s not worry about that!

For each system:

• What use cases is it well suited to
• What use cases is it poorly suited to

Discussion:

• Focus on client use cases and what frameworks would be a good or poor fit
• You can also ask questions!

Live blogging.

Use cases:

• Non-profit with custom forms and import/export
• Concert venue with strict event listing and advanced settings.
• NGO needs a database application for their highly confidential data.
• Generate a map out of data, and store extra information, like images for the data.
• Three-person company with basically static pages, non-technical users.
• Real-time application with websockets.
• A large company wants to monitor how well their customer service staff are doing. Strict form with statistics on it.

Pyramid:

• Best for APIs, not really CMS or websites, but applications
• Start small, grow
• Complex non-profit use case: you would have to build everything yourself.
• Event listing: we have a site that manages stuff for music bands as example, you just need some endpoints. Maybe websauna on top.
• NGO privacy: security really good, and simple enough to understand the full system. You can fully build your own fine grained security system. UI is a lot of work.
• 100 person company wants intranet with various content, installable by local IT team.
• Intranet: try to create a good solution for multiple clients, not tailored to one in a consulting project. Pyramid is good for building such products.
• Map: pyramid does not care which database you use. In a project we are mapping electical grids. In Guillotina they think they are nice with AsyncIO, but it makes their whole codebase harder to understand.
• Real-time: we had websockets for a year, but it was too slow, so we rewrote it in Go-Lang.
• Form statistics: you can create a form, store it in a database, export it, fine.

Django:

• Aimed at 80% of use cases, simple auth system
• Good for CRUD apps, smooth beginning
• Non-profit: export/import is good, we can do forms. Sharing access gets tricky
• Event listing: Django can do it, but just use Wordpress. But the technical user can do this in the admin interface.
• NGO privacy: permissions are too simple OOTB, not per object. You may want end-to-end encryption, which no framework offers. Limited built-in audit log, nice start.
• Intranet: not good fit for Plone for the people who do not often work with it. Django has easier CMSes for this. The expenses claim form could be easier to integrate into Django. Deployment just needs Postgres. DjangoCMS is Plone Light. Wagtail is WordPress Plus.
• Map: any of the frameworks except Plone can do the geo stuff in postgres. Images just on the file system. Static and uploaded files are handled fine by Django, can also be in the cloud.
• Real-time: not many Django users will care about websockets, will never be the focus.
• Form statistics: you can but I would not do it. This feels like a custom web application. Do it in any framework.

Guillotina:

• Small framework, scale from small to big
• Non-profit with forms: decent fit, use JSON schema
• Event listing: go to wix.com or something, it seems too simple
• NGO privacy: Good fit, permissions are no problem for this. You need to build the full UI. Okay, you may be able to start with Volto as UI, but that needs integration in the backend.
• Intranet: backend can handle it, need to build UI, deployment can be with docker and kubernetes.
• Map: for the large files, Guillotina wins because of AsyncIO.
• Real-time: we use websockets just fine.
• Form statistics: you can build an app, depending on your UI skills.

Plone:

• Good when you have different use groups with complex requirements for security.
• Edit interface is doable, but less so on mobile.
• Import/export complicated, but you can hire Jens.
• Difficult to find skilled people.
• Non-profit with forms: really good fit, end-users can create the forms. The import/export would need help from a provider.
• Event listing: do not bother with Plone. It sounds more relational, Plone would be overkill.
• NGO privacy: you need deep understanding of Plone security, hierarchy for storing data. Audit logging with add-on.
• Intranet: Plone is fine. You may need to help with installing at first, but it will keep running once installed.
• Small almost static site: none of us.
• Real-time: once Asko is done with his ZServer improvements, we can do it.
• Form statistics: do not use Plone. Use sed, awk, perl. Technically you could use some add-ons.