SPA (Single Page App) is about providing an entire app by exposing a single physical web page containing an enormous javascript bundle. It breaks the original web paradigm in many ways. Surprisingly enough, we invest a lot of efforts to mimic the regular web behaviour.

Isn’t it time for modern frontend to reconsider the SPA approach?

[Note: Eric presented by using a projector to show his slides on a black Plone conference T-shirt. :-)]

Why are we doing this? Originally we always requested a whole page and this was considered slow. But we have good bandwidth now. And if you don't have good bandwidth, the super big bundle is not good either.

With SPA we try very hard to bring back the original working of the page, especially the browser history, being able to browse and then share the link to the current page.

To mitigate problems, we created an enormous stack. And we deny the complexity. New tools create new problems, even when their individual creators does not see the complexity.

"SPA isn't stable or efficient." But there is no way back. For example, you cannot create Google Docs with server side rendered pages. Web 2.0 is 15 years old. It is still about content.

SPA is separation of concern, which is a good principle. But we mix the browser layer (how you get and view the page) and the content layer (the page content).

It seems a take it or leave it situation: either use SPA or don't. What do we want? We want proportionate complexity. Do we need 100 percent SPA?

You can use micro components, see for example the demo of Maik Derstappen in the lightning talks on Monday, using Svelte. Micro frontend is bigger than that. It is a part of the application, that you develop separately. For example, you could do the Plone Sharing page like this.

Can we compile each page separately? Then each page is an app.

ES6 native support would be interesting. Combine with HTTP/2 and you need no bundles. Bundling is the most brutal thing ever. Horrible. Get rid of it.

Respect the layers. SPAs are monolithic. Break them down.

We should have a generic browser layer, common to many different use cases, for example for logging in. I don't want to code that, but plug it. Second step: push this layer to the browsers themselves.

Here are the slides.

How about building Plone without buildout? Running Plone on Python 3 without WSGI? Deploying Plone and Volto with containers without Docker? Building all this in re-usable and safe manner in sandbox with restricted network access with Nix? Welcome to hear about our hipster setup where we lock, build and configure Plone deployments with Nix, insist to keep ZServer running on Python 3 for the love's sake, build software deployments into standalone tarball archives, and run them with Nomad – the simple on-premises-friendly alternative for K8S.

• The easy, documented way: buildout, WSGI, Docker (if you need containers), Registry.
• Our way: pip, TxZServer, Nomad, Nix

When you use a container infrastructure, you have multiple containers for running a Plone site, for example zeo clients, zeo servers, load balancer. Nomad helps there, and is much simpler than Kubernetes. We have one job file to rule them all: task groups, instance count, update policy, server resources, volumen mounts, tasks, consul services, vault secrets, environment variables, exec artifacts.

Nomad has "isolated fork / exec driver". No docker image needed. We have a Nix-built artifact, a tarball that we extract in the root of the container.

With Nix, you get 100 percent reproducible artifacts. Production equals development. You have a full dependency graph. The result is a standalone tarball, perhaps 100 MB. Disadvantage is that there are no conventions, no metadata, no shared layers, no documentation. It needs learning and practice. Well, some documentation now: https://nixos.org and https://nix.dev, partially made by people that were using Plone previously.

Some ugly parts from Nix:

• Every language has their own Nix-conventions
• dependency generator ecosystem is comples
• cyclic dependencies are not supported
• no storage device is big enough for /nix/store

Our (legacy) approach for Plone 5.2.1 without Buildout and with pip:

• generated requirements.txt with buildout
• create Python env with pip and nix
• use pip-branch of z3c.autoinclude
• disabled />
• generate instance skeleton with nix
• forked plone.recipe.zope2instance

Plone 6 without Buildout should be pip-installable out of the box, but that is hear-say.

We use TxZServer in production, so ZServer using Twisted.

We will walk through the process of building a product for Italian Public Administrations using a bootstrap-based theme. I'm presenting io-comune, RedTurtle's first product based on Volto and the strategies we used. We will see the possibilities in Volto for theming without SemanticUI, using bootstrap and sass and what are the next ideas we could work on.

Scenario:

• We wanted to adopt Volto in our new project.
• We needed to include Bootstrap.
• Volto uses SemanticUI instead.
• Two such frameworks will conflict, for example fighting over the same selector.

We tried. We tried harder. A cheap approach did not seem possible, so we looked for a sane one.

A new theme: pastanaga-cms-ui. Load only the CSS needed for Volto admin UI, see Volto PR 970. And public-ui for public pages. In your src/theme.js do not import the css/less from semantic-ui, but the pastanaga-cms-ui. In theme theme.config also use pastanaga-cms-ui. Also razzle-config.

You should normalize your base style, for example:

body.cms-ui {
  .public-ui {
    font-size: 18px;
  }
}

and wrap your components with .public-ui.

Building a product:

• Base common package for every customer: https://github.com/RedTurtle/design-volto-theme
• New intermediate layer for SemanticUI
• New config layer for razzle/customizations
• Template for actual projects: design-volto-kit, with a Yeoman generator: create-italia-volto-app

Through the Web Dexterity Content-Types with Schema Editor and Blocks Layout Editor

How do we define content types schemas in Plone?

• TTW schema editor
• GenericSetup profile
• Behaviors, schemas in Python

Why do we need them, we have Volto blocks, right? You still need metadata, a title, etcetera. Certainly for larger institutions you need a structure, a schema. Volto itself has schema-based components.

Layout editor. Blocks have properties, like a placeholder, a position. You can type text in a block: "Published on date by author". Then select "date" and link this text to the published date metadata, and select "author" and link it to the author. Save this as a layout for a content type. You can export this to a JSONField in a custom behavior, so you can save it in version control for production.

List of add-ons and other packages that make Volto awesome: https://github.com/collective/awesome-volto

I want to focus on Python performance, so not caching or database performance.

Tools:

• py-spy: Overall mix of the whole live application, top-like.
• repoze.profile: WSGI middleware, slows down application. Profile single request and analyse its call stack by count, call time, etc.
• dis: disassembler for Python at the bytecode level.

Improvements Plone 5.2.0-5.2.3:

• Avoided early providedBy calls
• __getattr__ early exit on common attributes
• zope.interface: some functions are called hundreds of thousands of times when you reindex an index, so a tiny improvement helps a lot. I found various places that could use improvements, and that landed in the package, together with memory improvements by Jason Madden.

Live demo. I call py-spy with sudo because I need to connect to an existing process id.

Future Todo's:

• plone.restapi has optimization potential, all navigation related, but currently it still supports even Plone 4.3. This will likely wait for a 5.2-only or Python3-only branch.
• plone.registry is called too often
• Use python: expressions in all page templates. They are way faster than standard Tales expressions.
• More introspection.
• Move more logic from page templates to Python code

Advice: start introspecting the performance of your application.