So… experiments with Svelte. The 2nd post (read the first one first!)

I showed the beta website to a friend. I said it should be fast. He replied: fast is an understatement. It’s instant.

That’s the good. Now… the bad.

The realization has come that the Svelte community is still growing and many problems are still pretty much unsolved.

Sapper is a super cool project with really good ideas but it’s not that actively being worked on.

The Routify project that I am involved in is evolving at a rapid pace, but it’s nowhere near the maturity that projects like Gatsby or GridSome have.

If my overall goal is to just have a great website, shouldn’t we just use a more mature technology?

One that has validated and tested server side rendering – hydration – code splitting – all the goodies that you need to deliver the quality I want?

The speed benefit of Svelte is obvious, but won’t we have a similar speed if we use React or Vue.js? The speed benefit might simply be in the fact that it’s an SPA, and not in Svelte itself.

If you look at a project like Gatbsy, they have templates like a starter blog. On the Vue.js site there is GridSome (nice website!).

There’s probably many resources to be found and every conceivable problem you run into, somebody has run in before. For example, a current problem I have now is that the Open Graph meta tags (which are used when sharing links on social media) are controlled through the Javascript, whereas they should be in the static HTML to be picked up by LinkedIn, Twitter and the likes.

On our site we like to have different Open Graph preview images depending on which section of the site you link to. If you have control over the HTML output, that is very easy to do. But if everything redirects to index.html, what do you do now?

The answer is something with SSR, but I don’t know how to implement that myself. I have to depend on my router to do it.

This seems to be a solved problem in the GridSome and Gatsby communities as far as I can tell. I would like to hear from someone experienced if that is actually the case or it’s more like a not really. 

Nobody has solved this in the Svelte community as far as I know. This is a problem that could prevent me from shipping the website in the end. It’s not the end of the world but quality problems can pile up.

I guess at some level, everything is a balance act, and who cares about perfect Open Graph tags when you have a faster site? Do you really need something like a sitemap.xml – and a perfect indexable site (actually… yes.)? Which website building techniques from the past — including SEO techniques — are still relevant?

It’s easy to shove the learnings from the past under a rug and ship a new cool website. But what if what you ship is just objectively worse? I read about the problems with SPAs and accessibility I’m almost thinking to just shut down this experiment completely and go for a fully static website.

What’s the point of fast loading if in the process you are making your content inaccessible to part of your audience? That’s just stupid and wildly irresponsible.

(BTW, I see there’s something like Gatsby cloud – I can’t help but wonder why you need a service to deploy a simple website? Did we really all collectively forget how to FTP and SSH?)

So let’s say that doubts are creeping up about whether this is the way to go.

Now, on the other hand. I have invested in learning Svelte. Our codebase is running Svelte. The other frameworks don’t have the same animation capabilities that I plan to use. I would hate to have to write code that looks like the examples here.

So… I think for now I am just going to push through and try to solve as many problems as possible. But there’s a business reality. There’s a set amount of time tp work on our website before we have to move back to client work. If we can’t make something better (technically), we’ll have to shut down the experiment.

Maybe we’ll just provide a content update on our portfolio, ship the CSS improvements we made and call it a day. I don’t know. 

We might run a beta of our website in parallel with the real website and be transparent about the problems with it. There’s clear talk about these problems in the industry. Maybe a combination of our work and better tools will solve the needs that we have in time.

But for now, I really don’t know. I am learning a ton though. So that’s good.