Windows 10 krijgt bij komende update ondersteuning voor Progressive Web Apps

De browser Edge krijgt bij de komende Redstone 4-update, die in de lente verschijnt, ondersteuning voor Progressive Web Apps. Dit zijn uitgebreide web-apps die op verschillende platformen en schermgroottes werken en ook offline te gebruiken zijn.

Bij de introductie van de komende update van Windows 10 verschijnen de eerste Progressive Web Apps in de Microsoft Store, meldt de softwareontwikkelaar. Microsoft legt al vast een basis hiervoor in previewversies van Edge: bij EdgeHTML 17.17063 zijn pushnotificaties en Service Workers standaard ingeschakeld. Service Workers is de verzamelnaam voor api's die functionaliteit van web-apps mogelijk maken als systemen offline zijn of verminderde connectiviteit hebben.

Afgelopen jaar heeft Microsoft de Bing Crawler gebruikt om voor het crawlen naar en indexeren van Progressive Web Apps, waarvan de kwaliteit volgens het bedrijf hoog genoeg is om opgenomen te worden in de Microsoft Store. Het bedrijf heeft 1,5 miljoen kandidaten beoordeeld en daaruit een kleine hoeveelheid geselecteerd die in de komende weken uit te proberen zijn door Windows 10-gebruikers. Naast de automatische selectie kunnen ontwikkelaars hun eigen webapps aandragen om opgenomen te worden in de Microsoft Store.

Daarbij zet Microsoft ze om in een appx-package, zodat ze binnen Windows 10 in een sandboxed container draaien, zonder de overhead van de browser. Progressive Web Apps zijn web-apps die op verschillende platformen en schermgroottes werken en die ook offline te gebruiken zijn. Daarnaast kunnen pwa's inhaken op functionaliteit van besturingssystemen en zo bijvoorbeeld notificaties sturen. Bij Windows 10 kunnen ze bijvoorbeeld Live Tiles en het Action Center ondersteunen. Volgens Microsoft zijn ze een aanvulling op Universal Windows Apps. Het bedrijf hoopt met het initiatief het aantal apps in de Microsoft Store te verhogen.

Reacties (105)

[pookie79]

Voor mijn gevoel is het een erg geforceerde manier om maar iets unieks te hebben die sowieso voor een selecte groep interessant lijkt. We moeten allemaal windows+egde+store maar ik ben bang dat dit het zoveelste is dat iets eerst potentie heeft en nog voor het uberhaupt echt wat is het al weer links is gelegd voor het volgende ei van columbus.

Het valt of staat bij de ontwikkelaars op dit moment. Als er genoeg applicaties zijn, zullen er genoeg mensen windows telefoons/ tablets/hybrid laptops etc willen. Dus dat je iets unieks bied is juist niet slim. Apple weert zelf dat soort apps uit de store vanwege oa preformance. Waarom zou je speciefiek for windows willen bouwen op dit moment.

[Reactie gewijzigd door pookie79 op 25 juli 2024 09:52]

[BarôZZa]

Apple weert dat soort apps omdat ze enorm veel geld verdienen met de store en je daardoor geen app store meer nodig hebt. Progressive web apps kunnen al tijden net zo vloeiend zijn als native apps. Alleen op iOS leeft de gedachte nog dat performance een probleem is, omdat het daar inderdaad schokkerig en minder soepel werkt. Iets wat Apple je maar al te graag wil laten blijven geloven. Op Android kan je prima instant loading offline apps bouwen met 60fps en non blocking verwerking.

Microsoft staat er juist om bekend om ontwikkelaars zoveel mogelijk opties te bieden. Al springen ze nu vooral op de trein doordat de Windows Store niet echt hard loopt. Er worden nog maar weinig nieuwe apps ontwikkeld die puur voor Windows zijn(of welk desktop OS dan ook, games uitgezonderd). Mobile is interessanter.

Overigens ben ik geen fan van de app stores vullen/vervuilenmet een eindeloze stroom web apps waarvan inderdaad een deel van lage kwaliteit zal zijn. De manier waarop Chrome dat op Android doet is eleganter, als een site een web app heeft en je het een aantal keer bezoekt, dan krijg je de melding of je het wil installeren.

[Reactie gewijzigd door BarôZZa op 25 juli 2024 09:52]

[BikkelZ]

Alleen op iOS leeft de gedachte nog dat performance een probleem is, omdat het daar inderdaad schokkerig en minder soepel werkt. Iets wat Apple je maar al te graag wil laten blijven geloven. Op Android kan je prima instant loading offline apps bouwen met 60fps en non blocking verwerking.

Ik heb je verhaal maar niet naar beneden gemod omdat het natuurlijk op zich verder een prima post is maar ik denk dat je je hier een beetje te veel door fanboyism laat leiden. De (web) performance van een gemiddeld iOS device ligt makkelijk twee keer zo hoog als die van een gemiddeld Android device aangezien er 1) meer telefoons met high end SoC's verkocht worden en 2) de high-end SoC's binnen de zelfde generatie vaak 50% beter presteren dan vergelijkbare Qualcomm SoC's op het gebied van single threaded performance, wat simpelweg de belangrijkste graadmeter is voor JavaScript performance en daarmee dus ook web application performance. Pure performance van Safari is lastiger uit te drukken aangezien Safari niet op Qualcomm draait en vice versa, maar Safari is wat efficiënter dan Chrome met resources wat wel een verschil geeft zowel positief als negatief soms.

De belangrijkste tip voor het testen van een mobiele applicatie is dat je hem niét moet testen op je nieuwe iPhone (of een S8, even goed) maar op een Android 5 telefoon van twee jaar oud. Anders kom je de performance problemen die de bottom 50% van je gebruikers zien nooit tegen.

De reden dat Progressive Web Apps minder populair zijn onder iOS is dat Apple simpelweg een aantal standaarden niet of niet geheel ondersteunt die wel heel handig zijn voor Progressive Web Apps, bijvoorbeeld de integratie met het OS is minder sterk. Ik schrijf zelf wel eens wrappers voor webapplicaties om bepaalde dingen te kunnen doen. Op zich is de performance echt prima voor simpele CRUD toepassingen, wat je toch vaak ziet binnen B2B of B2C applicaties maar het is lastiger om het echt "native" te laten voelen qua interactie en snelheid. Kán wel maar kost tijd = geld voor iets wat gratis is als je een echte native app hebt.

[Reactie gewijzigd door BikkelZ op 25 juli 2024 09:52]

[BarôZZa]

Nee, ik ben een web developer die voor alle platformen ontwikkelt. Chrome is beter en completer dan Safari. Single threaded JavaScript performance is dus juist niet de graadmeter, want de main thread is blocking. Het is de best practice om zoveel mogelijk taken door webworkers te laten uitvoeren zodat je UI op 60fps blijft draaien. Laat nu net daar de schoen wringen bij Safari op iOS, met oa buggy implementaties van indexedDb in webworkers en zaken die veel lastiger te debuggen zijn.

Apple heeft heel veel gedaan om web apps te ontmoedigen. Safari is vrij buggy en onhandig. Daarnaast hebben ze bewust gestures in de browser gestopt waardoor je die niet meer in je web app kan gebruiken etc. Je loopt continu tegen bugs aan.

En dan heb ik het over een recente iPhone vs een stokoude Moto G uit 2014 waarin de web app soepeler werkt.

Het is ook logisch, Google is een internetbedrijf en heeft baat bij een goede browser(meer tijd op het web is meer inkomsten voor Google), terwijl Apple er absoluut geen baat bij heeft.

[Verwijderd]

Ik ga met je mee met het feit dat Safari op iOS achterloopt op Chrome op Android. In features. En bepaalde bestaande features in Safari zijn buggy. Beide zaken staan als een paal boven water.

Je zit er echter compleet naast omtrent performance, althans wanneer we naar de real world kijken. Of je nu kijkt naar render performance, interactivity, wat dan ook: op iOS is de performance doorgaans een keer of 2 beter dan op Android, zoals de persoon hierboven ook al zei.

Op Android is het juist NIET vloeiend, behalve dan wellicht op jouw high-end Android nieuw uit de doos. Zelfs op nieuwere devices schokt het vaak nog als de ziekte.

"Single threaded JavaScript performance is dus juist niet de graadmeter, want de main thread is blocking."

Zou je niet denken dat indien single threaded performance twee keer zo snel is, het blocking gedrag wat je moet doen (DOM, events...zijn per definitie blocking) dus SNELLER zijn!?

"Het is de best practice om zoveel mogelijk taken door webworkers te laten uitvoeren zodat je UI op 60fps blijft draaien"

Een nietzeggend statement, en praktisch gezien helemaal geen best practise. Wat je zegt gaat op voor een lange reken taak (stel een filter op een geuploade foto toepassen). Het gaat niet op voor UI changes, events, clicks, etc. De reden dat web apps niet smooth zijn, gaat juist om die DOM updates, clicks, events, paints, layout changes...zaken die ALLEMAAL single threaded zijn en niet uit te besteden aan workers. Om die reden gebruikt geen hond workers, behalve wanneer je app een specifieke zware reken taak heeft.

Workers zijn juist loeizware processen die lang leven. Ze zijn niet bedoeld voor simpele interacties en het is al helemaal geen best practise om daar zoveel mogelijk taken naar toe te verschepen. Dat is een anti practise en er compleet niets van begrijpen.

[DutchKevv]

Je vergelijkt volgens mij de algemene performance van een IPhone met de daadwerkelijke WebApp.

Iphones zijn inderdaad sneller met single threading, maar dat zegt A: niet dat safari dat ook is en B: niet dat Apple alsnog de boel dwarsboomt met IndexDB en gebrek aan service-worker support etc.

Ik kan @BarôZZa zijn verhaal beamen, Apple houdt Safari en browsers in zijn algemeen tegen in zijn eco-systeem. En al is het wellicht niet to-the-point, alleen al dat je een Mac device moet halen om iets voor Safari te kunnen testen kan ik wel uitkotsen

[Reactie gewijzigd door DutchKevv op 25 juli 2024 09:52]

[Verwijderd]

"Iphones zijn inderdaad sneller met single threading, maar dat zegt A: niet dat safari dat ook is"

Dat zegt het WEL. Om de simpele reden dat browsers voornamelijk single threaded werken. Vrijwel alle JS op vrijwel alle websites ter wereld worden uitgevoerd op de main thread. DOM updates en de hele keten van "werk" die dit veroorzaakt intern voor een web browser (layout, paint, composite) zijn allemaal single threaded.

Snellere single threaded performance maakt een browser dus over de hele linie sneller. Je kunt 100 cores in je CPU duwen maar voor 95% zijn die volledig niet in gebruik bij web browsen.

Of Apple het web tegenhoud is een ander punt. Ik ben het daarmee eens. Ze bewegen langzaam, en ze laten lang defects in stand.

[DutchKevv]

Ik snap je punt volledig, maar nogmaals, zoals ik het zie: Safari !== de holy meetpaal van single threaded performance..

Omdat iets sneller kan zijn, zegt niet dat dat zo is.. Er bestaan ook nog dingen als software optimalisaties in de JS / render engines etc die er niet in kunnen zitten.. Immers word er ook geroepen dat elke browser versie weer 'sneller' is dan de vorige, dat komt echt niet omdat ze stiekem een jaar wachten met de single threaded CPU performance wat sneller maken, maar omdat de browser software beter in elkaar steekt met precies de zelfde CPU als daarvoor

Wat het onderwerp trouwens meteen op het volgende punt brengt:

Chrome zit op IOS al jaren vast aan de webkit engine van Apple, wat het dus totaal niet mogelijk maakt Chrome goed af te stemmen op perks van IOS. Android daar in tegen heeft een veel diepere integratie met Chrome, waardoor die dus ook door minder 'Apple' lagen heen hoeft.. kortom, al is je single thread nog 3x zo snel, als je ten eerst al totaal afhankelijk bent van Apple zijn abstractie lagen en beperkingen ben je je voordeel al kwijt tegen over Android zijn diepe Chrome integratie. Ten 2e laat het Chrome niet toe de zelfde optimalisaties te doen als Apple zelf waarschijnlijk doet in zijn core->browser laag gezien Google totaal afhankelijk is van wat Apple maar aanbied en eerlijk opkucht in zijn 'public' webkit runtime..

Compleet onder controle en gedeeltelijk beperkt dus door Apple

[Reactie gewijzigd door DutchKevv op 25 juli 2024 09:52]

[R4gnax]

DOM updates en de hele keten van "werk" die dit veroorzaakt intern voor een web browser (layout, paint, composite) zijn allemaal single threaded.

Nee, dat zijn ze niet. Je bent goed opdreef met je foute aannames als waarheid de wereld in te slingeren, dat wel.

In zowel Edge als Firefox als Chrome draait de compositor op een aparte thread. Van Chrome en FF is met zekerheid bekend dat ook paint operaties op een aparte thread draaien, soms zelfs meerdere tegelijk op meerdere threads als niet-overlappende segmenten parallel ingevuld kunnen worden.

Chrome en Firefox gebruiken daarnaast background threads voor het parsen en compileren van JS; voor het bijhouden en waar mogelijk uitvoeren van garbage collection voor JS; voor run-time analyse van JS en verdere versnelling van geselecteerde functies door de optimizing compiler; voor het decoderen en renderen van video en audio; en waar mogelijk voor het decoderen van images.

Dat laatste klinkt voor niet-kenners misschien vreemd, maar er zitten wat technische haken en ogen aan de DOM APIs waardoor bij programmatisch inladen en in het document inbrengen van images, dze synchronous gedecodeerd moeten worden. Er komt echter een nieuwe Image.decode API aan in o.a. Chrome waarmee je deze bottleneck kunt vermijden.

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:52]

[Verwijderd]

Vrijwel alle paints draaien synchroon, slechts enkele acties zijn in bepaalde browsers op een andere thread. Je negeert voor het gemak de verplichte synchroniteit van DOM akties, wat in iedere web app de belangrijkste aktie is, aangezien iedere vorm van interactie en state change dit triggered.

Maar goed, ik kap met de discussie. Je onkunde is te groot, je leest geen reacties en hoort met name jezelf graag praten.

[R4gnax]

Vrijwel alle paints draaien synchroon, slechts enkele acties zijn in bepaalde browsers op een andere thread.

Zowel Chrome als Firefox implementeren off-main-thread painting. In beide gevallen komt het er op neer dat er display lists met draw commands geprepareerd worden die daarna op aparte rasterization threads daadwerkelijk verwerkt worden. Dat zijn dus niet "slechts enkele acties" dat zijn alle acties.

https://docs.google.com/p...YFzWHW9G4/edit#slide=id.p
https://docs.google.com/d...it#heading=h.7qbyii4p18py
https://mozillagfx.wordpr...off-main-thread-painting/

Je negeert voor het gemak de verplichte synchroniteit van DOM akties, wat in iedere web app de belangrijkste aktie is, aangezien iedere vorm van interactie en state change dit triggered.

DOM acties zijn niet verplicht synchroon. Je kunt zoveel writes doen als je wilt, maar pas bij de eerste conflicterende read is het noodzakelijk dat er een layout->paint->composite reflow plaats vindt.

Doe je dat niet en batch je read en write operaties, dan kan je dat flink wat performance-winst opleveren omdat de browser op dat moment de reflow uit kan stellen tot een vast moment wanneer deze aan een nieuw frame gaat beginnen waarbij openstaande style wijzingen geflushd worden en de layout->paint->composite trein in gang gezet wordt.

Writes voer je in de regel uit binnen een requestAnimationFrame callback; die vindt nl. plaats exact voor dat vaste moment. Buiten een rAF callback voer je zoveel als mogelijk enkel reads uit.

Je hebt MV* applicatie-frameworks die hier ook rekening mee houden en dat soort read/write batching inbakken in hun update-systemen. Zeer recent nog is bijv. CanJS 4.0 uitgekomen, waarbij de afhandeling van data mutaties omgebouwd is naar een systeem op basis van een set queues die ook met batching van DOM read/writes rekening houdt. De developers van dat framework claimen dat het tot aan 150x betere performance geeft om mutaties op die manier te batchen. Zoveel maakt dat dus uit.

Maar goed, ik kap met de discussie. Je onkunde is te groot, je leest geen reacties en hoort met name jezelf graag praten.

Wiens onkunde?

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:52]

[BarôZZa]

Of je nu kijkt naar render performance, interactivity, wat dan ook: op iOS is de performance doorgaans een keer of 2 beter dan op Android, zoals de persoon hierboven ook al zei.

In Chrome is het mogelijk om offline first, instant ladende progressive web apps te maken met 60fps. Pageloads kan je vrijwel geheel elimineren. Zelfs op oude telefoons. Dat is real world performance. Een Javascript benchmark niet.

Als je de voordelen van zaken als webworkers(en service workers) niet snapt, dan loop je gewoon jaren achter. Dan ben je nog bezig met een paginaatje op te halen en een ajax calletje uit te voeren en het resultaat in een divje te knallen, niet met een echte web app.
Als je zaken uit web workers uitbesteed (cache, zoekfuncties, ajax calls, templates renderen, pagina's preloaden, db functies), dan heb je 16ms voor de UI updates, transitions tussen views en het afvangen van de click events, wat prima te doen is.

https://developers.google...mize-javascript-execution

Doe je het niet? Dan krijg je jank, een schokkerige UI. Een soepele web app die vrijwel altijd 60fps is is simpelweg al paar jaar de best practice, ik zou niet weten hoe je dat zou willen ontkennen.

[Verwijderd]

Je haalt wederom heel erg veel dingen door elkaar.

Offline first: dit is inderdaad met een serviceworker te bereiken. Welke inmiddels dus zo goed als cross browser zijn, Edge en Safari komen er aan.

Instant loading: Ik neem aan dat je hiermee wederom offline first bedoeld, het lokaal trekken van de UI shell. Ook hier is het voordeel van Chrome slechts tijdelijk.

60fps: Dit is een brede discipline van zeer zwaar performance tunen wat totaal niet Chrome specifiek is. Chrome heeft geen enkel voordeel tov andere browsers. Websites en apps die hier weinig aan doen, wat dus de meesten zijn, zullen zien dat juist in iOS de ervaring veel dichter tegen 60fps aankomt, dit vanwege het inertia effect wat veel beter is (en gepatenteerd).

"Pageloads kan je vrijwel geheel elimineren. Zelfs op oude telefoons. Dat is real world performance."

UX is veel meer dan page loads. De echte ervaring in een app is deze niet alleen opstarten, maar hem ook gebruiken. Als je het als heilig doel beschouwd dat een UI instant laad, dan kan dit al meer dan 5 jaar lang met voorlopers van serviceworkers.

" Een Javascript benchmark niet."

Browsers zijn hoofdzakelijk single threaded. Als die thread factoren sneller is op een bepaalde CPU, gaat de complete ervaring beter zijn. DOM changes, layout, paint, composition zullen allemaal spectacular beter zijn. Dit afschrijven als niet relevant toont keihard aan dat je geen flauw idee hebt hoe een browser werkt. Juist als je met 60fps slecht 16ms hebt, zal singlethreaden op een snellere CPU veel makkelijker zijn, je hebt immers MEER budget.

"Als je de voordelen van zaken als webworkers(en service workers) niet snapt, dan loop je gewoon jaren achter. Dan ben je nog bezig met een paginaatje op te halen en een ajax calletje uit te voeren en het resultaat in een divje te knallen, niet met een echte web app."

Leuke poging om op de man te spelen, maar je zult toch echt vroeger moeten opstaan wil je me er uit bluffen.

"Als je zaken uit web workers uitbesteed (cache, zoekfuncties, ajax calls, templates renderen, pagina's preloaden, db functies)"

Uitgerekend de link waar je naar refererd beschrijft dat workers uitsluitend bedoeld zijn voor computational taken. Lange reken taken die je vroeger op de server deed. Niet voor de super simpele normale UI taken die je als voorbeeld noemt (hooguit een uitzondering voor templates renderen). Niemand zet workers in op de schaal waarop jij doelt, omdat ze daar helemaal niet voor bedoeld zijn.

"Doe je het niet? Dan krijg je jank, een schokkerige UI. Een soepele web app die vrijwel altijd 60fps is is simpelweg al paar jaar de best practice, ik zou niet weten hoe je dat zou willen ontkennen."

Waar ontken ik dat? Begrijpend lezen is blijkbaar ook niet mogelijk. Ik protesteer tegen twee feitelijke uitspraken die je maakte:

- Dat Android/Chrome het leading platform is waarop 60fps op het web mogelijk is, en hierin voorligt op Apple. Exact het omgekeerde is waar. Je moet het meeste werk verrichten op Chrome om 60fps te bereiken. Zelfs Google engineers leggen dat uit op hun eigen events. De reden is heel simpel: Qualcomm CPUs zijn volstrekt waardeloos in single threaded performance, en aangezien het web grotendeels single threaded is, is Android dus de sjaak.

- Dat Workers inzetten voor vanalles en nog wat een best practise is. Dit is geen best practise. Het is een zeer specifieke oplossing voor zeer specifieke problemen, en absoluut geen algemene best practise.

[BarôZZa]

Uitgerekend de link waar je naar refererd beschrijft dat workers uitsluitend bedoeld zijn voor computational taken. Lange reken taken die je vroeger op de server deed. Niet voor de super simpele normale UI taken die je als voorbeeld noemt (hooguit een uitzondering voor templates renderen). Niemand zet workers in op de schaal waarop jij doelt, omdat ze daar helemaal niet voor bedoeld zijn.

Euh nee, alles behalve de UI taken move je naar web workers.

In many cases you can move pure computational work to Web Workers, if, for example, it doesn’t require DOM access. Data manipulation or traversal, like sorting or searching, are often good fits for this model, as are loading and model generation.

De meeste zaken die ik opnoemde zijn geen simpele UI taken, maar hebben betrekking op data verwerking. Iets waar web workers voor zijn gemaakt. De interface updaten doe je in de main thread. Als je een dataset aan het verwerken bent in je main thread dan ben je een ei.

- Dat Android/Chrome het leading platform is waarop 60fps op het web mogelijk is, en hierin voorligt op Apple. Exact het omgekeerde is waar. Je moet het meeste werk verrichten op Chrome om 60fps te bereiken. Zelfs Google engineers leggen dat uit op hun eigen events. De reden is heel simpel: Qualcomm CPUs zijn volstrekt waardeloos in single threaded performance, en aangezien het web grotendeels single threaded is, is Android dus de sjaak.

Ik heb het erover dat je als developer meer uit Chrome kan halen vanwege de betere multithreaded mogelijkheden dan uit Safari. Dat een eenvoudige pagina sneller rendert in Safari is een totaal andere discussie. Dan ga je geheel voorbij aan waar het artikel uberhaupt over gaat: progressive web apps.

- Dat Workers inzetten voor vanalles en nog wat een best practise is. Dit is geen best practise. Het is een zeer specifieke oplossing voor zeer specifieke problemen, en absoluut geen algemene best practise.

Het doel is om een web app te hebben die als een native app aanvoelt, dus zonder vertraging, laadtijden en schokken. Je ontkomt haast niet aan het gebruik van workers. Bovendien scheid je de dataverwerking/server communicatie en de UI op deze manier.

Ik heb geen idee hoe je erbij komt dat het overgrote deel single threaded zou zijn. Bij mij (grote productdatabase tonen/updaten zonder laadtijden bij pageloads en searches) is 95%+ niet single threaded. Alle single threaded performance heb ik nodig om de app meer native aan te laten voelen, met transitions tussen views en dergelijke. Dat geldt voor zowel Safari als Chrome. Het is niet alsof je bij Safari ineens meer tijd hebt om dataverwerking te doen zonder dat je frames dropt.

Uiteindelijk kan je het nog redelijk laten lopen in Safari, maar je mist nog steeds zaken. Ga je met teveel UI elementen tegelijk rommelen, dan loopt het vaak ook al minder.

[Reactie gewijzigd door BarôZZa op 25 juli 2024 09:52]

[Verwijderd]

Zware data verwerking op een client doen, een client welke zwaar underpowered kan zijn en ook nog eens op een langzame taal draait, is een fundamenteel slecht idee. Daarvoor zijn APIs. Tenzij de taak echt lokaal moet plaatsvonden maar dat is een uitzonderlijk scenario, geen algemeen goed.

"Ik heb het erover dat je als developer meer uit Chrome kan halen vanwege de betere multithreaded mogelijkheden dan uit Safari"

Workers zijn gewoon supported in iOS, dus waar heb je het over?

"Dat een eenvoudige pagina sneller rendert in Safari is een totaal andere discussie. Dan ga je geheel voorbij aan waar het artikel uberhaupt over gaat: progressive web apps."

Het is geen totaal andere discussie, het is exact dezelfde discussie. Een geloofwaardige web app als vervanger van een native app betekent soepel van begin tot eind. De snelheid en kwaliteit van renderen is daarin een van de meest in het oog springende zaken voor een gebruiker, die de boel geloofwaardig maakt of juist niet.

"Ik heb geen idee hoe je erbij komt dat het overgrote deel single threaded zou zijn."

En ik heb geen idee waarom jij denkt dat dit niet zo is. Het gaat niet om jouw code, het gaat om het werk wat een browser uitvoert. Dit is voor >90% single threaded. Je verandert iets in de DOM: singlethreaded write. Dit veroorzaakt een cascase aan layout changes, nieuwe paints, compositie akties: single threaded. Je handelt een event af: single threaded. Vrijwel iedere aktie die een gebruiker doet in een browser (scrollen, op knopjes tikken, typen) worden single threaded afgehandeld.

Omdat dat MOET. Deze zaken moeten in volgorde uitgevoerd worden. Stellen dat single threaded niet relevant is terwijl het hele web zo werkt laat mijn oren klapperen. Het betreft vrijwel IEDERE interactie die een gebruiker met een web pagina heeft.

[BarôZZa]

Het hele concept van moderne web apps is dat je meer clientside doet. API's zijn geen vervanging, zeker niet op mobiel waarbij je niet continu data heen en weer wil pompen ivm brakke verbindingen.
De zwakke devices zijn al jaren krachtiger dan computers van een paar jaar ervoor.

Je voorbeelden van single threaded zaken zijn precies waarom je de mainthread moet reserveren voor de UI en alle andere zaken erbuiten moet doen. API of webworker(die, newsflash, functioneert als een lokale API ipv serverside).

Het idee dat je geen zware taken in de browser moet doen is natuurlijk al jaren achterhaald. Er wordt juist steeds meer in de browser gedaan, ook mobiel.

[Verwijderd]

"Het idee dat je geen zware taken in de browser moet doen is natuurlijk al jaren achterhaald"

Dat idee is absoluut niet achterhaald wanneer je de realiteit in ogenschouw neemt dat het gemiddelde mobiele device (crappy Android) secondes nodig heeft alleen al om JS te parsen.

Compleet zware apps clientside draaien kan werken wanneer je alleen bouwt voor high-end.

[R4gnax]

"Het idee dat je geen zware taken in de browser moet doen is natuurlijk al jaren achterhaald"

Dat idee is absoluut niet achterhaald wanneer je de realiteit in ogenschouw neemt dat het gemiddelde mobiele device (crappy Android) secondes nodig heeft alleen al om JS te parsen.

Compleet zware apps clientside draaien kan werken wanneer je alleen bouwt voor high-end.

Ten eerste is de situatie met parse-times drastisch verbeterd ten opzichte van enkele jaren geleden, door verbeteringen in de JS engines van browsers.

Ten tweede maak je als goede developer gebruik van code-splitting; on-demand loading; en background-loading; waardoor opstarttijden beperkt kunnen blijven.

Ten derde is het zo dat als je een app maakt met een Service Worker en je zelf het cachen van de app voor offline gebruik in handen neemt m.b.v. de CacheStorage API, Chrome - en hopelijk ook andere browsers - het resultaat van het parsen en compileren van de JS code mee opslaat en deze bij een 2e gebruik direct inzet, zonder opnieuw te hoeven parsen of compileren. Deze feature noemen ze code caching.

Voor een 'normaal' script gebeurt dit trouwens ook. Als hetzelfde script binnen 72u een tweede maal uitgevoerd wordt, dan wordt het gecompileerde resultaat gecached. Het script wordt dan wanneer het een 3e; 4e; etc. maal nodig is, direct uitgevoerd zonder dat er parsing of compiling aan te pas komt.


Als een lamme web-developer geen gebruik wenst te maken van #2 en #3; dan krijg je ook een lamme app.

Dat is niet anders dan een lamme desktop-developer die geen zin heeft om background-threads te gebruiken en alles op de UI thread doet, waardoor gebruikers een "(Not responding)" venster te zien krijgen. Of een lamme game-publisher die niet investeert in de optimalisatie van een PC port zodat er uiteindelijk een halfbakken draak zoals Arkham Knight de markt opgeduwd wordt.

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:52]

[Verwijderd]

https://cdn-images-1.medi...BQ3bCYu1AVvJWPR1x8Yig.png

Op een gemiddeld Android device, kost het secondes om flinke brokken JS te parsen. In 2017. Dus die spectaculaire sprong in parse times zet nog steeds weinig zoden aan de dijk.

Inderdaad is code splitting en de vele andere technieken om dit te optimaliseren, de oplossing. Dat is een relatief nieuw fenomeen. Het is ook een noodzaak ingegeven door dramatisch slechte single core performance van Qualcomm CPUs.

[R4gnax]

"Het is de best practice om zoveel mogelijk taken door webworkers te laten uitvoeren zodat je UI op 60fps blijft draaien"

Een nietzeggend statement, en praktisch gezien helemaal geen best practise. Wat je zegt gaat op voor een lange reken taak (stel een filter op een geuploade foto toepassen). Het gaat niet op voor UI changes, events, clicks, etc. De reden dat web apps niet smooth zijn, gaat juist om die DOM updates, clicks, events, paints, layout changes...zaken die ALLEMAAL single threaded zijn en niet uit te besteden aan workers. Om die reden gebruikt geen hond workers, behalve wanneer je app een specifieke zware reken taak heeft.

Workers zijn juist loeizware processen die lang leven. Ze zijn niet bedoeld voor simpele interacties en het is al helemaal geen best practise om daar zoveel mogelijk taken naar toe te verschepen. Dat is een anti practise en er compleet niets van begrijpen.

Gefeliciteerd. Jij hebt niet begrepen hoe je een goed-schalende applicatie bouwt met web workers.
Je moet het omdraaien: je hele applicatie leeft in de worker en besteedt enkel het werk wat de DOM aanraakt terug uit aan de main thread.

MV* Frameworks die werken op basis van een virtuele DOM en state-diffing zijn hier uitermate geschikt voor. https://github.com/web-perf/react-worker-dom is een aardig voorbeeld, maar als je even zoekt zijn er nog meer te vinden.


Ook een aantal web-evangelists van Google hebben trouwens vrij recent nog door laten schemeren dat dit is waar we heen zullen gaan bewegen als het nieuwe normaal om vlotte jank-free UI te maken.

(Overigens is het vrij houden van de UI thread en het draaien van al je daadwerkelijke applicatie-code in een backing thread met desktop applicaties al decennia de norm. Zo ongeveer sinds Windows 95 al...)

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:52]

[Verwijderd]

"Gefeliciteerd. Jij hebt niet begrepen hoe je een goed-schalende applicatie bouwt met web workers.
Je moet het omdraaien: je hele applicatie leeft in de worker en besteedt enkel het werk wat de DOM aanraakt terug uit aan de main thread."

Dit is een absurde stelling. Dit is momenteel op geen enkele wijze een standaard werkwijze of best practise. In het beste geval is het een bleeding edge experiment.

[R4gnax]

Jij noemt het een bleeding edge experiment. Ik noem het een werkende proof-of-concept.

Ja; dat het niet standaard is, dat klopt. Ik claim ook niet dat dat zo is. Wat ik claim is dat het juist niet de standaard is, terwijl het dat wel zou moeten zijn. Ik claim dat mensen die serieus met het bouwen van complexe web apps bezig gaan, zouden moeten weten hoe dit werkt. En ik claim dat dat jij -- en anderen zoals jij -- de techniek niet af moeten gaan schieten als het inzicht in hoe je deze in zou kunnen en/of moeten zetten, je nog ontbreekt.

Maar goed: als jij er echt van overtuigd bent dat dit niet klopt, en dat het helemaal fout is, dan zou je geen probleem moeten hebben om ook met goed gefundeerde argumenten te komen die bijvoorbeeld Surma en Jake Archibald van hun ongelijk zouden kunnen overtuigen.

Toch? ... ... Of misschien toch maar niet?


(Er bestaat trouwens zoiets als een [quote] element op Tweakers. Dat is iets beter leesbaar dan gewoon aanhalingstekens.)

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:52]

[Verwijderd]

Leuke steken onder water, stellen dat mij het inzicht ontbreekt. Ik ontwikkel al 20 jaar op het web en volg de ontwikkelingen op de voet. Ik ben hoofdontwikkelaar op websites met meer dan een miljard pageviews. Ik ben niet echt een beginner te noemen, of iemand die het niet begrijpt.

Je kunt beginnen met begrijpend lezen: de discussie werd gestart met stellen dat het massaal inzetten van workers voor allerlei taken een standaard recept is, een best practise, en dat indien je dit niet doet, je jaren achterloopt.

Werkelijkheid: vrijwel niemand gebruikt workers, het is onontgonnen gebied. Workers zijn verder niet bedoeld voor triviale taken, slechts voor zware rekentaken, omdat ze "duur" zijn. Voor een zeer groot gedeelte van client side apps zijn er amper echt zware rekentaken.

Ik schiet de techniek dus helemaal niet af, ik stel dat het bleeding edge is. Verder schiet ik het onjuist inzetten van techniek af, zoals het lukraak inzetten van workers waar ze helemaal niet voor bedoeld zijn. Ik ben blij dat je naar die 2 muppets linkt, want dat is precies het probleem: developers die deze Googlers blindelings volgen en denken dat al hun onderwerpen, welke veelal niche en bleeding edge zijn, de enige waarheid zijn.

[R4gnax]

Leuke steken onder water, stellen dat mij het inzicht ontbreekt. Ik ontwikkel al 20 jaar op het web en volg de ontwikkelingen op de voet. Ik ben hoofdontwikkelaar op websites met meer dan een miljard pageviews. Ik ben niet echt een beginner te noemen, of iemand die het niet begrijpt.

(...)

Ik ben blij dat je naar die 2 muppets linkt, want dat is precies het probleem: developers die deze Googlers blindelings volgen en denken dat al hun onderwerpen, welke veelal niche en bleeding edge zijn, de enige waarheid zijn.

Je realiseert je dat je hier zelf de argument from authority-fallacy begaat, heh? Juist datgene waar je mij van beschuldigd in het aanhalen van bovenstaande Googlers, maar dan door jezelf ongefundeerd naar voren te schuiven als autoriteit.

Verder verkondig je ongefundeerd onwaarheden (bijv. over het single-threaded zijn van interne browser processen); snauw je mensen af; en reageer je op rationele argumenten door je vingers in je oren te steken; alvorens er een welles-nietes wie-schreeuwt-er-harder spelletje van te maken. Dan kun je ook een sneer verwachten van iemand die vindt dat je de discussie aan het vergallen bent. Niks niet vreemd.

(Voor de volledigheid: ik zit ook al zo'n 15 jaar in het vak en heb ook een bedrijfsbrede vooraanstaande rol op gebied van frontend zaken, maar ik zal niet gaan pochen over pageviews. Overigens zo nietszeggend over de kwaliteit van wat je aflevert: een aantal van de grootste pageview-trekkers op het internet zijn technisch de grootste bagger die je je maar kunt bedenken.)

Je kunt beginnen met begrijpend lezen: de discussie werd gestart met stellen dat het massaal inzetten van workers voor allerlei taken een standaard recept is, een best practise, en dat indien je dit niet doet, je jaren achterloopt.

Werkelijkheid: vrijwel niemand gebruikt workers, het is onontgonnen gebied. Workers zijn verder niet bedoeld voor triviale taken, slechts voor zware rekentaken, omdat ze "duur" zijn. Voor een zeer groot gedeelte van client side apps zijn er amper echt zware rekentaken.

Even voorop: er werd letterlijk gesteld dat PWAs "al tijden" net zo vloeiend kunnen zijn als native apps en dat om dit te bereiken het nodig is "om zoveel mogelijk taken door webworkers te laten uitvoeren zodat je UI op 60fps blijft draaien."

Het argument dat het een absolute best-practice zou zijn en het feit dat je "jaren achterloopt" als je het niet doet, dat kwam pas ter sprake nadat jij met jou dramkloterij BarôZZa op de kast gejagen kreeg. Chapeau. Leer zelf begrijpend lezen.

Met het originele argument van BarôZZa was niets mis.

Het bestond er uit om zoveel mogelijk taken op een worker plaats laten vinden zodat de main thread en de UI ontlast wordt en zo dicht mogelijk tegen het ideaal van 60 FPS aan kan blijven. Dat impliceert totaal niet dat je voor elke scheet en een knikker een short-lived worker moet aanmaken of dat je massaal veel workers moet gaan spawnen. Dat zou inderdaad heel duur zijn. De startup cost voor een worker is namelijk vrij hoog en het geheugengebruik is ook redelijk significant.

In de basis komt het er op neer dat je simpelweg zoveel mogelijk werk van de main thread af wilt duwen. Dat is een heel valide architectuur-insteek die het al letterlijk decennia goed doet met desktop-applicaties. In die zin is het architectureel trouwens ook wel degelijk een best-practice, alleen een best-practice die op het web lange tijd niet gebezigd kon worden en nog niet de kans heeft gehad om er breed door te breken.

Het is een opzet die je, zoals ik al eerder schreef, het makkelijkste bereikt door de relatie om te draaien en je hele applicatie binnen een worker te trekken en enkel de delen die de DOM raken terug uit te besteden aan de hoofd UI thread.

Frameworks die werken op basis van een virtuele DOM zijn daar bij uitstek geschikt voor omdat ze de uit te voeren DOM updates al als een soort commandlist prepareren om op de echte DOM uit te voeren. De virtuele DOM en alles wat er aan hangt kan in principe gewoon in de worker draaien. Deze commandlists kunnen daarna in batches overgeheveld worden naar de UI thread en daar uitgevoerd worden.

Aan de UI kant verwerk je de commandlists dan in een requestAnimationFrame callback; meet je periodiek met bijv. performance.now hoeveel frame-time je nog over hebt, en als deze op begint te raken stop je en ga je verder met de lists te verwerken op een nieuw frame, binnen een nieuwe rAF callback.

Omgekeerd stuur je DOM events en DOM-to-model updates aan two-way bindings juist van de hoofd UI thread naar de worker toe.

Geen reden dat zo'n systeem niet goed zou kunnen werken. En met letterlijk honderden verschillende oplossingen in JS app frameworks met praktisch elke maand wel weer een paar extra erbij, zijn er ook vast specialistische oplossingen die zoiets al doen.

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:52]

[BikkelZ]

Hij pakt één specifiek element er uit wat wel in Chrome werkt en (nog) niet in Safari en hangt daar dan zijn hele betoog omheen dat dat performance van Chrome spectaculair veel beter is. Dit, omdat hij blijkbaar zijn applicaties altijd eerste helemaal in Chrome bouwt zonder te kijken naar de capaciteiten van andere browsers die ondersteund moeten worden en daarna gaat klagen dat >25% van de gebruikers het verrekken de zelfde browser als hem/haar te gebruiken.

Zou ik een anti-Safari betoog moeten houden (en dat kan ik heel goed) dan zou performance zeg maar niet echt een bullet point op het lijstje van klachten zijn

Workers zijn juist loeizware processen die lang leven. Ze zijn niet bedoeld voor simpele interacties en het is al helemaal geen best practise om daar zoveel mogelijk taken naar toe te verschepen. Dat is een anti practise en er compleet niets van begrijpen.

Ook dat. Ik denk ook dat ik de ontwikkelaar die mij een web applicatie geeft die niet of slecht werkt onder iOS of IE/Edge ook gewoon niet zou betalen tenzij er letterlijk in de specs staat dat het niet in Safari of IE hoeft te werken. Aangezien zowel ik als mijn klanten (vaak zakelijke) vaak op iOS en Windows zitten.

[Reactie gewijzigd door BikkelZ op 25 juli 2024 09:52]

[Verwijderd]

Ik ga niet meedoen aan het Apple danwel Google geflame. Ik heb geen enkel belang bij beide bedrijven, en ik vind beiden ook diep immorele bedrijven. Het zal me een worst wezen welke bij een discussie beter uit de verf komt.

Waar ik echter slecht tegen kan en wat me enorm triggered zijn mensen die vol zelfvertrouwen een technische uitspraak doen die werkelijk waar totaal nergens op slaat. Voor een leek ziet het er slim en technisch uit, dus het zal wel kloppen.

Zoals hierboven meneer de web developer, die geen idee heeft hoe een web browser werkt, maar wel met een schijn van zelfvertrouwen even uitlegt wat de best practices zijn en daarbij compleet door de mand valt.

Ik ken dat soort developers. Ze hebben een leuk Google artikel gevonden over een niche onderwerp, bijvoorbeeld over PWA. Ze lezen het vluchtig, menen het te begrijpen, en prediken het als nieuwe waarheid rond.

Het probleem is dat ze achteraan zijn begonnen. Ze kunnen de techniek niet juist plaatsen omdat ze vele stappen hebben overgeslagen of enorme gaten in de kennis hebben. Tegenwoordig maakt dat niet veel uit, want blijkbaar bullshit je jezelf door alles heen, als het maar indrukwekkend klinkt.

[BikkelZ]

Chrome is beter en completer dan Safari.

Tenzij verbruikte resources en batterijverbruik ook een graadmeter zijn. Vandaar dat ik dit vanuit Safari voor macOS tik en niet vanuit Chrome. Laat staan op een mobiel OS waar je gewoon een dag met je telefoon wil doen. Maar Chrome loopt voorop qua features zonder meer.

Het is de best practice om zoveel mogelijk taken door webworkers te laten uitvoeren zodat je UI op 60fps blijft draaien.

Dat is allemaal leuk en aardig maar als jij technologie gaat gebruiken die niet in alle browsers ondersteund wordt (en je zit nog steeds met een redelijke % aan oudere IE gebruikers als je Apple niet meerekent) dan gaat de vlieger gewoon niet op. Als je dat niet leuk vindt moet je geen webdeveloper worden. Ik heb jaren ook IE6 moeten ondersteunen en daardoor The Latest New & Shiny wat wel in Firefox en Chrome zat niet kunnen gebruiken.

Microsoft is ook pas net aan boord, Apple is er inmiddels mee bezig. Het is altijd zo geweest met webstandaarden en het wordt ook nooit anders. Je hebt gewoon het verkeerde beroep gekozen als je alleen maar met de nieuwste spulletjes wil spelen.

iOS native apps developers hoeven altijd maar één versie terug te ondersteunen aangezien >90% altijd laatste of voorlaatste versie draait, is dat niet beter voor jou? Ik was in ieder geval erg opgelucht dat ik nooit meer aan legacy problemen hoefde te werken of dit of dat niet kon nadat je het gebouwd had omdat IE7 weer net wat dingen anders verkeerd deed dan IE6 en IE9.

Sowieso is het een slecht idee om te ontwikkelen en testen op de browser die de meeste features en de minste bugs heeft. Over een...

best practice

...gesproken

Performance van Safari is prima tenzij je dingen gaat doen die niet ondersteund worden. Maar dan worden de problemen veroorzaakt door een developer die niet goed kan inschatten wat wel en niet kan en niet door de host browser.

Natuurlijk wil ik ook dat Safari meer dingen gaat ondersteunen dan het nu doet, ik zeg niet dat het goed is dat het qua features achter loopt. Maar jij bent de professional en jij hebt de taak te begrijpen wat wel en niet ondersteund wordt op de platformen die door jouw klanten getarget worden. Aan de andere kant zou ik graag zien dat Chrome en Chrome gebaseerde software eens wat meer respect toont voor de resources op mijn computer. Het kan niet waar zijn dat een IDE als Xcode of zelfs Visual Studio minder RAM en CPU gebruikt dan HTML Document Viewer als Chrome.

[Reactie gewijzigd door BikkelZ op 25 juli 2024 09:52]

[BarôZZa]

Sowieso is het een slecht idee om te ontwikkelen en testen op de browser die de meeste features en de minste bugs heeft. Over een...

Absoluut niet mee eens. Marktaandeel van Chrome is verreweg het grootste, dus zorg ik dat daar de beste ervaring in is. Daarna zorg je ervoor dat je ervoor dat het werkt in andere browsers. Overigens is het vrijwel altijd zo dat als je je aan de standaarden houdt het vaak prima werkt in Chrome, Firefox en Edge. Pas als je in IE en Safari gaat kijken kom je vaak rare dingen tegen. Web workers worden ook al tijden ondersteund.

Als je optimaliseert voor de zwakste browsers, dan loop je altijd achter. Dat zijn hetzelfde soort mensen die niet af durfden te stappen van table layouts. Of van float: left voor designs, of geen flexbox durven te gebruiken. Of van die mensen die trage JQuery javascript animaties gebruikten. Of een native app moesten dachten te moeten ontwikkelen omdat hun websites/apps niet responsive waren.

Ik knal liever support af voor achterhaalde browsers die amper gebruikt worden dan dat ik niet het maximale uit de de moderne en meest gebruikte haal. En in de praktijk levert dat altijd veel meer op dan optimaliseren voor een groep gebruikers die alleen maar kleiner wordt en vaak niet eens meer echt bestaat. Je kan beter voorop lopen dan achterop. Wat nu shiny is, is straks gewoon de standaard. Ik weet nog hoe gestresst veel developers en bedrijven waren toen mobiele devices populairder werden. Daar hadden ze nooit rekening mee gehouden, die optimaliseerden voor IE6. Zelfs nu is de kennis bij developers op dat vlak vaak nog bedroevend.

[BikkelZ]

Wat nu shiny is, is straks gewoon de standaard.

Als het nu niet op de systemen van je klanten draait word je niet betaald.

Safari en IE negeren kost gewoon te veel omzet. Dus je komt op mij over als iemand die heel graag het nieuwste gebruikt maar dat niet mag van de baas.

[BarôZZa]

Niet mag van de baas? Ik weey niet in wat voor omgeving je werkt, maar het is gebruikelijk dat de baas gebruik maakt van je expertise en naar jou luistert. Als je kan aantonen dat de nieuwe app leidt tot meer activiteit, een hogere conversie en meer omzet dan heb je het gelijk aan je zijde.

Het is ook vrij logisch. Tenzij je bijvoorbeeld denk dat gebruikers met stokoude computers en browsers bijvoorbeeld meer online bestellen dan mensen met nieuwere apparaten.

En ja, dat heb ik allemaal in de praktijk toegepast en heb zo'n 20 jaar ervaring met web development.

Maar toch schattig dat je me zo goed weet in te schatten.

Ook geen woorden verdraaien, ik zeg nergens dat ik ze negeer. Op oude IE versies na, die zijn al jaren dood.

[Reactie gewijzigd door BarôZZa op 25 juli 2024 09:52]

[BikkelZ]

maar het is gebruikelijk dat de baas gebruik maakt van je expertise en naar jou luistert.

Mijn baas luistert meestal naar zijn klant en daar komen dan weer vereisten uit. Daar hoor jij dan weer naar te luisteren.

Tenzij je bijvoorbeeld denk dat gebruikers met stokoude computers en browsers bijvoorbeeld meer online bestellen dan mensen met nieuwere apparaten.

Tenzij het in dit geval ook gaat om mensen met een gloednieuwe iPhone X en dus blijkbaar een zeer kleine barrière om allerlei overpriced shit te kopen. Die wil je zeker wel binnenhouden als klanten. Je bent wel ongeveer bekend met de omzet die iOS gebruikers genereren in webshops bijvoorbeeld? Altijd een stuk groter dan het % van de bezoekers met iOS. Daar bovenop: het wordt veel zakelijk gebruikt en als het niet (goed) op de telefoon van de klant werkt is het gewoon stuk.

Met je baas kun je rustig praten over de nieuwste snufjes, maar klanten? Die kennen geen genade. En daar komt het geld vandaan.

Als je nou aan kwam met het argument dat het in TP49 zit en aangezien het project pas over x maanden af is tegen die tijd de laatste publieke versie het heeft, dan mag je het van mij proberen. Je bent dan wel afhankelijk van het feit of Apple de implementatie dan precies op een manier heeft gedaan dat jij geen problemen krijgt dus je legt je ballen wel op het blok, maar zo heb je het waarschijnlijk ook gewoon het liefste.

Ga je je hele implementatie baseren op iets wat bij een kwart van de gebruikers gewoon niet aanwezig is dan ben je gewoon niet echt bezig met internet maar meer met de technische dingen die jou het meeste boeien. Het is nog nooit anders geweest dat je altijd ergens weer een achterlijke browser moest ondersteunen. Gisteren IE6, vandaag Safari, in de Middeleeuwen Netscape. Als het er niet goed in werkt ben jij gewoon degene die het verprutst heeft.

Ik kan vanuit hier niet zien op welk project precies jij geen 60FPS kunt halen met Safari op een gloednieuwe iPhone maar ik durf te wedden dat als je je meteen had neergelegd bij je beperkingen en vanuit daar begonnen was dat het gezien ruwe snelheid van de browser en de onderliggende hardware gewoon te halen had moeten zijn.

En ja, dat heb ik allemaal in de praktijk toegepast en heb zo'n 20 jaar ervaring met web development.

Maar toch schattig dat je me zo goed weet in te schatten.

Ah wat leuk. 1997! Dus ooit een site eerst helemaal in IE gebouwd en daarna Netscape nog moeten doen dus. En daarna een site in Firefox om daarna toch weer IE6 te moeten ondersteunen. En nu eerst in Chrome om daarna nog Safari te gaan doen.

Je gaat toch ergens wel een patroon herkennen in de hoeveelheid en het soort problemen wat je steeds terug op je bureau krijgt om te fixen nádat je vond dat de website of -applicatie klaar was?

Of hoe deed je dat vroeger dan?

[BarôZZa]

Hoe kom je erbij dat ik Safari niet ondersteun? Ik zeg dat ik features bouw voor Chrome specifieke dingen die niet werken in Safari. Denk aan progressive web apps, paymentrequestapi, serviceworkers, notificaties etc.

Waarom zou je niet optimaliseren voor 75% van de gebruikers als het de andere 25% niet schaadt? Het is puur niet beschikbaar voor de mensen met iOS. Dat heet progressive enhancement. Dat iets niet op iOS werkt betekent niet dat je het niet moet laten werken op Chrome. De zaken zitten simpelweg niet in Safari.

En de angst voor klanten ken ik niet echt. Je zit overduidelijk verkeerd te denken, want de klanten waar ik het over had bestelden rechtstreeks bij de shop in kwestie, maar hadden geen zeggenschap. Resultaten zijn prima meetbaar. Bij andere organisaties was het ook geen probleem, klanten wilden niet veel geld kwijt zijn aan 0.1% van de gebruikers. Belde er in een zeldzaam geval iemand met een browserspecifiek probleem? Probeer het vanaf een andere computer. Tenzij je denkt dat het nuttig is om tijd te besteden aan of een app in Windows Phone 7.5 werkt.

Ik kan vanuit hier niet zien op welk project precies jij geen 60FPS kunt halen met Safari op een gloednieuwe iPhone maar ik durf te wedden dat als je je meteen had neergelegd bij je beperkingen en vanuit daar begonnen was dat het gezien ruwe snelheid van de browser en de onderliggende hardware gewoon te halen had moeten zijn.

Je lult in de ruimte. Als indexeddb buggy werkt in webworkers in Safari, dan gaat dat ten koste van de performance in Safari omdat je het buiten de webworker moet halen. Als je geen serviceworkers hebt in Safari, dan gaat dat ten koste van de performance in Safari bij het initialiseren. Dan heb je vaak nog de wat buggy/trage rendering van transitions en images. Neemt niet weg dat je nog een redelijk resultaat kan halen met veel werk, maar dat was het punt niet.

Het punt was dat Apple het verwaarloost en als je probeert iets ambitieus te maken, dat je veel eerder tegen de beperkingen aanloopt in Safari.

[R4gnax]

Dat is allemaal leuk en aardig maar als jij technologie gaat gebruiken die niet in alle browsers ondersteund wordt (en je zit nog steeds met een redelijke % aan oudere IE gebruikers als je Apple niet meerekent) dan gaat de vlieger gewoon niet op. Als je dat niet leuk vindt moet je geen webdeveloper worden. Ik heb jaren ook IE6 moeten ondersteunen en daardoor The Latest New & Shiny wat wel in Firefox en Chrome zat niet kunnen gebruiken.

Microsoft is ook pas net aan boord, Apple is er inmiddels mee bezig.

Jij haalt service workers en web workers door elkaar. Internet Explorer ondersteunt web workers al sinds IE 10 en alles onder IE 11 is feitelijk dood of stervende.

Performance van Safari is prima tenzij je dingen gaat doen die niet ondersteund worden. Maar dan worden de problemen veroorzaakt door een developer die niet goed kan inschatten wat wel en niet kan en niet door de host browser.

Performance van Safari is redelijk, maar kan Chrome in praktijkscenario's absoluut niet bijbenen.
Safari met pin-to-homescreen is trouwens een buggy rotzooi. Verschrikkelijk veel idiote bugs die zo voor de hand liggend zijn dat zelfs de meest die-hard Apple fanboy niet anders zou kunnen concluderen dan dat Apple deze hele feature bewust verwaarloosd heeft.

Daarnaast is het jaaaa----ren lang zo geweest dat Apple kritische performance features van Webkit afgesloten heeft gehouden voor derden en alleen aan Safari zelf toegankelijk maakte. Als je -- zoals bij Cordova apps -- van een app-shell om een WebView heen gebruik maakte, dan kreeg je met een slap aftreksel te maken: lange tijd kon/mocht een WebView niet eens de optimizing compiler voor JS inzetten waardoor alle JavaScript geforceerd in een extreem langzame full-interpreter modus draaide; en mochten WebViews geen gebruik maken van veel features in de hardware compositor, waardoor animaties en simpele zaken zoals scrollen vreselijk duur waren en een disproportionele impact hadden op de frame-rate.

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:52]

[RobinJ1995]

Op Android kan je prima instant loading offline apps bouwen met 60fps en non blocking verwerking.

Is dat zo? Ik heb indertijd namelijk het hele hybrid gebeuren maar opgegeven en mijn app herschreven in native code omdat het gewoon niet te fixen was. Constante haperingen en andere performance-problemen, en zelfs dingen die op verschillende telefoons (thanks, Samsung) zich weer net wat anders gedroegen.

Nee, ik kan je gerust zeggen dat native apps nog steeds vele malen beter presteren dan het hele hybrid-gedoe. Ik zeg niet dat PWAs totaal geen toegevoegde waarde hebben, maar als prestaties en een vlotte gebruikerservaring belangrijk zijn lijken ze mij (voorlopig nog, op zijn minst) niet the way to go.

[BarôZZa]

Wat is indertijd? Er zijn door de jaren heen veel ontwikkelingen geweest, maar pakweg de afgelopen 2 jaar is het heel goed mogelijk. Je moet wel wat verstand hebben en je verdiepen in de rendering (performance tab in Chrome dev tools is ideaal middel), gebruik maken van webworkers etc. En vaak is het lastiger als je gebruik maakt van allerlei frameworks, vanilla JS leverde bij mij de beste resultaten op.

Google heeft veel bruikbare documentatie en video's: https://www.youtube.com/w...continue=64&v=ZqdNgn5Huqk
Sowieso veel interessante presentaties bij de Progressive Web App Summit 2016

[kalikatief]

Progressive web apps kunnen al tijden net zo vloeiend zijn als native apps.

Dit is misschien bij topmodel telefoons en geweldige webapps zo, maar het blijft in het niets vallen vergeleken met iets native. Je kunt dan denken 'moeten ze maar beter coden', maar JS is zo een gigantische jenga-toren van opeengestapelde technologieën en mogelijkheden dat iets dat responsief is en nog een beetje vriendelijk is voor de batterijduur erg moeilijk is. Daarnaast is het zo dat de nummer één reden van het stotteren van webpaginas op mijn telefoon (zowel laden als scrollen) de advertenties zijn.

Dit betekent niet dat ik een fan ben van de duizenden slechte apps; echter vind ik het nog lager leggen van de lat met een bewezen langzame & onveilige laag een slechte zaak voor de consument.

[watercoolertje]

Apple weert zelf dat soort apps uit de store vanwege oa preformance.

Dat zijn geen PWA's maar apps op basis van html/js waar een hobbyistische laag tussen is gebouwd om functies te gebruiken waar een web-app normaliter niet bij komt.

Een echte PWA komt dan ook niet in een package, dat zou nergens op slaan. Daarnaast gebruikt het native functies die de browser aanbied, dus met een stabiele/snelle tussenlaag waarmee je enkele (en zeker niet alle) functies van een telefoon kan gebruiken.

En los daarvan is het wel vrij gemakkelijk om z'n app te maken wat dan meer mensen met onkunde aantrekt en dus inderdaad kan zijn dat verhoudingsgewijs meer slome troep tussen zit. Maar dat sluit niet uit dat je prima snelle apps kan bouwen, zeker als er de data/informatie toch opgehaald moet worden via het web.

[Reactie gewijzigd door watercoolertje op 25 juli 2024 09:52]

[Gelukshand]

Ten eerste is tweakers vergeten te melden dat het niet specifiek alleen voor Edge is. Want het kan ook op chrome of firefox, die ondersteuning word dan al gegeven.

Ten 2de google en microsoft werken samen aan dit project.

Dus het is helemaal niet het pushen van store of browser.
Het is het gemakkelijker maken voor makers van apps.
En voor de gebruiker want alle apps zien dan het zelfde uit.

[pookie79]

Zo klinkt het al een stuk beter.

[? ?]

Progressive Web Apps zijn toch de toekomst.
Waarom twee app maken voor verschillende systemen (Android, iOS) als je alles in één keer kan met de technologie die veel meer mensen kennen. Apple sputtert nog wat tegen omdat die liever elke ontwikkelaar 100 euro per jaar zien betalen.

Maar!! Apple heeft het opgenomen in de roadmap voor iOS. Het probleem is een beetje dat het te groot aan het worden is voor hen om het te negeren.

[Frank-L]

Uiteraard gaat het Apple helemaal niet om dat zakcentje. Het gaat om controle. Nieuwe apis toevoegen is plotseling heel lastig en vereist inspraak van anderen. En natuurlijk gebruikerservaring: met name de performance en de look and feel. Bijvoorbeeld een native scroll view werkt bij iOS veel lekkerder dan die van veel web apps.

[BikkelZ]

Bijvoorbeeld een native scroll view werkt bij iOS veel lekkerder dan die van veel web apps.

Sinds iOS11 gelijk qua snelheid

[Frank-L]

Ik heb het niet over de snelheid. Ik bedoel dat als je een beetje scheef duwt om te scrollen dat er dan niks gebeurt. Of het bounce effect aan het einde van de lijst werkt niet of anders.

[CEx]

Die 100 euro daar doen ze het echt niet voor. Het probleem (nu al in zekere mate aanwezig) is het gigantische overvloed aan nutteloze apps ten opzichte van apps met enigzins nuttige functionaliteit.

[Tweaker1234]

Lees je eens in over Progressive Web Apps ipv je onderbuik gevoel te laten opspelen.
Progressive Web Apps is iets wat Apple en Google ook willen.
En is beter dan allemaal losse apps.

[pookie79]

De app kan wel overal draaien in een browser. Maar zal zeker ook bij Apple geen app strore status krijgen. Dit staat ook in hun voorwaarden.

[BikkelZ]

Een schilletje om je applicatie leggen is zo gedaan. En een PWA geeft als "hybrid" app nog steeds een superieure ervaring. Het pinnen van een website kan ook maar dat is nog beperkt onder iOS.

[DutchKevv]

Voordeel van progressieve web apps is dat ze in uniform HTML+CSS+JS geschreven zijn dus het werkt ook buiten win10 store (zoals Android).
Android en Chrome vragen bijvoorbeeld een manifest.json met wat meta data om de PWA te installeren. Dus het is zeker geen Windows only taktiek, eerder een optie van MS om een app te kunnen schrijven zonder (windows only) win32/C++ te hoeven aanraken

[BramV]

PWA bestaat al jaren. Als je een manifest file maakt, heb je in feite al een web-app. Je kunt je website/app dan toevoegen aan 'home screen', waardoor het functioneert als een App omdat de gebruiker de URL balk niet meer ziet. Alleen gaan bedrijven als Google en nu ook Microsoft er mee aan de haal, en dan wordt het natuurlijk gecompliceerd. Maar nog steeds is een eenvoudige tekstfile de basis voor een standaard App. Funky

[Verwijderd]

Wat jij bedoelt is een normale website die in de appstore gezet kan worden. PWA is een benaming voor een set standaarden en technieken om die websites als echte apps te laten aanvoelen. Zie hier.

[BramV]

Ik weet, zoals ik al schreef, al jaren wat een PWA is, de basis is een manifest file waardoor je iedere site of webapp kunt laten functioneren als een App.
https://developer.mozilla...bExtensions/manifest.json

[Verwijderd]

In de basis is elke website HTML, gaan we dan ook zeggen dat we PWA's hebben sinds we HTML hebben uitgevonden?

[Verwijderd]

Hij heeft wel degelijk gelijk. Een PWA is een super slappe definitie. In de absolute basis is een manifest file genoeg om je website (die helemaal geen app is) een PWA te mogen noemen.

Leg de lat een klein trapje hoger (Lighthouse check) en dan vind zelfs Google je een PWA. Ook daar hoef je bijna niets voor te doen behalve dus die manifest, HTTPs gebruiken en een serviceworker hebben, ongeacht wat die doet.

Je kunt dus een stokoude website binnen 5 minuten een PWA maken indien je uitsluitend de technische term hanteerd, terwijl je NUL maar dan ook NUL van de PWA ideeen hebt geimplementeerd.

Dat is op zijn zachts gezegd wel een probleem, het is een compleet nietszeggende term.

[Verwijderd]

Het is alleen een nietszeggende term als je een technische check beschouwt als de waarheid, wat het in dit geval natuurlijk niet is. De definitie van Google gaat veel verder dan dat.

[Verwijderd]

Helemaal mee eens, maar hoe gaan we antwoorden op de vraag of iets wel of geen PWA is? Daar is geen antwoord op momenteel.

[BramV]

Nee je hebt een manifest file nodig om het te laten functioneren als een PWA.

Maar een html/hello world + manifest is inderdaad genoeg voor een App.

Gelukkig zijn er altijd mensen en bedrijven om het nodeloos ingewikkeld te maken. Dan lijkt het heel wat.

[Verwijderd]

[cracking cloud]

In dat geval is het een vervolg op de hta apps die microsoft de vorige eeuw al had bedacht

[cracking cloud]

idd, verplichte xkcd

[bush]

Wat een onzin, dit is het MS van 5 jaar geleden.

[BramV]

Doen hun best, maar de ondersteuning van Html-email standaarden in Outlook is dramatisch en jaagt het bedrijfsleven en uiteindelijk de consument, na het tragische IE8, wederom op hoge extra kosten. Als Outlook een voorloper zou worden bij het ondersteunen van standaarden dan zou ik in je onzin meegaan. Een bedrijf verandert niet zomaar.

[Reactie gewijzigd door BramV op 25 juli 2024 09:52]

[ManIkWeet]

Ik vraag me af wat voor voor/nadelen dit soort apps hebben op batterijduur...

[DutchKevv]

Relatief veel nadeel volgens mij.. Want je spawned in feite gewoon een browser met alle shizzle die er onderwater bij hoort.. Meer gemakzucht dan performance winst uiteindelijk

[Neko Koneko]

Relatief veel nadeel volgens mij.. Want je spawned in feite gewoon een browser met alle shizzle die er onderwater bij hoort.. Meer gemakzucht dan performance winst uiteindelijk

Bij heel veel applicaties moet tegenwoordig een heel framework ingeladen worden (.NET, Java, etc). Als de browser componenten in principe gewoon zoveel mogelijk gedeeld in het geheugen worden gelaten (dus je gebruikt de browser componenten als je "framework" zou het mogelijk zelfs in performance kunnen schelen. Het zou wat dat betreft beter zijn dan al die "apps" die gewoon een volledige Chromium browser ingebakken hebben en waar er per app een aparte instantie van de betreffende browser in het geheugen actief is.

[Reactie gewijzigd door Neko Koneko op 25 juli 2024 09:52]

[cracking cloud]

Het was toch juist allemaal gescheiden (ook in Chrome) omdat een bug in de ene tab dan geen fouten veroorzaakt in de andere tab? Dus dat er maar 1 tab hoeft te crashen ipv de hele browser. En hoe zit het met beveiliging? Zou er in theorie en lek kunnen ontstaan waardoor gegevens van de ene PWA naar de andere PWA gehengeld kunnen worden als de browser componenten worden gedeeld?
Ik heb er geen verstand van maar ben wel benieuwd wat de voor/nadelen zijn

[Verwijderd]

Ik denk dat dit het aanvalsoppervlak flink gaat vergroten en de privacy sowieso flink gaat verminderenb. Nu ontneem ik de browser allerlei rechten om te voorkomen dat elke website die kan misbruiken om targeted reclame te sturen (website diem'n lokatie wil weten? Dacht het toch niet.) of het zoveelste advertentievirus te droppen. Als straks elke site wil dat je een pwa installeert kan dat niet meer.

[DutchKevv]

True dat zou het wel grotendeels oplossen idd!

Electron (wat praktisch zelfde is als de PWA techniek van MS) is al wel aan het kijken of het lukt om een shared browser runtime te gaan gebruiken

https://github.com/electron/electron/issues/673

[watercoolertje]

Want je spawned in feite gewoon een browser met alle shizzle die er onderwater bij hoort.

Naja een hele hoop uit een reguliere browser heb je juist ook niet bij een PWA.

Los daarvan, waarom denk je dat dat niet efficient zou zijn?

[DutchKevv]

Als je electron apps vergelijkt (zoals slack etc ) met native apps kom je volgens mij op redelijk de zelfde (onderliggende) techniek, inderdaad zonder de omliggende browser Shell, maar nog wel 95% van de browser en die staan ook bekend als massive batterij slurpers. Correct me if im wrong

[Verwijderd]

Electron is wel zo'n verschrikkelijke troep, ik snap niet dat developers daar actief apps op maken. Laptops blazen als stieren wanneer je een eletron app opent. Het krijgt zelfs dikke desktops aan het zweten.

En vaak voor iets simpels als een tekst editen.

[Steyn_E]

Ik weet niet of de browsers daadwerkelijk de energieslurpers zijn. Het zou goed kunnen dat het veel te maken heeft met het feit dat je veel witvlak op het scherm hebt, bij een OLED scherm maakt dat veel uit voor het stroomverbruik. Daarom zie je bij OLED vaak zo'n verschil in accuduur bij browsen en bij film kijken (meer donker oppervlak).

[latka]

Omdat het tekenen van een pixel op het scherm door tig lagen van abstracties gaan. Abstracties zijn leuk, maar kosten performance/stroom dus per definitie minder zuinig (anders heeft je abstractie geen toegevoegde waarde).

[DevWouter]

Los dat het batterijverbruik door een heleboel verschillende factoren bepaald wordt is een PWA echt niet beter/slechter voor je batterij dan een gewone app.
Bovendien ontwikkel je een PWA juist vaak vanwege performance en het gemakszucht. Je moet echt in een zeer specifiek domein zitten wilt één van de twee een overhand krijgen.

Je kan (en zou eigenlijk altijd) bij elke applicatie afvragen: Wat is beter? Native of PWA?

[DutchKevv]

Die volg ik niet helemaal. Je vind een PWA betreft performance beter dan native?

Met andere woorden, HTML en JS zijn sneller en zuiniger dan C/++?

[DevWouter]

Als ontwikkelaar moet je rekening houden met het onderhoud van je applicatie en wat de klant/gebruiker nodig heeft. Al deze factoren en meer moet je meenemen wanneer je een keuze maakt.

Dat betekent dat PWA een betere ervaring kan opleveren dan een andere techniek, maar dat hoeft niet.

Voorbeeld 1: Cryptomunten minen - Hier zal een PWA het niet snel winnen. Dit is gewoon rekenwerk en hoewel de Javascript engines een fantastisch performance (relatief dan) zullen ze niet een C++ engine gebruik makend van threading en SIMD verslaan. (Althans nog niet)
Voorbeeld 2: Twitter client - Hier wint PWA. Je hebt interactie met het internet, je hebt complex layout vraagstukken (waar HTML+CSS voor uitgevonden zijn).
Voorbeeld 3: Een IDE: Dit is om het even. Qua performance zijn er geen grote eisen, maar je moet rekening houden met integratie van het systeem

[xFeverr]

En toch zoiets simpels als een teksteditor: kijk naar bijvoorbeeld Sublime tegenover VSCode/Atom/whatever...
Sublime is zóóóó veel sneller en heeft zóóóó veel meer performance dat je het echt heel goed merkt. En het is in de basis maar echt iets heel simpels.
En ja, een native twitter client kan dus echt wel beter werken. PWA wint daar dus alleen voor het gemak maar zeker niet voor de betere ervaring of performance.

[Verwijderd]

Klopt helemaal. Atom krijgt zelfs mijn dikke Alienware met supersnelle SSD en i7 bijna op de knieeen. Om een fucking tekst file te openen. Sublime is zo snel dat het oneindige performance heeft, gewoon geen zichtbare vertraging.

Fuck Electron en alle rotzooi die er mee gemaakt wordt. Iedere vooruitgang in hardware wordt in de vuilnisbak gekieperd door luie developers met shitty frameworks.

[xFeverr]

Hier ben ik het dus zo mee eens. Zo vind ik het zelf ook verschrikkelijk dat ik een übersnelle telefoon heb, maar dit volledig teniet wordt gedaan als er weer zo'n ramp-app tevoorschijn komt.

Als ontwikkelaar zal ik altijd strijden voor native apps in plaats van dit soort spul.

[Verwijderd]

Begrijp me niet verkeerd, ik ben juist voorstander van een PWA, mits goed uitgevoerd. Ik doel specifiek op de ellende die Elektron heet.

[g4wx3]

Spannend!
Toen Apple de iphone lanceerde, was het de bedoeling om websites op te waarderen tot apps.
(Apps waren toen voor nokia, windows mobile, of blackberry)
Apple ging volledig voor HTML5 want Apple kreeg weinig animo van Adobe en Flash. (ook niet op de iComputers).
Even daarna heeft Apple dan toch een appstore gecreëerd, met het gekende succes.
Als een pletwals door de industrie, Adobe op zijn doos. Enige tijd later begon Google op te klimmen uit het onderste van de markt.
Ondertussen was er weinig animo ivm webaaps. Tot nu Microsoft het opnieuw lanceert. Helemaal te verwachten, en het web is er klaar voor.
Tegelijk inderdaad opmerkelijk, dat Javascript vroeger afgedaan werd voor amateurs, en nu de adem is van het internet. Javascript zal belangrijk blijven, nu is het wel opletten waar het heengaat met web assembly.

[Verwijderd]

"Ondertussen was er weinig animo ivm webaaps. Tot nu Microsoft het opnieuw lanceert. Helemaal te verwachten, en het web is er klaar voor."

Uhm, Google is begonnen met PWA support, daarna Firefox. Apple heeft toegezegd en nu doet Microsoft als een van de laatste mee. Microsoft lanceerd dus niets. Wat wel nieuwswaardig is, is dat ze PWAs in de store plaatsen.

[Verwijderd]

Overzichtje van de ondersteuning hiervoor in de diverse browsers is wel zo handig: https://caniuse.com/#search=Service

[Verwijderd]

PWAs zijn meer dan alleen serviceworkers, het betreft ook de manifest file, push notifications, en aantal minder harde standaarden.

[Verwijderd]

Ik zou het op prijs stellen als ze de updates niet gedwongen geven. Vanaf Windows 10 is het echt een drama in bedrijven dat je pc spontaan opnieuw opstart vanwege updates. Of je laat je pc aan op je werk met wat virtuele machines open. Volgende dag alles gesloten. Ook servers overnemen en dan die irritante melding over je hele scherm dat er updates zijn.

[walteij]

Dan heeft het bedrijf de Windows Update GPO's toch echt verkeerd ingesteld staan.

[VOODOO_WILLIE]

"Progressive Web Apps".

Krijgen we dan ook constant dat gedram over diversiteit van die apps?

Alle Apps zijn gelijk!

[walteij]

Nee, dat is niet waar. Boze Witte Mannen Apps zijn minder gelijk dan de LGBTQROFLCOPTER Apps natuurlijk.

[DutchKevv]

What a great time to be a JS developer

On topic:
Bijna niet voor te stellen dat 7-8 jaar terug Javascript nog (op zijn best) als 'nutteloos' en 'lelijk' werd bestempeld en het vandaag de dag de nummer 1 taal is en het blijft (zoals bij win10) ook maar doorgroeien.
Dat gezegd snap ik wel dat mensen een pleures hekel hadden aan prototypal inheritence en de dubbele NULL + undefined aanwezigheid etc

[Reactie gewijzigd door DutchKevv op 25 juli 2024 09:52]

[CR35]

Gebruikte zelf TypeScript laatste keer dat ik aan een electron app werkte. Ook niet ideaal en de noodzaak tot constant te moeten transpilen naar JS was vervelend. Syntactisch ook nog lang niet zo mooi als C#, maar it gets the job done.

[lukjah]

Misschien maakt dit je dan blij? https://github.com/aspnet/Blazor

[CR35]

Bedankt, dat klinkt cool! Ik ga dat sowieso checken. Was helemaal niet op de hoogte van een dergelijk project.

[MrAndy9797]

Misschien ben ik een leek, maar welke alternatieven heb je om in een website bijvoorbeeld content te laten veranderen zonder de webpagina te refreshen? Naast Javascript (en afgeleiden zoals jQuery) natuurlijk. Heb vroeger gehoord dat Javascript ten dode was opgeschreven, maar heb nooit een alternatief kunnen vinden die het werk dat ik wou voor me kon doen...

[DutchKevv]

Tsja dat is een goed punt, tegenwoordig heb je wel WebAssembly zodat je ook in Rust, C/++ etc browser apps kan schrijven.

De grootste browsers ondersteunen het allemaal maar het is nog wel een beetje pril met Emscripten te compilen enzo. Ben er toevallig zelf veel mee bezig

[DutchKevv]

Haha kan je daarin geen ongelijk geven idd.. Dweilen met de kraan open tegenwoordig

[spoonman]

Beetje raar dat ze hiermee bezig zijn, terwijl ze er nog altijd niet in slagen om client-rendered applications correct te indexeren (bij google werkt dit al een tijdje).

[rmberendsen]

Ik weet niet of andere mensen hier ook last van hebben, maar ik zou graag willen dat MS de problemen met de "verkenner" kunnen oplossen. Ik heb sinds de laatste grote update (17-09) regelmatig last van het feit dat mijn computer zo goed als vastloopt wanneer ik meerdere verkenner schermen open heb staan.
Ik heb hier helaas zelf nog geen oplossing voor gevonden.
Voorheen kon ik rustig 10 verkennerschermen naast elkaar open hebben staan en dat was geen enkel probleem.... Nu is het soms zo dat zelfs het "opslaan als" scherm bij een download heel traag in beeld komt, ondanks dat ik verder geen enkel scherm van de verkenner open heb staan.
Ik heb het al op verschillende manieren getest om te kijken of het misschien te maken heeft met Chrome of Firefox, maar dat is niet het geval....

Iemand hier dus ook problemen mee??? En weet iemand de oplossing?

[rmberendsen]

Hoezo is dat niet relevant? Het gaat toch over een update en ik geef aan dat ik sinds de laatste update problemen ondervindt.... Volgens mij is dat dan best wel relevant..... Je zou ook inhoudelijk kunnen reageren....
Misschien hoort die vraag hier niet helemaal thuis, maar updates van windows en daar heb ik het ook over.......

[Verwijderd]

Het gaat over progressive web apps, niet over iemand met een willekeurig windows probleem.