Experimenting with Svelte (2): The doubts

- Posted in development javascript svelte website workflow - 3 comments

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.

3 Comments

  • Jan says:

    I can’t loose the feeling you are trying to fix the wrong problem. It’s not Svelte that’s the problem here, it’s trying to force your blog to be a SPA, a single-page _application_, a blogpost is a document, not an application.

  • Colin says:

    All these are just my opinions, as I’m thinking through some of these issues myself …

    Seems like everyone who’s invested in WP at scale and wants better load times but doesn’t have the time to recreate WP’s feature set has decided on a WP back end, Gatsby-generated pages deployed on a CDN, React rather than Svelte since that’s what’s being used in WP and Gatsby. This stack is being packaged and sold, there’s VC and developer investment, and due to that any niche problem is likely to have already been solved or addressed. (That doesn’t preclude you from using Svelte entirely, or even abandoning WP’s templates or routing, since once you have headless WP accessible you can have any front end you like accessing that content, of course.)

    I think that Svelte and an improved Sapper would be most satisfying from an _engineering_ perspective to work in, but realistically I can’t see it right now for larger businesses or sites with a lot of frequently-updated content, which is unfortunate, but understandable; React was expressly built to deal with problems only seen at scale – navigating a potentially infinite nodelist in a browser, with audiences measured in the billions, with thousands of developers – and it is indeed overkill for pretty much everyone at a smaller scale, but most businesses at any scale are going to opt for the solution that can potentially serve millions, rather than the solution that’d be fine for any smaller group, and that means all the resources will continue to pour into that bucket.

    For smaller projects – landing pages, documentation, personal sites with infrequent changes – with one or a few developers Svelte’s ideal because of its simplicity, and its approach/paradigm makes a lot more sense to me. I’m looking forward to doing more with it on a small scale and personally, but not yet as an app to hang a company on, and maybe not ever, which is more the fault of the marketplace rather than Svelte itself (cf Betamax v VHS). It may be that over time React will adopt some of the simplicity, if not the paradigm (there’ll be a virtual dom forever, I think).

    But since you’re already all-in on Svelte, have you checked out the work on a forked Sapper with SSG? `https://www.youtube.com/watch?v=JEH0V-zNGUk`

    Also you may enjoy an interview with the guy running the NYT on their stack, with some front-end thoughts: `https://stackshare.io/posts/evolution-of-new-york-times-tech-stack`

  • Elliot says:

    Well, am using Svelte and am not having any problems with it

Leave a Reply

Your email address will not be published. Required fields are marked *