Dus. Op het einde van een recente virtuele conferentie over Svelte wordt er een surprise demo gegeven van een “projectje” door de originele auteur van Svelte (en het Svelte core team).

Eerst wordt er aangekondigd dat Sapper (een framework rond Svelte, vergelijkbaar met Nuxt.js) nooit uit beta gaat en nooit 1.0 gaat bereiken. 

Daarna wordt er een demo gegeven met veel disclaimers van het nieuwe project met de voorlopige naam Svelte Kit. Het is “nog niet volledig bekend wat het gaat worden” (maar het wordt wel geschreven door het core team) en “het is allemaal een work in progress”.

Ze willen het graag privé houden want anders komen er te veel meningen langs, en dan gaan ze het op een bepaald moment releasen.

Deze houding op zich is exemplarisch voor hoe het Svelte team in het algemeen werkt: er is een core team dat wat afgescheiden werkt van al de rest, en die doen hun ding, en dat is het dan.

Die logica begrijp ik op zich wel als je een bepaald type werk gedaan wilt krijgen. Maar het wringt toch soms een beetje. Je kan volgens mij veel publieker werken op een professionelere manier dan het nu gebeurt.

Ten eerste wil ik zeggen dat we hier over een open source context spreken waar mensen van goede wil aan een project werken – en waar ze met de beste intenties proberen werken aan een verbetering van hoe we ontwikkelen voor het web.

Ik heb een aantal mensen van het core team leren kennen en dat zijn fantastische ontwikkelaars. Mensen die hun best doen en wellicht exact dezelfde doelen hebben als mij: een goed framework bouwen waarmee het fijn is om web applicaties te bouwen.

Ik wens ze oprecht veel succes en als gebruiker van zulke frameworks zou ik het geweldig vinden om een oplossing te hebben zoals die gedemo’d werd met:

• File based routing
• Optional static rendering
• Hot module reloading
• Propere error handling

Maar er zijn ook nog een groot aantal dingen zijn onbekend… gaat het “framework” deze zaken ondersteunen?

• Layouts
• Layout resets (of layout block extension)
• Nested routes
• Head injection (met een trappenlogica)
• Parameter logic (wellicht zoals in Sapper)
• Duidelijke controle over SPA output vs SSR output vs Static output
• Svelte preprocess support
• Plugin support of injectie logica in build process (voor bv. SCSS)
• Server routes
• …

Deze reeks vraagtekens leidt voor mij tot de vraag: moet ik nu verder op Svelte inzetten? Dit is effectief een reëele werkvraag, geen vraag voor een hobbyproject ofzo. En mijn antwoord is: voorlopig neen.

Svelte sukkelt al sinds ik het ben beginnen gebruiken met een volwassenheidsprobleem.

Dit is een reëel probleem: mensen vertrouwen Svelte niet voor hun applicaties in productie.

Dit soort aankondigingen, zonder datums, zonder release logica, zonder duidelijke RFCs, op een private repo, bestendigen voor mij het gevoel dat Svelte te veel een hobby project is dat een beetje te populair is geworden.

Maar dat het eigenlijk niet lukt om dit op een professionele manier aan te pakken.

Ik ben actief geweest in de Svelte community sinds augustus vorig jaar.

Ik heb de websites voor de voorbije 2 Svelte conferenties ontworpen en heb efforts gedaan om binnen de Svelte community iets te doen bewegen. Ik heb mee geholpen bij het opbouwen van een community rond Routify.

Net voor de lockdown 1 in België wou ik nog een event geven om mensen te enthousiasmeren om Svelte te beginnen gebruiken.

Maar nu, na de laatste conferentie, is mijn gevoel wel anders.

Voorlopig ben ik er een beetje klaar mee. Ik zeg niet dat het Svelte verhaal voor mij gedaan is. De kernideeën zijn goed. Er worden goede beslissingen gemaakt in de verdere ontwikkeling van Svelte. Maar mijn enthousiasme is bekoeld.

Ik ga wellicht nog meehelpen met de volgende conferentie. Ik blijf geïnteresseerd. Maar om nu fel in te zetten op Svelte? Voor een zijproject zou ik het wellicht wel gebruiken.

Maar voor applicaties die in productie moeten gaan, op het werk? Hmm. Ik denk het niet. Ik wil iets dat beter getest is, dat meer backing heeft. Ik wil echt niet de eerste persoon zijn die SCSS wil integreren in een onbekende dev pipeline die elke 3 maanden van structuur veranderd. Been there, done that.

Ik kijk de kat even uit de boom.