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.
Following up on “design tasks”. Apparently a topic of great interest, because I can keep writing about it?
Both @michaelbierut and @markboulton (two of my design heroes btw) have this belief in the portfolio. We’ve had over 60 candidates for our jobs. Very few people have portfolios that show what we need: digital product design for desktop & mobile.
If we have to deny based on portfolio alone we would not be talking to many people. I wish there were more portfolios out there that clearly show what people can do.
But they’re just not there. Especially in the 0-3 years experience range. I recently saw a very good one explaining product design problems encountered and how they were fixed through considered design work. But this is an exception, definitely not the rule.
What you see is these very generic portfolios, where it’s very easy to either hide behind group work and have it be totally unclear what your role was in the end result. The hiring manager then has to dig to figure out what the designer can do.
This is why I favor seeing personal projects – at least it’s clear who made them – but an argument could be made that this exclusionary; it favors people with lots of free time to dedicate to passion projects.
What I also see is the same school portfolio over and over with the same tasks executed in a different way. School tasks are NOT a portfolio. Maybe your final assignment is a portfolio item, if it’s custom. It’s what you had to do to get your degree.
I would implore designers to only show the parts that they did, and to be clear about process. If you only did the onboarding of some huge application, show that, not the marketing screenshots of the huge app itself showing parts you did not even touch.
It’s extremely important that things are done by -you-. I would rather have a handcoded website that is simple than a SquareSpace template that is fancy.
I would rather have a custom icon that is not perfect than a design that shows usage of a popular icon set and thus no proof of any insight in icon design.
I would rather have a designer show me a feature they made in an existing context (90% of real-life design work), than think they have nothing to show for after a few years of doing practical UI design work.
You don’t need to wait until the whole app design is yours to put in your portfolio. You just need to be clear about what you did (and have permission to show that, obviously).
If this blog post didn’t scare you… we’re still hiring UI designers! Check out our jobs and don’t hesitate to apply and start a conversation.
Ik las zondag een artikel van Monzo, over hoe zij het sollicitatie proces voor designers aanpakken. Twitter stond in vuur en vlam, want er had iemand gezegd dat het een belachelijk proces was (zie tweet), niet echt met een argumentering, gewoon een uitlating. En onder die tweet stonden dan veel gelijkgestemden: ja, dat kan toch niet, wat is dit voor proces, wat doen ze die sollicitanten toch aan?
Een designer die ik erg respecteer noemde het zelfs een ontmenselijkend proces. Weet je, ontmenselijken, dat is iets voor in een concentratiekamp, dat is niet het juiste woord voor een lang sollicitatieproces met een proef.
Toen ik het initiële artikel las, had ik zelf had zoiets van: hmm – ik lees hier een soort reflectie van ons eigen hiring proces bij Mono. Weliswaar een uitgebreidere versie van het proces, maar wel met veel parallellen.
Ik heb ook al eens een sollicitant gevraagd om een proef te maken. Wij laten mensen ook met meerdere personen praten. Wij proberen ook een culture fit te vinden door gerichte vragen te stellen. Wegens de overwegend negatieve reacties op het artikel ben ik dan beginnen graven en vragen stellen.
Waarom uitten designers die ik doorgaans heel erg vertrouw zich zo negatief t.o.v. dit artikel? Zit het dan fout met ons eigen proces? We hebben vorig jaar erg hard gezocht naar uitbreiding voor ons team en we zijn uiteindelijk geland op niemand nieuw in ons team. We hadden een heel goed jaar, met een vertrouwensopbouw en samenwerking in het team van hier tot in Tokio (wel, Barcelona eigenlijk), maar bij de personeelsteller is er niemand bijgekomen. Er is zelfs eentje afgegaan.
Als ondernemer denk je al eens na over het succes van je bedrijf in aantal mensen. Dat is compleet fout, maar het is de menselijke natuur om jezelf te vergelijken met anderen. Ik zie een gelijkaardig bedrijf op korte tijd groeien naar bijna twintig man, en ik heb daar veel gedachten over. Ik heb die situatie al eens gezien, en die is toen compleet misgegaan, dus ik ben daar redelijk weigerachtig tegenover. Nee, ik doe het liever zoals een Clearleft. Traag maar gestaag.
Maar ik wil wel groeien. Ik wil wel vooruit. Dus dan denk je ook eens na: aangezien we niemand gevonden hebben, ligt het dan aan het proces? Zijn wij gewoon te kritisch? Of wat is het nu juist?
Ik keek net naar een video interview met Bart De Waele op TechMag. Ooit heb ik van Bart de kans gekregen om in zijn bedrijf te beginnen. Ik was 18 jaar en ik had geen diploma. In mijn interview heb ik mijn website getoond en moest ik antwoorden op de vraag hoe ik een ongeordende lijst in HTML zou formatteren. Dat was het, en ik mocht beginnen.
Ik heb er enorm veel bijgeleerd en nu ben ik misschien één van die mensen die hij nu als concurrentie beschouwt (alhoewel ik wel denk dat wij met ons kleine bureau van 5 personen wel wat anders gepositioneerd staan dan Duke & Grace). Mijn interviewproces was minimaal.
Wij hebben al kandidaten gemist door te lang te twijfelen. Wij stellen onze eigen processen continu in vraag. Te veel proces is ook niet goed. Een designer merkte op op Twitter dat als het hiring proces overengineered is, dat de rest van het bedrijf wellicht ook zo is. Ik zie wel iets in deze logica.
Tegelijk vind ik het niet echt abnormaal om voor een fundamentele keuze als een nieuwe job door een proces te gaan. Beide partijen leren elkaar kennen. Een half uurtje bellen via Zoom. Een real-life gesprek. Een vragenlijst invullen. Je portfolio en/of design files presenteren. Dat lijken mij logische zaken.
Als je sommige tweets leest lijkt het wel alsof enige vorm van werk van de sollicitant er te veel aan is. Vergis u niet, voor de andere kant is elk werk dat gecreëerd wordt in het proces ook werk, en bestaat dat stukje van het process omdat die andere kant (ik of mijn collega Xavier dus) denkt dat er een fundamentele waarde zit aan dat stukje van het proces. Wij bedenken geen lang proces voor ons eigen plezier. Het proces dient om te valideren of iemand bij het team zou passen. En in dat proces krijgt de persoon de kans dat voor zichzelf ook te valideren.
Het maken van een proef, daar kan lang over gedebatteerd worden. Hoe beter iemand zijn portfolio is, hoe minder nodig het is om bewijs te leveren. Hoe duidelijker het is dat iemand zijn portfolio volledig zelf gemaakt is, hoe beter. Als designer kan je je ook gemakkelijk verbergen achter groepswerk.
Een lange proef die ávonden inneemt, daar ben ik sowieso tegen. Ik denk dat het stuk over de proef het meest problematische was geformuleerd in het initiële artikel en dat daar vooral stevig op werd gereageerd. Ik kan me inbeelden dat enkele designers dan terug denken aan die proef waar zij op gezwoegd hebben en die dan gevolgd werd met een erna een botte weigering. Dat maakt het heel persoonlijk. En dat maakt dit onderwerp ook licht ontvlambaar.
Met het risico nu slechte reclame te hebben gemaakt voor Mono, nodig ik geïnteresseerde interface designers toch uit om in de pen te kruipen en te solliciteren. Bekijk onze jobs, laat iets weten, en ik beloof om transparant te zijn over welk proces er volgt.
Ik ben ook nog steeds benieuwd naar meer meningen over het sollicitatieproces van Monzo, en meningen over goede sollicitatieprocessen in het algemeen. We kunnen allemaal maar bijleren!
Ik zoek een freelance web developer, iemand die in staat is om een design in Figma om te zetten naar responsive HTML/CSS die de webstandaarden volgt.
Omdat ik bij vorige vragen naar development hulp op Twitter bedolven werd onder de e-mails van outsourcing firma’s, zet ik de vraag deze keer in het Nederlands op mijn blog in de hoop iets gerichter te zijn.
Ik geef de voorkeur aan mensen die een eigen handgecodeerde persoonlijke website hebben en een Github profiel dat open source werk aantoont. Klinkt dit als iets voor jou? Stuur een mailtje naar imyourwebdev@johanronsse.be met de relevante links, jouw tarieflogica en je beschikbaarheid.
Ik ging naar de VS, en ik was van plan om een Ford Mustang te huren. Op de site van Hertz had ik er eentje geboekt, voor een vijftal dagen, om van San Francisco naar Portland te rijden. Nu, je hebt niet echt garantie op de exacte auto. Dus je moet een beetje geluk hebben.
Als je bij Hertz boekt, dan is het die auto of een vergelijkbare auto. Aangekomen bij de Hertz locatie vroeg ik benieuwd wat het ging zijn… en uiteindelijk bleek het helaas geen Mustang te zijn, maar een Chevrolet Camaro. Nu, het bleek ook een gloednieuw 2020 model te zijn, SS editie (455hp!), met nog maar 158 mijl op de teller. Nadat ik er een uur mee gereden had, was mijn teleurstelling dat het geen Mustang was al lang weg.
Deurtje open
Algemene indrukken: jezus, dit ding rijdt lekker. Een tikje op de gaspedaal brengt je van een 30km/u naar 50-60km/u met een heerlijke VROEM van de motor.
Ik ben een newbie in de autowereld. Mijn interesse in auto’s is eigenlijk gestart door het sim racen (zie o.a. deze blog post). Ik heb in mijn hele leven nog maar beperkt met andere auto’s dan mijn eigen kleine Japanner gereden.
Dat is dus 200 mijl per uur (321km/h)
Ergens met een Passat, eens met een A1, een A3, eens met een Touareg… een Dockx verhuiswagen… maar nooit lang. Maar nu heb ik mezelf dus iets aangedaan. Door deze ervaring is het verkrijgen van een betere rij-ervaring in mijn dagelijkse leven top of mind geworden.
Deze auto plakte lekker aan de weg, voelde goed aan in de bochten, kon zéér goed optrekken. Buiten dat het een automaat was, was ik helemaal verkocht.
Als een nieuwbakken autogek ben ik nu video’s aan het bekijken over GT86s, Supra’s, Porsche’s – aan het nadenken wat ik eventueel zou kunnen huren, leasen of aanschaffen.
(Met ergens in het achterhoofd ook een idee dat het niet echt milieuvriendelijk is om in 2020 nog een nieuwe sportwagen te kopen. Maar goed.)
Ik heb altijd een hele functionele auto gehad die gewoon diende om van A naar B te gaan. Een viertal jaar geleden heb ik er een road trip mee gedaan en voelde ik in de bergen al een hint van dat autorijden erg leuk kan zijn (ja, voor de vrienden die weten wat mijn auto is, zelfs met die auto). Ik ben ook al heel lang fan van de Ford Mustang.
Zodus kwam er door een recente reis naar SF een plan naar boven: waarom combineer ik dit niet met een roadtrip? Amerika zie je het best met een auto, toch? Ik moet zeggen, ik heb absoluut geen spijt van mijn beslissing. De noordkust van Californië is prachtig en als je er dan nog eens door mag cruisen met zo’n auto. Hot damn. Deze ervaring ga ik nooit meer vergeten.
Dit soort landschap is geen uitzondering
Ik ben al enkele weken mijn vrienden aan het spammen op Whatsapp met foto’s en gedachten over mijn ervaring. Iemand merkte op: Johan is verliefd. Ik zou het daar niet meteen mee vergelijken… maar… als je opstaat en aan een auto denkt. Dan kan je je afvragen wat er mis is.
When I lived in Japan, I went to a meetup that would get organized every few weeks, and it was all about learning Swift. People with different coding levels, from beginners to more advanced devs would meet and share their progress in learning Swift.
I want to start the same thing for Svelte now, this kind of low-key meetup where we talk about what we learned, our struggles, how we are progressing etc. My idea would be to hold a first event with a maximum of 5 persons – and just get together for 1,5 to 2 hours on an evening, drink something, talk about Svelte and we’ll see from there.
It would be organized in Antwerp, probably close to Berchem station.
No current investment in Svelte needed, just an interest and the intent to get started. If you are up to it, send me an e-mail at svelte@johanronse.be or a DM on Twitter.
As a teacher of sorts, I for one don’t want to explain the difference between CSS3 and CSS4 to junior web devs. There is simply no point. CSS is just CSS. We should be happy that it’s stable. We should be happy that we dropped the 3.
What would one hope to achieve with marketing and putting attention on something? Especially when from the start it’s clear that the marketing is insincere…
*(somehow my comment couldn’t pass the spam filter, so I decided to post it here)
Dylan Field, CEO of Figma, talked about three product themes that the team will be focussing on to improve Figma in 2020. He talked about thi on stage at Figma’s first user conference Config, in San Francico, CA.
The three pillars are creation, collaboration, and community.
In true Figma fashion, the presentation was mostly about features that are releasing either very soon or are already released today.
The first improvement in the creation pillar is a better font menu. You can now search for a font instead of scrolling through a long list. You can also see what is already used in the document in a quick list.
When selecting multiple layers, there is now a list of Selection colors that appears on the right side – this lists the colors that are used within the selection, and gives you the ability to directly manipulate them. The Figma team found this to be a big time saver for them ever since implementing the feature.
There are now stretch constraints with autolayout ❤️. Basically instead of aligning to left, right or center there is now a “stretch” option. This got a bunch of applause from the audience. When autolayout was released, this was seen as one of the gaps in the implementation.
Mr. Field showed off support to navigate prototypes with keystrokes – with a demo where he used Xbox accessible gamepad to navigate through a Tinder-like interface.
Using Xbox accessible gamepad to show off Tinder-like UI prototype that works with keystrokes.
Moving on to collaboration. How do we work together more smoothly?
Mr. Field then moved on the show off the plugin relaunch API. This is a way to see where a plugin has been used in the creation of a file. For example, if you click on a Mapsicle map, and you have no idea what Mapsicle is, the layer will link you to the right plugin.
Clickable links within the artboard – to external URLs, or to part of a Figma document – improve Figma’s ability to serve as a Keynote/Powerpoint replacement.
A long-standing issue which allowed prototype viewers to have access to the full design file has been fixed, with better controls on who can access what.
New community improvements allow for open source design. Remixes allow for public feedback to the person who created it. Public profile allow design team to show their work.
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.
I had to wait for 2 hours in a hospital today, so naturally I spend my time writing down long-winded thoughts in Notes.app.We are re-building our company website in Svelte. This seemed to spark some interest on Twitter, so I decided to write about it.
This is a draft for a blog post that will appear on https://mono.company/ . This is the long and wieldy version that needs an edit, but that some might appreciate. It’s about some technical beginnings, it contains some thoughts on routers, and then goes into thoughts about code splitting and ideas about how we could maybe replace WordPress(but probably won’t).
Replacing WordPress with Svelte: why bother?
We’ve recently started experimenting with using Svelte for our website. In this blog post, I’ll talk about some first findings and thoughts.
First of all, why?
To experiment with new technology
To make us excited about working on our site again
To have a codebase we can be proud of
To not have to fight WordPress’s caching mechanisms anymore
To not have to fight trying to make a WordPress site fast
Because we feel we are a bit stuck with our current site when it comes to experimenting with different ways to show our work
It’s an SPA!
First of all, what we are building is is essentially an SPA (Single Page Application).
This method of building a website comes with a different workflow than other methods of building websites, from static site generators to using CMSes like WordPress.
I am used to building sites with CMS’es; for years I experimented with static site generators like Jekyll; but I have never really built a site as an SPA. Up until I have always dismissed the idea, because I felt like there were too many disadvantages to shipping a site through a JS-only bundle. But a-hem -the times are changing – and I feel like I have to get on with the times. Which I might later regret.
SPAs essentially render all of your site’s content through Javascript. The biggest benefit is that an SPA does not need a page refresh. Clicking on navigation items or doing something on the page simply changes the content of the page, not the actual page you are on itself. The URL in the browser might change, but essentially every request you are visiting the same index.html. The requested URL is saved and passed into the router.
The biggest advantage here is speed. An SPA can be very fast. Once the initial bundle is loaded, you can navigate through it without any delays. We can see this in the test version of our site. It is fast. Really fast. And that makes me happy.
Let’s talk about routing first.
Routing
When you visit a web page, the page has a URL. The URL lets the browser know which page you are requesting. In an SPA you redirect every URL to index.html. In index.html, you then “catch” the URL that was requested (e.g. /work) and do something with it: typically render a page.
Routing can be very simple. You can theoretically write a router in 50-60 lines of Javascript (example; I did not write this code, but the fantastic pngwn did)
But a good router has more features than just simply displaying a page. For the Mono website, we chose to use Routify.
Routify is a file-based router. By constructing pages and paths you are essentially constructing routes that the router can derive. For me this is a super logical way to work as opposed to manually defining routes in a JS file.
If you’ve heard about Svelte, you might heard about Sapper. It works in similar ways.
A note on the Svelte ecosystem
It has to be said that Routify is quite new as a project. I am actively involved in this project to improve it myself. The authors are doing the hard work at the moment to create the best router for Svelte 3.
I see my role as promoting the router, explaining how to use it, providing good documentation, QA and being the “voice of the user”. The stated goal is that as a tool, Routify is so easy to that a beginner web developer could work with it and get things done.
Sneak peek of upcoming Routify website
Now, this is a good example of the state of the Svelte ecosystem. It’s young, there’s many things happening, but not a lot of it is locked down. This means that not every problem is solved yet, and some things might require some digging. That might not be up to your taste.
Bundle size
Earlier I mentioned that once the initial bundle is loaded, you can navigate through an SPA without any delay. This brings us to the topic of bundle size.
If your whole website is contained in a JS file, are you not loading a lot of things upfront that you don’t need? If your website has 30 pages and the visitor only visits 2 of them, aren’t you loading things that the visitor doesn’t need? What if they have a slow connection? Wouldn’t loading the code necessary to load 30 pages lead to a long initial render time?
All of the above are the kind of concerns you could have and that you need to be aware of when building SPAs. If your router supports code splitting (like Sapper does) you can migitate most bundle size problems (extended discussion here).
Code splitting is a technique to split your application into different pieces that are loaded on request. For section A you need bundle 1, for section B you need bundle 2, etc.
(Please note that this is how I understand it now – the whole notion of code splitting is pretty new to me).
Now, what about dynamic content?
If we take the example of blog posts, you could load dynamic content over an API and insert it in the page in a dynamic manner.
It makes no sense to make content part of your bundle. For example, we have about 95 blog posts on our web site. We can’t just add this content to our Javascript bundle. The simple act of bundling up, let’s say 15kb of HTML per post would lead to a bundle size of +-1.4Mb. What if the visitor never even visits the journal section of the site?
Having to request content dynamically comes with speed concerns. How and when do you build the page? Where does the content come from? How do we do this?
There are lots of solutions. To do things properly comes with new challenges. I think I am going to sidestep the “build a dynamic blog” problem for now and focus on rebuilding the website in a great way in Svelte except for the blog.
I’ll explain my rationale below.
The best of both worlds?
Our current site runs on WordPress.
Let’s consider the WordPress editing interface for a moment. I like having access to drafts, the multi user editing, the fact that I can easily add code blocks or callouts if I want to. I like that when I upload an image, WordPress automatically generates responsive images from the source, directly on the server. I can hit the publish button and have a post on my website in an instant, with a shareable URL.
Since we are rebuilding out website, it is now tempting to also rebuild the blog in Svelte. But there are a few technical realities.
First of all, the ecosystem around blogging with Svelte is not mature. There is no good sample Svelte blog project. There are no Svelte CMSes. You would essentially have to do the parts that you need from WordPress, from scratch.
There’s so many parts of WordPress that we actively use. We use categories, there is an RSS feed, there’s pagination; URL fallbacks; and that’s just scratching the surface.
And now I’m just describing the generated output side (i.e. what the CMS outputs). Then we have not even considered the user experience of writing and publishing. I’ve learned to love Gutenberg and for me there is no way back.
If we were to try and build the blog in Svelte, and try to “work with the least amount of technology possible” we would probably end up with something far worse in terms of user experience for us on the publisher’s side.
What about using WordPress as a data source and then using WordPress’s REST (or even GraphQL) API to pull in data? This technical solution could work, but creates a disconnect between the publishing side and the viewing side. How would you preview a post when you essentially decoupled the CMS from the data loading? How would you show the correct URL in the editing interface when the WordPress editor lives on a different server? (Or can you combine an SPA codebase in a PHP app?)
My current conclusion is that WordPress is just too powerful to replace, but the rest of our website can perfectly run in Svelte. If the WordPress runs on a subdomain, and the portfolio and every other page of the site is managed by a Svelte codebase, where both sites share the same header and footer, we might just have the best of both worlds – or we might just have created a technical monster.
