Skip to content

Blog

Flutter vs. Ionic

In mijn vorige blog heb ik Flutter geïntroduceerd en gekeken wat de voordelen zijn. In dit blog ga ik Flutter vergelijken met een andere populair front-end framework : het Ionic Framework. Hiervoor gebruik ik een een aantal metrieken.

Write once, use everywhere

Met deze metriek is gekeken naar  hoeveel van de code die je schrijft hergebruikt kan worden voor beide platformen.

  • Ionic: Geweldige herbruikbaarheid! Het "web app" concept zorgt ervoor dat je de code gemakkelijk kunt hergebruiken - je bouwt uiteindelijk gewoon een web applicatie. De grote componenten bibliotheek van adaptieve componenten (d.w.z. automatisch gestyled voor het platform waar de app op draait) helpt natuurlijk ook.

  • Flutter: Voor Flutter geldt ook een grote herbruikbaarheid. Er is echter geen sprake van een “web app” concept, maar wordt er een echte native app gemaakt. En dit heeft in aantal situaties performance voordelen.

Component Library

Hoe gemakkelijk is het om mooie UI's te bouwen? Moet je veel componenten (UI-elementen) zelf maken en stijlen of heb je een rijke suite van vooraf gebouwde componenten? Passen de componenten zich automatisch aan het onderliggende platform aan? Dat is waar deze metriek over gaat.

  • Ionic: Ionic is in zijn kern een grote set van kant en klaar gestijlde componenten. De compiler/ toolchain die een native app oplevert maakt ook deel uit van het Ionic pakket (afgehandeld via de CLI) maar het maakt gebruik van Capacitor. De componenten die Ionic levert passen zich automatisch aan aan het platform waar de app op draait en daarom maakt Ionic het maken van mooie, native ogende apps een fluitje van een cent!

  • Flutter: Flutter wordt ook geleverd met een uitgebreide suite van ingebouwde widgets, zowel Material Design (Android), als Cupertino (iOS) widgets. Met al deze widgets kun je snel mooi ogende UI's maken zonder al te veel handmatige styling te doen.

Popularity & Coverage

Een levendig ecosysteem is een goede zaak - maar hoe populair is een framework? Dit is niet noodzakelijk hetzelfde, want je kunt een rijk ecosysteem hebben omdat het alternatief verplicht is in een bedrijfstak zonder dat het erg populair is onder ontwikkelaars.

  • Ionic: Ionic is behoorlijk populair. Het stelt (web)ontwikkelaars in staat om native mobiele apps te bouwen op een vrij eenvoudige en snelle manier.

  • Flutter: Ook Flutter is erg populair en deze trend lijkt voorlopig niet te stoppen. Dit is niet verwonderlijk, want Google maakt hier ook veel reclame voor. En wat ook niet onbelangrijk is, er mee werken is echt heel leuk!

Real-World Usage

Het is natuurlijk heel mooi dat je als ontwikkelaar enthousiast bent over een technologie - maar hoe denkt de rest van de wereld erover? 

  • Ionic: Ionic wordt gebruikt door een aantal grote bedrijven. Een mooi voorbeeld is de app van Amtrak. Meer voorbeelden vind je op de Case Studies pagina van Ionic.

  • Flutter: Ondanks dat Flutter relatief nieuw is, worden er al een aantal spannende apps mee gebouwd - Google's AdWords app bijvoorbeeld. Je kunt een volledige lijst vinden in hun showcase, de kans is groot dat we binnenkort nog meer geweldige apps op die pagina te zien krijgen.

Conclusie

Met Flutter en Ionic is het mogelijk om mooie en high performance applicaties ontwikkelen. Mijn voorkeur gaat voor nu alsnog uit naar Ionic en wel om de volgende redenen: 

Ten eerste is het principe van Ionic om het webplatform te gebruiken en waar mogelijk open standaarden te omarmen. En dit vind ik erg belangrijk. Daarnaast kan men met Ionic gebruik maken van alle hulpmiddelen en programmeertalen van het web om applicaties te ontwikkelen voor mobiel, desktop en natuurlijk het web.

Flutter heeft er daarentegen voor gekozen om een op zichzelf staand ecosysteem te creëren dat op gespannen voet staat met de gemeenschappelijke talen, toolsets en standaarden die te vinden zijn in de bredere wereld van hybride app-ontwikkeling.

Flutter levert zeer goede prestaties op mobiel, maar door fundamentele beperkingen van de architectuur is het een mindere keuze voor webgebaseerde implementaties.

Maar uiteindelijk moet je oplossingskeuze gebaseerd zijn die aansluit bij je filosofie, waar en hoe je van plan bent je app te implementeren, en welke vaardigheden je vandaag kent of in de toekomst zou willen leren.