WhatsApp vernieuwt app voor Windows, gebruikt tot tien keer meer geheugen

WhatsApp krijgt een nieuwe versie van de app voor Windows. De native app verdwijnt ten gunste van een versie op basis van WebView2. Daardoor heeft de app tot tien keer meer geheugen nodig dan voorheen.

Waar de oude app, als je niets doet en niet ingelogd bent, rond 18MB aan werkgeheugen vraagt, gaat dat bij de nieuwe WebView2-app naar ongeveer 300MB, meldt WindowsLatest op basis van eigen tests. Bij gebruik schiet het werkgeheugenverbruik van de WebView2-versie naar 1,2GB, terwijl de huidige versie rond 200MB blijft hangen.

Daarnaast blijven de prestaties achter, claimt de site. Versie 2.2584.3.0 van de app op basis van WebView2 reageert traag en geeft notificaties minder goed door. De nieuwe versie zou nodig zijn, omdat WhatsApp-moederbedrijf Meta het team achter de native app heeft ontslagen en deze daardoor niet langer kan onderhouden. Gebruikers zouden nog enkele dagen tot weken de native app kunnen blijven gebruiken en daarna automatisch uitgelogd worden.

Het is al langer bekend dat de app zou gaan overschakelen op WebView2. Daar komen diverse nieuwe functies bij, zoals ondersteuning voor onder meer kanalen. Meta bracht de UWP-versie van de Windows-desktopapp in 2022 uit. De versie daarvoor draaide op Electron.

Reacties (170)

[calvinturbo]

Is het niet mogelijk om Electron/WebView applicaties sneller te maken en minder geheugen te laten gebruiken? Kan iemand met kennis hier een reactie op geven?

[Deathspike]

Dat is zeker mogelijk. Waar je als ontwikkelaar rekening mee moet houden is dat web technologiën inherent anders werken dan native technologiën. Met native ontwikkeling kies je een UI framework en dan is er vaak maar een enkele manier om een UI component op het scherm te krijgen, en die enkele manier is optimaal en efficient. Je krijgt automatisch native compilation en je gehele pipeline word volledig geoptimaliseerd.

Met web technologiën is er geen duidelijk pad van een UI component op het scherm krijgen, en krijg je geen native compilatie. Als ontwikkelaar kies je een UI framework, en afhankelijk van wat je kiest, zijn daar al vele concessies gemaakt om die UI technologie consistent te laten werken in verschillende browsers. Iets wat je totaal niet nodig hebt wanneer je een specifieke vorm van een WebView gebruikt. Je startpunt is volledig anders dan reguliere websites, maar vaak gebruiken de ontwikkelaars van zulke apps juist de UI frameworks die ze "toch al kennen" in plaats van de meer optimale keuze.

Verder is de compilatie van native en web volledig anders. En begrijp me niet verkeerd, web kan ontzettend snel zijn. Native is altijd sneller, maar het verschil is makkelijk kleiner dan 5%. Daarvoor moet je als ontwikkelaar wel kennis in huis hebben van de JIT die je gebruikt en als doel hebben om efficiënte code te schrijven. Dat betekend ook regelmatig dat je niet zomaar allerlei willekeurige packages moet importeren, omdat die vaak weer in de strekking ontwikkeld zijn voor web pagina's, en niet apps.

Als laatste heb je te maken met welke wrapper je gebruikt. Electron heeft een slechte naam, omdat deze met 1001 verschillende native functionaliteit word geleverd. Vaak heb je al die onzin niet nodig, en is een andere wrapper 10x sneller en 10x kleiner. Maar het gros gebruikt Electron, want dat is makkelijk, het is de grootste, en "waarom niet". Die levert een gehele webbrowser, terwijl je OS al een prima webbrowser ter beschikking heeft (WebView2 op Windows, WKWebView op Mac). Gebruik maken van de native browser maakt de app kleiner, sneller, en minder hongerig doordat een hoop onzin er niet in zit. Maar ja, dan moet je wel testen op twee (en potentieel 3!) platformen!

Op Android/iOS heb je weinig keuze: daar heb je WebView of WKWebView en kun je eigenlijk niet eens een eigen browser meeleveren. Het voordeel is dat deze apps veel kleiner zijn en het verschil met native apps niet eens zo groot. Op desktop is een andere wrapper al een wereld van verschil, bijv. Tauri. Maar ja... het gaat vaak maar om een enkel ding: geld.

Bron: Ik schrijf cross-platform apps met web tech voor mijn baas.

[Ed Vertijsment]

Heb je wat snelle tips voor ontwikkelaars mbt (JIT) performance?

[Deathspike]

Sure. Niet alles is strict JIT-specifiek, maar alle beetjes helpen:

1. Gebruik class in plaats van objecten. Initialiseer velden meteen in de constructor, ook de velden die undefined zijn. Het idee is om classes stabiel te houden en niet van vorm te laten veranderen, want een verandering van vorm maakt een nieuw JIT definitie voor de class.
2. Idem aan vorige punt, gebruik geen types door elkaar. Als je een veld hebt wat nu een number is en straks ineens een string, dan maak je weer een nieuwe JIT definitie. Probeer dat allemaal te voorkomen en kies een enkele consistente representatie voor een veld.
3. Idem aan vorige punt, gebruik nooit delete maar zet een veld naar undefined.
4. Gebruik liever een class dan een anoniem type object. Ja, een object in elkaar flansen is minder schrijfwerk, maar het is ook minder performant omdat ieder anoniem object mogelijk een eigen JIT definitie krijgt. Hoe beter de JIT je code snapt, hoe meer het kan optimaliseren.
5. Blijf met je tengels van prototype af.
6. Geen eval, .call en andere dynamische onzin.
7. Geen arguments gebruiken -> function aap(...a) is heel langzaam.
8. Gebruik Map in plaats van van Dictionary-stijl objecten.
9. Gebruik Set in plaats van arrays en .include
10. Generator functies zijn veel sneller dan meerdere .map, .filter, .reduce, enz.
11. Gebruik web workers voor parallel processing i.p.v. de event loop.
12. Ga slim om met arrays: .pop is snel, .shift niet.

En wat generieke DOM aandacht punten:

1. Schrijven naar properties triggered een paint, dus gebruik variables om eerst alles door te rekenen voordat je de uiteindelijke waarde naar de DOM property schrijft.
2. Gebruik nooit animaties geschreven in JavaScript (want paint en layout events). Gebruik alleen CSS voor animaties.
3. Gebruik nooit innerHTML: werk netjes met nodes en ga er slim mee om.
4. Render alleen wat nodig is; gebruik licht gewicht placeholders voor dingen die ver uit beeld zijn en toon ze alleen wanneer de gebruik in de buurt komt. Veel DOM nodes (1000+) maakt alles traag.
5. Soms is het slim om DOM nodes niet op te ruimen (bijvoorbeeld bij tabbladen) omdat ze opnieuw opbouwen langzamer is dan ze even verstoppen of detachen.
6. Verander alleen wat veranderd moet worden.

[Reactie gewijzigd door Deathspike op 12 november 2025 13:03]

[R4gnax]

1. Gebruik class in plaats van objecten. Initialiseer velden meteen in de constructor, ook de velden die undefined zijn. Het idee is om classes stabiel te houden en niet van vorm te laten veranderen, want een verandering van vorm maakt een nieuw JIT definitie voor de class.
2. Idem aan vorige punt, gebruik geen types door elkaar. Als je een veld hebt wat nu een number is en straks ineens een string, dan maak je weer een nieuwe JIT definitie. Probeer dat allemaal te voorkomen en kies een enkele consistente representatie voor een veld.
3. Idem aan vorige punt, gebruik nooit delete maar zet een veld naar undefined.
4. Gebruik liever een class dan een anoniem type object. Ja, een object in elkaar flansen is minder schrijfwerk, maar het is ook minder performant omdat ieder anoniem object mogelijk een eigen JIT definitie krijgt. Hoe beter de JIT je code snapt, hoe meer het kan optimaliseren.

Deze punten zijn grotendeels achterhaald. Moderne engines zoals de V8 engine in Chrome/ium, waar ook Node.js en Electron op draaien maken gebruik van zgn. hidden classes voor anonieme objecten die o.a. middels iets wat een TransitionArray bijhoudt hoe de ene object shape in de andere overvloeit bij het wijzigen v/h type v/d waarde achter een bestaande key, bij het toevoegen van een key, of bij het verwijderen van een key.

Blijf met je tengels van prototype af.

Klopt in zoverre dat je niet de prototype definities van bestaande data types aan moet gaan passen die onderdeel van de taal basis of gemeenschappelijk zaken zoals de DOM zijn. Dit kan namelijk verstrekkende de-optimalisatiegevolgen hebben wanneer je functies raakt die speciale optimalisaties in de runtime gekregen hebben.
Een goed voorbeeld hiervan is de implementatie van Symbol.iterator op itereerbare types aanpassen. Als je dat doet verdwijnen ineens een heleboel optimalisatie-mogelijkheden omdat er niet meer aangenomen kan worden dat iteratie op de normale manier werkt zoals bij bijv. een array hoort. En dus kan er geen optimale machine code representatie van gemaakt worden.

Maar verder is er helemaal niets mis met het aanpassen van prototypes binnen de data types die je zelf aanmaakt. Het is een heel goede manier om mixins en aspect-based programming te bezigen binnen JavaScript.

Geen arguments gebruiken -> function aap(...a) is heel langzaam.

Een rest argument is niet hetzelfde als de ambiente arguments variabele.

Rest arguments zijn in elk geval in V8 onderdeel van de type signature van de functie en vormen een onderdeel van de object shape van de functie. Deze kan in V8 monomorphic, polymorphic, of megamorphic zijn: dwz. aangeroepen worden in slechts één parameter variatie, aangeroepen worden in minder dan N verschillende variaties aan cardinaliteit en type van parameters, of aangeroepen worden in meer dan N verschillende variaties. Pas bij meer dan N vindt er een deoptimalisatie plaats en zal er geen efficiente machine code voor de functie aanroep gegenereerd kunnen worden.

Generator functies zijn veel sneller dan meerdere .map, .filter, .reduce, enz.

Omdat je geen interne tussentijdse collecties aan hoeft te maken.
Maar als het aankomt op bijv. enkel itereren, is .forEach tegenwoordig even snel als for-in, for-of en de klassieke for loop. De performance verbeteringen daarvoor zijn al minstens sinds 2017 gemeengoed.

Schrijven naar properties triggered een paint, dus gebruik variables om eerst alles door te rekenen voordat je de uiteindelijke waarde naar de DOM property schrijft.

Dit klopt niet. Schrijven naar properties kan een wijziging bewerkstelligen die een relayout of repaint nodig heeft. Maar wanneer dit nodig is wordt deze uitgesteld tot een later moment, efficient in de rendering pipeline, zodat meer wijzigingen samengevoegd in één batch ineens doorgevoerd kunnen worden.
Dat gaat niet als je tussentijds properties uitleest die afhankelijk zijn van layout. Wat je dus moet vermijden is het bijwerken van de DOM en vervolgens het meteen teruglezen van gegevens uit DOM, want dan draai je die optimalisatie de nek om en veroorzaak je een zgn synchronous layout pass. Klassiek voorbeeld is de hoogte aanpassen en vervolgens de clientHeight property terug uit lezen.

Reads en writes hoor je gescheiden te doen in batches, bij voorkeur mbv de requestAnimationFrame functie om deze op het optimale moment binnen de relayout cycle door te voeren zodat er slechts één asynchroon uitgevoerde re-layout nodig is die alle wijzigingen in één keer als batch kan doorvoeren.

Gebruik nooit animaties geschreven in JavaScript (want paint en layout events). Gebruik alleen CSS voor animaties

Als je requestAnimationFrame op de juiste manier gebruikt is dat qua gegenereerde paint en layout events even efficient als een CSS animatie. Belangrijker is dat je enkel eigenschappen manipuleert die middels de compositor afgehandeld kunnen worden en niet een re-layout of repaint nodig hebben. Animeer dus vooral zaken als opacity of transform en vooral niet zaken als width of height.

Gebruik nooit innerHTML: werk netjes met nodes en ga er slim mee om.

innerHTML is juist vele malen sneller omdat het in één klap de hele node tree aan kan maken zonder elke keer voor het aanmaken van elke DOM node tussen native object representatie en JS representatie te moeten call-marshallen.

adjacentHTML is iets wat tijden enkel in Internet Explorer ondersteund was, en waar JS framework auteurs super blij mee waren als performance verbetering tov via de Node/Element APIs siblings achter moeten voegen.

Render alleen wat nodig is; gebruik licht gewicht placeholders voor dingen die ver uit beeld zijn en toon ze alleen wanneer de gebruik in de buurt komt. Veel DOM nodes (1000+) maakt alles traag.

Dit is achterhaald. Je kunt dit tegenwoordig sturen vanuit CSS middels de content-visibility property en de contain property.

[Reactie gewijzigd door R4gnax op 12 november 2025 19:50]

[Marcel--]

Interessant, heb je een bron waar je deze informatie vandaan hebt? En verschilt het ook per JIT (V8 vs. Mozilla-specifieke compiler)?

Gebruik nooit innerHTML: werk netjes met nodes en ga er slim mee om.

Wat ik ooit geleerd heb (jaren geleden) was dat je juist wél innerHTML moest gebruiken om snel grote stukken DOM aan te passen, i.p.v. met losse nodes te werken. Dat was toen(!) aantoonbaar sneller (ook al zou de redraw pas getriggerd moeten worden als het script klaar is).

[karelvandongen]

https://medium.com/codex/innerhtml-vs-dom-speed-i-was-wrong-and-right-41d0e06f2b3b geeft volgens mij een goed antwoord, op wanneer je het een of het ander het beste kunt gebruiken.

[Ed Vertijsment]

Bedankt, de meeste was ik bekend mee of voelen natuurlijk, maar een paar was zeker leerzaam. Ik heb nog een vraag over delete

Eigenlijk gebruik ik die nooit, maar laatst toevallig omdat ik expliciet een use case had waar de key echt weg moest.

Wat maakt delete suboptimaal?

verder:

Geen arguments gebruiken -> function aap(...a) is heel langzaam

Hoe moet ik dit lezen, spreaden langzaam, expliciete argumenten niet?

1. Generator functies zijn veel sneller dan meerdere .map, .filter, .reduce, enz.

Kan je hier een voorbeeld geven?

Hier verhoud zich dat tot een klassieke for, ik heb geleerd dat, dat nog altijd het snelst is.

Thx!

[Division]

Probleem is de enorme overhead van de "host" laag: electron of edge. Je moet een stuk browser draaien rondom de app zelf, en browsers zijn helaas niet licht. Ook zijn ze niet geweldig in het snel en efficient uitvoeren van javascript, waardoor het naast een dikke schil ook een trage schil is.

Qua performance en afhankelijkheden dus dikke zaadpot. Enige voordeel? Cross-platform en dus goedkoper te onderhouden.

[iAR]

Met als bijkomend nadeel dat het ook nog veel design factoren negeert. Ik ben erg te spreken over de rust die het design doorgaans op een Mac uitstraalt. Anders dan bijvoorbeeld op Windows, wat een soort wild westen lijkt. Maar dit soort apps hebben daar een broertje dood aan.

[MarcoC]

De macOS app is (nu nog) native, maar heel slecht. Traag, lelijk en vol met bugs.

[TonnyTonny]

En wordt iedere week minimaal 1 keer ge-update.
Voor de gebruiker is er geen enkel verschil met de vorige versie te bespeuren, behalve dat het nog trager wordt.

[Travelan]

Dat valt dus best wel mee. Ik gebruik een WebView2 'view' als plugin user interface (VST3), en die heeft in het slechtste geval een 200 MB aan werkgeheugen nodig. In het beste (en tevens ook veelvoorkomende) geval is de memory overhead nihil, omdat er al een andere app op het systeem draait die de WebView2 host al in geheugen heeft geladen. Dan heb je alleen nog het geheugen wat je webpagina zelf nodig heeft (wat natuurlijk ook niet niks is, maar niet honderden MB's).

Waarom de WhatsApp app gigabytes nodig heeft, geen idee. Het is in elk geval niet per se de schuld van het gebruik van WebView2.

Ik zie dat WhatsApp in Firefox een 600-700 MB nodig heeft voor de pagina alleen al (Shift + Esc in je browser). Tweakers heeft nog geen 200 MB nodig en NOS zit onder de 100. Geen idee wat die WhatsApp allemaal aan het doen is op de achtergrond...

[Reactie gewijzigd door Travelan op 12 november 2025 12:43]

[honey]

JavaScript? Is dat tegenwoordig niet synoniem met een onveilige omgeving?

[Kjoe_Ljan]

Nee, dat was Flash.

[dasiro]

en java, niet javascript

[Alex3]

Iedere browser gebruikt JavaScript.

[air2]

Nee absoluut niet. Javascript heeft juist geen last van b.v. veel memory bugs waar C/C++ wel last van hebben (indien niet goed geprogrammeerd) Waarom zou Javascript onveilig zijn?

[whitemage2003]

Goedkoop is duurkoop?


Altijd al geweest. Merk het bij vele applicaties tegenwoordig. Performance van lik mijn vestje terwijl de apps die ik schrijf overal de performance voorbij vliegen. Zie groot verschil in gemakkelijk programmeren en echt programmeren. Mijn app loopt op bv. Trage pc en is nog steeds sneller dan andere op dikke machines.

Grootste probleem, memory overusage waarna het os over gaat op disk caching en vwala app is dood...

Voor eerste setup (proof of concept) leuk, maar naarmate langer gebruik is het niet meer vooruit te branden.. en daarna proberen te tunen wat bijna niet gaat waar veel waste zit in mijn ogen.. en dan vervolgens wordt over gegaan op iets anders

[Reactie gewijzigd door whitemage2003 op 12 november 2025 09:29]

[WillySis]

Ik zie steeds vaker dat de prestatie en het geheugengebruik van apps ondergeschikt wordt aan het gemak bij het programmeren. Het gebruik van zoveel mogelijk standaard beschikbare componenten (die veel meer kunnen dan je ooit nodig hebt) maakt de ontwikkeling en onderhoud goedkoop. Het is ook gemakkelijker aan andere ontwikkelaars over te dragen. Kortom, het kostenplaatje van de ontwikkelaar bepaald hoe een app gebouwd moet worden.

De snelheid, daar moet de gebruiker uiteindelijk zelf maar voor zorgen door te investeren in snelle hardware.

Zelf stam ik nog uit de tijd dat intern geheugen traag was en extern geheugen nauwelijks beschikbaar voor random acces (ponskaarten en -banden, tapes en verschillende maten floppy's). Compact programmeren was toen het credo.

[84hannes]

zie steeds vaker dat de prestatie en het geheugengebruik van apps ondergeschikt wordt aan het gemak bij het programmeren.

Ik mag toch hopen dat je dit niet pas sinds een paar weken ziet. Het voordeel van programmeren tegenover hard-wired functionaliteit? Het voordeel van assembly t.o.v. punchcards? Het voordeel van C t.o.v. assembly? Het voordeel van Java/C# t.o.v. C/C++? Allemaal wisselen ze performance uit tegen programmeergemak. En met reden: de performance van een jaren 80 game op jaren 80 hardware redt je alleen met assembly. Maar de complexiteit van een moderne applicatie redt je niet met assembly. Hardware wordt welk jaar krachtiger, programmeurs worden alleen krachtiger door geavanceerdere talen en frameworks te gebruiken.

Dat betekent niet dat je altijd voor slechte performance en makkelijke frameworks moet kiezen, maar het is aan afweging die al gemaakt wordt sinds de uitvinding van de computer.

[WillySis]

Zodra de PC over een harde schijf kon beschikken en de ontwerpfout van max 640 KB was omzeild zag je al meer algemene programmeertalen komen die altijd langzamere code dan het oude assembly opleverde. Voor de programmeur wel veel gemakkelijker en sneller. De frameworks zijn ook handig, maar kosten wel performance. De standaard "bibliotheken" als webview maken het de programmeur nog gemakkelijker, maar wel ten koste van veel geheugen en een matige snelheid. Maar... intern geheugen wordt steeds goedkoper en sneller. Voor opslag geldt dat ook, dus wie wil kan toch weer voor meer snelheid zorgen.

Zelf programmeer ik overigens al enige tijd niet meer.

[StarZ]

Tja het landschap was wel wat eenvoudiger vroeger. De PC thuis bij mensen die windows draaide. Tegenwoordig moet je een app hebben op Mac, Windows, Linux, Browser, Android, iOS, watchOS, tvOS, androidtv, carplay, android auto en zo zijn er vast nog wel een paar. Dan is het aantrekkelijk om je dev team te zetten op functionaliteit en kant-en-klare oplossingen te gebruiken om heet cross platform te maken. Ik denk een goede afweging.

[whitemage2003]

Dat heet api development en kan gemakkelijk met c# asp.net of met c++ als je nog meer performance nodig hebt. En dan de database modules/frameworks links links laten liggen en gewoon sql toepassen. Maar ja (oei, dan moet er weer over een database structuur nagedacht worden). Maar zo moeilijk is dat niet... interfaces is gewoon de key waar het tegenwoordig aan ontbreekt. Of ze maken interfaces die elke x tijd op de schop gaan... ja dan is het einde zoek...

[StarZ]

Volgens mij is API development iets heel anders. Neemt niet weg dat je daarmee nog een verschil aankaart met vroeger. Alles was lokaal waar nu alles online is, grote aantallen data waardoor alles distributed is geworden. We stappen alweer af van de microservices maar dat is/was natuurlijk ook een heel andere tak van sport dan de "vroegere" applicaties. Als je die clients allemaal native wilt maken dan ben je onnodig veel kosten aan het maken. Want elk van die clients vereist onderhoud. Het is denk ik beter om die tijd en geld te stoppen in een snellere backend en mooie interface in plaats van het optimaliseren van clients. Iedereen heeft een computer met 8gb ram in zijn of haar zak, gebruik het.

[whitemage2003]

Api development is backend en dan heb je nog een frontend development nodig. Dat is met html/css/javascript waar mooie lightweight frameworks voor zijn

[StarZ]

Dat weet ik, dit is mijn dagelijkse werk. Ik heb deze keuzes meerdere keren onderzocht. Maar voor een app als whatsapp snap ik heel goed dat ze een tool als proton gebruiken. Je kunt je react (of welk ander framework je ook gebruikt) gewoon in een app schil flikkeren en je bent een heel eind.

[WillySis]

Uit ontwikkelaars oogpunt is het wel te begrijpen dat men naar een zo generiek mogelijk systeem zoekt, maar gebruikersvriendelijk is het niet.

Microsoft Edge webview2 bevat ook nog eens een bug, waardoor het na gebruik niet altijd uit het geheugen wordt gegooid. Ik zie nu op mijn PC 22 instanties waarvan er slechts 5 actief zijn. Geheugengebruik van webview2 is ook slecht loopt bij mij nu van 0,5 tot 540 MB. Alles bij elkaar pakt dat toch ruim 2 GB.

[DrPoncho]

Voor eerste setup (proof of concept) leuk

Hierin zit 'm ook meteen het gevaar. Overtuig management dan nog maar dat je werkende PoC herschreven moet worden voor wat minder geheugengebruik en verdere optimalisatie 😁

[CH4OS]

Probleem is ook wel, dat men niet overal invloed op heeft. Doordat het een Webview app wordt heb je dus 3rd party dependencies (Electron, Edge)... En die hebben ook een en ander nodig aan resources om correct te kunnen werken. Dus hoewel Meta misschien wel verder wilt optimaliseren, betekent dat ook niet automatisch dat zij dat kunnen, omdat ook zij afhankelijk zijn van derden.

[DdeM]

Dan hadden ze ook aan het begin andere keuzes kunnen maken. Je kan bijvoorbeeld ook cross platform apps maken zonder dependency op electron of edge. Zijn genoeg frameworks die platform specifieke builds ondersteunen, zoals Maui of Tauri bijvoorbeeld.

[Reactie gewijzigd door DdeM op 12 november 2025 10:47]

[84hannes]

Zijn genoeg frameworks die platform specifieke builds ondersteunen, zoals Maui of Tauri bijvoorbeeld.

Hier komt een rant, niet verder lezen als je alleen maar in positieve opmerkingen over Microsoft geïnteresseerd bent:

Maui is van Microsofts. In weerwil van alle opmerkingen over de Google Graveyard hebben technologieën van Microsoft ook niet het eeuwige leven, het verschil is dat Google er eerlijker in is. Bij Silver light heeft het ook jaren geduurd voordat Microsofts erkende dat het end of life was. Of, waarschijnlijk zeiden ze dat het zo 'mature' was dat er geen onderhoud meer nodig was. Ik ben al een tijd op zoek naar een cross platform framework voor GUI's, maar als ik naar Maui zoek dan 'zou het best al eens dood kunnen zijn'. Scherper dan dat krijg je het niet. In de woorden van een willekeurige redditor:

MAUI has been dead since not long after conception. It's just not enough. Combined with Microsoft's track record in this area, I doubt many people are eager to adopt.

En dat is het mooie van een webapp: de browser verdwijnt niet. Iedereen met een beetje verstand weet dat JavaScript een vergissing was, maar het gaat niet zomaar weg. CSS mag een hel zijn, maar het werkt over tien jaar ook nog.

@Division omschrijft het probleem als de zware host die je moet draaien: een html en javascript engine. Dat verklaart helaas niet het hele resource-gebruik, maar het levert wel een deeloplossing. Je kunt HTML5 apps, en ik hoop dat ik niets schokkends zeg, ook in de browser draaien.

edit:
Ik zou zelf trouwens nog steeds Qt een kans geven als je iets croos platform wilt, meer kans dat het over tien jaar nog bestaat dan Microsofts flavour of the month.

[Reactie gewijzigd door 84hannes op 12 november 2025 12:20]

[locke960]

Goedkoop is duurkoop?

Nee, het is nog steeds goedkoop voor Meta.

Dit is een voorbeeld van kosten externaliseren. Meta's kosten worden lager, maar de kosten voor de rest van de wereld stijgen, en misschien ook nog eens onevenredig veel. Maar daar heeft Meta geen last van.

[hoosterb]

Meta wil gewoon zo extreem veel winst maken als maar mogelijk is. Zelfs een paar goede programmeurs betalen is blijkbaar al teveel. Helaas is WhatsApp zo algemeen ingeburgerd dat je er vrijwel niet onderuit kunt het te gebruiken.

[r2504]

Het gaat hier toch maar over een chat app en geen volledig ERP pakket hè?

[winkbrace]

Die vwala was vast per expres in spreektaal. Ik vond het wel geestig.

[William_H]

Samentrekking van voilà en wollah?

[Sjoeff]

@supersnathan94

Ik vind het altijd komisch als mensen zeggen: "Ik wil niet x of y zijn maaar...." en vervolgens precies doen waarvan ze net nog zeiden dat ze het niet willen zijn .

[TheVivaldi]

Voor cross-platform heb je meer opties die minder lomp zijn dan Electron, zoals Tauri.

[toonp]

Enige voordeel? Cross-platform en dus goedkoper te onderhouden.

Betekent dit dat we nu dan ook eindelijk ondersteuning voor Linux kunnen verwachten van Meta?
Ik gebruik nu een third party product, en dat is toch niet ideaal... (whatsapp-desktop)

[rustycrab]

Misschien dat Electron vervangen voor Tauri al een hele hoop zal helpen.

[Ed Vertijsment]

Waarom precies? Verder kan ik uit het artikel afleiden dat het hier weliswaar om een webview gaat maar niet (per se) om electron?

[rustycrab]

• Tauri gebruikt de ingebouwde webview van het besturingssysteem in plaats van Chromium voor alles. Daardoor hoeft Tauri geen aparte browser te starten; het gebruikt wat al in het systeem zit.
• De backend van Tauri is geschreven in Rust, dat native code compileert zonder runtime. Electron draait een volledige Node.js-runtime naast Chromium.
• Electron spawnt meestal meerdere processen (main, renderer, GPU, etc.). Tauri gebruikt één native proces + de systeem-WebView.

[Ed Vertijsment]

• Maar de native webview op Windows is toch gewoon webview2?
• Nergens staat dat electron word gebruikt, overigens is node behoorlijk snel (node zelf heeft geen DOM) en de backend code van de runtime hoeft niet groot en zwaar te zijn, de load zal vooral in de client code zitten.
• Meerdere processen klinkt eerder als een voordeel dan een nadeel op een multithreaded systeem, overigens spawned je webview ook gewoon een gpu proces.

Ik zie niets dat aannemelijk maakt dat een migratie veel performance gaat opleveren.

[rustycrab]

Zie inderdaad dat het hier om WebView2 gaat. Maar dan moet de desktopapplicatie nog steeds in een 'wrapper' als Electron of Tauri draaien toch?

[Ed Vertijsment]

volgens mij moet er in ieder geval iets van een executable zijn die de view aanroept, dat kan een tool als bovenstaande zijn of een simpele zelf neergezette app.

Electron en Tauri doen hetzelfde trucje, maar in de context van een volledige app is dat minimaal en de overhead klein. De vertraging ten opzichte van native zal vooral zitten in het gebruik van een browser omgeving (en ik vermoed) met de DOM, dat zorgt voor een dosis overhead.

[Marcel--]

Electron en Tauri doen hetzelfde trucje, maar in de context van een volledige app is dat minimaal en de overhead klein. De vertraging ten opzichte van native zal vooral zitten in het gebruik van een browser omgeving (en ik vermoed) met de DOM, dat zorgt voor een dosis overhead.

Nee, Electron levert een complete browser (Chromium) mee, met allerhande functionaliteit, Tauri gebruikt de ingebouwde WebView van het OS, dat al geladen is. Daardoor zijn Tauri-apps ook aanzienlijk kleiner dan Electron-applicaties.

[Zwarte_os]

Beter nog, waarom kan je niet gewoon een browser tab openen?

[thePiett]

Ik snap het nut van dit soort "apps" voor de gebruiker sowieso niet. Er is toch gewoon web.whatsapp.com?

[Bananenplant]

Een webapplicatie is een beveiligingsrisico: effectief maak je daarmee de https-verbinding een single point of failure. Dat betekent dat als je een kwaadwillende partij controle krijgt over rootcertificaten deze, e2ee ten spijt, al je gesprekken kan meelezen.

Een echt veilige messenger zou om deze reden geen webapplicatie moeten aanbieden.

[Rataplan_]

Maar de native app en ook deze verschrikkelijke webview versie connecten ook gewoon met https naar buiten, dus webapp of niet, dat probleem blijft..

[Bananenplant]

Toen ik de kop las vroeg ik me af of ze dat architectuutprobleem wellicht gingen oplossen. Maar niet dus. Gezien de eigenaar geen verrassing, trouwens .

Blijkbaar hebben ze in 2021 de architectuur veranderd en verbeterd, op een manier die lijkt hoe linked devices in Signal werken. Oud nieuws dus .

[Reactie gewijzigd door Bananenplant op 12 november 2025 08:20]

[Wolfos]

De browsersandbox is juist een extra laag beveiliging, een native applicatie heeft veel meer rechten.

[Tintel]

Dat ligt toch helemaal aan de sandbox implementatie? Een reguliere browser blokkeert van alles. Maar als de - ingebouwde - sandbox gewoon pass-through naar het OS heeft.... weinig extra beveiliging. Het idee dat extra lagen - in dezelfde applicatie(!) - voor extra beveiliging zorgt is niet zomaar waar.

[Dumpin]

Wat een onzin.. webapplicatie of niet, het moet communiceren met een server om functioneel te zijn. Welk protocol je ook kiest, je zal altijd afhankelijk zijn van een key die geheim moet blijven. HTTPS is niet minder veilig dan andere protocollen die e2e encryptie doen.

[Bananenplant]

Het klopt dat je met een back-end API moet praten. Maar daarvoor kun je zelf certificaten genereren en signen zodat je niet afhankelijk bent van het vertrouwen van rootcertificaten.

Daarbij komt nog iets anders: als er met certificaten gerommeld kan worden weet je niet zeker of je wel de authentieke webapplicatie aan het laden bent. Dat is eigenlijk het grootste probleem.

[Reactie gewijzigd door Bananenplant op 12 november 2025 08:16]

[jDuke]

Eeuhm, ik denk dat https (beter gezegd TLS) echt wel veiliger is dan een native app (die zeer waarschijnlijk ook TLS gebruikt) voor communicatie. Als ik TLS als risico / SPOF zou vinden zou ik me minder druk maken om Whatsapp maar eerder druk maken om bijv. mijn overheid- en bank-zaken.

[MarcoC]

Dat doen de native apps ook.

[Visgek82]

De desktop versie werkt veel fijner en sneller.

[Noxious]

Niet meer dus

[Visgek82]

Nou ja, weet niet wanneer deze "update" komt, maar tot die tijd iig wel. Daarna ga ik wel web gebruiken.

[Smuey]

Een tab met de webapplicatie van Whatsapp neemt ook al snel een GB aan geheugen in beslag, dus echt heel veel beter wordt het er niet van, helaas.

[Martinspire]

Een applicatie vs een website heeft nog wel wat voordelen. Notificaties komen beter aan, je zit niet tegen het geheugenproces van de browser aan te hikken en je hebt betere integratie met device API's. Meer controle over bv microfoon of camera. Voor een chat app is het niet zo heel spannend, voor een bel/meeting app is het wel wat interessanter. Niet iedereen zal er profijt van hebben, maar het is wel degelijk handig. Daarnaast heeft het een eigen icoontje en kun je het naar de taakbalk minimaliseren (tenminste, als ze dat ooit zouden implementeren). Wellicht krijgen we nu weer wat meer features, want ik had al het vermoeden dat de huidige app in bugfix modus zat en niet meer echt nieuwe features kreeg.

[rko4u]

Tel daarbij op dat een app bij startup kan opstarten en kan werken met lokale cache en dus niet in een cookie je inloggegevens hoeft te bewaren.

[Eagle Creek]

Ook websites die je als app installeert kun je vastmaken aan je taakbalk en opstarten met Windows. Zie hiervoor oa https://learn.microsoft.c...e/progressive-web-apps/ux. Integratie is al een paar jaar aan de gang.

Ook Kun je de cache van de betreffende app uitzonderen als je de browserscache leegt en andersom. Ik wil niet zeggen dat het allemaal perfect werkt maar voor veel gebruikers komt het toch wel in de buurt van een native app, zaken als prestaties en integraties uiteraard daar gelaten.

[Reactie gewijzigd door Eagle Creek op 12 november 2025 08:15]

[Triblade_8472]

Als er spyware in de browser komt, als dan niet via extensions/plugins, heb je daar erbuiten ook geen last van.

[Cid Highwind]

Ik ben eerder bang voor de richting andersom. Een browser versie kan je nog in een container en met plug-ins beteugelen, een desktop versie niet.

Spyware in de browser ben je zelf bij natuurlijk. Maar wat Meta programmeert, daar moet je maar afwachten wat er onder de map gebeurt.

[anandus]

Omdat het een stuk sneller is? Voor web.whatsapp.com moet je eerst je browser openen, dan naar de url gaan. Inloggen (telefoon erbij pakken), etc.

Bij een app staat het gewoon klaar in je taakbalk. Klik en klaar.

[bishman]

Zeker nog nooit gehoord van een snelkoppeling op je bureaublad naar de url?
Ik hoef nooit in te loggen in de webversie als ik eenmaal de koppeling heb voltooid

[Reactie gewijzigd door bishman op 12 november 2025 08:18]

[Alex3]

Bij mij blijft hij ingelogd totdat ik uitlog, ook als ik de browser sluit.

[Rabb]

1x inloggen is voldoende. Tenzij je altijd incogni werkt klinkt het alsof je een adblock of cookie probleem hebt.

[Annihlator]

Losse app op de taakbalk met notificatie-bubbel, maar (voor mij vooral) ook een manier om t volume van notificaties aan te passen zonder t meteen apparaatwijd voor alles te moeten doen, zoals op de telefoon. Daar staat whatsapp op stil met een paar uitzonderingen.

[Znorkus]

Nou ik heb geen bezwaren tegen het concept "programma's", die gebruik ik al met plezier voordat er browsers waren. Ook een programma, om internetpaginas te laten zien. Programma's hebben wel voordelen vind ik. Je hoeft ze niet via een ander programma te draaien (zoals een browser), maar je draait ze 'gewoon', om die term te gebruiken, direct vanuit het OS. Geen Microsoft of Google of Firefox product verder nodig, de applicatie is standalone. Je kan er ook bij zonder internetverbinding, bij web ligt dan meteen alles plat. Je kan op OS level dingen instellen zoals taskbar notifications etc. Het heeft z'n eigen bar op de taskbar. Ik heb vaak 20-30 tabs open en je hoeft dan niet te zoeken. Ik vind het wel handig.

Kwestie van waar je vandaan komt. Voor de huidige generatie is het de vraag waarom het niet 'gewoon' in een 'app' draait van de playstore. Voor de iets oudere generatie is het de vraag waarom het niet 'gewoon' een website in een browser is. En voor nog oudere lullen zoals ik, wij zien het liefste gewoon een 64-bit standalone installer (.exe), die wij handmatig installeren bovenop het OS, daarbij voor de advanced install opties gaan, en het icoontje vervolgens wegpleuren van de desktop en toevoegen aan Turbolaunch :-)

[MrSnowflake]

De native app had als grote voordeel dat hij veel efficiënter is dan web.whatsapp.com. Nu dus niet meer. Nu is het erger dan de webapp. Dus nu zal ik ook maar noodgedwongen web.whatsapp.com moeten gebruiken

[Noxious]

Je merkt echt niets meer van de vooruitgang van hardware, applicaties worden alleen maar trager want er zijn toch genoeg resources.

Een native MSN client op je 486 was sneller dan WhatsApp in 2025 op je zware moderne werkstation.

[zanza006]

Luiheid van ontwikkelaars? Soms snap ik ook niet dat simpele aplicaties op een smarthphone soms 500-800MB moeten zijn.

[bantoo]

Nee, is gewoon geen prioriteit. Als het werkt werkt het.

[Noxious]

Dit heeft minder met de ontwikkelaars te maken en is meer een zakelijke beslissing. Native apps zijn duurder en vragen meer onderhoud om de ervaring overal gelijk te trekken.

Het lijkt de laatste tijd populair om bij veel dingen te roepen dat de ontwikkelaars lui zijn, maar die doen ook maar het opgedragen werk. Dit zijn managementbeslissingen.

[HakanX]

Luiheid van ontwikkelaars? Soms snap ik ook niet dat simpele aplicaties op een smarthphone soms 500-800MB moeten zijn.

Komt omdat die "ontwikkelaars" allemaal complete bibliotheken van honderden MB's toevoegen voor elke miezerige functie dat ze voor een paar kB hadden kunnen typen.

[LOTG]

Als ontwikkelaar word ik altijd maar triest van dit soort opmerkingen. Als of we lui zijn en maar gewoon van alles doen om minder of minder efficiënte code te moeten schrijven.

De realiteit is dat we gewoon kaders opgelegd krijgen waar binnen we ons werk moeten doen. Schrijf ik dingen liever zelf in plaats van libraries te gebruiken? Zeker, en dat doe ik ook zo lang ik er mee weg kom.

Maar als er van buiten af een deadline gesteld word of er beslist word dat we een bepaalde richting uit gaan dan is dat vaak gewoon zo ondanks dat ik mijn zorgen uit of argumenten aan draag waarom dat niet zo zou moeten zijn.

Het is niet dat ik de hele dag naar buiten zit te staren omdat ik een library gevonden heb die het ook kan.

En nu stel ik het wel even heel erg zwart/wit want gelukkig zit ik in een positie waar ik er vaker wel dan niet mee weg kom om iets op een manier te doen die ik beter vind voor het product, en heeft mijn menig wel wat waarde maar de kern is wel waar.

Wat ik wel met een grote mate van zekerheid kan zeggen is dat applicaties die grotendeels door AI geschreven zijn (vibe coding etc.) vol zitten met dit soort issues. Bij ons zou dat gewoon niet door de pipeline komen, en daar weet je zeker dat voor elke scheet een package geinclude is.

[Splorky]

Als ik het verbruik van teams zie en de shitload aan allerlei functies die ze er in bouwen denk ik ook wel eens ze hadden alleen groepen en video bellen hoeven toevoegen in msn. Heck, Lync, de Enterprise versie was ook prettig.

Nu kost het een berg geheugen en eigenlijk hoeft het voor de meeste tijd alleen standby te staan tot er een melding binnen komt.

Hoe moeilijk moet het zijn voor bedrijven van het formaat Meta en Microsoft om een beetje fatsoenlijke messenger te maken waarvan de basis al decennia terug is gebouwd. Ok het had geen flat design, het trackte een stuk minder wat je deed en het heeft geen AI, maardst wil ik best opgeven.

[Noxious]

Sterker nog, MSN Messenger hád groepen en videobellen - de implementatie is niet helemaal meer van deze tijd maar er is volgens mij geen enkele echt nieuwe functionaliteit.

[Mathijs Kok]

Een native MSN client op je 486 was sneller dan WhatsApp in 2025 op je zware moderne werkstation.

Uhhh nee. Je overdrijvingen slaan kant noch wal.

Daarnaast heb ik nog nooit hoeven wachten op WA, jij wel?

[Noxious]

Daarnaast heb ik nog nooit hoeven wachten op WA, jij wel?

Dat was dus omdat 'ie native was - dit artikel gaat er precies over dat dit gaat veranderen

Dit gaat net zo'n gedrocht worden als Teams, Discord, enz.. En op die wacht ik toch regelmatig.

[Splorky]

486 is misschien wat krap, maar op een Pentium 2 van 266 MHz draaide het perfect op de achtergrond.

Het inloggen hoorde bij het opstarten van Windows, en het draaien van de poppetjes was een ding, maar nooit absurd lang, en meldingen waren instant.

Als dat even wachten bij het inloggen betekend dat 90% minder resources gebruikt worden dan zou dat geweldig zijn

[Kaasje123]

Is dat wat ze bedoelen met enshitification?

[CAPSLOCK2000]

Is dat wat ze bedoelen met enshitification?

Nee, dit lijkt meer op een 'captive market'. De gebruikers blijven toch wel omdat ze hun contacten niet willen verliezen. Er zijn geen andere apps die rechtstreeks met WA-gebruikers kunnen communiceren dus mensen zullen vrijwel alles slikken, hoe traag, slecht of onhandig de applicatie ook wordt. WA voelt dus geen druk om de "beste" app te leveren, wel om het goedkoop te houden.

[Dirk J]

Zeker wel, het marktaandeel is dusdanig groot dat ze niet of nauwelijks groeien. Geen groei = geen "number go up" dus dan moet er maar in de kosten gesneden worden. Het maakt niet uit dat de app daar (aanzienlijk) slechter op wordt, want de gebruiker heeft over het algemeen toch geen keuze. Niemand verlaat WhatsApp omdat de app slecht(er) is geworden dan voorheen.

[Tundreq]

Niet echt. De applicatie wordt wel slechter maar het zorgt er niet specifiek voor dat je meer op het platform blijft of dat ze meer verdienen. Dit is gewoon zodat het goedkoper ontwikkelt kan worden.

[Indy81]

Als het goedkoper ontwikkeld kan worden verdienen ze er dus meer op.

Dit is zeker enshittification. Je wordt er slechter van, krijgt er niets voor terug, maar de ontwikkelaar wel.

[Alex3]

Goedkoper voor hun, duurder voor de gebruiker als je er een GB bij moet prikken.

[asaki]

Gaat de MacOS app hier ook last van krijgen?

[dmantione]

Doel is 1 broncode. HTML, Javascript, voor alle platformen gelijk. Kwestie van tijd.

[silent785]

Ik betwijfel dat dat gaat gebeuren, aangezien de code voor iOS, iPadOS en macOS grotendeels overeenkomt wanneer SwiftUI wordt gebruikt:

https://developer.apple.com/swiftui/

Apple biedt bovendien verschillende tools om apps voor meerdere apparaten te ontwikkelen, zoals Mac Catalyst:
https://developer.apple.com/documentation/uikit/mac-catalyst

[JoghoJogho]

Dit gaat idd over Windows maar hoe zit het met de MacOS app. Kun jij aangeven wat die aan geheugen vraagt momenteel? Ik gebruik de app momenteel zelf niet maar als ik de browserversie nu bekijk geeft dat tabblad 439 Mb aan.

[asaki]

Versie 25.34.17 (822316325) gebruikt rond de 300MB aan memory.

[JoghoJogho]

Dank

[Master_duck]

dat ziet dat eruit als teams. en dat is ook al zo gedrocht. O, dat is ook Webview dacht dat het gebaseerd was op edge gebeuren

[xFeverr]

Jep, is een React app in een webbrowser. Mijn oude Windows XP-bak kon met MSN/Windows Live Messenger zoveel meer chats tegelijk handelen zonder enige vertraging terwijl Teams op een dikke workstation of MacBook met M4 Pro zo ontzettend traag voelt. Switchen tussen chats, een bericht typen of zelfs omhoog scrollen om de chat terug te lezen. Steeds maar weer zit je eventjes te wachten. Belachelijk.

Native Teams zou toch zoooooveeel beter zijn.

[Mellow Jack]

Teams is een brakke app. Zonder twijfel. Maar ik denk dat je dikke workstation of MacBook kapot is

[Cybje]

Beetje gekke opmerking om dan te concluderen dat de Macbook kapot is, want ik herken de problemen van @xFeverr wel. Ik heb een Macbook met M2 Pro, dus dat is niet de nieuwste, maar ook zeker geen sloom systeem. Als m'n Macbook praktisch idle is, duurt het zomaar 20 seconden om Teams op te starten. Ook daarna is het traag. En als je dingen te snel wilt doen, bijv. direct na het opstarten een video meeting in gaan, dan crasht Teams zelfs zo nu en dan.

Een volledige herinstallatie (en daarbij ook wissen van m'n profiel op de Macbook) helpt niet. Het is ook alleen Teams die zo traag is. Ik kan allemaal zware taken in m'n IDE doen en dat gaat heel erg snel, alleen Teams gedraagt zich alsof het op een computer van 10 jaar oud draait.

[Mellow Jack]

Op mijn MacBook Air M5 en duurt het starten 5 a 6 seconden. Vergelijkbaar voor mijn midrange Windows laptop

[Pendora]

Maar dat is toch absurd lang. Heb Air M2, Outlook, Excel, etc starten in 2-3 seconde op en lijken me wel een pak zwaardere apps. Alleen Teams duurt tergend lang. Alsof MS vergeten is hoe te programmeren.

[xFeverr]

Nee hoor. Die zijn niet kapot. Die doen hun harde werk prima. Het is gewoon bizar dat mijn IDE (Rider of Xcode) zoveel meer dingen tegelijk kan doen en waarbij alles zo goed als vloeiend loopt. Terwijl Teams gewoon moet nadenken als je de agenda opent. Het is te belachelijk voor woorden.

En je ziet het dus ook met Whatsapp. Hun native applicatie werkt gewoon vloeiend en snel. En nu is dat dus weg, voelt het traag aan en gedraagt het zich op veel punten gek.

[To_Tall]

Webview heel kort door de bocht is een applicatie idd gebaseerd op browser technieken. Scheelt veel ontwikkel tijd gezien je de Engine van edge gebruikt.

[MAD_Sofia]

Ik vind berichten typen veel fijner met het fysieke toetsenbord, dus gebruik de PC cliënt als het even kan, zeker als ik gewoon aan het werk ben op de desktop..

Over het geheugen: net de nieuwe client geforceerd geinestalleerd en inderdaad,What's app gebruikt 340 mb en mijn Microsoft Outlook (waar zakelijke mailboxes openstaan) 295,7 mb.. De PC kan het prima hebben (ik heb 32 GB ram op mijn workstation), maar jeetje, het lijkt bijna alsof ontwikkelaars slordig worden..

Dus.. toch een beetje hulde aan team Outlook, maar natuurlijk niet team Browser (maar dat is een ander topic )..

Ohja, meteen getest, aan iedereen die What's app web gebruikt in de browser: deze tab (in Edge) gebruikt 337 mb aan geheugen.. Dus dat is net zo slecht als de dekstop app.

[R_Zwart]

Voor Outlook is de stok achter de deur dat inkopers bij bedrijven requirements opstellen over van alles. Dat dwingt de leverancier om het product zo goed mogelijk te maken. Die incentive is er voor WhatsApp niet.

[Robertdw]

WhatsApp is een chat app, is toch niet bedoeld om hele verhalen te schrijven. Overigens tik ik dit nu ook in op mijn mobiel, dus is niet zo'n probleem

[moonlander]

Ik typ sneller op een toetsenbord dan op een schermpje zonder feedback van knoppen. En als je dan een spelfoutje maakt moet je met je dikke vingers zorgen dat je pointer goed staat.. Dat gaat met muis toetsenbord echt vele malen sneller.

[Robertdw]

Neem aan dat u op de hoogte bent van het bestaan van draadloze toetsenborden die ook verbinding met uw mobiel kunnen maken. En zoals ik al zei het is een chat app die gebruik je voor korte zinnen, niet om een roman te schrijven.

[moonlander]

Ah ja super handig een los toetsenbord voor je mobiele telefoon..

En zoals ik al zei het is een chat app die gebruik je voor korte zinnen, niet om een roman te schrijven.

Daar zijn geen regels voor. De 1 typt hele verhalen, de ander kort.

[Robertdw]

Dan denk ik toch dat die ander weinig WhatsApp contacten overhoudt en veel blocks

[moonlander]

Hoezo? Mijn oma typt hele berichten, is ze uren mee bezig. Prima toch?

[Robertdw]

Ja en natuurlijk is uw oma het voorbeeld van de doorsnee gebruiker.😂

[Robertdw]

Die draadloze toetsenborden kun je gewoon simpel omschakelen naar 3 verschillende apparaten

[GeroldM]

Nu ik de 50 ben gepasseerd, zijn mijn ogen slechter geworden. Een groot scherm of nog beter meerdere schermen aan mijn PC en/of laptops, samen met muis en toetsenbord, ben ik veel sneller en veel minder vlug geirriteerd dan wanneer ik naar een lein k.tscherm moet staren en een vreselijk onhandig schermtoetsenbordje moet gebruiken en vaak moet wisselen tussen de verschillende "lagen" van dit onscreen toetsenbord.

Want o ja, ik verdom het om "r u ok"-stijl van communiceren te gebruiken. Is voor mij een vorm van een mentaal gebrek en vooral respectloos naar anderen toe.

[Robertdw]

Iedereen moet gewoon doen wat voor hem het beste is. Maar daar gaat deze hele discussie ook niet over. Mij standpunt was dat er hier veel heibel wordt gemaakt over eigenlijk niets. Als je de Windows app wil gebruiken zal je het grotere geheugen gebruik moeten accepteren. Wat zeker bij zakelijke toepassing geen probleem hoort te zijn. En daarnaast denk ik dat de meeste mensen gewoon de mobiele app gebruiken. Trouwens uw "r u ok" stijl is denk meer uit het Nokia (multitap)tijdperk toen mobieltjes nog geen qwerty toetsenbord hadden.

[KorporaalTimmer]

Het probleem met dit soort “garbage” applicaties is dat er teveel gebruikers zijn; mensen zijn over het algemeen te ‘dom’ om een alternatief te zoeken, of om zich te storen aan de bizar slechte prestaties van zo een app en Facebook weet dat hierdoor normale gebruikers meegetrokken worden in het gebruik van whatsapp.

[CAPSLOCK2000]

Mensen weten gewoon niet beter dan dat computers, telefoons en apps allemaal vervelend, onhandig en langzaam zijn. Dat alles vol reclame, dark-patterns en vervelende pop-ups zit. Dat ze voortdurend het gevoel hebben dat ze te dom zijn om de moderne wereld te begrijpen. Dat alles hun eigen schuld is want anders zou toch niet iedereen het doen?

Wij techneuten hebben de luxe dat we veel beter begrijpen hoe zaken onder de motorkap werken, wat fundamentele problemen zijn, wat commerciele keuzes zijn en hoe het anders zou kunnen.

[CAPSLOCK2000]

De nieuwe versie zou nodig zijn, omdat WhatsApp-moederbedrijf Meta het team achter de native app heeft ontslagen en deze daardoor niet langer kan onderhouden.

Wat is dat nu voor flut-verklaring? Waarom hebben ze dat team dan ontslagen?
Bedoelen ze soms: "We hebben het oude team wegbezuinigd en vervangen door goedkope cowboys?"

[Cooyco]

Vervangen door AI

[HansvDr]

Oke. Heb je dus niets aan. Ook wel lekker rustig.