Googles ontwikkelplatform Flutter krijgt ondersteuning voor Windows-applicaties

Google kondigt Flutter voor Windows aan. Ontwikkelaars kunnen het UI-crossplatformframework gebruiken om applicaties te maken voor Windows, naast Android, iOS en browsers. In de komende maanden maakt Google meer bekend over stabiele ondersteuning voor macOS en Linux.

De stabiele ondersteuning voor Windows is aanwezig in versie 2.1 van Flutter. Daarnaast heeft Google bij deze versie prestatieverbeteringen en bugfixes doorgevoerd bij het framework voor gebruikersinterfaces. Google kondigde Flutter in 2017 aan en een jaar later verschenen de bèta en de stabiele release. Het gaat om een opensource-UI-framework waarmee ontwikkelaars op basis van een enkele codebase applicaties voor Android, iOS, het web en nu ook, met stabiele ondersteuning, Windows kunnen maken.

Microsoft heeft actief meegewerkt aan ondersteuning voor zijn besturingssysteem. Onder andere het team dat verantwoordelijk is voor de Fluent-ontwerpelementen van Windows, heeft bijgedragen. Net als bij Android en iOS bestaat de Windows-implementatie uit het Dart-framework en een C++-engine. De Flutter-engine communiceert met Windows om UI-elementen, zoals het aanpassen van vensters of het wijzigen van de dpi, mogelijk te maken.

Google benadrukt dat applicaties voor de desktop meer zijn dan alleen mobiele apps voor een groter scherm. Ze moeten bijvoorbeeld primair ontworpen worden voor gebruik met toetsenbord en muis en haken ook in op andere api's van het besturingssysteem. Zo kunnen apps ontwikkeld met Flutter direct met Windows-api's van Win32, COM en Windows Runtime communiceren via een C-tussenlaag van Dart of indirect via een met C++ geschreven plug-in. Ontwikkelaars kunnen hun uiteindelijke app in een installer verpakken en deze in de Microsoft Store plaatsen.

Reacties (47)

[Wolfos]

Apart dat Google zoveel programmeertalen pusht. Dit werkt met Dart, op Android pushen ze Kotlin en dan hebben ze ook nog Go. Hun cloudomgevingen werken dan weer met GoogleScript, en Angular draait op TypeScript van Microsoft.

Ik snap dat ze dingen willen proberen maar het lijkt me niet goed voor het ecosysteem van deze nieuwe talen om ieder framework op iets anders te bouwen.

[Reactie gewijzigd door Wolfos op 22 juli 2024 16:13]

[bruudt]

De adaptatie van programmeertalen heeft tijd nodig. Flutter is begonnen als framework voor Android en iOS, waarmee je in één taal, namelijk Dart, apps kunt schrijven. Hiermee is dus geen noodzaak meer om Java/Kotlin voor Android én Objective-C/Swift voor iOS te kennen. Vervolgens kwam Flutter voor Web, waarmee je dus wederom in Dart webapplicaties kunt schrijven en tenslotte is er ondersteuning voor desktop: Linux, Windows en Macos toegevoegd en kun je wederom je app, geschreven in Dart, laten runnen.

Google is overigens niet meer aan het proberen met Flutter/Dart. Hun nieuwe besturingssysteem Fuchsia werkt ook met Flutter/Dart. De tooling van Flutter is geschreven in Dart. Het Flutter framework zelf is geschreven Dart. Het draait zowel tegen een VM (wat hot reload mogelijk maakt) én kan gecompileerd worden naar machinecode (optimale performance), waardoor het ideaal voor ontwikkeling en productieve toepassing.

Doordat alle applicaties in Flutter op dezelfde manier werken (via Google's Skia rendering engine), hoef je juist minder platform specifieke zaken te weten in vergelijking met native ontwikkeling op de zes verschillende platforms. Het ontwikkelen van apps voor 6 verschillende platforms vanuit 1 codebase is een realiteit geworden en levert gewoon enorme kostenbesparing op!

Iedere taal/framework heeft zijn voors en tegens. Met Dart en Flutter stelt Google echter een taal beschikbaar die op álle denkbare platforms kan draaien. Zo heeft Google hun Google Nest zelfs al draaien met Flutter/Dart. Google zet heel hard in op Flutter en Dart en hoopt, net als ik, dat Dart en Flutter de wereld gaan veroveren, want niets staat je in de weg om voor alle toepassingen (Client, Server of Cloud) om Dart te gebruiken.

[brobro]

Hoe goed werkt Flutter? Het klinkt 'to good to be true'.

Er zijn zoveel versies van al die besturingssystemen, en zoveel verschillen. Ik ben bang dat er of heel veel beperkingen zijn in wat je kunt maken, of dat heel veel stuk gaat / buggy is en vervolgens lastig te repareren. Je zit immers met code die je niet zelf native heb geschreven, dus hoe ga je daar doorheen?

Heeft iemand ervaring hiermee?

[bruudt]

Door de opzet van Flutter, heb je eigenlijk heel weinig met het onderliggende besturingssysteem te maken. Flutter maakt gebruik van de Skia engine, die bv. ook in Chrome wordt gebruikt. Alle elementen die getekend worden, zijn dus geen native elementen, maar Flutter-elementen. Als je kiest voor Material Design, dan ziet jouw app er op ieder device hetzelfde uit: geen verschillend door Android versies, maar ook op iOS, Windows, etc. zie de app er exact hetzelfde uit. Voor iOS kun je andere elementen gebruiken die op de native iOS-elementen lijken en op Windows bv. elementen die op Windows lijken. Dat kan een beperking zijn of juist een voodeel: jouw app ziet er overal hetzelfde uit.

Flutter maakt dus gebruik van de Skia engine en dat is een hele snelle engine. Standaard target het Flutter 60 FPS en zelfs op hele oude devices van meer dan 10 jaar oud, haal je met gemak 30 FPS wat voor een app natuurlijk prima is. Voor het hele renderingproces is een hele uitgebreide debugger aanwezig, waarin je het volledige rendering proces kunt volgen en bv. de oorzaak van framedrops kunt achterhalen.

Buiten het rendering gedeelte in Skia, heb je natuurlijk een gewone debugger. Doordat het framework van Flutter ook in Dart is geschreven en volledig open source is, kun je tijdens het debuggen gewoon doorspringen in de broncode van Flutter (of een package) om te achterhalen wat er verkeerd gaat. Dit maakt het fixen van bugs juist heel makkelijk, waar je in andere frameworks vaak tegen binaries aanloopt waarvan je geen sourcecode hebt, kun je bij Flutter/Dart overal alle code van zien.

Naast een uitgebriede package library, is er ook de mogelijkheid om bv. native Android of iOS code in je app op te nemen door een plugin te schrijven. Voor veel use cases zijn die al gemaakt, maar soms heb je iets nodig, wat nog niet bestaat. Hierbij kun je dan een stukje native code schrijven die deze functionaliteit aan je Flutter app toevoegt via een slim systeem.

Het klinkt inderdaad te mooi om waar te zijn. Zo'n 2,5 jaar geleden ben ik gaan kijken of Flutter een waardig platform zou zijn om onze native Android en iOS apps te vervangen. Nadat we dit traject in zijn gegaan en zoveel verbeteringen hebben langs zijn komen, werden we steeds vrolijker van Flutter. Waar we eerst klanten nog moesten vertellen dat sommige dingen toch wel lastig/duur waren om te doen zoals animaties, is dat met Flutter juist allemaal makkelijker geworden en door het 1 keer in Flutter te maken, heb je het meteen in Android en iOS gemaakt, waar het eerst dubbel werk was.

Wij hebben juist veel geleerd van de source code van Flutter, qua opzet, structuur en werking. Veel concepten die zijn toegepast, hebben we juist overgenomen. En loop je tegen een bug aan, dan maak je gewoon een ticket aan op github en wordt dit verder opgepakt.

[? ?]

Ik ben het eens beginnen te leren.
Op dat moment <1 jaar geleden was er een ENORME bug die ervoor zorgde dat zelfs de meest simpele app met 1 schermpje, stutter/jank vertoonde in de animaties op IOS om iets te tonen op het scherm. Het kon niet direct door Google opgelost worden en het heeft maanden geduurd voodat er een oplossing was.
Mijn vertrouwen werd ermee gekelderd. Dit was geen kleine issue, maar had een enorme impact op alle Flutter apps. Aan je klant moeten uitleggen dat het zo is en je er niks aan kan doen? Laat maar!

[TheNooz]

Dit was omdat Apple had aangegeven van OpenGL af te willen stappen, waardoor Flutter op iOS ineens over moest stappen op Metal. En flinke refactor dus. Desondanks is OpenGL nog steeds niet "weg" uit Apple producten en oudere versies van flutter konden in die tijd (en nog steeds) prima blijven draaien zonder die "bug". Je kon updaten als het geen issue was in jouw geval en anders moest je op de lagere versies blijven.

De "bug" was overigens dat de metal implementatie nog niet volledig af was. Ze hadden het al stabiel en werkend en dus ook al opgeleverd voor gebruik in productie maar animaties werden nog niet zogenaamd "opgewarmd" voor het afspelen, wat initieel veel jank veroorzaakte.

[? ?]

Er was GEEN oplossing voor IOS apps en GEEN ondersteuning door het Flutter Team van Flutter in meerdere maanden. Wie, wat, waar: het werkte niet goed en niemand kon op dat ogenblik zeggen waarom precies en wanneer het opgelost zou worden. Heel veel mensen hebben Flutter doen dag gezegd. Zoiets is onacceptabel voor een produtie waardig product.

[TheNooz]

Nou ik was er gewoon bij en ik zuig deze beredenering niet uit mijn duim. Die -1 die je hebt is overigens niet van mij.

[keigezellig123]

Ik heb het gebruikt voor een Android app bij één van mijn hobby projecten (ritten-registratie). Deze app had ik eerst met React Native gemaakt en wat is Flutter dan een verademing, zeker qua tooling. Er is een fijne Flutter en Dart plugin voor Visual Studio Code en je kunt hier heel makkelijke voor elk target (Linux Desktop, Android emulator, Android device, Web) je app genereren en runnen.
Qua UI van de apps is het wel nog geënt op mobile toepassingen.

Wat betreft de taal Dart, daar was ik eerst niet zo kapot van, maar je bent er snel mee onderweg (het is een mengelmoesje van C(++), Java en Python). Ik had binnen een maand een basisapp op basis van Material Design in elkaar geknutseld die ook asynchroon data vanuit een queue leest.

Check het youtube-kanaal van ResoCoder, die heeft een mooie serie over Flutter en Dart

[oks]

Er zijn best aardige cursussen op udemy. Klein prijsje: veel kennis.

[sander1095]

Ik heb zelf gekeken naar flutter for web en ik vind het verschrikkelijk. Je kan niet een link in een tabje openen, want het is geen link. De hele pagina is een canvas waarop flutter tekent, het zijn dus eerder losse pixels.

Dit maakte voor mij op firefox de performance ook bagger.

En ik misste alle browser integratie. Geen "open in nieuw tab", geen "kopieer tekst", etc..

De developer experience is daarintegen wel erg nice

[rubenvb]

Doordat alle applicaties in Flutter op dezelfde manier werken (via Google's Skia rendering engine), hoef je juist minder platform specifieke zaken te weten in vergelijking met native ontwikkeling op de zes verschillende platforms. Het ontwikkelen van apps voor 6 verschillende platforms vanuit 1 codebase is een realiteit geworden en levert gewoon enorme kostenbesparing op!

Je post klinkt als een sales pitch voor managers.
Leuk in theorie en zeker niets nieuws onder de zon. Qt doet dit bijvoorbeeld al jaren in C++: single source, multiple targets (ook mobile). KDE breit daar dan een hele hoop extra's aan moest je ze nodig hebben.

Je loopt hoe dan ook altijd tegen de grenzen aan van het framework; ofwel is de UI toch niet "native", wat sommigen voor de borst stoot, ofwel ontbreekt net de integratie met een of andere OS feature/service, waardoor je app niet werkt zoals je zou willen, of is er ergens iets dat "lost in translation" geraakt, waardoor er vreemde quirks ontstaan die toch anders werken op verschillende OSen. Afhankelijk van de flexibiliteit kan je dan voor enkel dat stukje iets native schrijven, maar vaak komt dat toch niet helemaal goed omdat de customization points ontbreken, en dan begin je een lange strijd tegen het framework om toch te kunnen doen wat je wil.

Kosten besparen? Sure, zoals je zegt, single source multiple platforms.
Enorme kostenbesparingen? Doubtful. Want het bestaat al. Het wordt al toegepast. Het kost nog steeds veel geld om op meerdere platforms te ontwikkelen, testen, etc.
Revolutionair? Zeker niet.
Ga ik het in 't oog houden? Zeker wel. Zoals ook .Net Maui, Qt, en anderen die in mijn ogen toch al wel een strak track record hebben in de wereld van cross-platform applicaties.

[Robin94]

Vorige jaar heb ik mijn Android app herschreven in Flutter. Dit vond ik zelf al makkelijker en sneller gaan dan Java Android.

Met minimale aanpassingen kreeg ik hier "gratis" een ios app bij. Daarbij moet ik wel zeggen dat ik minimaal gebruik maak van de native api. In de paar gevallen waar ik dit zelf moest doen ging dit ook makkelijker dan ik gewend ben ik andere frameworks.

Zelf zie ik het verschil tussen de oude en de nieuwe versie eigenlijk niet. Op ios zou je het kunnen zien omdat ik gekozen heb voor een material design. Of dat een probleem is is een andere discussie.

[bruudt]

[...]


Je post klinkt als een sales pitch voor managers.
Leuk in theorie en zeker niets nieuws onder de zon. Qt doet dit bijvoorbeeld al jaren in C++: single source, multiple targets (ook mobile). KDE breit daar dan een hele hoop extra's aan moest je ze nodig hebben.

Je loopt hoe dan ook altijd tegen de grenzen aan van het framework; ofwel is de UI toch niet "native", wat sommigen voor de borst stoot, ofwel ontbreekt net de integratie met een of andere OS feature/service, waardoor je app niet werkt zoals je zou willen, of is er ergens iets dat "lost in translation" geraakt, waardoor er vreemde quirks ontstaan die toch anders werken op verschillende OSen. Afhankelijk van de flexibiliteit kan je dan voor enkel dat stukje iets native schrijven, maar vaak komt dat toch niet helemaal goed omdat de customization points ontbreken, en dan begin je een lange strijd tegen het framework om toch te kunnen doen wat je wil.

Kosten besparen? Sure, zoals je zegt, single source multiple platforms.
Enorme kostenbesparingen? Doubtful. Want het bestaat al. Het wordt al toegepast. Het kost nog steeds veel geld om op meerdere platforms te ontwikkelen, testen, etc.
Revolutionair? Zeker niet.
Ga ik het in 't oog houden? Zeker wel. Zoals ook .Net Maui, Qt, en anderen die in mijn ogen toch al wel een strak track record hebben in de wereld van cross-platform applicaties.

Wil toch graag even reageren. Ten eerste ben ik geen manager, maar een ontwikkelaar met 10 jaar mobile development ervaring, waarvan 2,5 jaar full time met Flutter en ik praat vanuit mijn eigen ervaring, niet vanuit de theorie. In je post stel je dat het allemaal al lang bestaat. Het komt echter over als dat je het framework niet echt kent.

Volgens mij ondersteunt QT/C++ geen hot reload en zul je dus bij iedere wijziging van je code je app opnieuw moeten compileren en deployen in plaats van binnen 1 seconde je nieuwe code te zien runnen. Dat levert een enorme tijdsbesparing op, als je met je klant even de UI kunt aftikken: dit moet iets breder, dit naar links, etc. en deze live de UI naar zijn wens aangepast ziet worden. Flutter is bij default smooth doordat Material Design gebruikt wordt en ook op een Android 5 device ziet het er even smooth uit als op Android 12 (wat een probleem was bij native ontwikkeling, bv.).

Dan de opmerking... "Je loopt hoe dan ook altijd tegen de grenzen aan van het framework". Doordat je eenvoudig de mogelijkheid hebt om danwel packages te gebruiken, dan wel zelf een plugin in native code kunt schrijven (gewoon in Swift in XCode of Kotlin in Android Studio) heb je gewoon volledige beschikking/aansluiting met het platform. Hier is gewoon goed over nagedacht. Je kunt zelfs native views in je app tonen (voor de liefhebber). Het klinkt dat je je eigen frustratie over QT probeert te projecteren op Flutter als het om platform integratie gaat.

Wij hebben dus als bedrijf wel enorme kosten bespaard. In plaats van een native Android en een native iOS app te moeten bouwen, hoefden we maar 1 app te bouwen. Bij een andere cross platform oplossing (Xamarin, de voorloper van MAUI) liepen we wel tegen allerlei platform-integratie zaken aan en moest de UI juist dubbel (native) uitgevoerd worden, waardoor de kostenbesparing uiteindelijk nihil was t.o.v. native ontwikkeling. Bij Flutter zijn we daar niet tegenaan gelopen. En met alle verbeteringen in Dart zijn die besparingen alleen maar toegenomen (null safety! statically strong typed! sterke analysis opties voor uniforme code en minder potentiële fouten). Maar goed, ik ben niet geen neutrale partij, maar baseer mijn verhaal op mijn ervaring en niet op een gevoel.

Het allergrootste probleem met Flutter is de nieuwe taal: een developer zal Dart moeten gaan leren. Developers die al C#, Javascript of C++ kennen zijn er plenty, maar de unieke combinatie van eigenschappen van Dart, maakt het wel een aantrekkelijke taal.

[meadow]

Zoals ook .Net Maui, Qt, en anderen die in mijn ogen toch al wel een strak track record hebben in de wereld van cross-platform applicaties.

.Net Maui is toch ook relatief nieuw? Het is zelfs nog in preview mode voor multi-platform: bron: https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui

Of heeft een strak track record omdat het gebaseerd is op Xamarin.Forms?

[laurxp]

Een belangrijke sales pitch van Kotlin is dat het multiplatform is. Typescript/Javascript draait tegenwoordig zelfs op broodroosters, en Google is ook al bezig met Go op Android/iOS. Voor de platformsupport maakt de gekozen programmeertaal weinig uit - vooral als je een bedrijf als Google bent.

Hot reload is leuk, maar Dart/Flutter zijn niet de eerste die het gebruiken, en het toevoegen aan een andere taal of framework is natuurlijk ook een optie.

Google werd in 2019 Kotlin-first - terwijl de eerste publieke release van Flutter in 2018 was en ze al sinds zeker 2012 bezig zijn met Dart. Het is zéker een valide vraag waarom Google zoveel verschillende programmeertalen aan het pushen is - zelfs voor overlappende doeleinden.

[Reactie gewijzigd door laurxp op 22 juli 2024 16:13]

[bruudt]

Kotlin volg ik niet meer, sinds ik in Flutter ontwikkel, maar kmm is als ik zo even Google nog steeds in Beta en dat is dan alleen ondersteuning voor Android en iOS. Flutter voor Android en iOS zijn sinds eind 2018 Stable is en inmiddels dus ook voor Web en Windows met Linux en MacOS nog in beta. Natuurlijk stelt Google "Kotlin first" voor Android, aangezien Flutter géén native Android ontwikkeling is, maar het feit dat Google steeds meer eigen cross platform apps herschreven heeft in Flutter, zoals Google Assistent, Google Pay, Google Ads en Google Stadia is veelzeggend. Bovendien hebben wij zelf ook ervaren dat Google actief klanten helpt als zij problemen hebben met Flutter.

Qua platform zal een taal niet zoveel uitmaken, maar er zijn weinig talen die op alle platforms kunnen compileren naar Javascript, kunnen runnen tegen een (Dart) VM of gecompileerd kunnen worden naar machine code op zes verschillende platformen. Bovendien biedt Dart als taal wel enkele significante voordelen die ik nog niet tegen ben gekomen in één taal/framework, zoals Null Safety, statically strong typing, volledige unit/integratie/end-to-en testmogelijkheden out of the box, stateful hot reload, UI maken in dezelfde taal als programma code, volledig open source inclusief alle packages, uitgebreide static analysis opties, mogelijkheid om native plugins te maken.

Dart is zeker nog niet perfect, maar doordat Google en de community zowel Dart als Flutter voortdurend blijven verbeteren, wordt het platform wel steeds aantrekkelijker (en het is al zo aantrekkelijk, haha).

Denk zelf dat Google al gekozen heeft voor Dart en Flutter, maar je zult ook ontwikkelaars mee moeten krijgen, die jouw framework willen gebruiken. Door de goede documentatie en je het gevoel hebt, dat ze aan de ontwikkelaars denken, denk ik dat ze daar zeker in slagen. Soms krijg je wel eens een vage runtime error met daarbij een omschrijving waarin meteen verwezen wordt naar een github issue waarin de te volgen stappen staan omschreven hoe je het probleem moet oplossen. Dat ben ik in mijn native Android en iOS jaren nog nooit tegen gekomen. Maar goed, ik ben een groot Flutter en Dart fan, dus. niet helemaal onbevooroordeeld

[Gropah]

Kotlin is niet van Google, maar Jetbrains. Die 2 bedrijven werken graag samen (zo hadden ze eerst al android studio gemaakt op basis van jetbrains producten), maar dat maakt het nog geen Google taal.

Maar zoals AlexOo in 'nieuws: Googles ontwikkelplatform Flutter krijgt ondersteuning voo... al uitlegt hebben verschillende platformen ook verschillende behoeftes en vereisten en is het dus niet per se raar als daardoor per platform ook een andere taal gebruikt word.

[AlexOo]

Omdat alleen een hammer niet genoeg is voor software development. Soms wil je ook wat andere tools in je gereedschapskist hebben om verschillende problemen te kunnen oplossen. Frontend, Backend, Server en App development totaal verschillende dingen met eigen wensen en eisen.

[Reactie gewijzigd door AlexOo op 22 juli 2024 16:13]

[Wolfos]

Dat je voor web frontend iets anders wil is inderdaad logisch, maar Dart en Kotlin pushen ze beiden voor app development.

[vanthome]

Dart is niet perse bedoeld voor app development. Je kan Dart ook gebruiken op server omgevingen, verder is het mooie van Dart dat je het overal naar toe kan compileren, niet alleen Android zoals kotlin, maar eigenlijk alles wel. Verder bestaat kotlin al even is het meer een toevoeging op Java (iirc). Flutter wordt ook gebruikt op de nieuwe nest omgevingen, dus er was waarschijnlijk een reden om deze niet java/kotlin te laten draaien. Misschien is dat dezelfde reden dat Fushia OS ook gebruikt maakt van Flutter.

[armageddon_2k1]

Kotlin is JVM, JS, iOS, Android, en ‘native’. Het is wel iets meer dan een toevoeging op Java. Het is een losstaande taal met compiler die “toevallig” ook naar de JVM kan compilen.

[Reactie gewijzigd door armageddon_2k1 op 22 juli 2024 16:13]

[vanthome]

Ah dat wist ik niet. Hoe werkt het op iOS, en javascript?

[GertMenkel]

Stabiel Kotlin kan naar native compileren, maar het is niet direct bruikbaar als volledig app-framework. Wel is Kotlin Multiplatform in alfa, daarmee kun je in puur Kotlin een cross-platformapplicatie maken. De guide vindt je hier. Net als bij Flutter heb je wat platform-afhankelijke wrappercode (waar je niet per se veel mee hoeft te doen) maar kun je het meeste werk gewoon direct in Kotlin uitvoeren.

Met een beetje moeite kun je dus de backend, mobiele applicaties en web frontend allemaal in Kotlin schrijven met alleen de broodnodige lijmcode om met platformen te integreren. Ik heb er nog niet mee geëxperimenteerd en veel ervan is nog niet stabiel, maar het klinkt wel enigszins aanlokkelijk.

[vanthome]

Voor zo ver wat ik kan zien is alleen business logic gedeeld voor iOS, dan moet je nog wel de front end in een andere taal schrijven, natuurlijk mooi dat het kan, maar het is niet volledig Kotlin. Naar web heb ik niet gekeken.

[KoningsGap]

Aanvullend hierop is Kotlin ontwikkeld door JetBrains en niet door Google.

[Reactie gewijzigd door KoningsGap op 22 juli 2024 16:13]

[Caelorum]

Kotlin kan je ook prima buiten Android om gebruiken. Cross-platform client software, server-side software, iOS kan ook prima.

[vanthome]

Volgens mij kan iOS alleen met KMM werken maar dan moet je ui wel in een andere taal maken. Flutter is met Dart wel dezelfde taal voor back-end en front-end.

[h3x4d3c1m4l]

Ik snap wat je zegt, maar vanuit (mijn) software developer-perspectief is er wel degelijk een use case voor al die talen. Ze zijn allemaal vanuit een andere noodzaak gemaakt.

Wil je een webapp, en wil je dicht op de browser API's zitten, dan kun je Angular en daarmee TypeScript gebruiken. Wil je het maximale (performance, native feel) uit je Android-app halen, dan ga je aan de slag met Kotlin. Wil je een (imo gouden) combinatie van cross-platform (Android, iOS én desktop) en developer productivity, dan zou je met Flutter en daarmee Dart aan de slag kunnen.

Maar met Flutter heb je niet zonder meer toegang tot alle Android- en iOS-specifieke API's, daar zul je een bruggetje voor moeten downloaden (via pub.dev) of zelf schrijven via Kotlin/Swift.

Al die talen implementeren ook verschillende manieren van programmeren, Angular doet MVC, Flutter doet iets wat op MVU lijkt. Het is maar net wat je prettig vindt.

tl;dr; Het is maar wat je prettig vindt werken én hoe dicht je op de native API van je doel-platform wil/moet zitten.

[SPee]

Er is geen enkele reden waarom ze voor Kotlin/Dart hebben gekozen in plaats van Typescript (als voorbeeld).
Allen zijn een programmeertaal met een bepaalde syntax. De mogelijkheden die je ermee kan doen hangen af van de compiler en libraries die je beschikbaar hebt.

Met Javascript/Typescript kun je immers nu ook een desktop app (mbv electron) of server app (mbv Node.js) maken. Of een website met C#/Rust (mbv wasm). Dus met taal X kun je enkel Y applicaties maken is veel te limiterend.

[michelb76]

Iedere unit gebruikt wat er nodig is voor interne promotie, en om belangrijke personen te behouden.

[Reactie gewijzigd door michelb76 op 22 juli 2024 16:13]

[reneflo]

Zoals je al zegt is typescript van Microsoft. Kotlin is van Jetbrains en werkt zo goed als Java vervanger dat ze het idd supporten. Go is nu idd hun taal voor de backend en Dart voor de frontend.

[jorisvergeerTBA]

Ach... al die talen zijn procedureel. Als je er 1 kent, ken je ze allemaal. Lekker belangrijk dat er diverse talen zijn. Als 1 taal nou beter past bij een bepaalde use case, dan gebruik je die toch?

[Wolfos]

Maar tools geschreven voor één taal werken niet voor de andere. Dat is wat ik bedoel met ecosysteem.

[jorisvergeerTBA]

Dan heb je nog steeds hetzelfde. Elk ecosysteem heeft zijn eigen use cases.

Het belangrijkste is dat je productief kan zijn in een ecosysteem. En niet dat je met allerlei randzaken tijd aan het verstoken bent.

[Havocnl]

Full stack or go home

[Bux666]

Zo kunnen apps ontwikkeld met Flutter direct met Windows-api's van Win32, COM en Windows Runtime communiceren via een C-tussenlaag van Dart of indirect via een met C++ geschreven plug-in.

Is Win32 serieus nog als API beschikbaar anno 2022?

[codebeat]

Yup, embedded bijvoorbeeld en voor compatibility.

[Ablaze]

Driekwart van alle Windows programma's gebruikt win32 calls. Als je dat uit Windows haalt, start het besturingssysteem zeer waarschijnlijk niet eens meer op.

Windows runtime is een fenomeen van Windows 8 en is later uitgebreid met UWP, ik vraag mij af of ze dat ondersteunen.

COM is een interface.

[vanthome]

Kleine verbetering, volgens mij is het versie 2.10 en niet 2.1.

[meadow]

Ik heb een tijdje gewerkt met Qt en Javasscript omdat deze voor meerder platformen te gebruiken zijn met dezelfde codebase. Nadeel van Qt vond ik de kleine community en beperkte hoeveelheid 3rd party libraries/packages.

Javascript was redelijk maar Angluar2+ en typescript was toch wel een hele verbetering omdat je alles in kleinere componenten kan opbouwen.

Sinds een maand bezig met Flutter en hoe meer ik ermee doe hoe enthousiaster ik word. Ik kan in een korte tijd apps maken die voorheen veel meer tijd in beslag namen. De hoeveelheid 3rd party packages helpt ook enorm. Dart is redelijk makkelijk te leren, zeker als je een C achtergrond hebt.

[FerronN]

Opzich een logische zet nu .Net MAUI eraan komt. Voor platform ondersteuning maakt het dan dus niet uit of je Flutter of .Net MAUI gebruikt. Verder zullen er vast nog flinke verschillen zijn in de visie achter beide producten.

[TheNooz]

Alleen kan .NET MAUI niet op web draaien. Daar heeft Microsoft Blazor voor nu. Flutter kan dat wel.

[BuckyBoy]

Kan Flutter ook gebruikt worden voor de ontwikkeling van Games?.. Of is het alleen geschikt om apps mee te maken, waarbij performance niet zo'n grote rol speelt?

[TheNooz]

Flame is de meest populaire game engine voor flutter die aardig wat aandacht krijgt. Het is alleen een engine voor 2D games en ik zou het op dit punt nog niet te serieus nemen.

[codebeat]

Dus Flutter is een soort nieuwe vorm van Flash. Als ik zo naar die lagen in de afbeelding bij het artikel kijk dan doet mij dat denken aan Flash.Of een webapp in een webview en in een app met native support, ziet er ook ongeveer hetzelfde uit qua opbouw. Drie lagen om van bovenaf met het onderste te communiceren.

Wat ik heel vervelend vind is het alsmaar bedenken van nieuwe talen en afhankelijkheden dat er voor zorgt dat wat je eerder hebt gemaakt niet kan gebruiken. Bij Google verdwijnt er nog wel eens iets, dan zit je met je Flutter app. Ken ondertussen al zoveel talen en frameworks dat ik er ondertussen een punthoofd van krijg. Het meest erge nog, niets dat je maakt is compatible.

Dus waarom hier tijd in investeren als het meer van hetzelfde is? Met een webview achtige constructie kun je ook mooie platform onafhankelijke apps maken. So whats the deal? Ik zie um niet.

[JDx]

Ben 8 jaar programmeur geweest in C# en PHP (nog voor frameworks), ben er nu een jaar of wat uit en er zijn echt zo veel dingen die me gewoon helemaal niets meer zeggen, gaat zo snel allemaal.

Wil er gelukkig ook niets meer mee doen qua werk, maar toch.