Tussen web en app

Pwa's moeten veel apps overbodig maken

Tot slot

Zoals bij alle webtechnieken zal bij progressive web apps alles staan of vallen met de ondersteuning binnen browsers en besturingssystemen. Wat dat betreft ziet het er voor pwa's goed uit, maar het kon beter. Waar Google en Apple ze juist uit hun downloadwinkels houden, zet Microsoft ze in de Windows Store. Chrome op Android ondersteunt pwa's op bijna alle fronten, maar op iOS is de ondersteuning weer beperkt.

Dat plaatst webontwikkelaars voor aloude dillemma's. Ga je een site ombouwen tot progressive web app of niet? En zo ja, ga je alle onderdelen inbouwen of alleen de delen die door de meeste browsers en besturingssystemen worden ondersteund?

Zoals zoveel technieken is de progressive web app een sterk staaltje techniek. Dankzij service workers is er meer mogelijk dan ooit tevoren met Javascript binnen een browser. De belofte van webapps bestaat al jaren, maar dankzij deze technieken komt de webapp die aanvoelt en werkt als een native app een stuk dichterbij. In de tot nu toe optimale versie, op Android, zijn progressive web apps echter op zijn hoogst benaderingen van de ervaring van een native app. De verschillen zijn kleiner dan ooit, maar nog altijd merkbaar. Op Windows 10 zijn weinig native apps, dus vaak gaat het om sites als apps. Apple laat iOS vooralsnog achterlopen op het gebied van pwa-ondersteuning.

Het web is gebouwd op standaarden die uitblinken in een brede ondersteuning, of dat nu op een Windows-pc, iPad of Android-smartphone is, zaken als html5 werken simpelweg overal. De progressive web app is daar nog niet. Het kan een grote stap worden in de webgeschiedenis of het belandt op het kerkhof vol goede bedoelingen. Het is nog te vroeg om te zeggen welke kant het op zal gaan.

Reacties (192)

[Blue-eagle]

Zo heb ik 3 jaar geleden een PWA gemaakt voor mijn werkgever. De eerste reacties van collega's was "GAAF!" en het management zei: "Shh, vertel het niemand."

Ik had in 2 weken tijd namelijk de complete white-label native iOS/Android app nagebouwd als een progressive web app. Met offline capabiliteit en push messages. Mijn payload was minder dan 800kb in grootte, terwijl hun apps begonnen bij 50mb. Mijn animaties waren allemaal 60fps (net als native) en het grootste verschil was dit:

iOS team: 6 FTE.
Android team: 6 FTE.
Web app team: 1 part timer.

(Ik ben al 18 jaar een front-end web developer, ik weet wat ik doe. Het was een 1:1 kopie van de native apps, alleen sneller/lichter en kostte veel minder tijd om op te zetten en te onderhouden.)

Native apps hebben geen enkel bestaansrecht, en dat hebben ze al jarenlang niet meer. Alles wat de telefoon kan zou je ook op web kunnen als die API wordt opgenomen in de browsers. Video kunnen we al, GPS kunnen we ook. Nu alleen nog fingerprint ID en face ID en iris ID erbij en we zijn er bijna.

Web is sneller, kleiner, makkelijker te ontwikkelen, en als je live wilt gaan kan dat DIRECT en is dat live voor IEDEREEN. Apps kosten soms vele dagen om live te gaan, en dan nog enkele weken voordat iedere gebruiker de update heeft geïnstalleerd.

De enige reden waarom PWA's nog niet zijn doorgebroken is heel simpel: Apple houdt het tegen. Ik ben een blije Apple gebruiker maar ze houden het tegen omdat ze via de App Store natuurlijk grandioos veel geld verdienen door alle micro-transacties. Op een PWA is het niet te voorkomen dat betalingen via andere kanalen gaan, en is de kwaliteit ook niet door Apple in de gaten te houden.

Ik denk dat de enige en beste oplossing het volgende is: PWA's moeten ook in de App Store komen, en alleen daarna zijn ze te installeren. Dan krijgen we superieure technologieën en merken we het verschil niet eens.

[Reactie gewijzigd door Blue-eagle op 22 juli 2024 14:57]

[grhmpf]

Sorry, ik vind het lastig te geloven dat je 12 FTE, 3 jaar development, overbodig maakt in 2 weken en dat management daar niet direct iets mee wil doen. Het zal ongetwijfeld een knap prototype geweest zijn, dat geloof ik best

[Blue-eagle]

Ja, dat vond ik zelf ook vreemd. Al kom ik er langzaamaan ook achter dat grotere bedrijven vooral niet efficient werken. Van die dingen als "we moeten per product een veld krijgen waar bedrijven de hoeveelheden kunnen aangeven die ze willen kopen." Geschatte tijd om dit werkende te krijgen kwam neer op 2 sprints van 2 weken. En ik had 't samen met een designer uitgetekend en geïmplementeerd in ongeveer 3 uurtjes werk. Met unit tests en alles wat je van een professional mag verwachten.

Waar het op neerkwam bij mijn POC (want dat was het, al was 't een erg complete oplossing) was dat de native app in die tijd ongeveer 5 keer herbouwd is. En in hun geval was het een white-label app die aan de hand van settings een compleet andere UI liet zien.

Dat hadden ze "heel slim" opgezet, maar kwam feitelijk neer op: "Staat het menu bovenaan of onderaan?" en "Welke kleur is de achtergrond?" en meer van dat soort triviale zaken. Hun configuratie van een nieuwe opzet kostte altijd 1 hele sprint, en als ik dat in CSS moest doen was 't gewoon een flexbox order property om het menu ergens anders te krijgen, of gewoon een background aanpassing van het body element, en zo voort.

Ik hield in mijn POC rekening met de 3 laatst uitgerolde producten van die white-label app. Mijn web-app was praktisch ook een white-label in opzet. Het enige wat ik moest toevoegen per klant was een SASS file die simpelweg bestaande CSS overruled.

Het management was er vooral hush-hush over omdat ze erg getalenteerde native developers in dienst hadden en die niet zomaar kwijt wilden raken. Plus, het was ook maar een web-app, dus het was geen vervanging, zeker omdat Apple toentertijd fel apps bestreed die enkel een webframe waren.

Toen ik het liet zien aan een paar native devs geloofden ze ook niet wat ze zagen en gingen ze ook uitgebreid testen. Performance tests, feature tests, integratie tests, et cetera. Want we maakten gebruik van dezelfde API voor onze data. Ze konden niks vinden wat niet werkte. Het was namelijk enorm simpel.

Mijn beeld dat veel bedrijven gruwelijk veel geld verspillen is daar ook ontstaan. Een jaar later zat ik freelance bij bedrijven als Flora Holland, TMG, RTL, en een bank waar ik een NDA moest tekenen En bij alle bedrijven zie ik diezelfde onzin.

Ik zit nu bij een telecom provider waar een intern end-to-end testteam zit die voor iedere web deployment een volledige end-to-end test moeten uitvoeren. Ze werken in sprints van 3 weken en vragen ons eerst onze release in te plannen in hun volgende sprint zodat zij het kunnen beoordelen, en dan de sprint DAAROP gaan ze testen.

Kortom, het kost anderhalve maand om iets naar live uit te rollen omdat een team van 6 Indiërs van mening is dat niet alles te automatiseren is. Dus ik en mijn team zijn nu bezig om buiten hun om alles te automatiseren, en we zijn er al bijna klaar mee. Over een paar weken duurt het niet meer anderhalve maand en 6 FTE om iets uit te rollen maar gewoon ~10 minuten en een automatische Jenkins taak.

[Croga]

Native apps hebben geen enkel bestaansrecht, en dat hebben ze al jarenlang niet meer. Alles wat de telefoon kan zou je ook op web kunnen als die API wordt opgenomen in de browsers. Video kunnen we al, GPS kunnen we ook. Nu alleen nog fingerprint ID en face ID en iris ID erbij en we zijn er bijna.

En laten dat nou net de belangrijkste selectie criteria van de consument zijn. Die koopt geen iPhoneX om vervolgens nergens FaceID te kunnen gebruiken.

Iedereen is gewend de nieuwste snufjes van zijn telefoon te kunnen gebruiken. Dat maakt PWA op dit moment onbruikbaar. En let wel; we praten hier over PWA die *jaren* achter ligt in implementatie van features. De volgende nieuwe feature op een telefoon zal pas over een paar jaar in PWA bruikbaar zijn. En daarom zijn native apps nog altijd the way to go. Het is leuk dat je met 1/6e van de kosten de PWA app kunt ontwikkelen maar als je dan 90% van je klanten naar die andere, wél native app, gaan dan is het nogsteeds een enorm domme keuze geweest.

[Blue-eagle]

Ja, dat klopt helemaal. En dat is dus iets waar wij als developers op moeten wachten. Apple bepaalt het tempo van die ontwikkelingen. Ze hadden tegelijkertijd met de fingerprint/face-ID feature ook een web API kunnen openstellen in Safari.

Maar dat doen ze niet, om financiële redenen. Dus tot die tijd zitten we met native apps opgescheept (die steeds vaker web-frames gebruiken voor veel van hun content).

Of je krijgt Phonegap of React Native tooling om juist die brug te slaan...

En dat laatste gebruik ik nu om makkelijker de hele markt te kunnen bedienen. Javascript van backend (Node) naar front-end (React) en native (React Native). Dus mij hoor je niet klagen, het is alleen zo jammer dat ze op de rem trappen daar

[Luca_Scorpion]

"Ze hadden tegelijkertijd met de fingerprint/face-ID feature ook een web API kunnen openstellen in Safari."

Dit is alleen niet zo simpel als je het nu laat lijken. Om zoiets daadwerkelijk succesvol en bruikbaar te laten worden moeten er standaarden voor zulk soort dingen zijn, en dat kost nu eenmaal tijd. Wat er anders gebeurt hebben we de laatste decennia genoeg voorbeelden van gehad lijkt me zo. We kunnen niet altijd op slimme developers blijven rekenen die overal polyfills voor maken.

[Blue-eagle]

Standaarden worden al afgesproken. Dit hadden ze 3 jaar geleden al kunnen beginnen en 2 jaar geleden kunnen afronden. Maar ze doen er niks mee.

En... Wat is er moeilijk aan? Laat websites zich registreren bij Apple, vervolgens vraag je via de API in de browser om Fingerprint ID, de browser zegt tegen het OS: "Hey check eens ff of dit URL dit wel mag", het OS checkt dat bij Apple, stuurt "jup" terug, en vervolgens regel je de rest net zoals met oAuth gebeurt.

Dus: de websites slaan geen fingerprints of face ID's op, die staan gewoon bij Apple. Identificatie gaat via oAuth oid en that's it.

De risico's lijken me ook enorm beperkt of makkelijk te beperken. Alles gaat alsnog via de Apple (of Google) servers.

[Luca_Scorpion]

Ik ben het er inderdaad wel mee eens dat veel van deze dingen (i.e. het afspreken van standaarden) sneller zouden moeten kunnen. Maar de oplossing die je nu beschrijft zou het wel weer vendor-specifiek maken, wat het meer gedoe zou maken om dit te implementeren op websites. Dus ik ben er wel van overtuigd dat zulke webstandaarden van grote waarde zijn.

[jabwd]

Je slaat hier wel heel veel over.

- Webapps zijn trager, "upcoming" technology maakt niks uit voor legacy gebruikers en native zal je daar altijd verslaan
- Je hebt nog steeds met versies en updates te maken, API's etc.
- Je hebt nog steeds issues met nieuwere en oudere browsers / engines te maken
- Je hebt nog steeds compatibility issues
- Features van speciale devices ondersteunen kost nog steeds ( en vaak meer ) werk. In veel gevallen gaat het ook nog eens ten koste van de code kwaliteit, al is dat ook al vaak ver te zoeken want ja we zitten vast aan CSS.

Bovendien:

- Extra security issues, Signal was recenetlijk heel erg belachelijk gehackt omdat ze kleuter electron gebruiken voor een secure messaging app
- Minder battery life
- Bepaalde standards die je niet gebruiken kan of nog niet, en dus hacks moet introduceren wat weer verder de code quality verlaagt.

Het is een ideaal in het idee van de gebruiker die altijd het nieuwste van het nieuwste heeft.

Waar het echt op slaat, en niet het super optimistische verhaal wat je verteld:
Minder kosten. Dat, is, en blijft de enige reden voor deze troep-ware.

[Reactie gewijzigd door jabwd op 22 juli 2024 14:57]

[Blue-eagle]

Webapps zijn trager? Wanneer dan? Wanneer is mijn 60fps 800kb webapp precies trager dan een native app van 600mb? Mijn webapp is ook offline capable, kan je ook aan je startscreen pinnen, kan ook enkele tot vele mb's aan data opslaan, etc.

Mijn web-apps zijn altijd meetbaar sneller en prettiger in gebruik (behalve fingerprint en face ID helaas) dan native. Want dat is altijd mijn doel bij die opdrachten: Superieur t.o.v. de native app. Ik doe aan sublieme animaties met After Effects (export naar animated SVG) en de code wordt gesplit zodat iedere pagina maximaal 80kb groot is. En na de eerste load worden ze gecached en zijn ze daarna direct beschikbaar.

Versies en updates: Een nieuwe website is gelijk live voor 100% van je gebruikers. Voor een native app duurt het weken tot maanden voordat iedereen over is op je nieuwe versie. En soms heb je tientallen versies van je app draaien in 't wild. Een website: 1 site + 1 API. Versioned, sure, maar gewoon 1 versie.

Browsers: Onzin, we werken allemaal op IE10+ tegenwoordig. Javascript features worden door Babel getranspiled naar een versie die werkt op de browsers die wij willen ondersteunen. En de standaarden waar ik het over heb worden door praktisch alle gebruikte smartphones (iOS of Android) ondersteund.

En als we het gaan hebben over devices die 5+ jaar oud zijn dan wil ik weleens zien of alle apps moeiteloos 5 jaar oude devices kunnen ondersteunen. Hint: websites gaan over het algemeen meer dan prima, apps niet.

Compatibility issues? Waar heb je het over?

Features? CSS? Waar heb je het over? Welke features doel je op? Vast aan CSS? Er is helemaal niks mis met CSS en er zijn talloze methodieken om het een developer makkelijker te maken.

Security issues zijn er nooit bij native apps? We hebben het over software, daar zitten altijd bugs en lekken in.

Battery life: Ja als je naar bed gaat heeft je telefoon nog maar 20% batterij over in plaats van 23%. Met de moderne processoren in de nieuwere devices is dat een miniem verschil tegenwoordig.

En hacks begrijp ik ook niet. Heb je voorbeelden? Polyfills worden over het algemeen door je transpiler toegevoegd. Verder is de kwaliteit van je code een eigenschap van je team, niet van de techniek.

[BikkelZ]

Versies en updates: Een nieuwe website is gelijk live voor 100% van je gebruikers. Voor een native app duurt het weken tot maanden voordat iedereen over is op je nieuwe versie. En soms heb je tientallen versies van je app draaien in 't wild. Een website: 1 site + 1 API. Versioned, sure, maar gewoon 1 versie.[/quote]

Twee dagen met iOS, Android nog minder. Je kunt mensen ook dwingen te upgraden al is het logisch dat je mensen die op een niet meer ondersteunde versie zijn blijven hangen wel een tijdje door laat werken op oude API’s.

En als we het gaan hebben over devices die 5+ jaar oud zijn dan wil ik weleens zien of alle apps moeiteloos 5 jaar oude devices kunnen ondersteunen. Hint: websites gaan over het algemeen meer dan prima, apps niet.

Geen idee? Een iPhone 5S draait toch alles?

[ppl]

En hoe zit het met je security? Runt de PWA vanuit zijn eigen sandbox en kan het zo niet bij andere apps? Hoe zit het met beheer van de devices: hoe makkelijk kun je dit soort zaken uitrollen naar devices en hoe makkelijk kun je ook blokkeren (zeer belangrijk bij de grote bedrijven)?
Bij een consument gaat het wellicht om of het draait op het apparaat of niet maar bij het bedrijfsleven werkt dat niet zo. Daar gaat het veel al om of het te beheren valt of niet en of het veilig is (zeker nu met de GDPR). Ik denk dan ook dat juist het bedrijfsleven is die het nu momenteel tegenhoudt en niet een Apple of Google. We zitten dus eerder met het bekende kip en ei probleem (Apple/Google doen niks want er is geen vraag en die vraag is er niet omdat Apple/Google het niet aanbieden).

Waar ik werk hebben we ook een web app en daar zit toch een behoorlijk stuk infrastructuur en aardig wat componenten in waaraan door heel wat meer mensen dan 6 worden gewerkt. Ik vind je verhaal over het aantal FTE dan ook echt veel te kort door de bocht. Er zijn heel wat meer zaken die bepalen hoeveel FTE je nodig hebt.

Ditzelfde geldt dus ook voor je uitspraak "web is sneller, kleiner, makkelijker te ontwikkelen". Als de app simpel is misschien maar bij de wat complexere zit je weer met allerlei andere systemen en zaken die ook meespelen. Het gros van de tijd gaat zitten in het hele design en niet in het daadwerkelijk bouwen. Als je iets nabouwt heb je niet zoveel met dat design proces te maken dus is het nogal wiedes dat het sneller is. Desalniettemin laat je voorbeeld wel goed zien dat native lang niet de enige en ook de beste keus hoeft te zijn. Maar ja, dat moet je vooraf dan wel weten (bijv. door te verkennen) en dat is weer extra tijd...

Enfin, ik zie dit soort dingen meer als een alternatief voor webinterfaces en voor een bepaalde soort app. Het geeft namelijk een hele mooie mengelmoes van web en native zonder dat je vastzit aan bepaalde operating systems, screen sizes, etc.

[Reactie gewijzigd door ppl op 22 juli 2024 14:57]

[Croga]

Bij een consument gaat het wellicht om of het draait op het apparaat of niet

Nope. Bij een consument gaat het er om of je alle laatste snufjes gebruikt. Je weet wel, fingerprintID, FaceID, IrisID. Juist al die dingen waar PWA altijd (een paar jaar!) achter blijft lopen zijn de selectie factoren voor de consument. En ook meteen de reden waarom PWA op dit moment (en in de nabije toekomst, waarschijnlijk gewoon altijd) niet werkbaar is.

[Blue-eagle]

Ja, en dat is helaas niet te wijten aan deze developers. Het zijn de fabrikanten (Google en Apple) die hier kiezen om die technologie niet te ondersteunen in hun browsers. Althans, vooralsnog niet.

Die ontwikkelingen komen er namelijk wel aan: https://developer.mozilla...PI/Web_Authentication_API

[Anoniem: 457607]

"En hoe zit het met je security? Runt de PWA vanuit zijn eigen sandbox en kan het zo niet bij andere apps?"

Een PWA is gewoon een website, welke inderdaad in een sandbox (process sandbox) draait en niet bij een andere "app" kan.

"Hoe zit het met beheer van de devices: hoe makkelijk kun je dit soort zaken uitrollen naar devices"

Er is geen beheer of uitrol, het is gewoon een web adres wat je benaderd.

"en hoe makkelijk kun je ook blokkeren"

Door simpelweg de URL in de firewall of proxy te blokkeren.

[rotterdams]

Dat vind ik ook het vervelende aan dit soort " nieuwe technologie ".

Er is niets nieuws. Het is een website met javascript en het zegt zelf een "pwa" te zijn door een "pwa json" bestandje te hebben. Het is slimmer of ander gebruik van al lange tijd bestaande technieken en ontwikkelingen. Echter moet er uiteraard een nieuwe naam aan gegeven worden en het moet gehyped worden als the latest and greatest zodat de marketing afdelingen ook nog wat kunnen verdienen (gecharcheerd)..

/rant

Bovendien zijn deze websites, sorry, PWA's... zeker niet van hetzelfde gemak in beheer en niveau als native apps. Look en feel. Snelheid (een pagina moet altijd laden, een volgend native scherm niet). Remote beheer. Uniformiteit binnen een platform. Enz

[Reactie gewijzigd door rotterdams op 22 juli 2024 14:57]

[Blue-eagle]

Je hebt het nu over fouten die mensen maken die niet uniek zijn weggelegd voor websites. Hoeveel apps staan er wel niet in de stores met 1 ster. Moet ik die erbij pakken om af te branden?

Komop zeg.

En "PWA" is geen marketing term, het is een technische term. Net als "responsive" dat is. Of "SPA". Het geeft simpelweg aan dat de website moet voldoen aan enkele kenmerken. In het geval van een PWA is dat inderdaad heel simpel.

En die simpliciteit is nu juist zo eng voor veel native developers. Want veel websites zijn al responsive, en zijn ook al "Single Page", dus als ze ook nog eens offline capable worden en automatisch updaten... waarom heb je dan nog een native app nodig?

Het is geen buzzword, het is een verzamelterm voor technologische eigenschappen.

[Boy]

Op dit moment heb ik als native Android dev werk genoeg, maar ben benieuwd of dit gaat veranderen inderdaad...en ja, dan moet ik gewoon iets nieuws gaan leren. Geen probleem hoor, dat lukt allemaal wel...is misschien zelfs leuk!

[Reactie gewijzigd door Boy op 22 juli 2024 14:57]

[Anoniem: 457607]

De term is PWA is enigzins slecht gekozen, maar ik ben het niet eens met al je punten:

"Er is niets nieuws. Het is een website met javascript en het zegt zelf een "pwa" te zijn door een "pwa json" bestandje te hebben"

Dat is niet helemaal waar. Het belangrijkste noem je niet: service workers. Tevens integreren PWAs in een OS op een manier die meer op een native app doet lijken. Er is wel degelijk iets nieuws, in ieder geval een verrijking van mogelijkheden.

Marketing afdelingen...welke precies? Het is een web techniek, niemand verdient specifiek aan een PWA.

"Snelheid (een pagina moet altijd laden, een volgend native scherm niet)."

Klopt niet. Preloaden kan op het web.

[Blue-eagle]

Een PWA draait in de browser, dat is zijn sandbox. Hij kan niet bij andere apps en ook niet bij andere websites, want dat is al lang door browsers en servers afgedicht.

Beheer van devices: Simpeler dan apps. Een app moet men namelijk handmatig updaten. Een website is up-to-date zodra je hem bezoekt. En als je wilt dat een gebruiker geen toegang meer heeft tot de app is dat simpelweg een kwestie van die gebruiker blokkeren uit je systemen.

De web app die ik maakte in mijn voorbeeld bestond uit 4 tekst pagina's en 1 dashboard met animaties. Denk aan een systeem waar je punten kon sparen voor beloningen. Het was heel simpel in zijn opzet, het meeste werk zat eigenlijk vooral in het animeren van SVG elementen (wat ik tegenwoordig met After Effects zou doen, die kan met een plugin exporteren naar animated SVG). Het grafische design was al wel klaar inderdaad, dus daar had ik ook voordeel mee. Maar die native developers zitten er nu 3 jaar later nog steeds aan dezelfde app te werken.

Het bedrijf had (en heeft) 12 man in dienst om 2 natives apps op te zetten. Dat verbaast mij nog steeds tot op vandaag, al heb ik inmiddels bij grotere bedrijven gewerkt waar ze ook verbaasd stonden van wat ik in 1 dag produceer waar ze normaal gesproken 2 weken mee bezig zijn...

Maar je hebt een punt, complexere websites zullen natuurlijk ook veel tijd kosten om op te zetten. En dat heb ik in de afgelopen jaren vooral gedaan: mijn pagina's code-split ik en zijn altijd van request tot "appear ready" klaar in minder dan 1 seconde. Vervolgpagina's zijn nooit groter qua payload dan 200kb. En dat wordt gecached in de browser.

En als we het dan gaan hebben over microservices als backend: ook daar zijn oplossingen voor. Denk aan GraphQL als middlelayer om data te consumeren, combineren, en presenteren. Dan doe je nog maar 1 request in plaats van tientallen HTTP requests naar een API.

Ik denk dat een hybride toekomst ook niet vergezocht is. Denk aan een native app die zorg draagt voor fingerprint/face-ID en vervolgens een PWA inlaadt binnen een full-screen web frame. Apple doet hier nu nog moeilijk over, Google minder. Dus dat is al een mooie stap. Al blijf ik erbij dat die hele app schil weg kan als we dit gaan doen, want dat hoort gewoon in het OS thuis...

[Dreamvoid]

Ik vind je verhaal over het aantal FTE dan ook echt veel te kort door de bocht.

Dat is het natuurlijk ook wel, hij heeft het over kopieren van een bestaande app, wat uiteraard een stuk minder werk kost dan vanaf scratch zelf iets ontwikkelen.

[418O2]

MS zet zelf al PWA's in de store Apple moet wel mee, duurt alleen wat langer.

Je verhaal is goed, alleen moet ik wel zeggen, als mede frontender, dat ik het nog niet snel zie gebeuren dat games als PWA echt lekker gaan lopen. Dan is directere toegang tot de hardware wel een muist.. Maar voor de meeste zaken waar mensen apps voor gebruiken (social media bijv) is het echt niet nodig een app te gebruiken.

[Blue-eagle]

WebGL maakt gebruik van je GPU Games als Angry Birds zijn simpel genoeg om te kunnen bouwen met enkel SVG's en CSS animaties. Collision detection en zwaartekracht zijn ook te programmeren in javascript en er zijn al libraries beschikbaar (Matter.js bijvoorbeeld).

De komende jaren zie ik echte 3D games inderdaad niet in web terecht komen. Maar ook dat is een kwestie van tijd.

[418O2]

Ik ken de mogelijkheden, maar zaken als asphalt oid is lastiger. Maar webgl en webassembly bieden wel mogelijkheden in de toekomst

[VincentdeVreede]

Heb je helemaal gelijk in, maar heb je al keer vergeleken hoe warm je telefoon wordt en hoe hard je batterij leeggetrokken wordt in vergelijking met native Angry Birds

In de toekomst gaat dit helemaal goed komen, maar voor nu helaas nog niet.

[Reactie gewijzigd door VincentdeVreede op 22 juli 2024 14:57]

[Anoniem: 457607]

Dan ben ik benieuwd wat je hier van vind:

https://airma.sh/

Geen PWA, maar 100% web. Soepele graphics, schaalt op iedere device, realtime multiplayer (wat super ingewikkeld is over een netwerk), keyboard/muis,touch support.

We zijn denk ik verder dan de meeste mensen denken op het web.

[codebeat]

Ik ben het helemaal met je eens. In 2015 had ik ook een mooie webapp gemaakt, zo mooi en dynamisch, dat kun je echt niet maken met de standaard tools, dat is zo ingewikkeld. Je bent dan weken bezig en wanneer je het met html en css doet ben je in een paar dagen klaar en het ziet er flitsend uit. Op Android vind ik het ook zo raar dat je voor elke schermresolutie assets moet maken, dat hoeft eigenlijk helemaal niet als het responsive is. Beetje slim omgaan met je afbeeldingen en dan is dat geen enkel probleem en maakt bovendien de executable kleiner. Het idee achter een UI opzetten is zo achterhaald in Android Studio. Snap niet waarom steeds het wiel opnieuw dient te worden uitgevonden.

[Ablaze]

Het is niet verplicht om verschillende assets te plaatsen in Android. Het helpt alleen met het schalen en is efficiënter. Een plaatje van 1024x1024 ziet er niet uit als je 'm automatisch laat schalen naar 128x128 en het kost bovendien een hoop CPU power voor die waarschijnlijk toch al goedkope telefoon die zulke kleine afbeeldingen nodig heeft. Juist dit soort dingen zorgen ervoor dat native apps sneller en vloeiender aanvoelen dan web apps.

Omgekeerd heb ik bij het ontwikkelen van web apps juist het idee dat het erg omslachtig is. Voor bedrijfstoepassingen zijn de native standaardcomponenten vaak prima. Ik kan in één uur in een RAD omgeving een complete UI opbouwen en een app schrijven. Web ontwikkelaars zijn vaak dagen bezig om de juiste CSS thema's te maken, HTML en JavaScript code te schrijven, libraries en frameworks uit te kiezen, de boel te testen in verschillende browsers, te minify-en en te bundelen en (in mijn ogen) omslachtig te debuggen in een browser.

Mijn visie is dat web apps vooral beter zijn als je meerdere platforms moet aankunnen, als je een optisch mooie (vaak voor consumenten bedoelde) UX wilt hebben of wanneer je veel online informatie moet ophalen/bewerken.

[WoutervOorschot]

Web apps voelen altijd nog totaal anders aan dan echte apps, fatsoenlijke ondersteuning voor terug navigeren is een groot ding, headers/footers die echt stil staan (en ook met het rubber banding effect stil blijven staan, altijd) een tab bar, maar bovenal, wat iOS altijd al beter doet dan android is consistentie, alle apps gebruiken grofweg dezelfde interface elementen, dezelfde UI/UX guidelines. De meeste websites (tweakers als 1 van de weinigen minder erg) gebruiken gekke menu’s, slechte navigatie, grafische fouten die native nauwelijks kunnen (text die van het scherm afloopt, niet netjes gecentreerd e.d). Maar bovenal, niemand doet het hetzelfde, en om het jaar is iets anders hip. Wat je al zegt, Apple zou het in de appstore kunnen laten zetten, maar dan moeten ze dus UI eisen gaan stellen willen ze de kwaliteit hooghouden want de gemiddelde web developer snapt niets of wilt niets snappen van mobile user experience design, iedere vorm van consistentie mist.

En daarnaast leg je nog een dikke laag overhead op je app, jacascript, wat je telefoon nog minder lang laat meegaan op een batterij.

[Blue-eagle]

Goed punt, dat zou inderdaad door de App Store (Apple én Android) gewaarborgd moeten worden. Daar mogen ze best eisen aan stellen, want ik ben absoluut een voorstander van een goede UI. De web technologie is al lang zo ver dat het wel kán, maar niet wordt gedaan omdat men speciaal wilt zijn. Binnen apps is daar minder ruimte voor omdat die standaard UI elementen gewoon herkenbaar en betrouwbaar werken voor anderen.

Gelukkig zijn er al vele CSS libraries die generieke styling toevoegen voor mobiele devices. Kijk eens naar het inmiddels overbekende Bootstrap: wrapbootstrap.com - vele thema's te downloaden met allemaal 1 en hetzelfde framework met dezelfde werking. En zo zijn er nog meer CSS frameworks die het responsive maken van een website generiek en toegankelijk maken

Consistentie mogen ze vanuit de App Stores afdwingen, want de tooling bestaat al lang.

[BikkelZ]

Het probleem is ook wel gewoon dat mensen niet gespecialiseerd zijn in PWA's maar webdevvers zijn die ook eens een keer een app maken, uitzonderingen daar gelaten. Voordat het echt perfect is ben je weer een paar stappen verder.

Ik zie best veel dingen fout gaan. Ook domme simpele dingen als een back knop die niet over de randen heen gaat op iOS: tap maar eens net onder de navigatiebalk dan ga je nog steeds terug, het oppervlak van die knop is veel groter zodat je je vinger kunt "gooien". Dat weten de meeste mensen niet eens maar als een back-knop ineens de hoogte van de navigatiebalk heeft of erger nog wat padding heeft dan is het net of hij tja....niet goed reageert?

[Boy]

Erg benieuwd naar die app! Als Android dev vraag ik me af in hoeverre animaties en dergelijke gedaan worden...

[Ed Vertijsment]

[quote]Ik denk dat de enige en beste oplossing het volgende is: PWA's moeten ook in de App Store komen, en alleen daarna zijn ze te installeren. Dan krijgen we superieure technologieën en merken we het verschil niet eens.[quote]

*pauper mode aan* Kwak het in cordova en publiceer, klaar

[MarnickS]

Je moet de quote tags wel afsluiten hé .
Zo: [qu0te] tekst [/qu0te]
maar dan met een o in plaats van een 0

[Reactie gewijzigd door MarnickS op 22 juli 2024 14:57]

[Dreamvoid]

De enige reden waarom PWA's nog niet zijn doorgebroken is heel simpel: Apple houdt het tegen.

Dit is wel ironisch, aangezien de originele iPhones (1e generatie en 3G) alleen werkte met web apps

[Ablaze]

Native apps hebben geen enkel bestaansrecht, en dat hebben ze al jarenlang niet meer.

Misschien in jouw branche (ik denk consumer services?), niet in de mijne (productontwikkeling en industriële automatisering).
Er zal héél wat moeten gebeuren, wil het álle native apps kunnen vervangen (en ik spreek dan niet alleen over mobile development, uiteraard):

1. Verdere ontwikkeling van WebAssembly en bijbehorende tools.
2. Daarmee samenhangend: veel meer draagvlak dan nu voor ondersteuning van programmeertalen als C++, C#, Go en Rust.
3. Debugmogelijkheden op het niveau van native applicaties.
4. Meer standaardisatie tussen verschillende browsers (na 20 jaar browseroorlog zitten er nog steeds kleine verschillen in hoe verschillende browsers pagina's verwerken).
5. Toegang tot lokale bestanden en aangesloten hardware, uitvoeren van andere applicaties en direct gegevens uitwisselen met andere "draaiende" applicaties, systeemtaken uitvoeren.
6. Een ecosysteem dat niet elk jaar compleet achterhaald is.
7. Rapid Application Development voor UI's met strenge richtlijnen voor de UX.
8. Makkelijker te realiseren offline functionaliteiten en permanente offline gegevensopslag.
9. Mogelijkheden voor achtergrondservices and headless toepassingen.

[BikkelZ]

iOS team: 6 FTE.
Android team: 6 FTE.
Web app team: 1 part timer.

Ik vind het een mooi verhaal en ik heb dit soort dingen ook eerder zien gebeuren maar waar denk je zelf dat het in gelegen heeft? Je kunt vrij snel dingen bouwen (kan alleen over iOS praten) als je je tools kent. 60FPS niet halen op iOS hardware is al helemaal een prestatie in negatieve zin. Ik heb niet het idee dat iemand binnen de zelfde afbakeningen sneller klaar is met Web dan met Native tenzij de kwaliteit van de programmeur gewoon stukken beter is of de programeur het probleem (en dan niet alleen in technische zin) gewoon beter begrijpt.

[Blue-eagle]

Vertel het mij maar. Ik zit nu bij een andere werkgever met een end-to-end testteam van 6 Indiërs die bij hoog en laag beweren dat niet al hun werk te automatiseren is, "tenzij we A.I. gaan gebruiken ha-ha". Door dat team kost het minimaal 6 weken om iets live te krijgen.

En nu ben ik bezig met mijn team om al hun tests te automatiseren. Daar zijn we nu bijna mee klaar en dat heeft ongeveer 4 weken in beslag genomen (tussen onze andere werkzaamheden door). Het resultaat gaat dus zijn dat we niet meer 6 weken + 6 FTE nodig hebben om te testen, maar ongeveer 10 minuten + 1 Jenkins taak.

En zo kan ik nog wel een 5-tal voorbeelden geven van corporate efficiëntie. Ik ben absoluut geen bizar goede programmeur, maar ik ben een lui stuk vreten die er niet van houdt om zo traag als dikke stront te gaan werken en vooral niet verder te kijken dan mijn neus lang is. Automatiseren dus.

Ik denk dat bij mijn eerste voorbeeld waar jij het over hebt 't ook heel simpel is: 6 ontwikkelaars per team die mondjesmaat werk krijgen en het werk wat 1 dag mag kosten rustig verdelen over een sprint van 2 weken. Want dat slag volk kom ik echt overal tegen.

[oscoweb]

Ik was in begin dit jaar bij ng-europe, daar hebben we een hele dag besteed aan PWA.

De potentie is echt enorm, de buglijst helaas ook nog.

Zo zijn er niet alleen nog wat haken en ogen aan push, maar updaten is echt een zorgpunt. Dat moet je zelf maken.
Het ontbreken van toegang tot Contacten is ook nog een groot gat, als ook de Beacon en stabiele Bluetooth ondersteuning.

PWA zijn helaas nog net niet productiewaardig, als je echt toestelfuncties moet gebruiken in mijn ogen, maar de portentie is enorm, en de ontwikkeling is zeker het volgen waard.

Bekijk de sourcecode en oordeel zelf: https://github.com/thinktecture/ngeurope-2018-pwa

En als je wil zien of de functie die jij zoekt ondersteund is ga je gewoon naar https://caniuse.com/

[Reactie gewijzigd door oscoweb op 22 juli 2024 14:57]

[Mavamaarten]

Eerlijk, geen enkele website hoeft mijn contactenlijst te weten en ik heb nog nooit een serieuze toepassing gezien voor beacons, met uitzondering van een app die tankstations kon herkennen. Maarja die heeft natuurlijk ook gewoon een app en geen veredelde mobiele website.

[Anoniem: 457607]

Dat is een beetje een kip-ei redenering. De website die op nuttige wijze gebruik maakt van je contactenlijst kan niet bestaan omdat het technisch simpelweg niet mogelijk is. Dus kun je makkelijk stellen dat geen enkele website het nodig heeft.

Contacten info is uiteraard zeer gevoelige informatie, maar juist de meest gebruikte native apps zijn er vrijwel geheel afhankelijk van: Whatsapp, Facebook, Twitter, Medium, the list goes on.

[Mavamaarten]

Twitter, Facebook en Medium hebben absoluut geen toegang tot contacten nodig, en dat krijgen ze van mij niet ook niet.

[Anoniem: 457607]

Twitter en Medium wellicht niet, Facebook wel. Facebook had niet in zijn huidige vorm bestaan zonder contactenlijst. Dat jij dat persoonlijk liever niet deelt (ik ook niet) boeit niet.

[Mavamaarten]

Facebook werkt 100% op basis van eigen contacten en niet op basis van contacten uit je telefoonboek. Dat laatste is er maar aan toegevoegd omdat data vergaren nu eenmaal de grootste bron van inkomsten is bij hun.

[Anoniem: 457607]

100% nog wel. Dus van de groei van een paar honderd miljoen richting 2 miljard stel jij dat 0% hiervan tot stand is gekomen door het automatisch delen van de contactenlijst, welke je dus verplicht deelt via de mobile app? De mobile app, weet je wel, waar 70 a 80% van de gebruikers opzitten ipv de website.

[Mavamaarten]

Contactenlijst delen is, nogmaals, niet verplicht bij Facebook. Dat de app het jarenlang heeft gedaan zonder toestemming is omdat het vroeger niet als permissie werd gevraagd op android.

[bilgy_no1]

Contacten info is uiteraard zeer gevoelige informatie, maar juist de meest gebruikte native apps zijn er vrijwel geheel afhankelijk van: Whatsapp, Facebook, Twitter, Medium, the list goes on.

Maar voor een hele hoop van die sites is het helemaal niet nodig dat ze je contactgegevens kunnen inzien. Ze gebruiken die mogelijkheid enkel om hun database met profielen van reclame targets (wij dus) verder aan te vullen.

Vanwege dit soort ongein bij mijn nieuwste telefoon een hele hoop apps niet meer geïnstalleerd. Dan maar via Firefox op Android met een aantal anti-tracking tools.

[oscoweb]

Indoor navigatie is een hele goeie toepassing voor beacons en BLE.
En juist bij dit soort toepassingen wil je niet telkens een app uit de appstore trekken.
Je moet je voorstellen dat je dan elk winkelcentrum dat je inloopt een app uit de appstore moet installeren... moet er niet aan denken.

Zo'n PWA zou je juist heel gemakkelijk via een QR of NFC erop kunnen krijgen. Vele malen toegankelijker dan nu. En ziedaar meteen de potentie. QR is trouwens alleen in Nederland niet populair, dus dat is slechts een kwestie van wennen en wat tijd.

[venqwish]

Inderdaad zijn alle native functies zoals toegang tot contactenlijst nog een gemis. Maar niets houdt je tegen om je PWA te wrappen in Cordova en zo alsnog een hybride app neer te zetten in de stores. Je hebt dan maar een kleine laag native code te onderhouden per platform. Natuurlijk moet je dan ook progressief (badum psssh?) omgaan met je beschikbare features als je dit dan ook served via de reguliere web browser.

Ik heb zo meegewerkt aan een bankaire app die zo werd uitgerold, ondertussen al 5 jaar geleden. Niet echt een PWA dus, maar wel cross platform progressief. Bvb enkel pincode in de native versie, indien je via browser binnenkomt heb je je kaart en bakje nodig.

[WoutervOorschot]

Dat was de rabobank dan zeker? De app werkt nog altijd niet zo mooi of goed als een native app

[venqwish]

Nope, niet ING . Het klopt dat web ui nog steeds niet zo mooi werkt als een native app. Over tijd zal dit wel beteren, maar het is een kost overweging meestal. Dan ga je ook niet investeren in een super performante web app (spijtig genoeg).

Als je nu recentere web VS native apps bekijk is er wel een veel kleiner verschil (op performante devices), maar enkel voor simpele UI toepassingen. Er is nog een gigantische inhaalslag nodig voor 3D, WebVR, ...

[oscoweb]

Cordova, en ieder Native platform trouwens ook, heeft al lang graceful degradation. Dat progressief omgaan met native functies is geen reden om te kiezen voor een PWA ingepakt in Cordova. Ik zou niet weten wat het wel is trouwens, het lijkt me dubbelop.

Bij een "normale" Cordova app is je app namelijk zelf al lokaal en offline beschikbaar en ga je in principe al alleen voor je data naar een server toe. Het al dat niet cachen hiervan hoef je niet perse met de serviceworker te doen. Het kan wel, maar er zijn betere en veiligere manieren om je data lokaal op te slaan in Cordova dan de Cache API die de serviceworker van een PWA hiervoor gebruikt.

[Reactie gewijzigd door oscoweb op 22 juli 2024 14:57]

[gitaarwerk]

PWA zijn best productiewaardig. Je hoeft niet alles te gebruiken. Al is het een manifest en wat offline-data kun je al een prima productiewaardig ding hebben. Maar wat je stelt, meer native device features werken niet altijd even lekker nog.

[smuldersbram]

Heel jammer dat er in dit artikel niet ingegaan wordt op het allergrootste voordeel van een PWA: Progressive.

Het bereik van een Progressive Web App is enorm! In essentie is het een website die, wanneer je hem goed bouwt, op elk platform waar dan ook in de wereld werkt. Doormiddel van progressive enhancement voeg je daar functionaliteit aan toe, zoals JavaScript, service workers en toegang tot exotische features.

Ondersteunt je browser een van die features niet? Geen probleem, want de basis ervaring blijft staan.

Nog een voordeel van progressive enhancement zijn laadtijden. De Twitter App op Android is bijna 30 MB groot. De PWA daarentegen vanuit een lege cache: < 1MB.
Je laad dus alleen het broodnodige in, wat dus heel veel bandbreedte bespaart.
Dit maakt je "app" ook toegankelijk in gebieden waar data nog klauwen met geld kost of gelimiteerd bereik hebben.

In potentie kan je door 1 website te maken de hele wereld voorzien van jouw informatie/tool/app/whatever.

Plus het zal qua ontwikkeling minder kosten om alle platformen en condities te bedienen met 1 PWA dan op alle platformen én het web te moeten ondersteunen.

Al met al: voor 90% van de apps is de huidige vorm van PWA voldoende om je bereik en ervaring te vergroten. Neem daarnaast de razendsnelle ontwikkelingen in ogenschouw en je hebt straks toegang tot dezelfde native functionaliteiten als native apps.

[Reactie gewijzigd door smuldersbram op 22 juli 2024 14:57]

[Webgnome]

Het bereik van een Progressive Web App is enorm! In essentie is het een website die, wanneer je hem goed bouwt, op elk platform waar dan ook in de wereld werkt.

Dat hebben we wel meer gehoord en daar is in de praktijk ook een heel andere mening over. Iets wordt of voor Browser x y z gemaakt maar niet voor w of je kiest puur voor browser w

[Reactie gewijzigd door Webgnome op 22 juli 2024 14:57]

[teacup]

Hiervoor moet je een beetje omdenken. In de huidige situatie zijn browsers leidend in welke functionaliteit wordt opgepakt. Zouden belangrijke content providers met behulp van pwa nieuwe functionaliteit omarmen en browser x kan hierin niet volgen dan kunnen de rollen ongedraaid raken.

Pwa kan heel goed worden voor contentproviders die de wereld iets te melden en te bieden hebben. Ik kan ook heel goed de ambivalente houding van Apple en Google begrijpen. Microsoft heeft niets te verliezen, en staat te juchen langs de zijlijn om deze ontwikkeling. Maar als pwa de machtsverhouding in de content-markt kan gaan omdraaien, dan weet ik niet of Microsoft nog zo enthousiast is. Uiteindelijk zijn alle techreuzen bang controle kwijt te raken als de invloed van contentproviders via pwa kan groeien. Platformonafhankelijk kan wat dat betreft op meer manieren worden geinterpreteerd.

Linksom of rechtsom verwacht ik dat de invloed van Apple, Google en Microsoft door pwa zal afnemen. Pwa ontneemt hen de mogelijkheid om een exclusieve toegang tot hun klanten te blijven afdwingen. En dit denk ik goed voor de markt en voor ons maar ook vooral ook de contentproviders, die meer kunnen verdienen aan wat ze voor ons produceren tegen (als pwa volwassen is geworden) minder kosten.

[Dreamvoid]

Er zal altijd wel een behoefte zijn voor een 'gatekeeper' die malware kan screenen - je wil niet naar een situatie waar willekeurige anonieme webcode low-level dingen doet op je telefoon, zonder dat iemand die code geaudit heeft en de developers te traceren zijn.

[Jerie]

Er is nog een groot voordeel voor desktops: we kunnen eindelijk van al die Electron meuk af. Ik ben die rotzooi zo spugzat, het is belachelijk hoeveel geheugen die dingen gebruiken! Ik begrijp dat devs niet meer native willen (Electron is goedkoper) en als het 1 of 2 apps zou zijn geen probleem maar dit is overhyped en gaat de verkeerde kant op.

[gitaarwerk]

Progressive is een methodiek. Het startpunt hiervan is niet overal hetzelfde,. Zoals Webgnome zegt zijn de mening er ook over verdeeld. Progressive heeft met meer dan alleen code te maken, maar ook met de look en feel en interactie. De ervaring zou altijd het uitgangspunt moeten zijn, en op basis daarvan kun je zelf kiezen welk pad je inslaat en waar je beginpunt is met "progressive enhancement".

Als je echt die-hard progressive enhancement wilt doen, weet ik niet of je altijd zo een goede user experience krijgt. Maar wederom, ontzettend situationeel. Als je offline first werkt, kun je een hoop assets al meeladen, waarvoor je een hoop van de progressive-ness (als dat een woord is) niet meer nodig hebt, mits je first load voor lief neem. Zoals ik al zei, het zijn keuzes. En die zijn het moeilijkste

[Anoniem: 457607]

Inderdaad een flink ontbrekend stuk in het artikel. Laat ik jouw punt op een andere manier formuleren:

Het ondermijnt de macht van de stores! En waarom is dat goed:

- Geen 30% tax wat een extreem nadeel is voor zowel ontwikkelaars als consumenten
- Geen almachtige god die op eigenbelang selecteerd wat je wel en niet mag zien: vrijheid dus
- Geen almachtige god die even je app "terugtrekt" of obsolete verklaard
- Geen publikatie of approval process
- Geen download, en gewoon alles kunnen sharen met een ander

En uiteindelijk, wanneer de PWAs goed genoeg worden: eindelijk weer vrijheid in keuze van je hardware platform. Geen iOS/Android/whatever gedwongen keuzes. Ieder stuk hardware met een fatsoenlijke web browser is genoeg.

[torp]

Heel jammer dat er in dit artikel niet ingegaan wordt

Waarschijnlijk de schuld van Luke van Drie en zijn pushnotificatie.

[WoutervOorschot]

Je hebt wel weer een (zeer) zware extra abstractielaag (de browser, javascript), die doet dan meteen die databesparing teniet

[Lethalis]

Het is allemaal nog "net niet", maar de potentie is enorm, zeker in combinatie met WebAssembly.

Want WebAssembly is wat mij betreft het echt grote nieuws van de afgelopen tijd. Want hoe mooi alle nieuwe oplossingen met JavaScript ook zijn, blijf ik van mening dat een strongly typed taal vele voordelen biedt ten opzichte van JavaScript.

Als tussenoplossing gebruik ik dan ook TypeScript op mijn werk.

Maar de dag dat ik een taal als C# kan compileren naar WebAssembly en daarmee kan interacten met de DOM, het platform en web API's... dan is JavaScript het eerste dat ik vaarwel zeg

De ontwikkelingen zijn er in ieder geval:
- WebAssembly zal een garbage collector gaan ondersteunen (dit maakt het gebruiken van talen als C#, Java en Golang eenvoudiger)
- WebAssembly zal DOM interactie gaan ondersteunen (dat gaat nu helaas nog niet)
- WebAssembly modules zal je gewoon met een <script> tag kunnen laden

Dan krijg je dus apps waarbij de user interface mooi wordt omschreven met HTML en CSS, en de code gecompileerd is naar WebAssembly modules. Dit heeft ook weer allerlei security voordelen, de performance is veel beter, enzovoorts.

Anyways, WebAssembly lijkt me echt de toekomst

JavaScript... brrr Ik doe er best veel mee, maar waarderen ga ik het nooit.

PS
Door WebAssembly te combineren met WebGL en een GUI toolkit als QT, kan je hele indrukwekkende applicaties bouwen. Zoek maar eens op de QT WebAssembly demo's. Onze beleving van wat "het internet" doorgaans is, zou hierdoor zomaar drastisch kunnen veranderen. Ik denk dat we steeds minder traditionele websites zullen zien en steeds vaker hele applicaties ons begroeten als we een URL bezoeken

En vice versa: onze beleving van de PC ook. Ik denk ook dat dit een grote bedreiging voor Windows gaat worden en dat met de komst van dit soort oplossingen alternatieven zoals ChromeOS, Android, etc steeds meer functionaliteit winnen.

Want waar je nu nog zegt "ik kan niet Photoshoppen op een Chromebook of een tablet, of op Linux", kan dat straks zomaar heel anders zijn als Photoshop uit WebAssembly modules bestaat die via WebGL een uitgebreide interface aan jou bieden die alles kan.

Hetzelfde geldt voor games, CAD toepassingen, Office, de hele mikmak. En de softwareleveranciers doen dit graag, want ze ontwikkelen liever 1 product dan X aantal producten voor allerlei platforms, ze bereiken een veel grotere doelgroep, en last but not least: ze kunnen het jou haast onmogelijk maken om de software illegaal te gebruiken en het jou bovendien als abonnementsvorm aanbieden (stabiele cash flow).

[Reactie gewijzigd door Lethalis op 22 juli 2024 14:57]

[Anoniem: 457607]

"Strongly typed" is gezever en geneuzel tussen ontwikkelaars. Heel de wereld draait op PHP, wat niet strongly typed is.

Wat wel relevant en een doorbraak is aan WebAssembly is het precompilen en packagen, en het schrijven in de taal van je voorkeur uiteraard, welke dat dan ook is.

[Lethalis]

Heel de wereld draait op PHP?

Kom jij wellicht van een andere wereld dan wij? Bedenk wel dat je er dan lichtjaren over gedaan hebt om hier te komen, en dat ze op jouw thuisplaneet inmiddels (hopelijk) ook verder zijn.

[Anoniem: 457607]

We hebben het hier over het web, wat voor een enorm groot gedeelte op PHP draait. Dus waar heb je het in godsnaam over?

[Lethalis]

We hebben het over Progressive Web Apps, web applicaties die op de client draaien en niet op de server. Daar waar JavaScript op dit moment heer en meester is.

Maar jij maakt er een algemene discussie van, over het al dan niet gebruiken van "strongly typed" talen. En doet het af als "gezever en geneuzel".

Terwijl - buiten het web om - strongly typed talen erg sterk in de meerderheid zijn en hele hordes professionele ontwikkelaars graag zouden zien dat het web dezelfde kant op gaat. Het is niet voor niets dat 1 van de populairste frameworks voor frontend ontwikkeling (Angular) volop TypeScript gebruikt.

Het afdoen als "gezever en geneuzel" vind ik dus erg kortzichtig.

Daarnaast zijn er ontzettend veel serieuze webapplicaties in Java en .NET geschreven, heeft Facebook speciaal Hack gemaakt om strongly typed PHP te kunnen doen, timmert Google aan de weg met Golang, enzovoorts.

Fijn dat de patatzaak op de hoek een PHP website heeft, maar als ik mijn bankzaken doe dan is de kans een stuk groter dat mijn browser met een Java of .NET backend praat. Dat er meer patatzaken dan banken zijn, betekent niet dat wat de banken gebruiken ineens irrelevant is.

Sowieso is er bijna geen enkel bedrijf op aarde dat vanilla PHP gebruikt voor een systeem dat een hoog volume aan transacties moet aankunnen. Bij veel succesvolle ondernemingen die ooit met PHP begonnen zijn, zie je dat de kritieke systemen al vrij snel worden herschreven in iets anders.

Dus nogmaals... strongly typed does matter. A lot.

[Anoniem: 457607]

"We hebben het over Progressive Web Apps, web applicaties die op de client draaien en niet op de server."

Nee, de definitie van een PWA is helemaal niet dat deze uitsluitend op de client draait. Dat is een architectuur kieze. Sterker nog, het standaard voorschrift, PRPL, gaat gewoon bij iedere page hit terug naar de server.

"waar JavaScript op dit moment heer en meester is."

Nietszeggend, aangezien het de ENIGE taal is.

"Fijn dat de patatzaak op de hoek een PHP website heeft"

Een lullige opmerking waarmee je PHP neerzet als hobby oplossing. Het is dat niet. PHP runt het internet.

Strongly typed doet er niets toe, net zoals commas of tabs, vi of een andere editor, microservices of monolith, en al dit soort eindeloze discussies allemaal gezever zijn en een kwestie van smaak.

[Lethalis]

"Een lullige opmerking waarmee je PHP neerzet als hobby oplossing. Het is dat niet. PHP runt het internet."

Vergeleken met een hoop andere technische oplossingen doet het inderdaad hobbymatig aan. Daar is niet per se iets mis mee - alles heeft zijn plek immers. Ik heb web development ooit ook geleerd met PHP, net zoals dat mensen nu met Python beginnen.

Het is gewoon handig om snel iets mee op te zetten.

Maar zodra je een groot en complex systeem gaat bouwen, zijn andere oplossingen gewoon handiger.

"Strongly typed doet er niets toe, net zoals commas of tabs, vi of een andere editor, microservices of monolith, en al dit soort eindeloze discussies allemaal gezever zijn en een kwestie van smaak."

Dat ben ik dus simpelweg niet met jou eens. Ik vind dat je een degelijk typing system niet op dezelfde hoop kunt gooien als de andere dingen die jij noemt.

Maar goed, daar gaan wij het toch niet eens over worden.

[Reactie gewijzigd door Lethalis op 22 juli 2024 14:57]

[BikkelZ]

Inderdaad JavaScript heeft zijn mooie kanten zeker de laatste versies maar ik kan met Swift gewoon er bijna van uit gaan dat als het compileert het werkt.

[Ablaze]

Ken je Blazor? https://github.com/aspnet/Blazor
Blazor is an experimental .NET web framework using C#/Razor and HTML that runs in the browser with WebAssembly
Wordt op dit moment voor je gemaakt door het ASP.NET team.

[Reactie gewijzigd door Ablaze op 22 juli 2024 14:57]

[Lethalis]

Ik heb het idd al gezien

[Finder]

Ik heb laatst wel de keuze gemaakt om de basis-functionaliteit wel te ondersteunen vooral omdat Google Lighthouse het onderdeel van zijn pagina-analyse heeft gemaakt. Er zijn zelfs tools op die je met de eerste stappen op weg helpen. Een handige website om het eerste manifest aan te maken is deze: https://www.pwabuilder.com/.

Een tweede groot voordeel dat je wellicht ook zonder PWA zou kunnen implementeren is de serviceworker. Je merkt gigantische snelheidsverschillen als je slim kan cachen in de browser. Bovenstaande website helpt je ook om een basis serviceworker te genereren.

Onlangs heb ik voor een eenvoudige Festival HTML project er voor gekozen om er ook een PWA van te maken. Veel van de bezoekers van de website komen allemaal op dezelfde tijd, en vaak met mobiele en minder snelle verbindingen.

Interessant boek wat je snel op weg helpt (met serviceworkers) is 'Going Offline' van A Book Apart: https://abookapart.com/products/going-offline

[Ed Vertijsment]

Er werkt ook veel wel. Pwa's kunnen, als de gebruiker toestemming geeft, toegang krijgen tot de locatie, camera, audio, Apple Pay en sensors als de gyroscoop. Ook WebAssembly werkt in pwa's.

In het artikel wordt meerdere malen gesuggereerd dat PWA er voor kunnen zorgen dat er extra mogelijkheden bijkomen. (Tweakers laat zelfs weten dat er geen PWA gepland staat omdat die extra features niet nodig zijn.) Op een soepelere intergratie na is dat gewoon niet waar, PWA bieden geen extra API's aan, die zijn al beschikbaar voor websites.

Locatie: https://developer.mozilla...API/Navigator/geolocation
Camera: https://developer.mozilla...MediaDevices/getUserMedia
Audio: https://developer.mozilla...ocs/Web/API/Web_Audio_API
Gyroscoop: https://developer.mozilla...ecting_device_orientation
Web Assembly: https://developer.mozilla.org/en-US/docs/WebAssembly
Push API: https://developer.mozilla.org/en-US/docs/Web/API/Push_API

De reden is simpel, een PWA is nog steeds een website. Niets meer, niets minder. Een manifest kan de browser zich enigszins anders laten gedragen (knopje op home screen, fullscreen venstertje, misschien een ander profiel voor de service worker). Maar er draait nog steeds een website. Op zich is daar niets mis mee, maar het heeft ook nog steeds dezelfde beperkingen. Zo kunnen UI elementen bijvoorbeeld niet zomaar native gerendered worden en ja, er zijn nog steeds verschillen tussen browsers.

een framework of library de taak van Phonegap of Cordova kan overnemen. "Populaire keuzes zijn Polymer, Angular en React.

Cordova/Phonegap zijn tools om een browser omgeving native te wrappen (met een paar API's extra d.m.v. beperkte calls naar native code), het manifest kan je hiermee vergelijken. Frameworks/libraries (React is een library, geen framework) niet. Veelal worden de boven goemde tools gebruikt bovenop Cordova/Phonegap. Zie Ionic Framework als voorbeeld.

Ik ben geen fan van Cordova (en ja heb er ervaring mee) maar SPA framework of zelfs een component library vergelijken met een platform abstraction layer slaat mijn inziens als een tang op een varken.

Ik vind de PWA hype een beetje overtrokken, heb ze zelf ook gebouwd bij use cases waar het nodig was. Maar dan noemde we het gewoon een offline web applicatie. Het is mooi dat we het web steeds meer in zien blenden in de platformen maar laten we wel wezen. Web applicaties kunnen nog steeds niet alles wat native apps wel kunnen. Laten we ook alsjeblieft niet vergeten dat we gewoon websites aan het bouwen zijn, met dezelfde nadelen (misschien meer) als producten van Cordova en aanverwanten.

Er zijn use cases voor dit soort constructies, maar het is absoluut (in ieder geval nu) geen gouden ei.

[Reactie gewijzigd door Ed Vertijsment op 22 juli 2024 14:57]

[StephanVierkant]

Als een site zich een progressive web app wil noemen, zijn er drie vereisten: de site moet ssl ondersteunen, hij moet service workers hebben en hij moet een manifest hebben dat de eigenschappen van de webapp omschrijft.

Alle grote browser-vendors hebben aangegeven alleen service workers te ondersteunen via https. Dat is dus een enigszins dubbele eis.

Tweakers wordt in elk geval voorlopig geen pwa (..) door de verschillen in ondersteuning.

Dat is een enigszins merkwaardig standpunt. Volgens de definitie ís Tweakers al bijna een PWA, aangezien service workers worden gebruikt. Daarmee wordt aan de belangrijkste voorwaarde voldaan (en daarmee ook https). Het enige wat nog moet gebeuren is een manifest dat omschrijft welke logo'tje gebruikt moet worden. Dat lijkt me een kleine stap. Daarna is het een kwestie van beetje bij beetje features toevoegen aan de website, als de browser een bepaalde feature ondersteunt. De verschillen in ondersteuning is juist het probleem dat wordt opgelost met PWA's. Dat je technieken niet nodig hebt (locatie) is niet per se waar (locatie-filter in V&A?) maar ook geen reden om dan maar geen PWA-features zoals caching in te zetten.

Volgens het artikel is een PWA als aan 3 technische eisen wordt voldaan, maar Jeroen Groeneweg wil Tweakers blijkbaar pas een PWA noemen als de gehele gereedschapskist is gebruikt. Volgens mij ligt de waarheid in het midden. Je hebt een PWA als je een service worker gebruikt en op een progressieve wijze features toevoegt als de browser daartoe de mogelijkheden biedt. Hetzelfde idee als 'mobile first' i.c.m. responsive web design, maar dan voor Javascript API's.

Op Android heb ik Tweakers al op m'n homescreen geplakt en daarmee voelt Tweakers aan als een (weliswaar beperkte) native app. Voeg nog wat extra features toe zoals betere caching, en je bent er. Het hele idee van een progressive web app is niet alleen maar dat het native apps kan gaan vervangen, maar dat je tegelijk de ervaring op desktop verbetert. Ook in dit artikel wordt dat weer vergeten: PWA's verbeteren de web-ervaring van gebruikers, maar niet alleen voor mobiele telefoons. Ook desktop-browsers hebben baat bij betere caching, notificaties, etc.

Om diezelfde reden is het nogal gek om je PWA in de appstore te willen hebben. Het voordeel van PWA's is juist dat je niet naar een appstore hoeft te gaan, iets hoeft te downloaden, etc. Windows (desktop OS, niet Phone) heeft sinds enkele jaren eindelijk een app store, maar die komt niet van de grond omdat het inmiddels ingehaald is door de realiteit: desktop apps worden nauwelijks meer gedownload, omdat iedereen zich op het web begeeft. De toenemende populariteit van Google's Chromebook is daar ook een voorbeeld van. Diezelfde ontwikkeling komt nu ook naar mobiele platforms. Denken dat je applicatie in de toekomst alleen nog wordt gevonden als het in een app store staat, is wat mij betreft hetzelfde als denken dat je nu nog een CD'tje voor een desktopapplicatie in de winkel moet hebben liggen.

[Reactie gewijzigd door StephanVierkant op 22 juli 2024 14:57]

[Anoniem: 457607]

Vooralsnog is het zeker zo dat mensen in app stores zoeken, als daar je PWA staat dan is dat een vooruitgang ten op zichte van dat er helemaal niets staat. Het kost verder ook niets, dus ik zie het probleem niet?

[Vinnie2k]

Sinds ik android heb (hiervoor WP) gebruik ik tweakers als gewoon met een bookmark in chrome die ik op m'n startscherm vast heb staan. Werkt vlot, geen URL balk en een goeie splash maken het een stuk overzichtelijker t.o.v. Een losse site

Dus ik vind dit eigenlijk wel beter als een App ervoor downloaden en installeren.

[josttie]

Ik heb tweakers ook als bookmark staan, maar dat is als pure noodzaak omdat er geen app is. Ik vind het een brakke oplossing op een smartphone om een website in te zetten als app. Op Tweakers is er totaal 0 caching waar ik wat aan heb. Bijvoorbeeld nu.nl kan je gewoon lezen terwijl je geen internet aan hebt staan, aangezien die app het nieuws voor je laadt. Laatst voor ik ging vliegen even gerefreshed en kon ik toch nog het nieuws lezen in het vliegtuig op een verveelmomentje.

Bij tweakers zie je net als alle andere responsive design websites dat je alleen maar aan concessies doet. Geen animaties, de ouderwetse lay-out shift zodra de reclame laadt en waardoor ik vaak op iets anders klik, geen terug knop ondersteuning (menu sluiten, of de full screen plaatjes weer verkleinen, ik ga altijd terug naar de vorige pagina)

Daarbij is alles voor de muis gemaakt en dat is te zien, touch interface hoort anders te zijn want ik wil grotere ruimtes hebben om iets aan te moeten raken met mijn vinger, anders dan met mijn muis.

Pwa's zie ik als een nieuwe responsive design met upgrades. Javascript is een hel en het is traag, en het zal alle problemen hebben die huidige hybris apps hebben en dan nog meer. Je moet nu verschillende browser ondersteunen, op verschillende OS'en met verschillende versies. Met alle hybrid frameworks zie je dat je enorm gelimiteerd bent door het frameworks, en dat de prestaties slecht zijn vergeleken met native. Dus pwa 's zullen dat probleem totaal niet oplossen, het zal wel weer de zoveelste oplossing worden dat net niet lekker werkt. Dus uiteindelijk kun je een beetje in de kosten snijden, maar dat zal altijd ten koste gaan van snelheid, user experience, stabiliteit en algehele kwaliteit. De enige die ik een kans geef om snel en stabiel te draaien voor een simpele app op meerdere platforms is flutter, maar dat draait dan weer niet op Windows.

[Misha]

Ik vind het ook erg jammer dat de ontwikkeling van Tweakers op het gebied van mobiel erg stil ligt. Inmiddels is het vier jaar geleden dat ik samen met drie developers Tweakers hebben geretrofit naar een responsive design in moordend tempo, maar sindsdien lijkt het wat stil te liggen. Erg jammer, gezien er zo bizar veel dingen mogelijk zijn. In die tijd waren er nog geen PWA’s. Van service workers hadden we nog niet gehoord. Inmiddels draait er bij Tweakers wel een service worker lijkt me gezien ze nu ook push ondersteunen. Maar buiten dat zijn er nog heel veel andere gave dingen te verzinnen om de gebruikerservaring te verbeteren. Browsers zijn er inmiddels ook wel klaar voor (Safari begint ook eindelijk!). Toen wij er mee bezig waren, waren zaken amper goed te animeren. Alles werd uiteindelijk trager door de animatie. Neem bijvoorbeeld het menu. Daar hebben we best wat tijd in gestoken om het tof te laten bewegen, maar qua performance kregen we het niet goed. Het werd meer een ervaring op zich dan als onderdeel van een ervaring, en dat is niet de juiste manier.

Ik heb inmiddels voor best wat mediamerken mogen werken aan hun mobiele strategie en veel geëxperimenteerd met de mogelijkheden. Hopelijk gaat Tweakers ook die kant op. Ik vind Tweakers bij uitstek hét Nederlandse merk die op dit gebied juist voorop moet lopen

[Reactie gewijzigd door Misha op 22 juli 2024 14:57]

[Anoniem: 457607]

Geen zorgen, Tweakers gaat echt wel die kant op zodra de statistieken maar genoeg mobiel verkeer laten zien, wat vrijwel onvermijdelijk is.

Verder een hart onder de riem: een gigantische codebase omzetten naar een daadwerkelijk goed functionerende PWA is geen kinderspel.

[josttie]

Dank voor je reactie! Ik moet zeggen: voor responsive design was ik in het begin zeker onder de indruk, en het is nog steeds goed. Alleen, ik wil een applicatie op mijn telefoon wat snel een overzicht kan geven en artikelen kan cachen, en dat mis ik. Ik kan mij zeker voorstellen dat animaties een zorgenkindje zijn, in native moet je het al op de goede manier doen, in javascript lijkt het mij lastig om op alle devices en browsers strak te krijgen.
Ik hoop ook dat tweakers in de toekomst een voorbeeld wil zijn voor app user

[Vinnie2k]

Reclame heb ik geen last van.. Ik betaal ook graag voor de toegang zonder reclame.

Qua data.. Ik heb onbeperkt.. Dus heb het eigenlijk ook niet nodig om te cachen.

Ik heb wel een hekel aan Javascript dus dat mag dood.. Maar verder vind ik t wel beter dan die 1001apps voor iets wat ik slechts een paar keer per jaar gebruik. Zoals bijvoorbeeld voor festivals enzo

[.net]

Ik begrijp dat nooit: 'Ik heb wel een hekel aan Javascript'

Waarom precies?

[84hannes]

Ik denk dat dat een opmerking is die je alleen van mensen zult horen die met een andere programmeertaal hebben gewerkt. JavaScript is inconsistent en het is eenvoudig dingen net verkeerd te doen, bijv. een functie toewijzen aan een variabele i.p.v. de uitkomst van een functie(), het gebruik van this etc. Zoek voor de aardigheid eens op ‘JavaScript the bad parts’. Ik krijg er jeuk van: waarom zou ik ooit een array met een integer willen vergelijken, of een string met een float? Waarom is er geen compiler die je afstraft omdat je er alleen al aan denkt?

[rickvandermey]

typescript

[Anoniem: 890159]

waarom zou ik ooit een array met een integer willen vergelijken, of een string met een float?

In een taal zonder pointers is dat inderdaad redelijk nutteloos. In C kan zoiets heel handig zijn, en in C++ kun je helemaal los gaan met operator overloading.

[.net]

Kleine disclaimer: Ik gebruik bijna dagelijks c#, Javascript, Swift en Java (Android).

Je persoonlijke voorkeur voor een programmeertaal vind ik absoluut geen reden om de hele taal af te schieten.
De argumenten die je geeft zijn voornamelijk gestuurd vanuit je (neem ik aan) persoonlijke ervaring met compiled languages. Ja dan kan het gebruik van Javascript verwarrend zijn, maar ik zie in je reactie geen beargumenteerde reden waarom Javascript slecht zou zijn?

Overigens kun je ook in talen als c# gewoon compares tussen strings, arrays en floats uitvoeren. Ook het doorgeven van functies is niet alleen mogelijk, het wordt zelfs enorm veel gebruikt voor bijvoorbeeld delegates.

[84hannes]

Je hebt gelijk dat het een persoonlijke voorkeur is, en ik weet dat er meer mensen zoals jij zijn die ervaring hebben met andere talen, maar toch denken dat JavaScript een acceptabele taal is. Ik denk dat niet.

Overigens kun je ook in talen als c# gewoon compares tussen strings, arrays en floats uitvoeren.

Nee, dat kan niet.
CS0019 Operator '==' cannot be applied to operands of type 'int[]' and 'string'
Wellicht kun je je eigen operators gaan schrijven, maar dat is omdat jij denkt dat het een betekenis heeft, voor iemand die een programeertaal ontwerpt zou ik niet weten wat het betekent als je wilt weten of een array groter is dan een float.

Ja dan kan het gebruik van Javascript verwarrend zijn, maar ik zie in je reactie geen beargumenteerde reden waarom Javascript slecht zou zijn?

Een programmeertaal moet niet verwarrend zijn. Het kan zijn dat bepaalde dingen uitleg nodig hebben, maar dat vind ik niet hezelfde. JavaScript is verwarrend. Ik hoef geen voorbeelden te geven, dat is al genoeg gebeurt. Kijk bijvoorbeeld eens op JavaScript the weird parts.
Een taal zonder compiler kan ook het fatsoen hebben foutmeldingen te geven als je rare dingen doet, denk bijvoorbeeld aan Ruby:
comparison of Integer with String failed (ArgumentError)
of Python
TypeError: '<' not supported between instances of 'int' and 'str'

De reden dat ik me hier druk om maak: als ik een applicatie zou schrijven dan zou ik een beetje bij de hand genomen willen worden. Een programmeertaal die minder onverwachtse dingen doet is daarbij een goede hulp. Als je nooit fouten maakt en de taal door en door kent dan is het misschien geen probleem, maar ik vind de leercurve van JavaScript voor alles na "Hello World!" een stuk steiler dan van andere programmeertalen.

[Reactie gewijzigd door 84hannes op 22 juli 2024 14:57]

[rickvandermey]

Als er veel vraag naar is om offline artikelen te lezen bij Tweakers, dan is dat eenvoudig te realiseren. Wanneer er een internet momentje is en je vraagt een set / subset van artikelen op, kunnen deze eenvoudig gecached worden, om ze vervolgens in je verveelmomentje in het vliegtuig te lezen.

[Anoniem: 890159]

Ja, een app als https://play.google.com/s...aella_services.s2slashdot maar dan voor tweakers zou ideaal zijn.

[Anoniem: 457607]

Je legt een aantal gevoelige en pijnlijke tekortkomingen bloot van een typische website tov een typische native app.

Die bevindingen zijn terecht, maar er is ook een stukje inleving nodig in het geval van Tweakers en menig andere website die al wat ouder is. Tweakers is een zeer uitgebreide website. Heel erg veel schermen en features. Opgebouwd in een periode van wat? 10 a 20 jaar?

Dan komt er *poef* een nieuwe techniek en ligt er de verwachting dat de hele boel eventjes omgebouwd wordt naar een compleet andere aanpak. Dat gaat natuurlijk allemaal niet zo snel. Een enorme codebase retrofitten is niet makkelijk.

Tevens is de vergelijking technisch gezien niet helemaal eerlijk. Een app is tegenwoordig vaak enorm, wordt gedownload, waarna alle code lokaal draait, en ook een deel van de content.

Een website wordt niet geinstalleerd maar er wordt inmiddels verwacht dat hij niet te onderscheiden is van een native app. Maar er mag niks gedownload worden, althans het moet allemaal in 1 a 2 MB passen anders vinden we het te traag of zwaar.

[josttie]

Ik gebruik tweakers altijd om mijn internet te checken, lekker snel, maar de meeste grote websites zijn vele malen groter da 1 a 2 mb. Er moeten gigantische scripts ingeladen worden, en de content komt pas meestal een paar seconden later. De Facebook website vind ik echt een hel om te laden bijvoorbeeld, maar ik snap dat dat een slecht voorbeeld is. Er was ooit een leuke video over de grootte van sites tegenwoordig, kan je makkelijk richting de 20mb gaan voor een populaire site. Die 1 a 2 megabyte klinkt als een droom maar weinig mensen die optimizen, zeker omdat 10mb in een paar tellen bijna is

[Anoniem: 457607]

En dat is dus het "oneerlijke" voordeel wat ik bedoel. We vinden het prima om een app van 200mb te downloaden en daarna is deze snel, alles staat immers lokaal.

Van het web wordt verwacht dat het slechts een fractie hiervan kan/mag downloaden, maar tegelijkertijd wordt wel dezelfde snelheid en functionaliteit verwacht.

Die 2 dingen zijn niet te verenigen met elkaar. Oh nee, toch wel. Ik kan je alvast waarschuwen voor wat er komen gaat: "slimme" ontwikkelaars trekken offline wat je aanklikt, op dynamische wijze. Als je dus een beetje rondsurft, trekt het je hele telefoon vol zodat het lokaal beschikbaar komt.

[Martinspire]

Ik vind het jammer dat die bookmark je niet meer de mogelijkheid geeft om linkjes in nieuwe tabbladen te openen. Wat ik op de PC vaak doe is naar mijn topics gaan en daar alle topics met nieuwe berichten in nieuwe tabbladen openen zodat het allemaal al klaar en geladen is als ik het ga bekijken. Al moet ik zeggen dat als ik Tweakers in Chrome open en vanuit daar met tabbladen ga werken, het ook niet heel erg fijn werkt. Te sloom en te omslachtig.

[Vinnie2k]

Is dat niet een kwestie van de instelling aanpassen dat ie nieuwe pagina's in nieuwe tabs moet weergeven? Wanneer is dat eruit gesloopt dan..

Je kan in de browser altijd nog tampermonkey gebruiken om het er terug in te scripten..

Ik gebruik dat veel voor bijvoorbeeld reclame vrije Facebook.. En ik moet zeggen.. Dat werkt heerlijk

/edit: laatste alinea

[Reactie gewijzigd door Vinnie2k op 22 juli 2024 14:57]

[watercoolertje]

Als je een site als 'webapp' opent heb je geen urlbalk en geen tabbladen

[watercoolertje]

Al moet ik zeggen dat als ik Tweakers in Chrome open en vanuit daar met tabbladen ga werken, het ook niet heel erg fijn werkt. Te sloom en te omslachtig.

Gewoon swipen op de URL-bar om te wisselen, niet fijn? persoonlijk, maar sloom? vliegt er over hier

[Qunix]

De meeste klanten preferen een naitive app boven een pwa. Zij zien het als reclame in een andere omgeving waar momenteel iedereen naar toegaat als men praat over een app (lees: de app store).

Ook technisch zie ik enkele problemen. Vrij wel alle e-commerce klanten willen een bar/qr code scanner en dat kan nog niet. Ik ben bewust van enkele hacks, maar dit moet gewoon normaal werken. Hetzelfde geld optioneel toegang krijgen tot oa. contacten enz. Ik denk dat op OS niveau er een oplossing gevonden moet worden om wel een sandbox te draaien, en toegang te krijgen tot info/hardware op het apparaat. Misschien sandbox per tabblad/pwa in een sandboxed browser? Geld weer per OS en browser anders natuurlijk... ik wacht af.

[Reactie gewijzigd door Qunix op 22 juli 2024 14:57]

[Martinspire]

Of je nou een native twitter app download uit de store of een progressive twitter app, maakt voor die reclame/discussies niet uit.

En er zijn wel meer businesses die een scanner willen of andere hardware gebruiken, maar je kunt dus in cordova prima de hele app progressive hebben, met hier en daar toegang tot hardware e.d. In principe zet je gewoon een app in de store die je op een bepaalde manier bouwt. Sites een manifest geven is 1 manier, maar Twitter is gewoon in de microsoft store te krijgen.

[Anoniem: 179216]

Je hebt helemaal gelijk dat de meeste klanten een native app willen. Dat is ook mijn ervaring.

Er moet wel bijverteld worden (maar dat doen agencies natuurlijk niet) dat veel, héél veel, van die apps amper gebruikt worden. Een paar honderd downloads en daar houdt het mee op. Het gros van de klanten heeft naar mijn mening meer dan genoeg met een goede responsive website. Native apps hebben uiteraard hun bestaansrecht, maar vaak zijn ze geheel nutteloos.

[Dreamvoid]

Dat denk ik ook, en die goede website zou je dan ook het liefst bouwen zonder JavaScript, zo krijg je het beste van twee werelden: veilige websites voor de zaken die server-side afgehandeld kunnen worden, plus native apps voor dingen waarbij client-side dingen berekend moeten worden en toegang tot lokale hardware vereist is. PWA's zijn weer een stap terug.

[Anoniem: 162126]

Ik heb zelf laatst gekozen om het (nog) niet te ondersteunen. Deels omdat ik niet echt de waarde er van in zie. Niet veel later kwam de NOS met hun PWA achtige site. Waarbij een artikel een soort PWA was. Als je het mij vraagt is dat precies het scenario waar PWA's niet voor bedoeld zijn.

Ja het kan technisch interessant zijn, voor echte applicatie functionaliteit. Ik zie het wel gebeuren dat iedereen en zijn hond de techniek zullen gebruiken omdat het kan. En daarmee de toegevoegde waarde van de mogelijkheden tekort doen. Ik hoef echt geen App button voor een artikel op de NOS site. Of een app button voor een specifieke pagina op een site. Of zelf voor 1 product dat op een site staat.

We zullen zien welke kant het op gaat.

[Kid_Stevie]

Bedoel je de Instant app van de NOS of hebben ze beide?
Want een instant app is niet echt een pwa. Een instant app download een stukje van de app wat jij nodig hebt. Waarbij ik ook idd het nut nog niet helemaal inzien van de instant app bij de NOS. Het voegt niets toe aan content en is ook niet sneller dan de website laden. Het doel is dan ook meer dat je word overgehaald om de app te downloaden.

[Anoniem: 162126]

Oh inderdaad. Zou best eens een instant article kunnen zijn ipv een PWA oid. Voorheen had ik steeds bij het openen van een artikel op nos.nl dat in in een app achtige omgeving zat. Nu niet meer trouwens. Ik was nog niet op de hoogte van de instant articles en accelerated mobile pages (facebook vs google). Dus eerst PWA en dan die 2 andere er nog eens bij.

PWA's kan ik me nog wel voorstellen, voor allerlei webapps die specifieke functionaliteit bieden maar niet echt een native app nodig hebben. Instant Articles en AMP lijken me precies zoals je zegt weinig toegevoegde waarde te bieden.