Als webdeveloper kan het je tegenwoordig haast niet ontgaan zijn, het Laravel framework. Een populair framework geschreven in PHP voor het ontwikkelen van web applicaties. Met Laravel kan je zowel een losse API als een complete full-stack applicatie ontwikkelen. Zo heeft Laravel een heleboel standaard functionaliteiten zoals een ORM, dependency injection, queues en scheduled jobs. Daarnaast kan er met een extra package en enkele commands een compleet authenticatie systeem gegenereerd worden. Hierdoor is het een zeer geschikt framework voor de snelle realisatie van een proof of concept applicatie.
Echter komen met al deze functionaliteiten ook de nodige tools bij kijken die je moet installeren op je machine. Zo heb je in elk geval PHP en Composer nodig en ontkom je eigenlijk ook niet aan een database als MySQL. Als de applicatie eenmaal iets uitgebreider wordt kom je ook al snel dingen tegen als NPM, NodeJS en Redis voor bijvoorbeeld het maken van een WebSocket server of het compileren van frontend assets. Uiteindelijk zorgt dit ervoor dat iedereen in het team en op de productie omgeving vanalles moet installeren en vervolgens ook nog dezelfde versie moet draaien. Hierdoor loop je al snel het risico dat je het welbekende probleem tegenkomt: "maar op mijn machine werkt het gewoon hoor".
Docker? Eerst nog even iets anders
Als oplossing voor dit probleem hadden de developers van Laravel al snel een oplossing. Virtuele Machines!
Met een Virtuele Machine werd dit probleem van verschillende ontwikkel- en productieomgevingen opgelost voordat Docker de standaard was. Laravel heeft hiervoor de Homestead package ontwikkeld. Dit is een Vagrant box voorverpakt met alle tools die je die je in je dagelijkse Laravel development tegenkomt. Vagrant is hierin de tool voor het beheren van virtuele machines in combinatie met VirtualBox of Parallels. Hierdoor had elke developer dezelfde ontwikkelomgeving en hoefde deze alleen nog maar nagebouwd te worden op de productieomgeving.
Deze oplossing werkt in principe prima alleen is het probleem dat een Virtuele machine relatief zwaar is wat betreft hardwaregebruik. Voor elke applicatie heb je een nieuwe VM nodig en uiteindelijk neemt dit ook wel de nodige opslagruimte in beslag. Het werkt maar is niet de ideale oplossing.
Docker, dé oplossing!
Docker biedt voor het probleem van hardwaregebruik en snelheid de ideale oplossing. Docker is een platform voor het beheren van container applicaties. De containers zijn een stuk minder zwaar in gebruik dan virtuele machines. Daarnaast zijn containers snel en zijn ze makkelijk uitbreidbaar. Voor een uitgebreide vergelijking tussen containers en virtuele machines raad ik dit artikel aan.
Uiteindelijk heeft Laravel hiervoor ook een package gemaakt genaamd Sail. Hiermee kan de hele stack die voor Laravel nodig is gebruikt wordon zonder zelf ook maar iets te installeren. Het enige wat je nodig hebt is een Docker installatie en wanneer er Windows gebruikt wordt WSL2 (Windows Subsystem for Linux).
Aan de slag!
Nu gaan we daadwerkelijk aan de slag een een Laravel project opzetten met Docker. Zorg ervoor dat je Docker en Docker Compose hebt geinstalleerd. Bij Windows en macOS zit Docker Compose standaard bij je Docker Desktop installatie. Alleen voor een Linux OS is het noodzakelijk Docker Compose apart te installeren. Voor de installatie instructies van Docker zie de Docker Docs.
Aanmaken project
Start een terminal op en voer de commando hieronder uit.
Let op: als Windows gebruiker moet je in de WSL terminal zitten door wsl uit te voeren in PowerShell of Command Prompt.
curl -s https://laravel.build/voorbeeld-app |bash
Deze commando maakt een nieuw Laravel project aan in de map voorbeeld-app en installeerd alle Composer dependencies. Uiteraard kan de tekst voorbeeld-app veranderd worden naar de naam van je project.
Ga vervolgens naar de map van je nieuwe project door de volgende commando te doen:
cd voorbeeld-app
Vanuit deze map kan de applicatie gestart worden in Docker. Dit gebeurt met de volgende commando:
./vendor/bin/sail up
Nu worden alle Docker images gedownload de containers gestart. Als alles goed is verlopen zou het project beschikbaar moeten zijn op localhost. Ga naar de browser en typ localhost in de url balk om dit te verifieren. Als het goed is is nu het volgende scherm te zien.
Gefeliciteerd, je hebt nu een Laravel applicatie draaien en kan aan de slag om een prachtige applicatie te ontwikkelen!🎉
Dependencies installeren vanuit een git repository
Het kan natuurlijk voorkomen dat jij niet degene bent die een nieuw project opzet in het team. Je zal dan hoogstwaarschijnlijk het project clonen via git alleen ontbreken vervolgens alle dependencies. Ook hier is aan gedacht en er is daar ook een commando voor.
Deze commando zal een aparte docker container aanmaken (en vervolgens ook verwijderen) en vanuit daar alle Composer dependencies installeren zodat je zelf geen Composer hoeft te installeren op je eigen machine.
Verder lezen
Ben je nou nieuwsgierig geworden naar Laravel of Docker? Kijk dan eens op de volgende sites.
Development en webdesign zijn termen die vaak door elkaar worden gehaald. Hoewel het twee aparte taken zijn varen ze wel in hetzelfde vaarwater en zullen ze in een groot deel van de web-trajecten overlappen. Uit mijn ervaring blijkt dat veel personen die in één van deze twee categorieën werken ook behendig zijn in de ander, maar hebben altijd voorkeur voor hun eigen onderdeel. Welke mogelijkheden zijn er voor wie als we het hebben over doorgroeien (als designer)?
Er zijn een aantal mogelijkheden waar je uit kan kiezen als designer: je wil doorleren en de code echt gaan beheersen, je wil omscholen en het design achter je laten, je vindt allebei leuk en blijft er tussenin hangen, of je sluit de code helemaal uit.
Vergeet het design
Er is een mogelijkheid om het designen helemaal te laten voor wat het is en je vol te storten op de code. Dit is iets wat ik niet zou aanraden; veel bedrijven zijn blij met developers die ook designkennis hebben. Om binnen organisaties de overlap tussen design en development zo soepel mogelijk te laten lopen zijn een aantal, of tenminste één zo’n persoon nodig. Je kunt dus een belangrijke rol gaan spelen.
In het begin heb je nog niet veel aan je design skills, dit komt omdat je nog heel beperkt bent in wat je kunt maken. In een later stadium zul je gaan merken dat je niet alleen vette dingen kunt maken, maar ook verzinnen. Je kunt dan nauw samenwerken met de designers, en ze zullen ook blij zijn met jou.
Leer het bij: Code, Code, Code!
In het begin is het niet te overzien; verschillende tools, talen & frameworks; Vue, Angular, React etc!
Ook worden er veel fancy Engelse namen en programmeertalen gebruikt in dagelijks communicatie. Afhankelijk van je doel is de leercurve best steil, zeker als je alleen een design achtergrond hebt. Er zijn ook veel overeenkomsten, die zie je vooral terug in HTML/CSS. Denk aan eigenschappen van elementen, werkstructuur en het uiteindelijke doel; gave dingen maken!
Ik heb gemerkt dat het iets is wat je over je heen moet laten komen. Veel stof is logischer en minder ingewikkeld dan hoe het er in eerste instantie uitziet. Als designer heb je ook te maken met projectmatig werken, het einddoel waarborgen en een professioneel product afleveren. De tooling is alleen anders.
Het moeilijkste om te leren is het denken als een developer; een soort analytische, oplossingsgerichte visie die je moet hebben, naast je algemene programmeer vaardigheden natuurlijk. Met genoeg oefening is dit zeker onder de knie te krijgen en moeten de meeste designers met een beetje geduld, hier wel uit gaan komen.
De dubbele pet: WordPress
In mijn geval was ik meer vaardig in design terwijl ik meer interesse had voor de development. Als tussenoplossing daarvoor maakte ik gebruik van WordPress.
Een veel gebruikt CMS die theme based veel mogelijkheden biedt. Na het maken van het design kon ik het in een populaire builder zoals Avada of Elementor het design ongeveer nabouwen. Het design van het web is voor klein MKB veruit het belangrijkst. De onderliggende techniek is niet zo belangrijk. Door een behoorlijke groep mensen word de designer ook gezien als developer. Als designer heb je dus een dubbele pet als je het hebt over theme based werken.
De technische kennis beperkt zich tot basis HTML/CSS vaardigheden wat goed te overzien is. Een groot nadeel van WordPress is dat het gebruik maakt van externe plug-in’s en dat er veel updates gaande zijn. Op het moment dat er hier ergens wat fout gaat ben je afhankelijk van je technische kennis of de bouwer van het thema/de plug-in.
Sluit het uit: no-code
No-code frameworks zijn programma’s waarmee niet-technische mensen software kunnen ontwikkelen zonder te coderen. Deze tools hebben meestal een gebruiksvriendelijke UI en dingen als een drag-and-drop-mogelijkheid, zodat er makkelijk assets toegevoegd kunnen worden zonder technische skills. Dus wil je ver van de code vandaan blijven? Dit is je beste optie.
Wat zijn de grote voordelen van het maken van programma's zonder zelfs de code te schrijven? Snel, goedkoop en een all-in-one oplossing zijn slechts enkele voorbeelden van hoe het ontwikkelen met no-code voordelen kan bieden. Om die redenen is het een steeds populairdere optie bij designers. Mede door die groeiende interesse ontwikkelen de platformen zichzelf ook. Een bekend no-code voorbeeld is Webflow.com
Het zijn niet alleen maar positieve punten. Aanpassing van software in no-code platforms is beperkt. Anders gezegd, je moet het doen met wat het platform biedt. Ook met het oog op de toekomst is dit een risico waar je rekening mee moet houden.
Veel websites, webwinkels en blogs maken gebruik van een CSS framework. Erg populair is nog altijd Twitter Bootstrap. Een ervaren webdesigner / frontender herkent het direct zonder in de code te hoeven kijken. Grafisch gezien lijken ze namelijk vaak sterk op elkaar. Bootstrap is snel inzetbaar en je hebt in no-time een responsive website staan. Zelf de source downloaden en Bootstrap builden wordt helaas nog vaak overgeslagen. Men plakt de productie CDN link in de head en de overrides worden er aan toegevoegd. Er kleven hier echter een aantal nadelen aan. Vaak wordt er maar een klein deel van de hele library gebruikt, terwijl de browser de volledige stylesheet in moet laden. Dit gaat ten koste van de performance en de UX; verspringende fontsizes en kleuren zie ik helaas nog te vaak.
Ik ben zelf lang weggebleven bij Bootstrap, met de overtuiging alleen te schrijven wat de browser nodig heeft. Niets meer en niets minder.
Tegenwoordig zijn er slimme oplossingen bedacht om toch gebruik te maken van een CSS framework, met alleen de styling die daadwerkelijk nodig is. Een tweetal die ik hier uit wil lichten is Tailwind CSS en Windi CSS.
Het concept van beide frameworks
Het idee is dat je je html schrijft met de classes die je nodig hebt voor je designs en componenten. Tijdens development heb je alle classes tot je beschikking. Een responsive grid, tools, spacing, backgrounds, kleuren, vormen, animaties, noem het maar op. Op het moment dat je gaat builden voor productie, worden de aangegeven templates gescand en wordt er een CSS bestand gegenereerd met alleen de classes die je gebruikt hebt. Resultaat: een optimale stylesheet van slechts enkele kilobytes!
Tailwind
De Tailwind CSS library kan wel oplopen tot 12Mb (unminified), dus je zult begrijpen dat er echt heel veel beschikbaar is. Een groot nadeel van Tailwind was dat tijdens development de gehele stylesheet in de browser geladen werd. Er zat zoveel in dat sommige browsers 'laggy' werden en soms zelfs vastliepen! Vanaf versie 2.1 is dit opgelost door een JIT-compiler. Bekijk het filmpje op deze pagina voor een goede uitleg.
Nu kan je alleen nog geen classes toevoegen in de inspector, als ze niet aanwezig zijn. Een ander nadeel is dat je soms erg lange class names krijgt in je html. Qua leesbaarheid wordt het daar niet beter van. Hier heeft Windi CSS de oplossingen voor.
Windi
Net als Tailwind, worden tijdens development alleen de classes gegeneerd die je gebruikt, in plaats van de hele bibliotheek. Maar dan vraag je je af: hoe pas ik dan in de inspector mijn classes aan, zodat ik kan zien wat ik verander? Hier heeft Windi gelukkig aan gedacht. Voeg 'virtual:windi-devtools' aan je main entry. Pas je nu de HTML aan in de inspector, zal Windi on-the-fly de classes toevoegen aan de head van je pagina, een onmisbare feature.
Om classes leesbaarder te houden, kan er gebruik gemaakt worden van handige shortcuts. Je voegt eenmalig een custom classname toe aan de config met hierin de verzameling van de benodigde classes. Ook is het erg eenvoudig om varianten te gebruiken.
Aan de slag!
Beide frameworks zijn geschikt voor meerdere build tools, andere frameworks en IDE ondersteuning.