Home   2026-08-03 17:31:33

←

Microsoft haalt bloatware uit Foto's-app, maar zet die om in een WebView2-app

Original article

Microsoft herziet Windows' Foto's-app door in de bovenbalk en het rechtermuisklikmenu minder knoppen naar Microsoft-apps en diensten op te nemen. De opgeruimde, snellere app is te testen in het Experimental-kanaal voor Windows. Daarnaast verschijnt een WebView2-app die Foto's (Preview) heet.

Het gebruik van een webapp kan betekenen dat Foto's (Preview) meer geheugen en processorvermogen kost. Een app draait dan namelijk op Windows' ingebouwde webengine Edge. Dit staat haaks op Microsofts inspanningen om bloatware uit Foto's te verwijderen, schrijft Windows Latest. Die standaardapp in Windows 11 is vernieuwd en voelt nu wel sneller. Het lijkt volgens Windows Latest meer op de functionele app die het ooit was.

Microsoft krijgt echter kritiek omdat het nu ook de WebView2-app Foto's (Preview) uitbrengt. Die app is een testversie van een nieuwe release van OneDrive Foto's. De naam daarvan lijkt nu verwarrend genoeg ingekort naar Foto's.

Het ontwikkelen en uitbrengen van deze WebView2-app druist in tegen de recente oproep van Microsoft-topman Rudy Huyn om terug te gaan naar native apps. Hij zet daarvoor een nieuw ontwikkelteam op. Afgelopen vrijdag beloofde Windows-topman Pavan Davuluri optimalisaties waardoor het besturingssysteem beter draait op pc's met maar 8GB geheugen.

Toch niet terug naar native apps?

In de afgelopen maanden lijkt de Windows-maker toch vaker voor webapps te kiezen. Zo was een nieuwe testversie van de Copilot-app in maart niet langer een native app, maar een webapp. Verder bleek de functie voor agenda-informatie in het Actiecentrum voor Windows 11 een geheugenhongerige webapp te zijn. Deze functie zat al in Windows 10, maar ontbrak in de opvolger.

Update, 9.14 uur – In het artikel waren aanvankelijk de apps Foto's en Foto's (Preview) met elkaar verward. Eerstgenoemde is de standaardapp in Windows 11 om foto's weer te geven en te bewerken. Laatstgenoemde is een testversie van de app OneDrive Foto's, die hernoemd lijkt naar alleen Foto's. Dit is nu aangepast.

Windows 11, laptop op tafel, startmenu. Bron: Microsoft

Door Jasper Bakker

Nieuwsredacteur

Feedback • 02-08-2026 09:20
108 • submitter: KipKroket

02-08-2026 • 09:20

108

Submitter: KipKroket

Lees meer

Reacties (108)

Dit hele artikel is fout en haalt 2 apps door elkaar.

De Foto's app is nu opgeruimt.

De OneDrive Foto's app waar de tweede heflt van de bron over spreekt is echter altijd al een web app geweest. De Foto's app zelf heeft geen WebView componenten.
Nou ja, het artikel zegt zelf ook dat OneDrive Foto's nu "Foto's (Preview)" heet en nu automatisch wordt geïnstalleerd in Windows 11 previews. Het doet daarna de aanname dat dit de vervanging wordt van de bestaande Foto's app.

Het blijft een aanname, maar gezien de naam vind ik het ook weer niet zo'n gekke aanname.
Als ik het bronartikel goed lees is de update van de Photos app geen webview2 app en gelden de updates daarop. Naast de update wordt er blijkbaar een Photos (preview) geïnstalleerd die wél dan webview2 wrapper is. Dus een extra app.
Het artikel is inderdaad zéér slecht geschreven en haalt 2 apps door elkaar. Die 2de app, "OneDrive Photos" is trouwens altijd al een WebView2 app geweest en bestaat al enige tijd, ze is recentelijk gewoon hernoemt naar "Photos (Preview)".
Soms vraag ik me echt af hoe dat er bij Microsoft op de werkvloer uit ziet. Met dit soort acties krijg je toch het beeld dat iedereen daar als een kip zonder kop door elkaar rent en lekker z'n eigen ding aan het doen is.
Ik vermoed dat dit traject al gestart was voor de roep om meer native apps. Als deze oplossing beter is dan de huidige app, waarom zou je het dan niet alsnog uitbrengen.
Het is eigenlijk best krankzinnig om een hele engine die gebouwd is om websites van 1990 tot nu te renderen op te starten alleen om een foto te tonen.
Die engine is al geladen, want die wordt gebruikt voor verschrikkelijk veel dingen.
Misschien is het wel juist heel efficiënt: als die engine afbeeldingen kan tonen, waarom zou er dan in Windows nog een andere functie zijn om ook afbeeldingen te tonen?

Het doet mij denken aan Word, waar voor sommige dingen letterlijk meerdere mogelijkheden zijn om die te doen waardoor soms compatibiliteits problemen ontstaan.
Misschien is het juist een zeer goed idee om al die dubbele mogelijkheden er uit te slopen.
Nee dit is niet efficient, want voor elke afzonderlijke app/functionaliteit wordt er een complete browser gestart. Dat bespaart misschien een klein beetje opslagruimte, al durf ik dat ook te betwijfelen. Een native app maakt natuurlijk ook gebruik van al beschikbare libraries in Windows en kan dus juist ook heel klein zijn. De webapp kost sowieso veel meer geheugen dan nodig omdat er veel te veel overbodige functionaliteit wordt ingeladen
Complete misvatting, en ik word moedeloos van deze steeds terugkerende misvatting. Dit is geen Electron-app, waar een hele Chrome wordt meegebundeld. Een WebView gebruikt de renderer die al in Windows zit. In absolute MB's aan opslag maakt het dus niet zoveel uit.

In werkgeheugen: de code pages van die runtime deelt Windows tussen processen, dus die betaal je niet N keer. Uiteraard zit er wat overhead in; een eigen heap, en een DOM is nu eenmaal duurder dan native widgets, maar je hebt het over een paar honderd MB, tegenover al snel een gigabyte voor een browser en tot 100 MB voor een native app.

Het beste voorbeeld is Microsoft Teams zelf. Dat is in 2023 herschreven van Electron naar WebView2, en volgens Microsoft twee keer sneller met 50% minder geheugengebruik en plus zo'n 70% minder schijfruimte. Zelfde app, zelfde webtechnologie, alleen een ander schilletje. En eerlijk is eerlijk: Teams is nog steeds geen toonbeeld van efficiëntie, want de app zelf is gewoon zwaar. Dat is precies mijn punt. Dat komt door de ontwikkelaars van Teams.

Er zijn door de jaren heen een hoop dramatisch slechte Electron-apps uitgebracht die met een yolo-mentaliteit in elkaar zijn gedraaid: niet-geoptimaliseerde React-apps met memory leaks, met Discord en oudere Slack als bekendste voorbeelden. Dat zegt iets over die apps, niet over de onderliggende techniek.

Een fatsoenlijke chat-app of mailclient kan echt onder de 200 MB werkgeheugen blijven in een WebView-schilletje.
Het enige verschil dat je hebt met webview is wat opslag maar dat is niet wat een web-tech app zo traag maakt. Het probleem is de hele rendering overhead. Disk opslag is het probleem niet. En dat lost webview2 niet op.
Rendering is inderdaad wat overhead, native is altijd sneller. Maar er zijn vele webapps met flink wat functionaliteiten die prima performen binnen je browser. Beweren dat het web-tech apps traag zijn is veel te kort door de bocht. Tweakers zelf zal ook best een complexe app zijn, dat performed echt dikke prima. Ik zou misschien afraden om 60fps te renderen, maar de enige echte overhead die er is binnen een goed geoptimaliseerde webapp zit hem in wat ram. In niet goed geoptimaliseerde app (helaas zie ik dat veel) zijn dat slechte frameworks en luie ontwikkelaars.
Ik geloof je verhaal meteen. Maar het feit dat je Teams aanhaalt als voorbeeld haalt het voor mij weer onderuit. Teams is mega traag en soms laden de iconen pas na een halve minuut gebruik. (New) Outlook hetzelfde verhaal. Ik heb zakelijk een recente Intel vPro laptop met 32 gig ram en je zou toch zeggen dat die het allemaal vrij vlot op het scherm kan toveren.
Ja dat is misschien een beetje verwarrend aan mijn statement. Met het Teams voorbeeld wilde ik het voorbeeld van overgang van een gebundelde Chromium instantie (wat lololig beargumenteert als zijnde een WebView) naar een WebView: deze winst is gratis en scheelt een hoop ram.

Ram hebben we genoeg. Het feit blijft dat Teams inderdaad een logge vervelende applicatie is, maar dat komt niet door de WebView, maar door hoe Teams geprogrammeerd is. Probeer Teams maar eens in je browser, daar is de ervaring net zo slecht.

Ik weet niet wat voor voorbeelden ik in jouw vakgebied kan noemen, ik denk bijvoorbeeld niet dat je Figma Desktop gebruikt, maar dit is ook een extreem complexe applicatie met veel DOM elementen goed werkt. Of je gebruikt misschien wel Whatsapp of Signal desktop voor overleg met mensen voor je werk die niet direct collega's zijn 'bronnen'. Spotify Desktop is een webapp, 1Password en Bitwarden ook. (1Password is helaas ook niet zo goed).

Maar in het kort: als je zelf nog een app in de browser gebruikt waarvan je denkt: 'dit werkt eigenlijk wel lekker' weet dan dat je daar een heel licht schilletje overheen kunt leggen die ervoor zorgt dat het zich gedraagt als desktop app.
Whahaha teams als goed voorbeeld aanhalen 🤣🤣. Mijn dag is weer gemaakt!
Gelukkig is begrijpend lezen ook een eigenschap die je moet bezitten. Teams is helaas nog steeds een voorbeeld van die 'luie developers'. Maar puur door de overstap van Electron/ een gebundelde Chromium instantie naar een WebView bespaart de alsnog logge, trage en slecht geprogrammeerde applicatie, gratis en voor niets, een gigabyte in werkgeheugen.
Ik heb een zbook met ram zat, ik heb liever een communicatie applicatie die vlot navigeert en goed werkt als als dat ik een beetje ram bespaar...
dan* dat ik een beetje ram bespaar.

Mijn Zbook met 64GB loopt toch ook tegen zijn RAM limieten aan hoor als ik toevallig twee IDE's aan heb staan, hp een firmware update besluit te pushen EN windows malware executable service ineens 30% van mijn ram besluit op te eten. En dan mag van mij het RAM gebruik van Teams dat op dit moment idle ook nog 1/64ste is van mij ook nog wel naar beneden, terwijl het ook nog eens normaal tussen pagina's wisselt. En dat kan ook prima binnen de huidige stack, daar hoef je echt niet ineens afscheid voor te nemen van een WebView. Je moet echter wel begrijpen wat je aan het doen bent en waarom.
Er is helemaal geen engine nodig om een afbeelding the laden en te tonen. Alleen maar een library. Het goede van libraries is juist dat ze gedeeld worden.
Maar die engine is niet "al geladen".

Elke applicatie start haar eigen WebView2-browserprocessen op. Dat is vanuit security- en stabiliteitsoogpunt een logische keuze, maar het betekent wel dat elke app haar eigen renderer, JavaScript-engine, GPU-processen, enz. heeft.

Het argument dat "de engine toch al geladen is" gaat dus niet echt op. Elke WebView2-app brengt opnieuw een aanzienlijke hoeveelheid code, processen en geheugen met zich mee. Dat is fundamenteel iets anders dan een native API om bijvoorbeeld een afbeelding weer te geven.
De eerste publieke versie van Edge WebView2 is uit 2020.

En sinds juli dit jaar wordt hij iedere 2 weken ge-updated.
https://learn.microsoft.com/en-us/microsoft-edge/webview2/release-notes/?tabs=dotnetcsharp
Als je net als bedrijf de ommezwaai hebt ingezet en dat ook publiek hebt gemaakt dan zou ik dat vanuit die optiek persoonlijk niet meer doen. Het laat nu, zoals ook uit het artikel duidelijk is, de gebruikers weer twijfelen of je het als bedrijf eigenlijk wel meent om terug meer native te gaan.
Te zien hoeveel alles ondertussen al gekost heeft
Copilot is laatst herschreven als webapp (ondanks dat iedere developer zogenaamd 100x productiever is door AI :+ ) dus denk dat dat het een doorlopend proces is hoor.
Ik heb altijd het idee gehad dat bij Microsoft de coders echt wel willen en ook zien hoe het beter kan, maar dat alle beslissingen, zelfs over de kleinste details, door hoger management worden genomen. En dat daarom de dingen zo gaan.
Ik denk dit ook. Vooral de Amerikaanse corporate hiërarchie die gewoon roet in het eten gooit.

Ergens moet het dingen goed doen om door te kunnen gaan, en er zitten ook veel slimme mensen die echt veel verder de materie in kunnen dan wij, maar dan na tig development cycles en managers die er wat van moeten vinden komen ze met: dit.

Hele app opnieuw opgebouwd (want native naar webview is niet ff twee tellen en klaar, nee dat moet ook gewoon door de pipelines heen en goed getest enzo. QA en QC kost ook tijd). Naar een methode waarvan je van tevoren al weet dat het minder efficiënt gaat zijn.

Met de overstap van Mail naar Outlook had ik dat ook. Van een prima app met weinig franje, naar een logge applicatie die weliswaar alles kan, maar waar de meeste klanten gewoon niet om vragen op een thuis PC.

Ik wil gewoon mijn mail kunnen lezen. Hoezo by default “prioritized” inbox?

en nu dit ook. We weten al een jaar dat resources in een PC gewoon duur zijn en we weten al veel langer dat Native apps gewoon de weg voorwaarts zijn.

zo ook dit. Fijn dat er minder knoppen zijn die je ineens naar een andere app leiden, maar waarom moet dan de keerzijde zijn dat je een performance hit gaat krijgen? Want heel veel applicaties die MS heeft omgezet van native naar web (electron ook) verbruiken veel meer. En dat is gezien de techniek ook gewoon wel degelijk te verwachten.
@Juice2000 @supersnathan94

Altijd die arodatie voor de coders, die mensen doen ook maar gewoon hun job. Het zijn geen heiligen ofzo.

Ook het bashen op managers enzovoort is ook typisch hier. Komt dit uit soort van jaloezie? Ik weet het niet maar het is altijd de coders/proggrameurs willen het best voor het bedrijf en de wereld en managers verpesten alles!

Terwijl beide groepen er maar gaat om hun brood te verdienen
Ik denk niet dat coders heiligen zijn of managers automatisch de boosdoeners. Maar er is wel een verschil in beslissingsmacht. Een developer kan prima zien dat een WebView-app logger is dan een native app, maar alsnog de opdracht krijgen om hem zo te bouwen omdat productstrategie, integratie met OneDrive/M365, kostenbesparing of KPI’s zwaarder wegen. Kritiek op “management” gaat dan niet per se over individuele managers als mensen, maar over de incentives en besluitvorming binnen zo’n corporate omgeving.

Ik zou het volledige met je eens zijn als we onze Europese hiërarchische kaders op de amerikaanse corporate cultuur zouden kunnen leggen, maar dat is gewoon niet het geval. In de VS is de beslissingscultuur bij zulke mega corps heel simpel. Je doet gewoon je werk zoals je dat aangeleverd krijgt en als het dergelijke performance verslechteringen gaat geven (want inherent aan de techniek) dan heb je daar maar op een andere manier mee te dealen.

Microsoft, maar ook Facebook en Google werken met een leveling system voor hun personeel en engineers. Waar wij vaak werken met een redelijk open starter, junior, medior, senior zit je daar met een numeriek systeem waar echt wel veel van afhangt. Je volledige salarisstructuur, healthcare de hele rambam, YouTube: Working at Microsoft is … weird

In Amerikaanse big tech heeft management institutioneel veel meer ruimte om top-down te sturen: at-will employment, lage cao-dekking, sterke aandeelhoudersdruk en performance-managementsystemen zoals stack ranking (wat MS in 2013 gelukkig heeft uitgefaseerd) en dit alles komt ook nog eens met het Peter-principe.

Maar als ik er nog nader naar kijk dan is dit waarschijnlijk intern ook nog prima te rationaliseren hoor.
  • Windows-team: “we moeten Foto’s opruimen, minder bloat, sneller.”
  • OneDrive/M365-team: “we willen een cloud-photo experience op Windows.”
  • Edge/WebView2-platform: “wij bieden de standaard manier om webervaringen in apps te embedden.”
  • Management erboven: “hergebruik, cloudintegratie en time-to-market wegen zwaarder dan lokale elegantie.”
Iedere laag kan intern rationeel lijken, terwijl het eindresultaat voor de gebruiker voelt als: “waarom start er ineens een volledige browser voor mijn foto-viewer?”

Er valt wat voor te zeggen voor die verticale integratie, maar het zorgt er wel voor dat je steeds meer naar generieke componenten gaat die eigenlijk bijna alles moeten kunnen en daarom dus ook een gigantisch framework aan de achterkant nodig hebben om dat dan te kunnen doen.

Alleen heb je daar als Dev gewoon vrijwel niks over te zeggen.

Microsoft zegt dat het sneller voelt, dus als die experience ook meetbaar te maken valt zie ik dat graag.
Microsoft heeft voor Windows alleen al dubbel zoveel ontwikkelaars en misschien wel 50 keer zoveel managers, als Apple in totaal aan ontwikkelaars en managers binnen het complete bedrijf heeft. Dat kan dus nooit efficiënt zijn wanneer we de output vergelijken.
Dat is ook de reden voor het overweldigende marktaandeel van macOS.
Het marktaandeel macOS op apparaten boven de 1000 of 2000 euro kan overweldigend lijken, maar in totaal zal Windows zeker meer installaties hebben
Haha ja ik was ook sarcastisch
Als je dat dan weer vergelijkt met het totaal aantal installaties van Linux. Blijven het beide besturingssystemen in de marge.
Hangt er natuurlijk vanaf hoe je dat telt. Consumenteninstallaties (PC en laptop varianten), sure, dan wint Windows met gemak, gevolgd door MacOS en daarna Linux.
Maar kijk je naar wereldwijde installs op machines (servers, IoT) en mobiele devices, dan zou Linux (varianten) nog wel eens nek aan nek kunnen gaan met Windows.

[Reactie gewijzigd door William_H op 2 augustus 2026 22:14]

Dan wint Linux met gemak. Zelfs MS Azure draait erop.
Was daar maar een bron voor.
Dat kan wel wezen maar dat maakt sturing toch juist extra belangrijk? In gepaste mate, want meer managers aannemen heeft natuurlijk weinig zin.

Er luistert daar volgens mij ook niemand naar de afdeling UI? Hoe kan het toch zo zijn dat werkelijk elk softwarepakket van Microsoft zijn eigen UI principes hanteert? Vergelijk dan eens de foto's app met de verkenner of het configuratiescherm met Teams, waar het al helemaal de spuigaten uit loopt? Hoe kan dat?!

Toen ik een jaar of 15 geleden privé over ging naar Linux speelde dat daar ook. Nu moet ik zakelijk noodgedwongen terug naar Windows en godallemachtig, wat een postpocalyptische ravage heeft men ervan gebrouwen :X

[Reactie gewijzigd door doltishDuke op 2 augustus 2026 10:47]

Ik ben met de introductie van Windows 10 juist van linux weer naar Windows gegaan. Niet omdat het beter was, maar omdat mijn boekhoudpakket windows-only is en Windows 10 goed genoeg was.

Nu mijn boekhoudpakket inmiddels is vervangen door een webapplicatie (die 100x sneller is omdat de latency tussen desktop applicatie en Azure database wegvalt) overweeg ik om gewoon weer linux te gaan gebruiken. Windows 11 is een fikse achteruitgang tov 10 wat mij betreft.
😁 Dat is een interessant gegeven.
Maar is het een gegeven? Of een mening?
😁 Dat is een interessant gegeven.
En tegelijkertijd complete onzin.
Een paar weken terug kwam in het nieuws dat bijvoorbeeld Bethesda 17 layers van management boven zich had. Geen idee hoeveel daarvan bij Microsoft of bij Bethesda zelf zaten, maar het geeft wel een beeld van de cultuur natuurlijk.

Engineers ga ik me niet over uitspreken, geen idee hoeveel personen er aan Windows werken. Dat is zo uitgebreid tegenwoordig dat het aantal je vermoedelijk zou verbazen.

[Reactie gewijzigd door Powerblast op 2 augustus 2026 11:09]

... Bethesda 17 layers van management ...
In het persbericht van 6 juli (https://news.xbox.com/en-us/2026/07/06/resetting-xbox/) stond dat het om 14 lagen aan management gaat niet 17. Dat is nog steeds heel veel en maakt daarom je argument niet veel minder sterk.
Wellicht zoals bij elk zeer groot corporate bedrijf: heel veel managers die allemaal hun eigen positie constant (moeten) verdedigen.
Het resultaat is een draak die HEEL traag is in reactiesnelheid.
Wat vandaag klaar is, is wellicht een jaar eerder beslist.

Rudy Huyn is niet de grote baas, dus als hij iets zegt, wil dat niet zeggen dat alle afdelingen dat gaan volgen, misschien zelf alleen zijn afdeling.
Soms vraag ik me echt af hoe dat er bij Microsoft op de werkvloer uit ziet. Met dit soort acties krijg je toch het beeld dat iedereen daar als een kip zonder kop door elkaar rent en lekker z'n eigen ding aan het doen is.
Sterker nog. Vermoedelijk zit elk team in een eigen kantoortuin of verdieping.
Teams praten niet met elkaar (terwijl 'Teams' bestaat.)
De ene club verkracht het startmenu, de ander buigt zich over ronde hoeken of de plek van de taakbalk. Werk is werk, en de zon schijnt.
Je ziet Microsoft teveel als 1 team. Het is zo ontzettend massief dat je het kan vergelijken met een walvis. Dat de kop al een andere richting op gaat wil nog niet zeggen dat de staart ook gelijk die kant op staat.e

Best kans dat ze alleen voor de foto's app al een eigen afdeling hebben met eigen projecten, tijdlijnen etc. Dan kan de top wel leuk een nieuwe route bedenken, maar ondertussen heeft deze afdeling zn nieuwe foto app bijna klaar, waar misschien wel maanden aan gewerkt is.
Ik zo'n ding als bing. ALs je die zoek machine opened krijg je gelijk een hoop scam websites te zien. En dan denk ik.... Ik werk bij een bank, dan zou je verwachtend at dat soort dingen uitgezet worden.. Maar nee, "Carly Simon doorbreekt haar stilte" Geen idee wie dat is, maar wat mot ik daar mee denk ik dan...
Zo zit Microsoft inderdaad in elkaar. Zie het aloude org chart meme grapje: https://www.globalnerdy.c...charts-tech-companies.png

Dusja Microsoft is een soort organisatie van tegen elkaar strijdende stammen en daar zie je dit soort resultaten in terug.

Ook dat ze bijvoorbeeld zowel de geweldigst performerende electron/webview app maken: VS Code, en anderen die afschuwelijk en niet vooruit te branden zijn. Lessen worden niet intern gedeeld en elke afdeling heeft eigen conflicterende belangen.
Hoe er gewerkt wordt kan ik niet vertellen maar ik ben wel op de campus in Seattle geweest en als je beseft hoe groot dat is en hoeveel gebouwen er zijn, dan is het ineens een stuk makkelijker te begrijpen dat dingen langs elkaar heen bewegen.

De Teams afdeling is een interne klant van de Outlook afdeling als het gaat om integratie van Teams in Outlook om maar een voorbeeld te noemen.

Je kunt daar in Redmond niet even naar de buren lopen om te overleggen maar je moet de auto pakken.

Maar ook geldt dat bepaalde zaken misschien al vergevorderd waren voordat er een nieuwe richting is uitgestippeld. Zie het als een enorme olietanker die niet zomaar even het bochtje om gaat.
Maar wat zijn precies de cijfers voor het geheugengebruik?

Bij de webversie van outlook, bijvoorbeeld, zie ik commentaren waarbij beweerd wordt dat die met gemak een halve tot één gig reserveert, waar de native client 100-200MB pakte.
offtopic:
leuk detailtje, met de alpine mail client kom ik comfortabel onder de tweeëneenhalve MB.

[Reactie gewijzigd door AnonymousGerbil op 2 augustus 2026 09:32]

Bij mij gebruikt Thunderbird (snap package) momenteel 1.02GB werkgeheugen onder Linux. Vind dat echt wel veel.
Thunderbird is dan ook deels een XUL-applicatie. Een soort webview.
Hier 572 MB onder Bazzite met KDE :)

Misschien als je veel e-mails hebt en een volle agenda, maar als je Thunderbird afsluit komt heel het geheugen weer ter beschikking wat onder Windows niet het geval is. Spotify doet wel 1,09 GB.

Met 32 GB in het systeem is dit helemaal geen zorg ;)
Thunderbird kan je voor een klein mail-account geopend hebben of (zoals ik) met 10 tot 12 betrekkelijk grote accounts van diverse providers. Dat kan nogal een verschil maken.

Daarnaast gebruik je een snap-package. Heb je gekeken naar het geheugengebruik van de hele snap of van alleen de thunderbird executable? Het zou zomaar kunnen zijn dat jouw thunderbird is gecompileert met zo veel mogelijk libraries aan boord. De thunderbird die je vanuit de repository van je distributie haalt zal juist zo veel mogelijk shared-libraries gebruiken en is daarmee mogelijk zuiniger met resources.

Toegegeven, ik heb de details niet gecontroleerd en heb ook geen idee van het geheugen gebruik op de platformen die ik met thunderbird gebruik. Wel weet ik dat thunderbird met meerdere accounts op een 4GB linux systeem (uit 2009) nog netjes draait.
Ik heb net even de Thunderbird snap gestart met een nieuw leeg profiel en dan zit Thunderbird op 983MB. Dat is echt wel een stuk meer dan @jimh307. Misschien dat ik nog eens de flatpak ga proberen, voor nu heb ik geen geheugen problemen dus laat het even voor wat het is.
Op het werk heb ik zowel de klassieke als de mordern Outlook staan, en vaak ook alle twee openstaan. Enkele dagen terug was ik in task manager en zag ik Outlook 2,5GB aan geheugen in gebruik nemen. De klassieke Outlook daarentegen, met dus identiek dezelfde mailboxen open, gebruikte nog geen 250MB.
Wat is Alpine Mail? Een TUI? Ik zoek nog een goede mail client, vind alle alternatieven op flathub etc tot nu toe niet echt fijn.
Ik kende het ook niet, maar is een 'nieuwere' kijk op Pine. Mét utf ondersteuning. Inderdaad !en CLI client.
Is het niet zo met Webview2 dat je 1x de "browser" moet laden, maar dat dat dan gedeeld wordt qua resources door alle apps die er gebruik van maken? Of wordt voor elke app een aparte "browser" opgestart, dus dat je telkens met de overhead zit?
Is het niet zo met Webview2 dat je 1x de "browser" moet laden, maar dat dat dan gedeeld wordt qua resources door alle apps die er gebruik van maken?
Deels. De app die in WebView2 draait moet daar wel voor geschreven zijn, standaard draait elke WebView2-app zijn eigen processen, browser etc:
Each WebView2 control creates its own set of processes, such as browser, renderer, and GPU. Resource usage generally grows as more WebView2 instances are created, with each instance running its own set of browser processes.

A WebView2 instance uses memory based on the complexity of the web content and the browser processes it creates. Running many instances of the WebView2 control can strain system memory.

Below are best practices to manage and reduce the memory footprint.

Share WebView2 environments
- To save memory, use one CoreWebView2Environment across all WebView2 controls in an app, ensuring consistent parameters for sharing.

- Reuse the same environment in tabbed interfaces, rather than creating multiple environments.
Maar dat kan je deels dus mitigeren door te sharen:
If feasible, use app-level process sharing.

Multiple apps can share a browser process by using the identical user data folder and CoreWebView2EnvironmentOptions. This reduces memory usage, but requires careful management of profiles and thorough testing, due to possible cross-app interference.

Keep in mind that when sharing a User Data Folder (UDF), underlying data (such as cookies, caches, and databases) is being shared between different applications.
Microsoft heeft dit gedocumenteerd in de Best Practices guide: Performance best practices for WebView2 apps - Microsoft Edge Developer documentation | Microsoft Learn
This reduces memory usage, but requires careful management of profiles and thorough testing, due to possible cross-app interference.
Dus niemand doet dit, want het is een security issue.
Plus: als dan je shared WebView proces omvalt, dan valt er ineens een stuk meer om.
Bij een native app heb je ook een voordeel dat bepaald bibliotheken gedeeld kunnen worden als het programma dynamisch is gecompileerd. Bij een webview2 programma werkt dat denk ik niet. Als twee webview2 programma's gebouwd zijn op basis van react, dan zal react voor beide programma's los in het geheugen geladen moeten worden.
Tja. Je kan het zien als een poging om simpelweg alle "apps" compleet uit Windows te halen. Alles is dan immers een schil om Edge/webbased. Zo kan ik het ook, Windows op 8Gb te laten draaien, gewoon alles eruit halen was geen OS is. De rest wordt wss niet meer standaard 'geïnstalleerd' en kan je tijdens de install of later aanklikken waarna MS het hogere verbruik bij de klant legt.

Ik ben fel tegen deze manier van werken. Ik verwacht een basis zet native apps, en een fotoviewer hoort hier wat mij betreft gewoon bij.
Maar als je die optionele applicaties vervangt door WebView2 applicaties krijg je bij het gebruik van die applicaties dat ze significant meer RAM nodig hebben.

Die 8GiB gaat over RAM gebruik, niet HDD/SDD storage.
Ja, maar als dat door MS niet onder het OS meer gerekend wordt... Snap je? ;)
Ik denk dat je het niet helemaal snapt. Het gaat om de Edge engine. Dat is wat anders dan Edge als browser.

Een browser is aanzienlijk meer dan een engine.

Webview2 wordt vaak gebruikt als component van native software zodat ze niet zelf een hele webengine hoeven te schrijven om wat online-componenten te verwerken, of dat ze zelfs een externe engine moeten integreren (en patchen/enz.) gigantisch veel derdepartijsoftware gebruikt dit al jaren en jaren (in verschillende iteraties.)

Edge zelf gebruikt dit ook.

Dit gezegd hebbende vind ik het heel onlogisch klinken om een foto-app hier in te schrijven.
Dit gezegd hebbende vind ik het heel onlogisch klinken om een foto-app hier in te schrijven.
Heeft denk ik vooral te maken omdat de pool van web developers veel groter is dan de pool van native developers (C++, C, Rust, enzovoort).

Die trend zie je al jaren aan de gang. Alles moet een webapp zijn of de app er zich nu toe leent of niet, het moet en zal webbased worden. Positieve zaak vind ik dat persoonlijk niet. Vanuit onderhoud kan ik het snappen, vanuit development speed ook. Maar de basis is toch je gebruikers een fijne en goeie ervaring bieden. Dat lijkt soms ondergeschikt te zijn aan de eerste twee.

Mooi voorbeeld is tegenwoordig Outlook. Die nieuwe variant is ook Webview2 in tegenstelling tot de old version. Dat ding zit echt vol met bugs, laadt zeer traag of laadt in zijn geheel images niet. Mails die eerst in draft stonden, verzonden zijn, maar toch in draft blijven staan tot je de boel herstart. Search werkt voor geen meter meer. Ik kan zo nog wel even verder gaan :). Vooruitgang is het niet vind ik.

[Reactie gewijzigd door Powerblast op 2 augustus 2026 11:21]

Zou een concern als Microsoft daar ook last van hebben? Kan het me bijna niet voorstellen om eerlijk te zijn. Alles 'naar web app' lijkt vooral een cross-compatibility en onderhoud-ding te zijn toch?

Voor cross-compatibility: Met webapps is het makkelijker om een een app te maken die zowel op Windows, MacOS, Android, iOS en Linux draait.

Voor onderhoud: Heel veel zaken worden door de (in dit geval WebView2-)engine geregeld. Dit hoef je dan dus niet zelf te onderhouden. Het hart van de applicatie wordt door Microsoft onderhouden. Je zag dit ook met de populariteit van Java.
Met zekerheid kan ik dit niet zeggen want ik werk er niet :). Maar ik zou dat wel denken. Zowat elk net afgestudeerde developer kent javascript. Diegene die afstuderen met c++ kennis worden in mijn omgeving althans zeer schaars. Ik neem ook even aan dat ze met native dus c++ bedoelen. Rust zou ook nog kunnen, maar zelfs als fan van Rust moet ik erkennen dat er amper tot geen jobs voor zijn.
Maar is dat in de VS ook zo? En werkt Microsoft met (relatief veel) net afgestudeerden? En ik heb even geen idee, maar ik heb wel is begrepen, dat als je eenmaal een bepaalde taal goed kent en het in je zit om een goede programmeur te zijn (dit schijnt een bepaald slag personen te zijn), is het leren van (bijvoorbeeld) C++ toch 'best te doen'?

Even een disclaimer: Ik word niet gehinderd door enige professionele programmeer-ervaring :).
De eerste taal is naar mijn mening inderdaad de moeilijkste. Omdat je naast de syntax ook moeten leren denken als een programmeur. Dat heeft bij mij alvast in het begin toch even moeite gekost. Daarna is het inderdaad "maar syntax" leren. Ken je er één, dan is de tweede, derde... veel minder moeite.

Er zit echter wel een heel groot verschil tussen de syntax complexiteit van iets als Javascript en C++/Rust. Vooral dan om memory management. Ik ben zelf primair Java programmeur en zelfs daar hoor ik heel dikwijls: "zo complexe syntax", terwijl het voor mij ondertussen qua syntax een eenvoudige taal is. Memory management doe je bijna niet.

Rust en C++ daarentegen... Vooral Rust is echt lastig nadenken. Al heb je ook daar mensen die het eenvoudig vinden (al is dat wel de minderheid :p).

Ik wil dus maar zeggen. Ik zie een Javascript programmeur (minus de uitzonderingen) niet van vandaag op morgen naar C++ or Rust overstappen. Dat duurt echt wel even. Rust geloof ik dat ze zeggen een 6tal maanden. C++ wordt zelfs 1j plus gezegd, ook al is het mental model "simpeler" naar mijn mening. De syntax is pakken lastiger. Maar dat is heel persoonsafhankelijk.

[Reactie gewijzigd door Powerblast op 2 augustus 2026 17:15]

Ze kunnen ook een .NET taal gebruiken. MS heeft met C# de tegenhanger van Java gemaakt; bekende syntax en beperkt memory management.
Een Typescript ontwikkelaar zou dat makkelijk moeten kunnen leren.
Die is er ook nog inderdaad. Veel verschil zit er niet tussen de twee vind ik persoonlijk. Heb ze beide al gebruikt en het verschil tussen Java <> C# voelt eigenlijk niet meer als zeg maar een framework verschil. Syntax klein beetje anders maar verder bijna hetzelfde, ook qua onderliggende principes van de JVM/CLR.
Juist, baal nog wel steeds dat MS niet het standaard Webbrowser ActiveX component compatible heeft gemaakt met webview2.
Dat zou een breaking change zijn, en dat gaat niet bij een bedrijf wat over het algemeen backward compatibility hoog in het vaandel heeft staan. En dus moet je die breaking change zelf maken, door het webview2 component in je applicatie te gebruiken, in plaats van het standaard webbrowser component. Iets wat, afhankelijk van je use case, overigens niet heel lastig hoeft te zijn, zelfs niet als je her en der af en toe wat moet communiceren tussen de javascript en je applicatie code
Tja. Je kan het zien als een poging om simpelweg alle "apps" compleet uit Windows te halen. Alles is dan immers een schil om Edge/webbased. Zo kan ik het ook, Windows op 8Gb te laten draaien, gewoon alles eruit halen was geen OS is. De rest wordt wss niet meer standaard 'geïnstalleerd' en kan je tijdens de install of later aanklikken waarna MS het hogere verbruik bij de klant legt.
Dat is inderdaad wel een goeie. Ze hebben eigenlijk niet echt verduidelijkt wat ze als echt "OS" beschouwen. Straks zitten we nog opgezadeld met een OS met wat basis functies en zit alle core functionaliteit in webapps... Niet standaard installeren zie ik bij Microsoft dan weer niet gebeuren. Ze hebben een historie van proberen om steeds meer basis mee te installeren.
Wat maakt het uit of de foto app native of webview2 is, als die maar fatsoenlijk snel werkt, ik ken ook genoeg 'native' apps die traag als dikke stront zijn. Ik zette expres al native tussen quotes, want wat is native tegenwoordig.. een naar assembly gecompileerde executable of bv een lokaal draaiend python scriptje....
Omdat webview veel makkelijker kapot kan en altijd maar geupdate moet worden/daarin kapot kan, laat staan de afhankelijkheden.

Native werk fantastisch, supersnel en gaat gewoon nooit stuk. Ik heb nog nooit oude Windows applicaties stuk zien gaan.
Mwah. Veel games uit de jaren 90 die op XP al niet meer werkten, omdat ze met hoop en gebeden aan elkaar hingen, en zeker op Windows 10 gewoon met geen mogelijkheid aan de praat te krijgen zijn. En als je dan naar de disassembly kijkt, zie je al vrij snel waarom: Veel van de code is maar net "Works on my machine"-kwaliteit en komt klaarblijkelijk zelden of nooit in het failure pad, waar soms schrikbarend veel fouten in voor komen.

Veel van die software zou er baat bij hebben om, net als bijv. Lego Island en Diablo, een decompilation community te hebben, zodat de code gefatsoeneerd en werkbaar gemaakt kan worden, want als de verschillende APIs goed worden gebruikt, kan software echt oneindig forward compatible zijn.
Ik ben fel tegen deze manier van werken. Ik verwacht een basis zet native apps, en een fotoviewer hoort hier wat mij betreft gewoon bij.
Wat is voor jou een basisset?

Een foto / PDF viewer vind ik inderdaad basis, maar niet iedereen zal dat vinden.

En die foto viewer, moet die ook (simpele) edits kunnen doen? De een zou het fantastisch vinden, de ander vindt het ballast.

Eén ding wat je zeker mag verwachten, is dat de Windows 11 basisset native apps zijn, geoptimaliseerd voor grootte en performance.
Bor Coördinator Frontpage Admins / FP Powermod 2 augustus 2026 09:34
Kan het zijn dat de webapp versies een tussenstation zijn en we dit later terugzien als native app? Het draait hier veelal om testversies zo te lezen.
Heeft u een alternatief programma dat u kunt aanbevelen boven Microsoft Photos?
Ik wilde Immich voorstellen, maar zie net dat daar geen Windows versie van is
Irfanview is een native viewer voor oa fotos, maar ook videos.

De interface is niet zo gelikt als wat je nu veelal ziet, maar laat wel snel en leest heel veel formaten.
Mijn voorkeur is nog steeds picasa maar helaas heeft google dat actief van internet gehaald.

Tweakers -> Downloads -> "view": https://tweakers.net/downloads/zoeken/?keyword=viewEn kijk bij die pagina's ook in de comments voor verwijzingen naar nog meer vergelijkbare tools.
DigiKam, crossplatform, opensource en direct de mogelijkheid tot taggen / organiseren, inclusief lokale face recognition modellen

[Reactie gewijzigd door demartijn op 2 augustus 2026 22:51]

Tja, MS kan uitleggen dat dit een native app is, want webview2.

Zullen ze niet doen, maar kan wel. Er is niet voor niets een lange, lange geschiedenis van eigen uitleg bij standaarden (kijkt met een schuin oog naar de vroege internet explorer en huidige uitleg van Office-standaarden versus de documentatie).
In een app met embedded html renderer is het veel makkelijker om even een paar ads binnen te slurpen en te tonen als in een compleet native app zonder html renderer.

Wat is nou mooier om jou foto's te laten scannen door AI, en dan toepasselijke ads te tonen.
Wil je dat niet.. dan moet je betalen.

Ze moeten toch ergens profit uit al die windows installaties halen he O-)
Na Win 10 ben ik op Fedora overgestapt met een local nextcloud server. Wat me vooral opvalt hoeveel meer ik bezig kan zijn met daadwerkelijk werken in plaats van met popups en dingetjes die mijn aandacht vragen zoals welk weer het nu buiten is of wat de aandelenmarkt doet.

Helemaal suf werd ik van de onzinnige bloatware ingebakken in het OS.

Mijnenveger was leuk. Maar 3 verschillende foto en plaatjes apps out of the box? Linkjes naar Office365 apps die er niet zijn, maar eerder irritante reclame zijn. Het niet gebruiken van Onedrive melden als een foutmelding terwijl er al op een andere manier gebackupt wordt? Hoe verzinnen ze het.

Om te kunnen reageren moet je ingelogd zijn