Google trekt begin 2024 stekker uit HTML-weergave van Gmail

Google trekt in januari 2024 de stekker uit de html-weergave van de Gmail-webclient. Dat staat te lezen op een ondersteuningspagina. Nadat de wijziging van kracht is gegaan, schakelt de webclient automatisch over naar de standaardweergave van mailclient.

De HTML-versie van Gmail is volgens Google bedoeld voor gebruikers met een trage verbinding en/of oudere webbrowser. Nieuwere Gmail-functies zoals postbuscategorieën en de spellingscheck zijn dan ook enkel toegankelijk via de standaardweergave. Vanaf januari 2024 wordt deze weergave dus de enige weergave.

Gmail html-weergave via Ghacks

Reacties (97)

[decramy]

Hoe zit dat? Op het www is toch alles HTML? Wat gebruiken ze dan?

[seapip]

Misschien bedoelen ze HTML als in zonder JavaScript. Iemand enig idee of deze weergave werkt zonder JavaScript?


Edit: het is inderdaad zonder JavaScript.

[Reactie gewijzigd door seapip op 23 juli 2024 15:27]

[Hans1990]

Het verschil is single-page application (zoals YouTube) vs een JS-vrije interface die gewoon doorlinkt naar andere paginas. Single-page applications zijn helaas stukje zwaarder.

Dat wil niet zeggen dat de "HTML interface" compleet geen JS bevat overigens. De interface werkt zonder JS, maar bijvoorbeeld mail addressen kunnen wel worden opgezocht in contacts. Daarvoor wordt (een klein beetje) javascript gebruikt.

[HollowGamer]

Ik heb geen enkel idee waarom je hier upvotes voor krijgt, want een SPA/PWA zijn niet per definitie 'zwaarder'. Sterker nog, een PWA bijvoorbeeld kan juist sneller zijn, aangezien het hardware kan aanspreken van het apparaat. Daarnaast kan het cachen, en het kan zelfs offline werken.

Een SPA kan gewoon aan lazy loading, etc. doen. Dus ook dit is in de meeste gevallen gewoon sneller, en veel minder data-verkeer voor de gebruiker (+ server).

De vraag is ook of je tegenwoordig niet sneller bent met JS, dan zonder.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 15:27]

[latka]

Ik snap wel waar het vandaan komt. Het kan sneller zijn als er genoeg tijd en energie ingestoken wordt. Dat laatste gebeurt veel te weinig zodat de gemiddelde spa/pwa traag laad (alles up front) sluggish aanvoelt en in het algemeen gewoon ronduit slechter is dan een native applicate of een server rendered oplossing (om nog maar niet te spreken over de gemiddelde elektron app).

[djwice]

Nah, valt reuze mee. Ik heb een PWA ontworpen van 150 regels (incl. comment) die in een bestaande website geïnjecteerd kan worden en vervolgens simpelweg als cache gaat fungeren, alle plaatjes, is, css etc in aparte 'mapjes' die je per stuk kunt invalideren vanaf de server.

Zo wordt de 2e keer dat de bezoeker naar je website komt enorm veel sneller, zonder dat je enorm veel rework nodig hebt.

De invalideer mogelijkheid zorgt er voor dat mocht je foute scripts gepubliceerd hebben of pdf bestanden die verouderd zijn, dat je dan zelfs als de server dezelfde naam houdt voor de geupdate file, dat je kunt zorgen dat alle bezoekers ook echt de nieuwe versie krijgen.

In sommige situaties wijzigen bijvoorbeeld de product voorwaarden eerder dan verwacht en wil je niet dat iemand onbedoeld nog de oude voorwaarden krijgt geserveerd.

De PWA zorgt in de meeste gevallen voor een 80-95% lagere server load, met uitschieters tot zelfs 99%.
Bij pay-per-use CMS systemen of veel traffic is dat dus erg rendabel.

En aangezien de laadtijd enorm versnelt is de klant beleving en dus ook de conversie hoger.

[Reactie gewijzigd door djwice op 23 juli 2024 15:27]

[XIU]

klinkt handig, heb je ook een link of de naam of is dit niet vrij te gebruiken?

[djwice]

Ik heb een voorbeeld draaien op https://mijnnaamdag.nl/ de proxy die ik heb gemaakt die dit injecteert en ook je website security upgrade naar https://observatory.mozilla.org/analyze/www.mijnnaamdag.nl en https://www.ssllabs.com/s...&ignoreMismatch=on&latest

Is niet publiek beschikbaar, maar als een bedrijf intresse heeft kunnen we altijd praten
Hij draait nu ook bij twee grote internationale verzekeraars al weer ruim een jaar in productie, eind dit jaar gaat de 300ste site live.

[Reactie gewijzigd door djwice op 23 juli 2024 15:27]

[jaapzb]

Precies hetzelfde kan gebeuren bij een server side rendering applicatie of een native app, dat heeft meer te maken met de kwaliteit van je ontwikkelaars (of projectmanagementtechnische prioriteiten) dan het feit dat het een SPA is.

[latka]

Uiteraard kan dat. Verschil is dat op een server-side applicatie je eenvoudig met task manager kan zien dat het 'druk' is. Bij een PWA/SPA moet je die zelf openen en gebruiken voordat je het weet. De meeste devs openen kijken fixen bug en zijn weg. Dit doen ze op snelle machines met snelle verbindingen naar de server dus het kan tergend traag zijn voor de gebruiker maar de serverbeheerder ziet daar niets van omdat het op de client gebeurt en de devs zien er niet zoveel van want die werken 5 min. in het systeem ipv. een paar uur.

[Ed Vertijsment]

Een spa is niets meer dan een term, caching, en andere API’s zijn ook gewoon beschikbaar voor andere websites.

Wel is het zo dat JS uitvoeren vaak zwaarder is op de cpu en “spa’s” vaak aardig heavy daarop kunnen zijn.

Ook zullen die pagina’s vaak meer functionaliteit omvatten wat meer data kost.

Het is geen harde realiteit maar doorgaans is een minimalistische HTML versie lichter.

[Verwijderd]

Single-page applications zijn helaas stukje zwaarder.

Die vlieger gaat niet op voor hybrid SPAs... Als je een SPA hebt dat puur alles via JS doet, sure. Was onzin dat te veel mensen voor vielen want dat was de "hip" (en nog altijd mensen voor vallen).

Het probleem is dat mensen met volledige shadow doms zaten te werken, alles moest dynamisch van de browser kant afkomen enz, dan ja, dat maakte enorme trage websites.

Maar als je de hybrid gebruikt zoals HTMX, dan zijn "hybrid SPA's" gewoon lichter dan puur HTML rendering.

Collega maakte een SPA in Angular, en ding was 250MB geheugen gebruik, 1MB download, en traag al hell wanneer je veel input fields had. Toen hij vertrok en de klant klaagde, hetzelfde "SPA like" ding later herbouwd.

Beetje Ajax/Fetch framework van nog geen 150 regels, en ik deed hetzelfde vlotte opbouw, dynamisch berekeningen, enz, met 40MB geheugen gebruik, 5KB download en 1000de input fields zonder problemen.

Hetzelfde wat HTMX (https://htmx.org/) doet deze dagen.

En over de jaren hebben sommige mensen ingezien dat je geen bloatware SPA moet hebben dat alles in de browser via JS deden, nee, wat je wilt is een hybrid aanpak waar je het beste van beide werelden gebruikt.

[blorf]

Naar mijn idee moet je er gewoon vanuit gaan dat het gaar is omdat er een interacvtieve "applicatie" wordt omgezet in voer voor een een browser, met alle onnodige resource-verpilling als gevolg.
Ik heb er nog geen gezien die ook echt aanvoelt als een programma. Alles is traag, met lange laadtijden en beperkt input-responsive.

[Reactie gewijzigd door blorf op 23 juli 2024 15:27]

[jaapzb]

Enige voordeel van SPA is echt niet alleen dat het "hip" was/is. Server-side rendering, SPA en hybrides hiervan hebben allemaal hun eigen voor en nadelen en zoals alles met techniek en ontwikkeling moet je kijken naar de prioriteiten en requirements van je project om hierin een juiste keuze te maken bij het bepalen van je tech stack.

Gewoon roeptoeteren dat iets slecht is, is junior developer gedrag.

[Reactie gewijzigd door jaapzb op 23 juli 2024 15:27]

[anno361]

Tot circa 2010 was front-end ontwikkeling echt wel "the far west",
de tools waren echt wel beperkt.

Die SPAs hebben die front-end ontwikkeling echt wel naar een nieuw niveau getild.

En concreet voor AngularJS had die eerste versie echt wel veel memory issues.
Maar die zijn er intussen uit, we zitten nu aan Angular 16, en als ontwikkelaar moet je eigenlijk niet veel moeite meer doen. Het systeem is echt matuur geworden.

[Verwijderd]

Tot circa 2010 was front-end ontwikkeling echt wel "the far west",

Ben verbaast dat mensen nooit gehoord hebben van AJAX ... Dat was rond 2005, en ik maakt toen al tools dat hybrid SPA waren. Grappig genoeg is wat ik vandaag gebruik letterlijk een continuatie van men code in 2005, gewoon met de jaren geupdate, en aangepast aan de syntax.

Het probleem was dat we in die tijd, nog altijd de anti-JS crowd hadden en je moest opletten met functionaliteit te bouwen rondom JS. Wat SPA gedaan hebben, is ervoor gezorgd dat die dat graag JS uitzetten in un browser, beetje uitgestorven zijn (of ze konden het net niet meer gebruiken).

[com2,1ghz]

Web crawlers en Safari mobile(Nokia anyone?) die sites gecomprimeerd ging ophalen via een proxy zonder JS. Dat waren naar mijn weten de belangrijkste clients zonder JS.
Mensen die het bewust uit gingen zetten waren vrij minimaal dacht ik.

[anno361]

Naar mijn gevoel is web ontwikkeling pas volwassen geworden bij ECMAScript5 en HTML5.
En alles wat daaraan vooraf gaat is gepruts.

En om helemaal compleet te zijn, denk ik dat er in 2005 een kloof was tussen back-end en front-end van bijna 20 jaar. Ik bedoel daarmee dat er voor web-ontwikkeling geen goede tools waren, geen stabiliteit, geen platform onafhankelijkheid, een achterstand op vlak van OOP en design patterns.

Tegen 2009, dankzij die ECMAScript 5 en HTML 5, kwam alles in een versnelling. Op dat moment was die achterstand misschien nog 15 jaar, maar die hebben ze extra snel ingehaald. En die SPAs hebben een belangrijke rol gespeeld daarin.

En ik volg je wel gedeeltelijk:
Je kan echt wel een front-end maken zonder SPA. Anderzijds, kan je ook echt wel een back-end maken zonder framework. En je kan echt wel een server hosten zonder cloud provider. En wie heeft er een CI/CD pipeline nodig, wanneer je gewoon zelf de files via een SFTP client kan overpompen.

Het ding is, je wint tijd als het over kleine projectjes gaat, maar zodra het groter wordt moet je de dingen toch gewoon deftig opzetten, en dan zijn enkel de meest professionele tools goed genoeg. En zonder al die tools, ben je eigenlijk gewoon aan het prutsen.

[DeCo]

De laatste tijd ben ik bezig met. NET Blazor. Basis JS framework is natuurlijk groter dan HTMLX, maar daar blijft het verder bij. Er komt geen letter JS meer bij kijken. Geen AJAX/fetch requests meer, alles gaat via SignalR. Voor de ontwikkelaar een verademing, wat mij betreft. En de applicatie voelt snel aan.

[Reactie gewijzigd door DeCo op 23 juli 2024 15:27]

[armageddon_2k1]

HTMX is weer de nieuwste hype en lijkt op wat we 20 jaar geleden deden.

[PainkillA]

helemaal mee eens. server side render met htmx geeft een veel betere gebruikerservaring maar nog veel belangrijker is dat het ongelofelijk veel complexiteit en state management uit de frontend haalt.

[SenkZ]

Wat is het verschil tussen htmx en iets als Astro? Dat is een js library die werkt met een zogenaamde island architecture.

[Hugo_ijslijk]

Htmx is een techniek om stukjes html over de lijn te sturen en dan met een heel klein beetje javascript de pagina dynamisch te maken en te updaten. Opbouw van html gebeurd dus server-side. Astro is een framework om statische pagina's te maken, waar je met islands delen client-side dynamisch maakt

[holoduke51]

Probleem is echt niet de render engine van de browser. Dynamisch content renderen gaat echt wel snel genoeg. Hele paginas kan je makelijk in 5ms renderen. Probleem zit hem in de bloated frameworks met 100 abstractie lagen. Van xml layout files parsen tot enorme complexe viewcontrollers met bindings naar data en elementen.
Wij gebruiken een inhuis framework(je) van nog geen 30kb. Waarmee we alles volledig clientside kunnen doen. Hele applicatie is zon 150kb. Hybride kan inderdaad ook door eerste pagina load server side te renderen. Ook goed voor SEO. Maar met service workers kan je alles zo goed cachen dat het voor ons niet nodig is. Wij richten ons vooral op telefoon apps. Geen normale sites.

[armageddon_2k1]

Welk framework parsed er xmls als layout?

[seapip]

Single page applicaties kunnen overigens tegenwoordig met bundle splitting en lazy loading ook een stuk minder zwaar gemaakt worden. Waarschijnlijk een van de redenen dat ze de HTML view uitfaseren, de moderne interface kan tegenwoordig ook snel gemaakt worden.

Een andere doelgroep die HTML only wel gaat missen zijn de privacy/security gebruikers met extensies zoals noscript. Maar ik denk dat het JavaScript vrije internet tijdperk ondertussen wel zo'n beetje ten einde is.

[cobaco]

"Maar ik denk dat het JavaScript vrije internet tijdperk ondertussen wel zo'n beetje ten einde is. "

er is een verschil tussen
- internet als informatieverdeelplatform
- internet als applicatieplatform

voor die eerste heb je geen JS nodig (en wil je dat ook niet)
voor die 2e wel

[Dreamvoid]

Voor het tweede wil je native apps, die draaien a) geverifieerde/signed code en b) een stuk sneller met minder geheugengebruik.

[RoelRoel]

Dat zou misschien ideaal zijn maar natuurlijk voor de meeste klanten totaal onbetaalbaar.

[cobaco]

"Voor het tweede wil je native apps,"

persoonlijk ben ik het helemaal met je eens

zowiese zouden browsers JS standaard moeten uitzetten (om dezelfde reden dat je in je mailclient niet standaard exe's laat aanklikken)

[i-chat]

deze versie was inderdaad gewoon 100% serversite html

de opmaak en de features etc allemaal in pure html met <forms> en http-post etc

de nieuwe interface gebruik voornamelijk clientsite code, soorteren van emails opmaken autosave eigenlijk alles werkt in de browser. maar daarvoor worden wel eerst vele honderden zoniet enkele duizenden kilobits verzonden.

[Dreamvoid]

Zorgelijke ontwikkeling, het web moet naar meer sites die zonder Javascript werken, niet meer. Hoe meer domeinen je Javascript kan uitzetten, hoe minder kans op exploits en traagheid/excessief geheugen gebruik.

Maar serverside renderen kost Google cpu cycles en dus geld, clientside komt voor de rekening (en risico) van de klant, helaas.

[faim]

Dus jij wilt weer terug naar 1995? Een web zonder JavaScript is niet meer denkbaar.

Het gaat Google echt niet om de server side rendering, het gaat erom dat ze iets moeten blijven ondersteunen wat amper gebruikt wordt en niet meer van deze tijd is.

[Dreamvoid]

Nee ik wil naar 2025+, een wereld met HTML5 en CSS3, maar wel terug naar server-side rendering. Met de dikke datapijpen van nu is dat zinniger, en het bespaart stroomverbruik/cpu/memory aan de user kant. Een stuk veiliger ook, zonder runtime.

[FrankSpin]

Ja ze gebruiken uiteraard nog html in andere weergaves. Maar naast html ook nog veel JavaScript om de pagina’s interactief te maken.

Hoe meer JavaScript je toevoegt, hoe meer data ingeladen moet worden. En JavaScript code moet ook verwerkt worden door je browser. Dat kost weer rekenkracht van je device

[Buitenaerts]

Renderen van HTML kost ook rekenkracht. Maak je bijvoorbeeld gebruikt van ReactJS en je code is goed (belangrijk dat er geen bug als rerenders in zitten), is dit denk toch een stuk sneller aangezien je alleen het stukje beeld opnieuw rendert waar de daadwerkelijke wijzingen in zitten.Verder is json data natuurlijk ook stuk minder groot dan allemaal html meuk waar tables etc in zitten.

[Sando]

Is dat misschien HTML 4 ipv 5?

[Luchtbakker]

Php en javascript

[seapip]

Naast PHP kan aan de server kant nog tal andere talen gebruikt worden. Overigens gebruikt Google geen PHP voor Gmail zover ik kan vinden maar C++/Java.

[Xirt]

Volgens zorgen bovenstaande talen (welke overigens server side vs. client side zijn) uiteindelijk wel voor een weergave van DOM elementen. In hoeverre je dan kan zeggen dat een DIV-container als DOM element geen HTML is (er is op z'n minst sprake van een HTML-variant, equivalent of representatie) is in mijn ogen nog iets waarover je een goede discussie kan starten. Dat Gmail dus geen HTML weergave meer heeft is wat "kort door de bocht" / onduidelijk.

[Travelan]

Ik kan me niet voorstellen dat Google PHP heeft gebruikt voor Gmail... Heb je een bron?

[_Pussycat_]

Het nieuwe gmail wordt in Flash gemaakt!!

Maar serieus ik vraag me hetzelfde af...

[karelvandongen]

De standaard versie gebruikt html+js en zonder JavaScript actief werkt de standaard versie niet ! , gelukkig is er nog imap.

[Vibonacci]

Klopt, maar ze bedoelen 'bijna alleen HTML', of een light versie. De echte Gmail web is namelijk gemaakt met het Angular framework en bevat enorm veel JavaScript.

[Reactie gewijzigd door Vibonacci op 23 juli 2024 15:27]

[Mystic_Jack]

HTML weergave is ideaal om alle overbodige tracking mogelijkheden uit te schakelen.

In Gmail doe ik dat niet, al worden afbeeldingen niet standaard gedownload.

Geen idee wat de meerwaarde is om HTML weergave te verwijderen. Volgens mij is dat alleen in het voordeel van Google?

Maar in Tutanota die ik ook gebruik heb ik HTML weergave wel standaard ingeschakeld.

[Verwijderd]

Inderdaad, zodat je de trackingmogelijkheden niet meer uit kunt schakelen, vermoed ik!

[bantoo]

Dat is natuurlijk verkeerd om gedacht, alle software is aan onderhoud onderhevig. Iets dient een bestaansrecht te hebben om niet verwijderd te worden. Alles heeft inherent een meerwaarde om te verwijderen aangezien het je codebase simpeler maakt.

[checkpointx]

Het is een gratis dienst, niet zo gek dat google dingen doet in het voordeel van google toch?

[armageddon_2k1]

Ik kan jou gewoon tracken met puur HTML hoor.

[AdoptieMoeder]

vraag me toch af hoe je met pure html voor elkaar wil boksen.

[The Zep Man]

Als de nieuwe mailinterface te zwaar is, kan je natuurlijk ook een native IMAP mail client overwegen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 15:27]

[MineTurtle]

Als de nieuwe mailinterface te zwaar is gebruik je volgens mij nog een aardappel om je mail op te bekijken.

[jmvdkolk]

Ik wissel regelmatig naar de oude interface. Dat doe ik op plekken op deze wereld waar de internet snelheid niet zo hoog is als wij gewend zijn. Die plekken zijn er steeds minder. En ik heb de pech (of geluk) dat ik met enige regelmaat op dat soort plekken kom.

Kortom, het komt niet door de computer, maar door de brakke infrastructuur op sommige plekken op deze wereld.

Anyway, ik had de mail al gehad van Google. Ik zal een oplossing moeten verzinnen.

[MineTurtle]

Zo had ik er niet over nagedacht nee. Dan is misschien een mail client een idee (zoals mozilla thunderbird), dan hoef je alleen maar de mails op te vragen en geen complete website.

[jmvdkolk]

Een mail client is denk ik de enige optie op mijn werklaptop. Ik zal met mijn werkgever moeten overleggen wat er binnen onze security policy mag op mijn werklaptop. Alternatief is dat ik mijn privé laptop ook meeneem. Daar staat natuurlijk wel een mail client op.

[ep667]

Er zijn natuurlijk ook web based mail clients waarmee je op een externe mailserver inlogt. Kan vermoedelijk zelfs met bijvoorbeeld Squirrelmail. Die moet je dan wel zelf ergens kunnen hosten.

[jmvdkolk]

Er zijn allerlei opties als ik van Google Workspace afstap. Ivm de superieure anti-spam ben ik nog niet zover dat ik daarvan af wil stappen.

[ep667]

Je hoeft niet van Google Workspace af dan. Installeer op een eigen webruimte een webmail client die met externe IMAP werkt. Dan laat je die verbinden met je Google Mail. Dan werkt die gewoon als hosted mailclient.

[jmvdkolk]

Dank je wel voor het meedenken. Ik denk niet dat ik mijn mail setup duurder en complexer ga maken. Mijn privé laptop ook meenemen is dan een prettiger optie.

[Macshack]

Voor je privé-mail kun je natuurlijk ook gewoon een mail-client op je privé-laptop installeren.

[jmvdkolk]

Klopt. Alleen neem ik mijn privé laptop niet mee op dit soort reizen naar de middle of nowhere. Dit ivm ruimtegebrek in de bagage.

[Jeffrey2107]

ja of het is door 3 domme prutsers in elkaar gezet. nu is de standaard gmail interface best vlot dus is dat niet het geval maar als je kijkt naar youtube zie je dat die "normale" interface veel trager is dan de oude.

[Alfa1970]

De ervaring is weliswaar beter geworden, maar dat is niet omdat de standaard gmail interface vlotter is geworden, maar omdat de gemiddelde computer sneller is geworden. De interface is nog steeds bloatware.

[moonlander]

Vergeet niet dat niet elk land high tech smartphone of laptops hebben. In sommige delen van Afrika mogen ze blij zijn als ze al internet hebben op een pentium 2. Soms nog eerder een computer dan een waterput. Al zijn sommige delen van Afrika weer verder dan ons kikkerlandje

[i-chat]

gewoon overstappen naar pop of imap met je eigen mailclient en een app-password dan kun je zelfs met mutt nog in je gmail. - dat kan overigens zo: howto mutt gmail

maar serieus: die htmlweergave was 10jaar geleden al overbodig en ondergeschikt aan bijna elke lokale (of online) mailcient.

[Reactie gewijzigd door i-chat op 23 juli 2024 15:27]

[jmvdkolk]

Totdat je met je werk laptop in the middle of nowhere bent met traag internet. Dan is deze HTML weergave ineens de enige manier om je privé mail te lezen.

[djwice]

De html weergave werkte het snelste als je een configuratie in Gmail wil veranderen. Filters bewerken, nieuwe afzender adressen etc.

Op telefoons en tablets ging dat zonder de html weergave lastig.

[Reactie gewijzigd door djwice op 23 juli 2024 15:27]

[markg85]

Het artikel legt dit bijzonder slecht (niet) uit, maar het gaat dus om de Basic HTML view in gmail. Dat is een versie van gmail met minder features om op meer browsers te werken.

Vrijwel iedereen gebruikt de "Standard HTML" view op browsers van vandaag de dag en die blijft ook gewoon.

Een artikel als dit is o.a. waarom ik bij artikelen hier op tweakers graag een duimpje omhoog/omlaag wil kunnen geven. Deze zou een duimpje omlaag zijn, de informatie is incompleet op zijn best.

[CH4OS]

Met de screenshot erbij, lijkt het mij wel redelijk duidelijk. Ik weet echter niet of die er ook stond toen jij jouw bericht postte.

[Luminair]

Ja, eens. De manier dat ik het las leek het wel alsof Gmail vanaf nu alleen nog maar text-only e-mails zou tonen. Maar ze bedoelen dus de UI van Gmail, en dat die straks verplicht JavaScript nodig heeft.

[Ascathon]

Net zoals dat het "volgens Google" naar je mailbox wijst om een setting aan te passen en niet naar een nieuwsbericht. Waarom ik in de enquete ook heb aangegeven waarom ik Tweakers minder goed vind de laatste jaren. Nieuwswaardigheid a la, maar kwalitatief vind ik het gewoon met puur gemakzucht geschreven en al vooral met 0 passie.

[markg85]

Ja, eens. Bot gezegd komt het over als "we pompen er een artikeltje uit voor de kliks en advertenties, kwaliteit slecht nemen we voor lief". Jammer en gebeurd helaas steeds meer hier.

[PCG2020]

Dan doe je één van deze twee dingen:
- je solliciteert naar een functie bij de redactie, of
- je start je eigen techwebsite, zonder clicks en advertenties

Een beetje zeuren in de reacties heeft natuurlijk weinig nut verder.

[MrMarcie]

Precies, een kopie paste van een Engels document of zo. Zeer onduidelijk en verwarrend. Eigenlijk wordt het er alleen maar beter op. Nu wordt de suggestie gewekt dat dat niet zo is.

[MMaster23]

Ik dacht even dat ze HTML weergave van emails gingen weghalen. Dat zou een hoop mail kapot maken gok ik zo.

Maar het gaat dus om een oudere email GUI.

[Htbaa]

Dat dacht ik dus ook. Pas na het doorklikken op de link in de artikel gaat het om de vereenvoudigde weergave van Gmail. Nu had het mij niet geraakt omdat ik geen Gmail gebruik (heb het altijd een draak van een interface gevonden + het is Google). Maar stel ze zouden stoppen met HTML weergave van mails ben ik benieuwd wat dat zou gaan betekenen voor de hele mail marketing markt. Daar wordt alles opgemaakt in HTML. Denk dan eerder dat Gmail snel minder gebruikers zal zien.

[Macshack]

Yep vreemde mogelijk bewuste click-bait artikel. Want de HTML interface blijft gewoon bestaan.

[jacob.korf]

Hoop wel dat ze dan alle settings overzetten die je wel in html weergave hebt

[andru123]

Ik vind simplistic weergave beter om, eigenlijk, mail te lezen. Zonder fancy JS animaties of 100 functies die ik nooit gebruik.

[Macron]

Erg jammer. Ik gebruik in Firefox de LocalCDN-plugin om zo veel mogelijk tracking d.m.v. bijvoorbeeld Google/webhosted-fonts te verwijderen. Wanneer ik dan GMail open gaat dat zooo traag dat ik switch naar de Basic HTML-weergave. Die staat nagenoeg meteen in beeld.

[W00fer]

Doodzonde. Gebruik dit regelmatig op iets oudere hardware die anders op de afvalberg zou komen.

[afraca]

Ik zit op een erg afgelegen locatie met VSAT internet die soms erg slecht werkt. Dan was die js-loze weergave wel erg fijn om te hebben. Maar gelukkig wordt VSAT wel steeds betrouwbaarder, behalve tragische ping (700ms) halen we 90% van de tijd gewoon 25 mbit/s.