This is a follow-up to Experimenting with Svelte (2): the doubts.

In the last post I expressed my doubts about using Svelte for a production website. Some people have commented on this by saying that we might be using the wrong tool for the job.

They say a website is a document, so static HTML might just be enough? They say: why would you try and use an app-like framework for a document?

This reminds me of the age-old “is it a website or an app” discussion. Here’s a thought exercise. When you’re booking a ticket for a flight, are you in a website or in an app? For years I’ve liked to divide things into neat boxes: here’s a marketing website and it has needs x, y and z. Here’s an app behind a login and it has needs a, b and c.

The thing is that the line is not always so clear-cut. The flight booking website is a good example. There are static information pages, but the booking experience is an app-like experience.

Both experiences live on the same website and typically use the same design system. You have to adapt the UI to the page the person is visiting. Maybe for reading your typography is based on 16px, but then in the app-like experience you go down to 14px base so there is enough room for a complex UI control, like a seat picker.

In this case we are talking about a portfolio website for a UI design firm. I want to argue that if we revert to a static HTML website (well, actually we would be reverting to WordPress), we don’t have the possibilities that we have with Svelte. I am talking about:

• Animations and the possibilities thereof in the future
• Abstraction of complex code (i.e. responsive images, skinnable device frames, lightboxes, sliders etc.) with a good developer experience
• Ability to deliver a highly interactive experience
• Built with a development stack that is realistic to maintain changes to it (i.e. a tool that has state management built-in, as opposed to traditional jQuery-like methods that lead to spaghetti JS)

Now somebody is going to argue that you can do all of the above (or at least part in a static website as well. But the development experience is simply not the same. And the end result is also not the same. We know because we we’re trying both.

We came up with a plan. What if we work with a two-pronged approach?

• Do a version in WordPress that is the best it can be
• Do a version in Svelte that is the best it can be

It’s interesting to compare both solutions. They each have their own benefits.

We might end up with the WordPress version, because there are inherent accessibility and SEO problems with the Svelte version that I believe makes it problematic to ship that solution. And before anyone comments to use Gatsby or Gridsome or something like that, first of all I am going to repeat that I dislike writing React, and I don’t know enough about Vue.js – and second of all, the same problems exist in these frameworks.

I have a separate post lined up exploring that.

Aside from any quality discussions about Svelte vs static website vs using something like Gatsby, it’s important to talk about the aspirational aspect of the work.

You can use your website project as a chance to do something new, and to show what you are capable of.

As a consultancy, we are a team of persons, solving interface design problems. If we the creation of our website as a project to bring our techniques to a new level, it’s the perfect excuse to elarn as a group.

Compare, and make a decision. And ship it. So that’s we are doing right now.