Waarom zijn browsers na 27 jaar nog zo slecht?
Zo'n belangrijke tool is na al die tijd nog steeds net bèta-software.
Hoe kan het dat browsers, inmiddels zulke belangrijke software, nog steeds zo instabiel en zich onvoorspelbaar gedragen? Iets gaat er niet helemaal goed met de ontwikkeling.
Waarom zijn browsers na 27 jaar nog zo slecht?
Hoe kan het dat browsers, inmiddels zulke belangrijke software, nog steeds zo instabiel en zich onvoorspelbaar gedragen? Iets gaat er niet helemaal goed met de ontwikkeling.
Mosaic werd in 1990 geïntroduceerd door Tim Berners-Lee in na meer dan 26 jaar ontwikkeling is het nog steeds een van de slechtste softwarepakketten die we hebben. Het zijn brake, buggy, geheugenvreters die lijden aan bloat, onder malware, crashes en slechte rendering. Ik kan hier een hele klaagzang met voorbeelden geven, maar waarschijnlijk snap je wel wat ik bedoel.
Daarnaast is het heel belangrijke software geworden. We gebruiken het niet alleen maar voor video's en websites, maar in de SaaS en cloudwereld is de software een belangrijke portal geworden in de zakelijke wereld. Browsers moeten dus betrouwbaar en stabiel zijn, maar in de praktijk is er wel iets mis met elke browser. Kijk naar de volgende:
- Internet Explorer: Malware richt zich het meest op deze browser, vanwege diens populariteit vroeger. Er zijn geen third-party extensies beschikbaar, zoals bij concurrenten als Firefox en Chrome. Hij presteert vaak slecht in renderingstest en andere benchmarkonderzoeken.
- Edge: Had geen extensies tot de Anniversary Update van afgelopen zomer en nog steeds is de keuze daarvoor beperkt.
- Firefox: Dit is een geheugenvreter die bijna al het werkgeheugen opvreet in mijn systeem met 16 GB RAM. Hij laadt afbeeldingen niet soepel en crasht iets te vaak.
- Chrome: Verticale tabbladen zijn niet mogelijk. Tot voor kort was het een geheugenvreter en nog steeds ondervind ik foutieve rendering, waardoor ik regelmatig loop te F5'en.
Momenteel gebruik ik Firefox en dat is maar om één reden: verticale tabbladen. Als je dat eenmaal hebt geprobeerd, wil je nooit meer terug. Je kunt met gemak 30 tabs open hebben en alle titels zijn dan nog gewoon te lezen. Met tabbladen horizontaal bovenaan raak je het overzicht heel snel kwijt. Ik kan Tree Style Tab om die reden niet genoeg aanbevelen.
Chrome-issues
Google, waarvan je zou vermoeden dat het meer slimme mensen heeft dan de bescheiden organisatie Mozilla Foundation (niet beledigend bedoeld: Google is nou eenmaal enorm) heeft het ontwikkelen van verticale tabs opgegeven in Chrome en dat vind ik ongelooflijk. Eén persoon in Japan krijgt voor elkaar in Firefox wat onbeperkte resources bij Google niet voor elkaar kunnen boksen in Chrome?
Een groter probleem is dat de rendering in mijn configuratie vaak misgaat. Ik heb geen idee waar dat door wordt veroorzaakt, maar mogelijk is het de Tweetdeck-Chrome-app. Dat is al tijden geen stand-alone app meer en zoals zoveel gebruikers ben ik daarom overgestapt op de browser-plugin. Als ik die een paar uur draai, is de tab gecrasht en moet ik hem herstarten.
Firefox-problemen
Firefox is helaas ook niet ideaal. Zoals ik al aangaf, bezet het erg veel RAM. Dat is vooral zo als mijn machine enkele dagen draait en ik de browser niet herstart. Ik zie in Wise Memory Optimizer het geheugengebruik langzaam (en soms snel) oplopen naar 50 procent naar 70 procent. Ik sluit dan de browser, optimaliseer het geheugen en dan ben ik terug op 35 procent.
Firefox kan ook langzaam zijn bij het laden van pagina's en afbeeldingen worden niet altijd ingeladen. Slideshows gaan vaak niet goed. Ik weet niet precies waarom, maar de browser heeft moeite met grafische elementen.
IE-gebreken
Ik heb IE11 niet overwogen vanwege het plugin-gebrek en Edge is geen optie voor me omdat ik Windows 7 gebruik. IE heeft daarnaast de irritante gewoonte om favorieten alfabetisch te sorteren, in plaats van de volgorde die je zelf graag wilt. Ondanks dat HTML relatief simpel en volwassen is, is het opvallend hoe verschillend pagina's zich gedragen tussen verschillende browsers. Ik ben de tel kwijt van hoe vaak ik een pagina in drie verschillende browsers heb moeten laden om te zien of de site daarin wel wordt geladen.
Er zijn natuurlijk naast deze grote namen ook alternatieven als Vivaldi en Brave, maar de meeste daarvan (inclusief deze twee) zijn gebaseerd op Chromium, dus ik zou een Chrome-browser krijgen met een andere gebruikersinterface.
Er is geen excuus voor: browsers moeten simpelweg een stuk beter zijn. Sterker beveiligd, stabieler en uniform beter met het renderen van pagina's. Als reuzen als Microsoft en Google het al niet goed krijgen: wie kan het dan wel?
Browsers zijn niet slecht, ze voldoen alleen niet aan de verwachtingen van de auteur. Dat is heel wat anders.
Al decennia proberen diverse partijen de browser te adopteren als ware het een applicatieplatform terwijl de browser daar niet voor gemaakt is. Eerst Netscape en Sun, toen Macromedia/Adobe, vervolgens de Web2.0-hype en ook nu weer talloze cloudaanbieders.
Een browser is primair een viewer voor documenten in diverse versies van de HTML-markuptaal. Door de jaren heen is daar een zodanig gigantisch waterhoofd bovenop gezet, dat "de browser" een topzwaar product is geworden met allerhande voorzieningen die eigenlijk lager in de stack beter op hun plaats zouden zijn.
Zo is het niet logisch om een complete programmeeromgeving (Javascript) binnen de context van een document te draaien. Het vervolgens binnen die omgeving in elkaar knutselen van een complete viewer voor een totaal ander documentformaat (PDF), waar op zijn beurt ook weer uitvoerbare code in kan zitten, vind ik al helemaal opmerkelijk.
Deze in mijn ogen bizarre ontwikkeling (en bovenstaande zijn slechts twee voorbeeldjes van de gekkigheid die in browsers plaatsvindt) is alleen vol te houden omdat computers in een onvoorstelbaar tempo krachtiger zijn geworden. Het verbaast mij dan ook niets dat browsers tegenwoordig honderden MB's aan RAM-geheugen opvreten en instabiel draaien.
Die bizarre ontwikkeling heeft alles te maken met interactie. Een viewer kan niet interacteren, terwijl dat wel gewenst wordt. Dit heeft er toe geleid dat de browser een applicatieplatform is geworden.
Een browser is geëvolueerd tot een applicatieplatform (Je moet nu ook je best doen om javascript uit te zetten). Hierdoor is Windows irrelevant geworden, ondanks de dooddruk praktijken van MS naar Netscape, en kan ik mijn werk doen zonder terug te vallen op windows. In die zin voldoet de moderne browser uitstekend.
Als platform-onafhankelijke document editor of viewer is het niet geslaagd. Je kon ook niet fatsoenlijk iets uitprinten, vandaar de PDF oplossing als plugin of helper. Dat die PDF viewer zo nodig ingebouwd moet worden (maakt het traag) begrijp ik ook niet.
De Netscape composer heeft het niet heeft gered. De CMS systemen waren blijkbaar toch handiger, alhoewel daar nu ook een (javascript) composer is ingebouwd.
De Amaya browser is al jaren een platform onafhankelijke document/web editor maar nooit wat geworden. [Link]
Je kan altijd nog een tekst browser gebruiken.
ik wacht met smart op je eerste post, waarin Windows niet wordt genoemd ;-)
Het wordt duidelijk hoog tijd dat je je concentreert op de inhoud en niet op de man ;-)
En dat is dan een serieuze bedoelde opmerking ? Lees dan je eigen eerdere reactie op deze pagina nog eens door
"Splinter - balk verhaal. Alleen zit die balk in je loensend Windowsoog, dwars door die dikke roze MS-bril"
Misschien tijd voor enige zelfreflextie ?
Mee eens. Sterker nog, een voorspelling van mijn kant is dat de browser de virtual machine van de toekomst is. Een eerste stap (nog steeds op applicatie niveau) is de introductie van webassembly (nu als preview optie al beschikbaar, vanaf medio 2017 (?) standaard beschikbaar). Een tweede stap is het ondersteunen van een technologie zoals Docker in de browser. De laatste is denk ik wel nog wat verder weg in de toekomst, maar ik zie het wel gebeuren.
Dat soort dingen zie ik inderdaad ook wel gebeuren en ik betreur ze ten zeerste zolang de browser in essentie primair een documentviewer blijft. Het vehikel voor alle in-browser applicaties (gelinkte/meegecompileerde extensies uitgezonderd) is nog altijd een HTML-pagina in e.o.a. vorm. Dat is ronduit bizar te noemen vanuit architectuur, en je krijgt de hele onevenwichtige "kitchen sink" aan onsamenhangede componenten bij al je appjes meegeleverd. Het hele paradigma van applicaties die werken met documenten wordt omgekeerd. In een browser zijn het de documenten die applicaties manifesteren. Op zich wel wat voor te zeggen, maar niet in combinatie met een onderliggend OS Dat dan weer volledig gebouwd is op de omgekeerde metafoor. Dat wordt een ondoordringbare spekkoek waar een heleboel onnodige omwegen in worden bewandeld en met een gigantisch contactoppervlak voor aanvalsvectoren en bugs.
Als je het hebt over web *applicaties* (in tegenstelling tot web *sites*), dan ben ik het niet met je eens. Je hebt gelijk, maar het vehikel is wel typisch beperkt tot een paar regels HTML (in de index.html). De rest van de applicatie, inclusief de bijbehorende HTML templates worden netjes gebundeld. Je gebruikt deze HTML templates om views te definieren. Dit is niet anders dan native applicaties die daarna gecompileerd worden naar bijvoorbeeld een shared library. De functie van de "index.html" in SPA's (single page applications), is wat mij betreft vergelijkbaar met een snelkoppeling in Windows. Het geeft aan wat het startpunt van de applicatie is (vergelijkbaar met main() function for C/C++ applicaties).
Of de componenten samenhangend zijn, ligt ook meer aan de ontwikkelaar dan aan de onderliggende architectuur. Ik kijk dan ook zeer uit naar het beschikbaar hebben van web assembly in de browser. Dit opent de mogelijkheid om cross-platform/cross-device applicaties te bouwen die nagenoeg niet onder doen voor native applicaties. De stack wordt dan HTML5/CSS/Javascript/webassembly, waarbij webassembly code gegeneerd wordt op basis van een door de ontwikkelaar te kiezen taal (nu nog vooral C/C++, maar talen zoals Rust/C# etc. zullen waarschijnlijk snel volgen). In combinatie met service workers (offline support + caching van applicatie code) heb je dan wat mij betreft een prachtig platform voor applicatie ontwikkeling.
Wat is het verschil tussen een website en een webapplicatie? Ik zie daar alleen een glijdende schaal die reikt van platte HTML-pagina tot volledig client-side draaiende applicatie zoals een DOS-emulator in Javascript. Waar trek je de lijn precies? Met name een toepassing zoals genoemde emulator vind ik hogelijk dubieus om te hebben binnen de context van een documentviewer. Index.html is wel te zien als een snelkoppeling, maar zo is het natuurlijk nooit ontworpen. De spekkoek van nodeloze abstractielagen blijft in stand en daarmee ook de faalkans die veel groter is dan noodzakelijk.
Wellicht verraad ik mijn leeftijd hiermee, maar ik ben geen voorstander van het eindeloos stapelen van indirectielagen om problemen niet te hoeven oplossen. Soms is een indirectielaag goed, maar lang niet altijd. In browserland is men m.i. ernstig doorgeschoten en ik ben van mening dat de auteur dat ziet in de vorm van logge, foutgevoelige applicaties omdat de architectuur (voor zover daar nog sprake van is) de beoogde functionaliteit te indirect probeert te realiseren.
Je ontkomt er niet aan om een platform onafhankelijke laag te creëren. Microsoft heeft het geprobeerd met windows only, totdat Netscape zich begon te roeren en later Sun met JavaOS).
De browser zou zich moeten beperken tot alleen de user interface, bestaande uit HTML en javascript of ? . Applicaties worden serverside aangeboden m.b.v microservice architectuur (HTTP resource API)
De browser als eenvoudige document viewer is al lang achterhaald. tenzij je met een andere web runtime omgeving op de proppen komt.
Het is al een stuk beter geworden. Ik herinner me nog wel de leveranciers die de platform-onafhankelijke laag toch weer platform-afhankelijk probeerden te maken.
Hier ben ik het niet helemaal mee eens. Als je kijkt naar progressive web apps, dan zijn dat applicaties die in een browser omgeving draaien. De server kant is vooral verantwoordelijk voor het (a) het aanbieden van de applicatie code zelf (die daarna dus aan de client kant kan worden opgeslagen, ook wanneer de client off-line is) (b) het voeden van de applicatie met data/content (die wederom aan de client kant ge-cached kan worden voor off-line gebruik). In dit scenario draait een groot deel van de applicatie code in de browser. Voor het vakgebied waar ik in zit (veel data/images die grotendeels niet meer veranderen) biedt het veel voordelen om zoveel mogelijk van de code in de browser te draaien.
Functioneel is dit zeker handig, maar is een document viewer het geëigende platform voor deze manier van werken? Is een markup-document het geëigende vehikel om als container voor een applicatie te dienen? Is het draaien van een volledig turing-complete VM-achtige omgeving binnen een document viewer de geëigende manier om business-logic van een applicatie uit te voeren?
Op al deze vragen zeg ik overtuigd 'nee', zelfs al komt men er in de praktijk nu nog wel mee weg. Dat houdt een keer op namelijk, is mijn voorspelling.
Volledig eens dat de browser geen eenvoudige document viewer meer is (in functionele zin), maar ze zitten technisch nog wel zo in elkaar. Dat is vanuit de theorie vragen om problemen en zowaar, dat zien we dus ook in de praktijk gebeuren. Het functioneert allemaal nog net wel, maar wel met de symptomen die auteur beschrijft. De creatie van een platformonafhankelijke laag is op zichzelf namelijk niet erg, maar wél wanneer die laag zelf wordt ingekapseld in iets wat op zichzelf al een applicatie in de onderliggende platformonafhankelijke laag is. Dat is de spekkoek waar ik naar verwijs, het soort ranzigheid die alleen is vol te houden met hardware die jaar over jaar exponentieel beter presteert. Een soort kredietcrisis op basis van tech-debt dus eigenlijk want er zijn grenzen aan de groei.
Platformonafhankelijkheid is ouder dan het web en begon al op het moment dat de eerste compiler verzonnen werd. De geschiedenis van FORTRAN en de uitdagingen van de IBM-engineers destijds is een aardig verhaaltje voor het slapengaan in dat opzicht.
IK ben het met je eens dat het wel erg hoog in de stack zit. Voor de GUI zou het eigenlijk niet uit moeten maken of een applicatie in- of extern draait met bijbehorende rechten. Wat dat betreft was/is X-windows zo gek nog niet. Nu is het meer de browser als desktop (ChromeOS). Er zullen vast nog wel wat slimme display technieken ontworpen worden. Wat dat betreft schiet Xspice ook niet echt op.
Hoe zou het toch komen dat browsers onder Windows slechter presteren ? Mijn FF doet het uitstekend onder centos en fedora.
Voor het eerst dat ik er naar kijk sinds ik ben overgestapt van win 10 naar Ubuntu en ja, maar een paar honderd MB, dat was in Win10 heel anders.
Alleen jammer dat het zo extreem lang duurde voordat er een fatsoenlijke 64bit versie was.
In Google Chrome kan je een soort van verticale tabs krijgen door Tabs Outliner te gebruiken. Het is even wennen. Zelf vind ik het krachtiger dan Tree Style Tab in Firefox.
Je kunt beter vragen of web browsers de laatste 15 jaar er beter of slechter op zijn geworden. Inderdaad hoopte ik dat toen de Netscape browser Open Source werd en Mozilla of Firefox (of nog anders) werd genoemd, het aantal bugs zou verminderen, maar daar is niets van te merken en het aantal features wordt ook steeds meer in plaats van minder.
Dit artikel valt me niet mee, wat een besodemieterde vertaling. Wat browsers betreft, gebruik ik firefox, inderdaad een resource vreter, wel met leuke plugins.
Beetje verwend geneuzel. Het moet de specifieke wensen van meneer -in FF een experimentele add-on en in Chrome het instabiele tweedeck- aankunnen, natuurlijk met tientallen vensters en tabs, en ook nog eens snel en veilig zijn. Dit is geen goed artikel.
Zal ondertussen niet veel van over zijn maar IE was natuurlijk het afgetroggelde Mosaic.
Het is inderdaad frappant hoe pagina's verschillend gerenderd worden in verschillende browsers, al zijn de verschillen wel kleiner geworden. FF is inderdaad een ramp (ververst zelfs niet bij herhaaldelijk opstarten), chrome is best goed, en meer fatsoenlijke alternatieven, behalve Safari, zijn er eigenlijk ook niet. Terwijl alles draait om internet.
Maar goed, tekstbestanden worden ook verschillend gerenderd in verschillende tekstverwerkers en viewers. Muziekbestanden klinken in winmediaplayer ook beter dan in VideoLAN. Een Apple-pc rendert je foto's ook beter dan een gemiddelde pc.
Safari voor windows is al geruimte tijd zo dood als een pier.
Dus mocht je die nog hebben: snel deleten
Ik mis Opera in dit verhaaltje. Klein maar vaak fijn. Al gebruik ik zelf chrome met zijn nadelen.
.... (dubbelpost)
Ben ik toch eens benieuwd naar: wat denk jij dat de kans is als iemand Safari in 2017 een relevante browser noemt dat hij het over Safari voor Windows heeft? Dat medio 2012 is overleden?
Zou zoiets zijn als IE6 heden ten dage aanprijzen. Nogal idioot, dus.
Vraag me dan af wat de meerwaarde is van jouw opmerking.
Zucht... dat is toch precies wat Zorba zegt, of wil je het weer niet begrijpen?
Bij Ctrl is altijd de trigger; Apple product in negatief licht stellen, bam, dan reageert ie altijd.
Lezen en ook begrijpen waar het over gaat is niet echt jouw ding hè? Zorba stelde hier nogal nadrukkelijk een al jarenlang niet meer relevant Windows product in een negatief daglicht. Met als enige reden dat het al jaren niet meer relevant is.
Het hedendaagse Apple product staat nergens ter discussie in deze draad.
Jij kunt zelfs een Ad-hominem verprutsen. :-D
Te makkelijk weerlegbaar
Hoewel je ziekelijke drang om te stalken eigenlijk een negeeractie zou verdienen, blijkt na heel wat tekst van je, dat je het eigenlijk toch wel begrepen had.
Safari is verlaten door Apple omdat het een beroerde browser was onder windows. Zoals wel meer Apple programmatuur ( denk aan het rampzalige programmeerwerk bij itunes).
Als iemand spreekt over een reeks aan browserkeuzes dan is het eigenlijk al per definitie geen apple verhaal ( daar is je keuze extreem beperkt namelijk) en safari onder linux.. tja.
Dus uiteindelijk snapte je het maar dat kost zoals altijd weer een aantal postings ;)
Splinter - balk verhaal. Alleen zit die balk in je loensend Windowsoog, dwars door die dikke roze MS-bril.
Je moet wel verder lezen hè. Er staat een vraag onder die tekst.
Precies; diezelfde vraag geldt dan ook voor jouw bijdrage: je herhaalt alleen (in andere bewoordingen) wat Zorba zegt.
Hm. Opera is tegenwoordig ook gewoon een Chrome browser met een eigen UI.
Als je het process begrijpt van het ophalen van een pagina tot het uiteindelijke renderen van de pixels op je scherm, is het niet verbazingwekkend dat een pagina er in de ene browser er anders uitziet dan in de andere. In verreweg de meeste gevallen ligt het aan de CSS waarmee de verschillende elementen van de pagina's zijn opgemaakt. Omdat de standaard opmaak niet vastgelegd ligt in de CSS of HTML specificatie, kiest elke browser zijn eigen defaults. Als de auteur van de web pagina, geen definitie geeft, valt de browser dus terug op defaults. Deze zullen per browser verschillen. Zie hier de reden voor bibliotheken om alle CSS definities te resetten.
Bottom-line: het verschil in rendering in browsers ligt bijna nooit aan de browser, maar aan de auteur van de web pagina.
Reageer
Preview