Menu

WooCommerce vs Shopify – Clash of the Titans deel 3 – De Techniek

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on tumblr
Share on email

De techniek achter Shopify en WooCommerce, wie wint?

In mijn twee vorige blogposts heb ik het gehad over respectievelijk de functionaliteiten en de kosten van het hebben van een webwinkel in Shopify, danwel WooCommerce. Vandaag beëindig ik dit drieluik graag met een blik op de techniek achter beide systemen.

WooCommerce – Open Source Pur Sang

WordPress is geschreven in PHP. En daar is een heel goede reden voor. In de tijd dat WordPress werd ontwikkeld was PHP de meest verspreide programmeertaal voor het Internet. En wanneer je op zoek was naar een betaalbaar hosting pakket eigenlijk de enige optie. We kunnen zonder enige twijfel zeggen, dat PHP het Internet groot heeft gemaakt. En zonder PHP zou het Internet zoals wij het nu kennen waarschijnlijk ondenkbaar zijn. Vrijwel ieder populair Open Source programma op het Internet is hier in geschreven.

Toch is PHP beslist niet de snelste, meest efficiënte of ‘beste’ programmeertaal.

Plugins en WordPress

WordPress heeft zijn succes te danken aan de relatief eenvoudige plugin structuur. Je kan zomaar een extra functionaliteit toevoegen aan WordPress en je hoeft hier niets ‘extra’ voor te doen. Deze flexibiliteit komt wel tegen een prijs.Bij het laden van iedere webpagina wordt een lijstje afgewerkt om te kijken, of bepaalde plugins op bepaalde momenten ‘iets aan willen passen’ aan de gegevens. Deze acties kosten tijd en dat is ook één van de redenen, dat een groot aantal plugins een site langzamer maken.

Ditzelfde gebeurt met thema’s. Soms hoor ik geluiden van ontwikkelaars die het liefst zo veel mogelijkheden in thema’s willen stoppen. Behalve dat dit qua robuustheid van de site een ongelukkige keuze is, lost dit ook niets op met betrekking tot het performance probleem. Sterker nog, thema’s met te veel ingebouwde functionaliteit vertragen WordPress eigenlijk nog meer.

Plugin conflicten

Een tweede mogelijk probleem wordt gevormd door plugin conflicten. Eén heel eenvoudig type conflict wordt gevormd door plugins die gelijknamige gegevenstypen implementeren. Stel je voor, je wilt voor je website een gegevenstype ‘Portfolio’ hebben. Hiervoor installeer je een plugin. Enkele maanden later koop je een thema met ‘ingebouwd’ Portfolio gegevenstype. En hoewel beide gegevenstypen dezelfde naam hebben, hoeven ze niet per definitie dezelfde informatie vast te leggen. En hier kan dan behoorlijk wat ‘vreemd’ gaan bij het gebruik van plugin en thema met eenzelfde gegevenstype.

Maar er zijn meer problemen denkbaar. Het is een ‘goede gewoonte’ om iedere functie (een stukje zelfstandig opererende programmatuur) door een voorvoegsel uniek te maken. Dus in plaats van een functie doe_iets te noemen, zou ik het met wxp_ (van WordXPression) vooraf laten gaan, waardoor het wxp_doe_iets wordt. Zo kan ik er van uitgaan, dat een functienaam uniek is. En hoewel dit een heel goede gewoonte is, wordt dit niet voor iedere plugin gedaan. En hierdoor krijg je soms conflicten, omdat een plugin de functie ‘doe_iets’ aan wil roepen, maar in plaats van de eigen ‘doe_iets’, wordt de ‘doe_iets’ van een andere plugin aangeroepen, die iets heel anders doet. Met alle gevolgen van dien.

Lees ook  En opnieuw vijf plugins die je website meer power (kunnen) geven...

En tenslotte nog het probleem van de ‘meegeleverde bibliotheken’. Om bepaalde dingen uit te voeren, is het soms nodig een (openbare) programmabibliotheek mee te leveren. En van zo’n bibliotheek zijn vaak verschillende versies in omloop. Het kan dus gebeuren, dat ik dus ‘versie 1.6’ van een bibliotheek in plugin A heb en ‘versie 1.8’ in plugin B. Als plugin B als laatste wordt geactiveerd, zal ‘versie 1.6’ geladen zijn. Als er in 1.8 een functie voorkomt, die niet in 1.6 voorkomt, zal dit een fout opleveren.

Code kwaliteit en veiligheid

Bovendien is niet iedere plugin even goed geprogrammeerd. Er is geen ‘kwaliteitsborging’ voor plugins. Iedere plugin die je installeert kan veiligheidslekken hebben of -erger nog- heel bewust uit zijn op het ‘implementeren van een achterdeurtje’. Want iedere plugin kan in principe overal bij op het systeem.

 

Shopify – Een verrekt snelle black box

Officieel weet ik heel weinig van de technische oplossing achter Shopify. De makers hebben zelfs niet bekend gemaakt in welke programmeertaal Shopify geschreven is, hoewel kijkend naar het programmeurs team en hun CV’s op LinkedIn, ik vermoed, dat ik er niet ver naast zal zitten, wanneer ik gok dat Shopify in Ruby on Rails is geschreven.

Deze taal is veel sneller in de uitvoering dan PHP. Bovendien is dit makkelijker te gebruiken op een gedistribueerd platform als Shopify.

Geen hostingproblemen

Omdat Shopify één groot gedeeld platform is, heb je niets met de hosting te maken. Dat wordt voor je gedaan. Voordeel hiervan is, dat je ook zelf niets aan de bewaking van het online zijn van je website zal hoeven te doen. Het Shopify team heeft storingen al ontdekt, voor jij de kans krijgt deze te ontdekken. Bovendien is alles redundant uitgevoerd (iets wat een kapitaal zou kosten, als je dit zelf zou moeten verzorgen), waardoor de kans dat er iets merkbaar mis gaat minimaal is.

Een App is geen Plugin

Het verschil tussen een App en een Plugin is meer dan een verschil in naam. Een Shopify App is -zoals een aantal keren eerder al aangegeven- niet een onderdeel van Shopify, maar daadwerkelijk een ander programma, waarmee je even een ‘uitstapje’ maakt naar het systeem van een ander, een systeem wat van jou toestemming heeft gekregen om met jouw Shopify data te ‘praten’.

Het voordeel hiervan is, dat er niets wordt geladen wat het systeem trager kan maken. Ook ‘plugin conflicten’ zullen niet voorkomen. Op het moment dat je immers de app gebruikt, ben je even ‘uit Shopify’. Dat zie je ook direct door de andere url die er ineens in je browser staat.

Lees ook  2017 in Blogberichten

Nadelen van de App structuur.

Persoonlijk, vanuit mijn verleden als System Integrator, vind ik dit een geweldige oplossing. Shopify is oneindig uit te breiden, maar zonder enig risico voor de performance. Toch kleven hier ook enige nadelen aan, die goed overwogen moeten worden.

Allereerst is de ontwikkeling van een eigen app duurder dan de ontwikkeling van een plugin. Dit heeft een aantal redenen. De eerste reden is, omdat de app moet communiceren via de API, wat iets omslachtiger is dan direct functies van het systeem zelf aan te kunnen roepen.

Ten tweede is het noodzakelijk een complete gebruikersinterface voor het beheren van de app gegevens te ontwikkelen. Je kan niet, zoals bij WooCommerce, even ‘inhaken’ op bestaande schermen.

En een derde punt wat de kosten doet stijgen bij een maatwerk app, is het feit dat deze ook gehost moet worden. Je bent met een maatwerk app dus helemaal niet van het hosten af… je moet een complexer systeem gaan hosten. En dat kost geld.

Continuiteit

Een vierde gevaar is de continuïteit. Op het moment dat ik in Shopify een app ga gebruiken, is het theoretisch mogelijk dat de maker van de éne op de andere dag besluit met zijn dienst te stoppen. En dan ben jij een wezenlijk stuk functionaliteit uit je winkel kwijt! Vergelijk je dit met een plugin voor WooCommerce, is dit risico veel kleiner. Want ook al stopt iemand met de plugin, hij stopt met het onderhoud. De plugin zelf blijft bestaan. Je hebt voldoende tijd om een nieuwe plugin met vervangende functionaliteit te vinden en te testen.

Veel apps op Shopify hebben een abonnementsstructuur. En dat is eigenlijk prima. Want zolang de maker van de app een stroom geld binnen krijgt, heeft hij alle redenen om de app in de lucht te houden. Een app die ‘gekocht’ wordt door een eenmalige betaling is hierin veel riskanter. Want het ‘draaiend houden’ van de app kost de maker geld. Wat doet hij, indien na één of twee jaar zijn app geen nieuwe gebruikers meer krijgt?

Thema’s

Zowel Shopify als WooCommerce hebben een thema nodig voor de vormgeving van de site. In WordPress/WooCommerce is zo’n thema helemaal ontwikkeld in PHP. Door mijn ervaring met PHP zie ik het niet als een direct probleem, maar voor veel webdesigners is het ‘bouwen van een WordPress thema’ een nachtmerrie. Eén van de redenen, dat ik ben begonnen met een cursus om webdesigners te leren zelf hun thema’s te bouwen.

Lees ook  Nog meer snelheidsverbetering met WordPress en WooCommerce

WordPress premium themes

Door deze complexiteit is er een markt ontstaan voor zogenaamde ‘Premium Theme’s’, veelal thema’s met een enorme keur aan instelmogelijkheden om het thema helemaal ‘op maat’ te maken. Thema’s als Divi, Enfold, Avada en Flatsome geven je een bijna oneindige combinatie van mogelijkheden om een eigen stijl te krijgen met je website. Maar dat komt wel met een prijs. Dit soort ‘super flexibele thema’s’  zijn meestal ook beruchte snelheidsvreters en met name het steeds populairder wordende Divi drijft al menig webwinkel-eigenaar tot waanzin.

Liquid

Shopify heeft een eigen ‘programmeertaal’ ontwikkeld voor het maken van thema’s. Liquid. Het kost mij vier weken om iemand die al overweg kan met HTML te trainen om ook WordPress thema’s te kunnen ontwikkelen. Het kost mij minder dan vier uur om iemand met Liquid te leren werken. Liquid is logisch en lijkt bijna op natuurlijke taal. Het is nog steeds niet geschikt voor de eindgebruiker, maar iemand die met HTML overweg kan, werkt ook zo met Liquid.

Liquid biedt niet de vergaande mogelijkheden die PHP biedt om het thema flexibel te maken. Om iets ‘eigens’ te willen, zal de webwinkel eigenaar al snel beroep op een professional moeten doen. Maar daar staat tegenover, dat deze aanpassingen veel makkelijker (en dus goedkoper) door te voeren zijn.

Samenvatting

En weer geen conclusies. Alleen nogmaals stil staan bij de belangrijkste verschillen tussen beide platforms. Aan de éne kant WooCommerce. Een geweldig pakket wanneer je met een webwinkel van start wilt gaan. Naarmate je winkel en het verkeer naar je winkel groeien, zal ook de technische complexiteit groeien… en zal mogelijk performance een serieus probleem worden. Dan heb je altijd de keuze om WooCommerce te blijven gebruiken en meer geld in de kwaliteit van je hosting te steken, of om over te stappen naar Shopify.

Shopify is vooral geschikt voor de ondernemer die er serieus van overtuigd is, dat hij vanaf het begin goed zal verdienen. Mijn persoonlijk advies is, indien je geen serieuze plannen hebt om gedurende het eerste jaar minimaal 30.000 (of liever 50.000) euro omzet te maken met eCommerce, Shopify voorlopig niet te overwegen. Heb je wel plannen in die richting, dan kom ik graag met jou in contact om voor jou een ‘demonstratiewinkel’ op te zetten, waarin je zelf wat kan ‘spelen’ met de mogelijkheden.

Of plan gewoon je eigen afspraak in om via Skype eens over de mogelijkheden van Shopify voor jou te overleggen.

Natuurlijk kan je ook naar één van de eCommerce trainingen van WordXPression komen:

  • DOWNLOAD GRATIS

  • Meest recente berichten

  • Tags

  • Categorieën

  • Een webwinkel starten?

  • Een Webwinkel, begeleiding en alle training die je nodig hebt voor een acceptabele prijs?
    Lees dan meer. Nu hoeft niets jouw succes meer in de weg te staan!

  • Geef een reactie

    Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *