[Disc.] Toekomst van Javascript...

[BtM909]

Mooi frontpage artikel: nieuws: Microsoft en Mozilla oneens over toekomst Javascript

Een aantal quotes uit het artikel:

Mozilla en Microsoft zijn het onderling oneens over de volgende versie van EcmaScript, de basis voor onder andere Javascript. Chris Wilson, platform architect van Microsofts IE-team, ziet niet veel in het door Mozilla gesteunde EcmaScript 4.

De voorgestelde wijzigingen in EcmaScript 4 zouden leiden tot niet goed functionerende websites en -applicaties, omdat het samengaan van een fundamenteel gewijzigde scripttaal in combinatie met backwards compatibele code nooit goed kan uitpakken.

Kort gezegd: Microsoft wilt graag de discussie starten (??) om niet naar EcmaScript 4 te kijken, omdat de vernieuwing de backwards compatibility in de weg zitten (en vice versa). JScript is dusdanig beschreven dat er eigenlijk rekening gehouden moet worden als er gepraat wordt over een nieuwe versie van de basis van scripttalen. Mozilla daarintegen geeft aan dat iedereen vrij was om te reageren en dat Microsoft zijn beurt heeft gehad. ES4 is the way to go...

* disclaimer: even veralgemeend naar bedrijfsnamen ipv. specifieke personen binnen de diverse organisaties.

Interessante links:
• Chris Wilson: ECMAScript 3 and Beyond
• Chris Wilson: What I think about ES4
• Brendan Eich: Open letter to Chris Wilson

---

Een tweetal dingen die opkomen na het lezen van dit artikel:

1. Moeten we kijken naar een nieuwe taal om hedendaagse onvolkomenheden uit de weg te ruimen. En zou backwards compatibility hiervoor moeten wijken.

WhatWG heeft ook een hele moeilijke taak gehad om zowel goede vernieuwing te definieren, alszijnde backwardscompatibiliteit te creeeren.

Persoonlijk denk ik dat de discussie gelijkwaardig is als de fameuze render-engine van IE

2. Wat denken jullie zelf wat de toekomst van Javascript zou moeten brengen? Ik trek het even door naar JS ipv. EcmaScript in 't algemeen.

Moeten we een keer gaan breken of langzamerhand bepaalde "modules" (en welke componenten dan?) gaan verbeteren c.q. vervangen?


Ben benieuwd wat de rest ervan denkt?

[CoolGamer]

Een van de voordelen wat het hedendaagse javascript heeft is dat het redelijk simpel is. Door al dat object-geörienteerde spul erbij te doen, wordt het voor een beginner er niet makkelijker om het te begrijpen. Daarentegen voor de mensen die echter een wat groter stukje script (complete webapplicaties bijvoorbeeld) willen schrijven of gebruik willen maken van een framework, kan ik me voorstellen dat ze wel wat hebben aan de uitbreidingen.

Veranderingen die de huidige code incompatibel maken, lijkt mij beter om te vermijden tenzij het een echt grote winst oplevert. Nadeel van een nieuwe taal, zoals dat als een goede mogelijkheid wordt beschouwd door Chris Wilson, is wel weer dat mensen weer de nieuwe scripts moeten gaan schrijven als ze gebruik willen gaan maken van nieuwe features. Voordeel is dan wel weer, dat alles wat 'fout' was of niet meer voldoet aan hedendaagse eisen in javascript kan worden hersteld. Vroeger had je al die foefjes niet nodig, want je schreef niet heel erg grote stukken javascript code. Dat is tegenwoordig wel anders En zolang beide talen langs elkaar heen gebruikt kunnen worden, kan de migratie naar de nieuwe taal ook rustig verlopen.

Eén ding waar ik in ieder geval niet op zit te wachten is dat Microsoft en Mozilla allebei hun eigen "standaard" implanteren, waardoor codes niet werken cross-browser. Maar daarentegen lijkt mij het niet waarschijnlijk dat Microsoft ineens met een nieuwe taal op de proppen komt. De kritiek op de specificatie was ook niet van Microsoft, maar van 1 van de medewerkers. (Bron) De kritiek is wel heel erg op de man gericht, terwijl het niet eens een officiële reactie was.

Ik denk dat het maken van classen in een groter project zeker de vruchten kan gaan afwerpen. Iets wat ik hoop dat alle implantaties eigenlijk nagenoeg hetzelfde worden, dus niet zoals nu dat Microsoft en Mozilla hun eigen extensies/afwijkingen op de specificatie hebben. Maarja, dat zal toch niet gebeuren.

[disjfa]

Heeft MS niet geleerd van het verleden toen we allen een ander script ondersteunden. Toen alles elke keer anders moest. Javascript gaat nu juist een kant op dat het werkt. Dan moet er door gebouwd worden.

Wel grappig dat MS erg tegen is, maar dan wel een eigen nieuwe taal gaat bouwen met een silverlight. Dan is het wel een plugin, maar wel weer een nieuwe.

Maar dit verhaal doet wel weer erg denken aan de language tag die MS ooit begonnen is. Waar we kunnen zien met welke taal we nu net weer mee bezig zijn. Lekker IE4 opnieuw herleven. Het lijkt mij geen plan dat weer te implementeren. IE wilt backward blijven werken. Zodat de good old days geocity sites nog steeds blijven werken. Maar hoe lang moet een browser nog met depreciated rotzooi blijven werken? Firefox heeft al steeds meer oude troep te ondersteunen om meer gebruikers te trekken, maar mag MS dan wel een keer kappen met dit. Is er geen punt waar de browsers moeten zeggen dat ze moeten stoppen omdat het gewoon niet meer kan. Elke minimale webontwikkelaar weer ondertussen wel te werken met huidige standaarden. Laat die minimale groep lekker vallen.

[crisp]

Ik heb het meeste wel gezegd in voornoemde blogposts en in de reacties op het artikel zelf (waar ik bij het opstellen uiteraard zelf bij betrokken was ), maar naar mijn mening komt het hierop neer:

Microsoft heeft gewoon zijn eigen agenda en Chris Wilson is niets meer dan de 'messenger': MS is niet geinteresseerd in open standaarden (sowieso zien ze zich benadeelt door hun gigantische achterstand op dat gebied) en steekt daarom ook het liefst zo weinig mogelijk geld in de eigen implementaties daarvan. Daarentegen wordt er wel veel geld gestoken in nieuwe proprietary technologieën zoals Silverlight/XAML. Ondertussen proberen ze standaardisatie-processen zoveel mogelijk te verstoren door het verspreiden van leugens en FUD in de hoop zo hun eigen technologieën te kunnen pushen als de nieuwe de-facto standaard.

And who thought the browser-wars were over?

[ Voor 4% gewijzigd door crisp op 03-11-2007 00:53 ]

[orf]

Firefox heeft al steeds meer oude troep te ondersteunen om meer gebruikers te trekken, maar mag MS dan wel een keer kappen met dit. Is er geen punt waar de browsers moeten zeggen dat ze moeten stoppen omdat het gewoon niet meer kan. Elke minimale webontwikkelaar weer ondertussen wel te werken met huidige standaarden. Laat die minimale groep lekker vallen.

En alle bestaande sites dan?

[disjfa]

orf schreef op zaterdag 03 november 2007 @ 01:00:
[...]
En alle bestaande sites dan?

Die weten wat webstandaarde zijn? Gebruiken geen javascript meer wat in 1994 nog actueel was. Weten wat ze aan het doen zijn?

Ik heb het niet over sites die de afgelopen 5 jaar ontwikkeld zijn

[NMe]

Nou ben ik zelf geen JS-goeroe, maar als ze voor deze nieuwe versie nou eens een apart type gebruikten (<script type="text/javascript_versie_x"> ofzo ) en verder de oude JS-engine al het andere laten afhandelen, dan is er toch tijd genoeg voor die achterhaalde sites om up to date te raken?

[disjfa]

-NMe- schreef op zaterdag 03 november 2007 @ 01:10:
Nou ben ik zelf geen JS-goeroe, maar als ze voor deze nieuwe versie nou eens een apart type gebruikten (<script type="text/javascript_versie_x"> ofzo ) en verder de oude JS-engine al het andere laten afhandelen, dan is er toch tijd genoeg voor die achterhaalde sites om up to date te raken?

Dat was MS dus ook al van plan ten tijden van IE4. Daaron vind je de language tag terug in veel js code. En word tot de dag van vandaag nog steeds gebruikt door onwetende. Dat is irritant om te gebruiken en moet je niet doen

Maar waarschijnlijk als er iets nieuws bedacht word forceert MS het wel weer.

[RobIII]

-NMe- schreef op zaterdag 03 november 2007 @ 01:10:
Nou ben ik zelf geen JS-goeroe, maar als ze voor deze nieuwe versie nou eens een apart type gebruikten (<script type="text/javascript_versie_x"> ofzo ) en verder de oude JS-engine al het andere laten afhandelen, dan is er toch tijd genoeg voor die achterhaalde sites om up to date te raken?

Omdat je dan 2 (of erger: meer) engines moet gaan onderhouden en omdat de 'achterhaalde sites' dan ook niet gestimuleerd worden om 'over te gaan' want "ach, het werkt toch nog"? Zo kom je natuurlijk nooit van je brakke ouwe zooi af en moet je het tot in den treure blijven ondersteunen

Het lijkt mij nog niet eens zo'n stom idee om bijvoorbeeld (net als de 'information bar') in volgende versies van browsers het volgende te doen als er oude code wordt aangetroffen:

Warning

This site uses deprecated scripting features. To ensure the future of the web, please contact the webmaster and report this problem. Support for these features will be dropped Jan 1st, 2009.

Continue to the webpage
Read more about this notice

En dan niks geen workarounds toestaan ofzo; die bar verschijnt gewoon elke keer. Basta. Kijken hoe snel het web is 'opgeruimd'

disjfa schreef op zaterdag 03 november 2007 @ 01:12:
Daaron vind je de language tag terug in veel js code.

Even muggenziften hoor
Het is een language attribuut van het script element (of tag).

disjfa schreef op zaterdag 03 november 2007 @ 01:12:
En word tot de dag van vandaag nog steeds gebruikt door onwetende. Dat is irritant om te gebruiken en moet je niet doen

Dat het irritant is is natuurlijk geen argument. Dat het inmiddels deprecated is lijkt me een beter argument

[ Voor 73% gewijzigd door RobIII op 03-11-2007 01:52 ]

[crisp]

-NMe- schreef op zaterdag 03 november 2007 @ 01:10:
Nou ben ik zelf geen JS-goeroe, maar als ze voor deze nieuwe versie nou eens een apart type gebruikten (<script type="text/javascript_versie_x"> ofzo ) en verder de oude JS-engine al het andere laten afhandelen, dan is er toch tijd genoeg voor die achterhaalde sites om up to date te raken?

That ain't never gonna happen.

Ik quote mezelf maar vanaf de frontpage:

quote: http://tweakers.net/react...=Posting&ParentID=2275628

Versionering is een implementors nachtmerrie. Niet alleen kost het 2 keer zoveel moeite om seperate scripting-engines te ontwikkelen en onderhouden, maar je blijft ook zitten met het feit dat je de problemen in de huidige implementaties en de onderlinge verschillen dan niet oplost terwijl de huidige content op het web zeker niet zal verdwijnen en voor een groot deel ook niet aangepast zal worden.

Verder loop je het risico dat vendors op een gegeven moment de 'oude scripting engine' helemaal niet meer gaan ondersteunen waardoor hedendaagse content straks niet meer volledig toegankelijk zal zijn en ' weg zal rotten'. Het doel van standaardisering is juist om dat te voorkomen en daarom is het ook belangrijk dat nieuwe versies zoveel mogelijk backwards compatible blijven met vorige versies (afgezien van bugfixes). ECMAScript 4 placht dat ook te doen.

Het probleem van ondersteuning van oudere browsers is altijd maar een relatief tijdelijk probleem, oude content daarentegen is een bijzonder zwaarwegend probleem van niet tijdelijke aard.

Hetzelfde geldt voor HTML en voor CSS overigens. MS blijft erop hameren dat ze version identifiers nodig hebben voor HTML5, maar volgens mij snappen ze zelf donders goed dat ze door het introduceren van nieuwe 'rendermodes' gebaseerd op versienummers ze het enkel lastiger maken voor de competitie om uit te vissen wat nu precies wel en niet ondersteund wordt door Microsoft in elke rendermode, en met welke bugs rekening gehouden moet worden.
Zolang MS nog de marktleider is kunnen andere browservendors dan enkel lijdzaam toekijken hoe Microsoft ze opnieuw dwingt om hun implementaties te reverse-engineeren - standaard of geen standaard. In ieder geval houdt MS de HTML WG al 2 maanden in suspense met betrekking tot de eind augustus beloofde review van de huidige draft.

[Verwijderd]

-NMe- schreef op zaterdag 03 november 2007 @ 01:10:
Nou ben ik zelf geen JS-goeroe, maar als ze voor deze nieuwe versie nou eens een apart type gebruikten (<script type="text/javascript_versie_x"> ofzo ) en verder de oude JS-engine al het andere laten afhandelen, dan is er toch tijd genoeg voor die achterhaalde sites om up to date te raken?

code:

<script type="application/javascript;version=1.8">

?

wordt dus gedaan...

voor e4x (grootste syntax-in-de-war schopper) heb je

code:

<script type="text/javascript; e4x=1">

[ Voor 9% gewijzigd door Verwijderd op 03-11-2007 01:44 ]

[crisp]

Verwijderd schreef op zaterdag 03 november 2007 @ 01:42:
[...]

code:

<script type="application/javascript;version=1.8">

?

wordt dus gedaan...

dat is vziw een tijdelijke switch voor experimental features

[NMe]

RobIII schreef op zaterdag 03 november 2007 @ 01:26:
[...]

Omdat je dan 2 (of erger: meer) engines moet gaan onderhouden en omdat de 'achterhaalde sites' dan ook niet gestimuleerd worden om 'over te gaan' want "ach, het werkt toch nog"? Zo kom je natuurlijk nooit van je brakke ouwe zooi af en moet je het tot in den treure blijven ondersteunen

Ik had het dan ook over een overgangsperiode om developers de tijd te geven om te updaten. Met zo'n balkje erbij (zoals je hierboven zelf hebt verzonnen ) zou dat in een perfecte wereld een prima oplossing zijn. Maar ik zie, zeker na het relaas van crisp hierboven, ook wel in waarom MS daar geen trek in heeft.

[Alex)]

Ik kan me Microsoft's houding wel voorstellen... als ze in IE 8 (of IE 9) ineens een totaal nieuwe scriptengine introduceren die een hele hoop oude zaken breekt zijn heel veel mensen not amused. Het herschrijven van bestaande websites en internet/intranet-applicaties zal heel veel geld kosten, wat verhaald zal worden op MS. Zij introduceren immers een nieuwe scriptengine waardoor 80 tot 100% van de bezoekers niet meer met de applicatie kan werken.

Microsoft heeft in het verleden foute keuzes gemaakt en ik geloof ze als ze zeggen dat ze willen proberen om hun fouten te herstellen. Doordat ze de grootste zijn, hebben ze het wel het moeilijkste... ze kunnen het zich niet veroorloven om zomaar de boel om te gooien omdat ze dan echt het web breken.


Stel dat Microsoft een brandstofleverancier is, en een eigen formule hanteert. Ze houden de formule geheim, maar de prijs stukken lager dan de concurrentie. Alleen auto's van een paar merken (Daihatsu en Fiat bijvoorbeeld) kunnen rijden op Microsoft-brandstof, de rest kan er niet op rijden. Het is inderdaad niet netjes, maar het is wel zo gegroeid.

Na een aantal jaar lopen de verkopen bij Microsoft (en Fiat en Daihatsu) terug, en besluit men om over te gaan naar de standaardbrandstof die anderen ook verkopen. Als Microsoft al hun brandstof meteen zou vervangen door de standaardbrandstof, zullen vele auto's met stukken komen te staan. Daarom moet er een oplossing bedacht worden voor dit probleem: het voeren van twee verschillende soorten brandstof tot de oude auto's in z'n geheel zijn afgeschreven. Een proces van jaren.

De enige manier om onderscheid te krijgen tussen "oude" MS-only Fiat's en hun jongere broertjes die op standaardbrandstof lopen, is door een duidelijk verschil aan te brengen. Een ander aansluitsysteem is geen optie omdat je dan een zelfde situatie krijgt (weer auto's die alleen bij MS kunnen tanken).

Een eenvoudig aan te brengen verschil is een versienummer. Nieuwere auto's krijgen een 2 (of een 4 of 5) opgeplakt, de pompbediende zal moeten opletten of hij een bepaalde auto de juiste brandstof geeft. Een enorme rompslomp waarbij fouten gemaakt zullen worden, en er moeten ook 2x zoveel tankinstallaties moeten worden onderhouden... maar een betere oplossing is er niet.

[crisp]

Alex) schreef op zaterdag 03 november 2007 @ 04:45:
Ik kan me Microsoft's houding wel voorstellen... als ze in IE 8 (of IE 9) ineens een totaal nieuwe scriptengine introduceren die een hele hoop oude zaken breekt zijn heel veel mensen not amused. Het herschrijven van bestaande websites en internet/intranet-applicaties zal heel veel geld kosten, wat verhaald zal worden op MS. Zij introduceren immers een nieuwe scriptengine waardoor 80 tot 100% van de bezoekers niet meer met de applicatie kan werken.

ECMAScript versie 4 is zo opgezet dat deze backwards-compatible is met ES3, dus waarom zouden bestaande applicaties dan opeens breken?

Microsoft heeft in het verleden foute keuzes gemaakt en ik geloof ze als ze zeggen dat ze willen proberen om hun fouten te herstellen. Doordat ze de grootste zijn, hebben ze het wel het moeilijkste... ze kunnen het zich niet veroorloven om zomaar de boel om te gooien omdat ze dan echt het web breken.

Dat is een zienswijze, maar een andere zienswijze is dat het web al 'gebroken' is; immers zijn alle pagina's en applicaties die gebaseerd zijn op MS proprietary technologieën of die misbruik maken van bugs in MS' implementaties al in meer of mindere mate niet toegankelijk in non-IE browsers.
Tel daarbij op de kosten en moeite die gepaard gaan met het crossbrowser maken van websites en applicaties, en de problemen voor andere browservendors om hun browsers toch zoveel mogelijk 'compatible' te maken met IE's quirks dmv reverse-engineering en je moet wel inzien dat dit al jaren een onwenselijke situatie is. Jaren waarin MS geen donder heeft gedaan om die situatie ook maar enigszins substantieel te verbeteren.

Stel dat Microsoft een brandstofleverancier is, en een eigen formule hanteert.

Please, bespaar me de analogieën, die lopen toch altijd mank.

Als Microsoft zo begaan is met open standaarden laat ze dan hun eigen implementaties eerst maar eens fixen. Ik denk niet dat het fixen van de bugs in hun ES3 implementatie zo'n grote impact zal hebben (DOM, HTML en CSS is een ander verhaal). Ga developers en andere browservendors echter niet opzadelen met extra werk omdat je zelf stiekum je eigen proprietary technologie wilt blijven pushen. Opt-in zou moeten gelden voor de MS-manier, niet voor de standaard manier, dan leg je het probleem ook neer bij diegene die het veroorzaakt heeft en frustreer je de adoptie van open standaarden niet.

[Fuzzillogic]

Wel opvallend is dat ze (MS met name) kijken welke vorm van scripting de minste moeite vergt om te implementeren, en niet wat uiteindelijk voor de (professionele) webdevelopers het prettigst is om mee te werken.
Terwijl m.i. de moeite van implementatie, hoeveel dat ook is, compleet verbleekt met de hoeveelheid moeite die de uiteindelijke gebruikers van de taal/implementatie erin steken. De baggere HTML/CSS/DOM/JS-implementatie van de huidige IE-versies is een treffend voorbeeld hiervan.

Een soortgelijk spelletje zie je nu met HTML5 ontstaan. Relatief makkelijk te implementeren, want het gaat gewoon door met tag-soup-parsing. Het weglaten van version identifier verzekert dat browserbouwers in de toekomst niet alsnog voor grote wijzigingen komen te staan.

Maw: browserbouwers zouden zich eens veel meer moeten richten op de ontwikkelaars die hun product als platform gebruiken. Ik zou veel liever zien dat er een compleet nieuw platform komt, dat hooguit wat cherry-picking doet van de huidige systemen, dan dat we blijven doormodderen met HTML5 en Javascript voor het maken van websites en webapps.

[Mei]

Het verbaast me soms nog dat er discussies nodig zijn wat MS en standaarden betreft. MS bewijst keer op keer maar weer dat ze gewoon voor de big bucks willen gaan en niet voor kwaliteit. OOXML, Implementatie van technieken in IE, nu met de ontwikkeling van Javascript. Elke keer weer gaan ze niet overleggen, maar proberen ze hun eigen (slecht gedocumenteerde en niet op kwaliteit gebouwde) formaten erdoor te rammen. Een heerlijke MS-bash, maar ze hebben het aan zichzelf te danken. Als ik heel eerlijk moet zijn, denk ik dat MS toch zijn eigen zin doordrijft wat JS betreft en kunnen de andere ontwikkelaars beter naar hun eigen gezonde verstand luisteren. De nieuwe standaard wordt anders alleen nog meer vertraagd om niks.

Ik heb een tijdje terug iets gelezen over MS versus Netscape over de toekomst van JS. Netscape had mooie voorstellen om classes eindelijk eens goed te implementeren en dergelijke. Stond me iets van bij dat MS het weer compleet anders wilde doen. Dat is dus wat ik net ook al zei. MS wil het élke keer weer anders doen en negen van de tien keer is het slecht gedocumenteerd en dergelijke.

//edit: Even op hierboven reageren: HTML5 was volgens mij juist bedoelt om de hele soup minder te maken. Het werd strenger, net zoals XHTML, en simpeler, zodat code overzichtelijker en consistenter wordt. Het nadeel van version ID's is zoals net ook al gezegd dat browsers steeds meer engines nodig hebben (en dat wil je zeker bij IE niet) en je op die manier webdevvers ook niet dwingt moderne technieken te gebruiken. Soms is het noodzakelijk, maar als je door kan bouwen op wat je hebt zonder nadelen, dan moet je dat gewoon doen.

[ Voor 19% gewijzigd door Mei op 03-11-2007 14:40 ]

[crisp]

Fuzzillogic schreef op zaterdag 03 november 2007 @ 13:57:
Wel opvallend is dat ze (MS met name) kijken welke vorm van scripting de minste moeite vergt om te implementeren, en niet wat uiteindelijk voor de (professionele) webdevelopers het prettigst is om mee te werken.
Terwijl m.i. de moeite van implementatie, hoeveel dat ook is, compleet verbleekt met de hoeveelheid moeite die de uiteindelijke gebruikers van de taal/implementatie erin steken. De baggere HTML/CSS/DOM/JS-implementatie van de huidige IE-versies is een treffend voorbeeld hiervan.

Volgens mij snijdt je hier twee punten aan; in de eerste plaats de moeite die developers zich moeten getroosten omdat huidige technologieën simpelweg niet interoperable geimplementeerd zijn. Dat is zeker een valide punt, maar dat is geen argument voor het andere punt dat je impliceert, namelijk dat diezelfde technologieën ontoereikend zouden zijn.

Een soortgelijk spelletje zie je nu met HTML5 ontstaan. Relatief makkelijk te implementeren, want het gaat gewoon door met tag-soup-parsing. Het weglaten van version identifier verzekert dat browserbouwers in de toekomst niet alsnog voor grote wijzigingen komen te staan.

Ik denk dat je de meest algemene use-case voor HTML vergeet, namelijk dat mensen ermee moeten werken en mensen maken nu eenmaal fouten. Een markup taal zonder (al dan niet gedefinieerde) error-correctie voorziet niet in die behoefte, en een UA die niet in staat is op een vergevende manier met markup op het web om te gaan zal zich nooit kunnen verheugen op een substantieel marktaandeel.

Daarnaast is versionering (met afwijkende behaviour in elke versie) een potentiele interoperability nachtmerrie, om nog maar niet te spreken over wat dat in de verre toekomst voor gevolgen gaat hebben voor oude content.

Maw: browserbouwers zouden zich eens veel meer moeten richten op de ontwikkelaars die hun product als platform gebruiken. Ik zou veel liever zien dat er een compleet nieuw platform komt, dat hooguit wat cherry-picking doet van de huidige systemen, dan dat we blijven doormodderen met HTML5 en Javascript voor het maken van websites en webapps.

Ik zie dat soort uitspraken wel meer, maar wat ik daar dan meestal bij mis is een uitgebreid voorstel van hoe zo'n platform er dan uit zou moeten zien. We hebben natuurlijk wel al wat alternatieven zoals Flash/Flex en Silverlight, maar dat zijn oplossingen die slechts beperkt bruikbaar zijn. Het zijn geen alles-omvattende oplossingen, niet in de laatste plaats omdat het proprietary technologieën zijn, maar ook omdat ze weer allerlei problemen met zich meebrengen mbt toegankelijkheid en gebruiksvriendelijkheid...

[Fuzzillogic]

crisp schreef op zaterdag 03 november 2007 @ 23:18:
[...]

Ik denk dat je de meest algemene use-case voor HTML vergeet, namelijk dat mensen ermee moeten werken en mensen maken nu eenmaal fouten. Een markup taal zonder (al dan niet gedefinieerde) error-correctie voorziet niet in die behoefte, en een UA die niet in staat is op een vergevende manier met markup op het web om te gaan zal zich nooit kunnen verheugen op een substantieel marktaandeel.

Ik vind dat met de hedendaagse IDE's geen argument meer. Al tijdens het invoeren van de code wordt de syntax gecontroleerd door IDE's. Een puntkomma vergeten, element niet afgesloten, verkeerd type variabele gebruikt en je wordt met een rood kringeltje erop gewezen. Bijvoorbeeld: het aantal 'parse errors' dat ik van PHP naar m'n kop krijg gegooid (haakjes en puntkomma's vergeten e.d.) is vrijwel tot 0 gereduceerd sinds ik een bruikbare PHP-IDE gebruik.

Sterker, ik pleit juist van het uitbannen van de uitzonderingen die het 'vroegah' makkelijker zouden moeten maken. Geen optionele puntkomma's meer na een statement als er verder niks meer komt op die regel. Gewoon ALTIJD een puntkomma. Simpel, duidelijk.

Een nieuw webplatform moet niet als doelstelling hebben dat ook tante Bep ermee aan de slag kan. Het moet een gedegen, professioneel platform worden waar professionals met flink wat know-how snel en eenvoudig goede en toegankelijke webapps kunnen maken. Tante Bep kan gewoon haar websitejes maken met de vele tools die daar inmiddels voor zijn.

Daarnaast is versionering (met afwijkende behaviour in elke versie) een potentiele interoperability nachtmerrie, om nog maar niet te spreken over wat dat in de verre toekomst voor gevolgen gaat hebben voor oude content.

XML is ontzettend human-readable (tenzij je toevallig OOXML voor je neus hebt). Ook XHTML6 kun je als mens gewoon 'begrijpen'. Good enough for me. En dit punt hebben we eerder al aangekaard

Ik zie dat soort uitspraken wel meer, maar wat ik daar dan meestal bij mis is een uitgebreid voorstel van hoe zo'n platform er dan uit zou moeten zien. We hebben natuurlijk wel al wat alternatieven zoals Flash/Flex en Silverlight, maar dat zijn oplossingen die slechts beperkt bruikbaar zijn. Het zijn geen alles-omvattende oplossingen, niet in de laatste plaats omdat het proprietary technologieën zijn, maar ook omdat ze weer allerlei problemen met zich meebrengen mbt toegankelijkheid en gebruiksvriendelijkheid...

Klopt, ik constateerde ook slechts. Maar als ik een voorzetje mag doen:

• Weg met SGML, of welk castraat daarvan dan ook. Gewoon XML met namespaces. Duidelijk, zeer simpel te parsen.
• Echte GUI-widgets voor webapps, in hun eigen namespace. Dus toolbars, date pickers, panels, menu's, combo boxes. Een enorme boost voor toegankelijkheid en gebruiksvriendelijkheid. XUL is een prima voorbeeld!
• Fatsoenlijke graphics mark-up language, in zijn eigen namespace (Goh ehhh, SVG?!) Bij voorkeur ook 3D (a la VRML, maar dan minder antiek)
• Ditch javascript in zijn huidige vorm. Er zijn weinig hardware platformen tegenwoordig die NIET in staat zijn om een full-fledged JIT-compiling runtime met uitgebreide en veelzijdige RT-library, zodat je niet telkens het wiel hoeft uit te vinden. Script-taal hoeven niet helemaal te verdwijnen, het kan erg handig zijn voor RAD.
  De nieuwe programmeeromgeving moet natuurlijk eenvoudig de XML-DOM kunnen manipuleren en handige tools hebben voor XHTML, XUL, SVG e.d.
  Een Java-gebaseerd/achtige oplossing lijkt mij ideaal.
• Maak van een webpagina/webapp weer een gestructureerde package. De hedendaagse PHP en Javascript-IDE's hebben de grootste moeite om te bepalen welke classes/methods/functions er beschikbaar zijn, omdat de plaatsen waar files geinclude kunnen worden echt veel te obscuur is (bijv: in een javascript kun je weer een andere library 'includen' door in de HTML-DOM een extra <script />-element te prikken. Een IDE kan daar niet mee omgaan!)
• Ditch weak-typing als 'primair systeem'. Echt. Weg ermee. Eventueel een 'variant'-type om weak-typed-variabele te kunnen gebruiken.

[Alex)]

Je hebt een aantal mooie punten, Fuzz, maar dat je per sé een IDE zou moeten gebruiken stoot mij eigenlijk tegen de borst. Ik werk het liefste met Notepad (of een variant) of nog erger: met nano. Maar verder heb je een goede ideeën (vooral over die widgets), en zou ik je best willen helpen met campagne voeren voor je plannen

[ Voor 4% gewijzigd door Alex) op 04-11-2007 00:04 ]

[djiwie]

Je hoeft toch niet persé een IDE te gebruiken? XML, XSLT e.d. kun je ook gewoon in Notepad schrijven, alleen moet je dan goed opletten dat je geen foutjes maakt. Het is alleen 10x makkelijker in een goede IDE.

Verder: goede ideeën. Ik vrees alleen dat Microsoft voorlopig niet mee gaat werken.

[Toolskyn]

Weg met SGML, of welk castraat daarvan dan ook. Gewoon XML met namespaces. Duidelijk, zeer simpel te parsen.

Opzich mee eens, ware het niet dat het grootste gedeelte van de webpagina's niet gemaakt wordt door een webguru, maar door een simpele gebruiker, en die schrikt zich helemaal kapot als hij een dikke vette xml parse error krijgt, met als gevolg ergernis, met als gevolg 'pech gehad, dan maar niet'-reacties en dat lijkt me een slecht idee voor het web. Dat HTML bestaat heeft niets te maken met luiheid, het vervult gewoon de behoefte om iets simpels dat niet gelijk zeurt als het niet helemaal goed is.

Echte GUI-widgets voor webapps, in hun eigen namespace. Dus toolbars, date pickers, panels, menu's, combo boxes. Een enorme boost voor toegankelijkheid en gebruiksvriendelijkheid. XUL is een prima voorbeeld!

Lijkt me ook absoluut geen slecht idee. Grootste probleem lijkt me dat users een website dan te snel kunnen gaan vertrouwen, een gewone applicatie geeft veel mensen toch een soort van vertrouwen wat zeker bij websites vaak niet gegrond is. M.a.w.: er moet nog wel een of ander element (ik heb het niet over een HTML element) zijn waardoor het duidelijk is dat het om een website gaat.

Fatsoenlijke graphics mark-up language, in zijn eigen namespace (Goh ehhh, SVG?!) Bij voorkeur ook 3D (a la VRML, maar dan minder antiek)

Helemaal mee eens!

Maak van een webpagina/webapp weer een gestructureerde package.

Wel mee eens, maar ik vraag me wel af hoe je je dat dan voorstelt? Hoe wil je mensen forceren om een bepaalde structuur aan te houden?

Een Java-gebaseerd/achtige oplossing lijkt mij ideaal.

We willen wel graag eenvoudige standaarden, maar eentje extra kan er nog wel even bij. Dus dan krijgen we er nog een <program></program> tag bij? Nee bedankt, 1 taal om dynamische dingetjes te doen bij de client lijkt me meer dan genoeg, tenzij je natuurlijk zoiets bedenkt zodat elke programmeertaal in principe gebruikt kan worden (in het idee van .NET) lijkt het me een slecht idee om nog maar weer eens een nieuwe taal te introduceren.

Ditch weak-typing als 'primair systeem'. Echt. Weg ermee. Eventueel een 'variant'-type om weak-typed-variabele te kunnen gebruiken.

Welk nadeel heeft het voor jou dan? Ok, in javascript zijn ze gewoon puur dom geweest door de concat en optellen operators allebei een + te laten zijn, dat is gewoon enorm stom en dom. Maar verder zie ik geen echt probleem? Je input moet je toch wel controleren, of het nou een int, string of var in het algemeen is, dus ik zie echt geen verschil met weak-typing en strong-typing qua extra werk.

[eghie]

Fuzzillogic schreef op zaterdag 03 november 2007 @ 23:55:
[...]

Ik vind dat met de hedendaagse IDE's geen argument meer. Al tijdens het invoeren van de code wordt de syntax gecontroleerd door IDE's. Een puntkomma vergeten, element niet afgesloten, verkeerd type variabele gebruikt en je wordt met een rood kringeltje erop gewezen. Bijvoorbeeld: het aantal 'parse errors' dat ik van PHP naar m'n kop krijg gegooid (haakjes en puntkomma's vergeten e.d.) is vrijwel tot 0 gereduceerd sinds ik een bruikbare PHP-IDE gebruik.

Sterker, ik pleit juist van het uitbannen van de uitzonderingen die het 'vroegah' makkelijker zouden moeten maken. Geen optionele puntkomma's meer na een statement als er verder niks meer komt op die regel. Gewoon ALTIJD een puntkomma. Simpel, duidelijk.

Een nieuw webplatform moet niet als doelstelling hebben dat ook tante Bep ermee aan de slag kan. Het moet een gedegen, professioneel platform worden waar professionals met flink wat know-how snel en eenvoudig goede en toegankelijke webapps kunnen maken. Tante Bep kan gewoon haar websitejes maken met de vele tools die daar inmiddels voor zijn.

Dit bevorderd wel de kwaliteit van de websites, omdat de kwaliteits eisen gewoon hoger liggen.

Klopt, ik constateerde ook slechts. Maar als ik een voorzetje mag doen:

• Weg met SGML, of welk castraat daarvan dan ook. Gewoon XML met namespaces. Duidelijk, zeer simpel te parsen.

Voor browsers zou dit wel een opluchting zijn. XML met namespaces is een stuk beter te parsen dan SGML achtig iets. Ook voor tante bep is dit een voordeel, aangezien de IDE's/WYSIWYG-editors er ook beter mee kunnen omgaan, omdat het ook beter te parsen is voor hun. Dit geeft betere kwaliteits sites, die via WYSIWYG editors zijn gemaakt.

• Echte GUI-widgets voor webapps, in hun eigen namespace. Dus toolbars, date pickers, panels, menu's, combo boxes. Een enorme boost voor toegankelijkheid en gebruiksvriendelijkheid. XUL is een prima voorbeeld!

Ben ik helemaal een voorstander van. Ik heb me nog altijd "verbaasd" dat er bijvoorbeeld nog geen date/time picker bestond in standaard HTML.

• Fatsoenlijke graphics mark-up language, in zijn eigen namespace (Goh ehhh, SVG?!) Bij voorkeur ook 3D (a la VRML, maar dan minder antiek)

Misschien 2D en 3D dezelfde taal houden, wat wel zo handig is. Mij lijkt het beste om SVG uit te bereiden met 3D ondersteuning.

• Ditch javascript in zijn huidige vorm. Er zijn weinig hardware platformen tegenwoordig die NIET in staat zijn om een full-fledged JIT-compiling runtime met uitgebreide en veelzijdige RT-library, zodat je niet telkens het wiel hoeft uit te vinden. Script-taal hoeven niet helemaal te verdwijnen, het kan erg handig zijn voor RAD.
De nieuwe programmeeromgeving moet natuurlijk eenvoudig de XML-DOM kunnen manipuleren en handige tools hebben voor XHTML, XUL, SVG e.d.
Een Java-gebaseerd/achtige oplossing lijkt mij ideaal.

Wat maakt dat voor verschil met Javascript? Je kunt ook de library uitbereiden die Javascript ondersteund. Hoef je ook niet de hele tijd het wiel opnieuw uit te vinden. Uiteraard kun je JAVA applets (blijven) gebruiken. Uiteraard lijkt het me wel handig om vanuit een JAVA applet je DOM te kunnen manipuleren.

• Maak van een webpagina/webapp weer een gestructureerde package. De hedendaagse PHP en Javascript-IDE's hebben de grootste moeite om te bepalen welke classes/methods/functions er beschikbaar zijn, omdat de plaatsen waar files geinclude kunnen worden echt veel te obscuur is (bijv: in een javascript kun je weer een andere library 'includen' door in de HTML-DOM een extra <script />-element te prikken. Een IDE kan daar niet mee omgaan!)

Het mooiste is, dat ECMAscript 4 support krijgt voor iets als (in PHP) require_once. Scheelt een hoop gedonder met je IDE. Ook is het makkelijker met het gebruik van Javascript in je HTML-achtige documentje, want je hoeft maar 1 bestand te includen.

• Ditch weak-typing als 'primair systeem'. Echt. Weg ermee. Eventueel een 'variant'-type om weak-typed-variabele te kunnen gebruiken.

Zowieso moet concat en optel teken elkaar niet in de weg gaan zitten. Vind ik een beetje jammer nu. Ik ben ook meer een voorstander van strong-typed. Is al een stuk validatie opzich. Daarnaast weet je gewoon waarmee je werkt. Overigens is het met ES4 ook de bedoeling dat het strong typed met variant-type begint te worden. Dus bij strings is dan een + concat en bij int kun je altijd nog casten naar string voor concat en anders is het gewoon optellen.

Om browser specifieke dingen aan te roepen, lijkt me ook wel handig om iets te hebben. Iets als CreateObject(). Wat je hiermee zou kunnen doen is Firefox plugins aanroepen, ActiveX in IE, Opera Widgets, etc. Dit ben ik echter nog niet echt tegen gekomen in ES4.

Volgens mij kun je met ES4 zelf niks includen, of zie ik dat over het hoofd? Zou wel handig zijn, dat hij daar ondersteuning voor krijgt. Die zich gedraagd als require_once in PHP.

Undefined mogen ze van mij ook wel null maken. Vind het jammer dat ze undefined en null apart hebben met Javascript nu. Hebben andere talen ook niet.

Ben ook niet zo weg van die dynamic properties:

JavaScript:

 dynamic class C { } 
 c = new C; 
 c.x = 37;   // adds a property 
 delete c.x; // removes it again

Dan kun je na mijn idee beter gebruik maken van een named array en dan met functies as c.getAttrib('x') en c.setAttrib('x', value). Zit je de andere variablen ook niet in de weg. Maar ik hoeft het natuurlijk ook niet te gebruiken.

Ik zie trouwens in het document van ES4 voorstel niks over ; aan het eind van de regel. Die worden zelf weg gelaten bij de voorbeelden. Die zou ik er wel in willen hebben. Ik wil geen VB achtige taal. Echter in de wiki staan ze bijvoorbeeld wel bij de voorbeelden. Dus ga er vanuit dat ze er wel in komen.

[Verwijderd]

eghie schreef op zondag 04 november 2007 @ 12:22:

Ik zie trouwens in het document van ES4 voorstel niks over ; aan het eind van de regel. Die worden zelf weg gelaten bij de voorbeelden. Die zou ik er wel in willen hebben. Ik wil geen VB achtige taal. Echter in de wiki staan ze bijvoorbeeld wel bij de voorbeelden. Dus ga er vanuit dat ze er wel in komen.

Vergeet het maar. Een statement bestaat in de basis uit maar 1 regel. Als je meerdere statements op 1 regel wilt, moet je puntkomma's gebruiken. Maar het hoeft dus niet. En ES4 heeft nog steeds dezelfde issue betreft multiline strings. Dat gaat niet zomaar. Talen gebaseerd op ES4 moeten niet proberen om teveel op Java of PHP te gaan lijken, dat is allebei een andere tak van sport.

Overigens durf ik best te beweren dat je zelf vast ook nog weleens die puntkomma vergeet:

JavaScript:

bla = function () {
   // function body
};

[Fuzzillogic]

Toolskyn schreef op zondag 04 november 2007 @ 10:28:
[...]
Opzich mee eens, ware het niet dat het grootste gedeelte van de webpagina's niet gemaakt wordt door een webguru, maar door een simpele gebruiker, en die schrikt zich helemaal kapot als hij een dikke vette xml parse error krijgt, met als gevolg ergernis, met als gevolg 'pech gehad, dan maar niet'-reacties en dat lijkt me een slecht idee voor het web. Dat HTML bestaat heeft niets te maken met luiheid, het vervult gewoon de behoefte om iets simpels dat niet gelijk zeurt als het niet helemaal goed is.

Internet is inmiddels zijn experimentele fase wel ontgroeid. Zaken worden complexer, en we willen er steeds meer mee. Het is van groot economisch belang geworden. Commerciele websites worden niet meer gemaakt door het handige neefje, maar door professionals die een opleiding ervoor gehad hebben. Ik vind dan ook dat het webplatform zich moet richten op die professionals. Dat er dan opeens minder 'handige neefjes' zijn die zelf met HTML aan de slag gaan, soit. Misschien maar goed, een beetje het kaf van het koren scheiden. Als een groot project in 80% van de tijd gemaakt kan worden met 80% van de bugs met een grotere toegankelijkheid en eenduidigheid, dan weegt dat m.i. veel en veel zwaarder dan of het handige neefje de brui eraan geeft omdat hij geen valide XML kan schrijven.

Tante Bep kan nog steeds haar poezenpagina maken. Dat doet tante Bep nu ook al met een programma die het hele "programmeerwerk" haar uit handen neemt. Voor haar zal het dus niets uitmaken.

Wel mee eens, maar ik vraag me wel af hoe je je dat dan voorstelt? Hoe wil je mensen forceren om een bepaalde structuur aan te houden?

Simpel, anders werkt het niet. Wat is er mis mee om een bepaalde structuur op te leggen? Sterker nog: ik acht het gewenst! De mogelijkheden van IDE's voor C++, Java, C# zijn zo ontzettend veel beter dan de IDE's voor bijv Javascript en PHP. Dat is mede te danken aan de strakke structuur van deze talen.

Welk nadeel heeft het voor jou dan? Ok, in javascript zijn ze gewoon puur dom geweest door de concat en optellen operators allebei een + te laten zijn, dat is gewoon enorm stom en dom. Maar verder zie ik geen echt probleem? Je input moet je toch wel controleren, of het nou een int, string of var in het algemeen is, dus ik zie echt geen verschil met weak-typing en strong-typing qua extra werk.

Het gaat niet alleen om strings en integers. Het gaat ook om classes. Een programmeertaal moet DUIDELIJKHEID verschaffen. Ik wil aan de programmacode kunnen zien met welke types ik te maken heb. In een hedendaagse Java IDE weet de IDE al precies wat het returntype is van een method. Je krijgt een rood kringeltje als je een String in een Integer probeert te proppen. Je wordt gewaarschuwd als je een exceptie niet afvangt. En dat allemaal terwijl je typt, dus je kunt het meteen fixen. Het aantal verrassingen tijdens compilatie en nog belangrijker, tijdens uitvoeren is dramatisch verminderd.

Voorbeeld van afgelopen week in PHP:

PHP:

if (strstr($veld,'zoektekst')) {
...
}

De code binnen de if werd niet uitgevoerd, terwijl dat toch echt de bedoeling was, omdat 'zoektekst' wel degelijk voorkwam in $veld. Alleen stond zoektekst vooraan. Vat je hem? Ik was een kwartier op zoek naar deze bug.

In c# krijg je deze constructie niet eens meer gecompileerd, immers integer!=boolean. Je wordt dus gedwongen om het netjes te doen, met minder fouten als resultaat.

[eghie]

Verwijderd schreef op zondag 04 november 2007 @ 12:54:
[...]

Vergeet het maar. Een statement bestaat in de basis uit maar 1 regel. Als je meerdere statements op 1 regel wilt, moet je puntkomma's gebruiken. Maar het hoeft dus niet. En ES4 heeft nog steeds dezelfde issue betreft multiline strings. Dat gaat niet zomaar. Talen gebaseerd op ES4 moeten niet proberen om teveel op Java of PHP te gaan lijken, dat is allebei een andere tak van sport.

Overigens durf ik best te beweren dat je zelf vast ook nog weleens die puntkomma vergeet:

JavaScript:

bla = function () {
   // function body
};

Klopt ik vergeet zeker wel eens puntkomma's, zeker bij anonymous functions enzo, aangezien ik niet had verwacht dat ze daar ook moesten. Vanwege die accolades. Uiteraard is dat ook een statement, dus is opzich ook wel logisch.

Wat bedoel je precies met het volgende?:

Talen gebaseerd op ES4 moeten niet proberen om teveel op Java of PHP te gaan lijken, dat is allebei een andere tak van sport.

Het blijft namelijk een script taal. Een taal gebasseerd op ES4 heeft dezelfde "problemen" die een taal als PHP en JAVA ook hebben. Dus waarom zouden ze geen dingen uit Java of PHP mogen afkijken, om die "problemen" op te lossen?

[Verwijderd]

crisp schreef op zaterdag 03 november 2007 @ 10:51:
[...]

ECMAScript versie 4 is zo opgezet dat deze backwards-compatible is met ES3, dus waarom zouden bestaande applicaties dan opeens breken?

Ik weet zo goed als niks van Javascript, maar volgens mij heb je het antwoord zelf al gegeven. Bestaande applicaties zijn veelal gebaseerd op JScript (de microsoft implementatie van ES3), ES4 is niet backwards compatible met JScript. Als Microsoft ES4 implementeert, breken de huidige applicaties.

Ik vind dat er in dit topic erg kortzichtig wordt geredeneerd vanuit het viewpoint van de webdeveloper. Voor zover ik het kan overzien maakt een typische website gebruik van meerdere webtechnieken; bijvoorbeeld HTML, CSS en Javascript. De ontwikkelingen in webstandaarden gaan ongelovelijk snel, het ene jaar wordt de ene techniek van een nieuwe versie voorzien en het volgende jaar de andere. Als je geen rekening houdt met versie nummering van standaarden, verwacht je dat iedereen binnen een korte overgangstermijn overstapt op de laatste versie. Dit is misschien niet zo'n probleem voor webdevelopers, maar het gros van de mensen / bedrijven gebruiken websites als middel. Niet als doel opzich zoals webdevelopers. Het is totaal onredelijk te verwachten dat bijvoorbeeld een bedrijf elk jaar hoge kosten moet maken om een webdeveloper zijn website na te laten kijken. Een website moet zonder aanpassingen kunnen blijven werken voor een aanzienlijke tijdsperiode; i.e. 5 tot 10 jaar. Niet zoals roblll zegt huidige implementaties na een extreem korte periode afschrijven. Microsoft hanteert voor eigen technologieen als .net een zelfde beleid. Microsoft forceert immers geen overstap op b.v. .net3.5. Dit stelt ze in staat om nieuwe zaken te ontwikkelen en personen en bedrijven de vrijheid te geven over te stappen op een nieuwe versie wanneer het hun uitkomt. Een zelfde model kan toch ook voor de webwereld gehanteerd worden?

Microsoft heeft aagegeven dat hun huidige implementaties van de standaarden fouten bevatten en dat ze zich in de toekomst willen beteren. Het commentaar van Brendan zegt eigenlijk: het maakt me niet uit dat het niet compatable is met JScript, zoek het maar uit. Waarom moeten er altijd van die absolute standpunten worden ingenomen en kan er niet gekeken worden naar de realiteit om daar op verder te bouwen?

De oplossing is volgens mij simpel. Werk met versies van standaarden (of heel nieuwe standaarden), zodat een bepaalde versie/standaard de andere niet uitsluit. Dit heeft het voordeel dat: 1. Het web zich kan ontwikkelen (niet gebonden aan fouten in huidige standaarden; vrijheid om dingen beter te doen) 2. Toekomstige standaarden uniform geimplementeerd kunnen worden door browsers zodat webdevelopers bij het ontwikkelen van een website zich maar aan 1 standaard moeten houden. 3. Klanten zelf kunnen kiezen wanneer ze upgraden en verzekerd zijn de werking van ontwikkelde websites over de jaren.

Het is volgens mij niet realistisch om ook maar de denken dat er ooit maar 1bepaalde versie van een standaard zal zijn in een snel ontwikkelende industrie als deze.

[Fuzzillogic]

In de softwareindustrie wordt vaak met major en minor versienummers gewerkt. Dat lijkt me voor webstandaarden eigenlijk ook wel een aardig idee. Zo kun je stellen dat Javascript 1.x altijd backwards compatible blijft, maar dat Javascript 2 de boel flink kan omgooien. Dat hoeft niet te betekenen dat een Javascript 2 interpreter/compiler niet zou kunnen omgaan met Javascript 1.x, dus het from scratch opnieuw schrijven is geen vereiste. Met versioning kun je juist de verschillen eruit pikken. De klacht dat er parallelle enignes moeten draaien en onderhouden worden lijkt me dan ook veel minder ernstig dan dat wordt voorgesteld. Hetzelfde geldt voor een XML-parser voor XHTML vs de huidige tag-soup-parsers. Bovendien komt hier nog bij dat een XML-parser veel eenvoudiger (en sneller) kan zijn, en dat alle moderne browsers deze al hebben. De resulterende DOM is toch identiek, het gaat puur om het parsen!

De hang naar backwards compatiblity is mij echt nog steeds onduidelijk. Iedereen begrijpt dat het niet redelijk is om software te schrijven die ook nog onder Windows3.11 draait. En dat software geschreven voor Windows3.11 niet zomaar meer in XP draait, dat zal ook voor weinigen een verrassing zijn. Dat een next-gen-webplatform een nieuwe browser vereist valt aan het publiek heel goed uit te leggen, want ze zijn eigenlijk al bekend met de redenen daarvoor. Bedrijven vervangen vaak toch eens in de 3-5 jaar hun website, simpelweg omdat deze niet meer voldoet aan de verwachtingen en eisen. Voor intern gebruik, waar vaker met oudere software/systemen wordt gewerkt, zou je kunnen denken aan stand-alone browsers of virtuele machines.
Als voor consument en bedrijf het wel duidelijk is dat we niet eeuwig compatible kunnen blijven, waarom dan toch die sterke drang daarnaar?

Overigens vergat ik nog wat punten voor mijn lijstje:

• De mogelijkheid om thick-client/stand alone applicaties te maken. Niet alle apps lenen hiervoor, maar een fotobewerktool voor een online album is een typisch geval van thick client. Dit soort applicaties komen in een cache te staan, waaruit ze worden verwijderd als ze enige tijd niet gebruikt worden, tenzij de gebruiker aangeeft dat ze de app willen behouden.
• Integratie met de desktop. Niet alleen een suf icoontje op het bureaublad, maar echte integratie: drag&drop, lokale bestanden, file-handlers. Voorbeeldje: de mailto:-link werkt nu niet als je puur gebruik maakt van een webmailclient. Dat vind ik belachelijk.

En valt het al op dat heel veel van deze punten eigenlijk gewoon al tijden tot de mogelijkheden behoren, met bestaande software? Er wordt nu ontzettend veel energie gestoken in EC4/WA1/HTML5, terwijl de mogelijkheden en flexibiliteit daarvan verbleken met (een combinatie van) bestaande technieken zoals XUL, XHTML, .NET en Java.

[Toolskyn]

Fuzzillogic schreef op zondag 04 november 2007 @ 13:15:Tante Bep kan nog steeds haar poezenpagina maken. Dat doet tante Bep nu ook al met een programma die het hele "programmeerwerk" haar uit handen neemt. Voor haar zal het dus niets uitmaken.

Als die tools dan in ieder geval eens wat intelligenter zijn dan de huidige troep, die extreem slechte en ook nog eens trage code uitspuugt.

Fuzzillogic schreef op zondag 04 november 2007 @ 13:15:Simpel, anders werkt het niet. Wat is er mis mee om een bepaalde structuur op te leggen? Sterker nog: ik acht het gewenst! De mogelijkheden van IDE's voor C++, Java, C# zijn zo ontzettend veel beter dan de IDE's voor bijv Javascript en PHP. Dat is mede te danken aan de strakke structuur van deze talen.
[...]
Je krijgt een rood kringeltje als je een String in een Integer probeert te proppen. Je wordt gewaarschuwd als je een exceptie niet afvangt. En dat allemaal terwijl je typt, dus je kunt het meteen fixen. Het aantal verrassingen tijdens compilatie en nog belangrijker, tijdens uitvoeren is dramatisch verminderd.

En dat is wat jij wil, andere mensen willen dat weer niet. Mij maakt het eerlijk gezegd niet heel erg veel uit. Persoonlijk werk ik even goed met elke editor, met elk OS, met elke programmeertaal (ok ok, ik heb wel mn voorkeuren, maar het maakt me uiteindelijk niet echt veel uit). Ik denk dat je altijd verschillende manieren open moet laten, voor de verschillende wensen van de gebruikers. Een simpele persoonlijke homepage heeft meer dan genoeg aan wat PHP als 'template engine', om wat uit een database te halen en dat in een pagina te stoppen. Voor een grote bedrijfswebsite of site voor je intraweb is het gebruik van een gestructureerde pagina natuurlijk veel beter.

Fuzzillogic schreef op zondag 04 november 2007 @ 16:16:Als voor consument en bedrijf het wel duidelijk is dat we niet eeuwig compatible kunnen blijven, waarom dan toch die sterke drang daarnaar?

Dat probleem zie je in elke industrie wel terug. Je merkt in elke industrie dat er niet 'opeens' een nieuwe manier is om 'het' te doen. Dat gaat altijd met kleine stapjes en met het zo min mogelijk kapot maken van oude manieren van werken etc. Uiteindelijk komt het er wel, maar het duurt vaak tientallen jaren. Ik denk dat de IT wel vaker heel erg snel vooruit wil, terwijl dat niet echt lukt.

Je ziet het al op het hardwareniveau: waarom in vredes naam zouden we nog het verschrikkelijke en hopeloos verouderde x86 gebruiken? Het is eigenlijk een slecht platform voor wat men tegenwoordig wil. Toch wordt er geen roer omgegooid. Zelfde bij Windows: waarom niet eens radicaal die beveiliging omgooien, waarom niet de structuur van het hele OS eens aanpakken? Windows Vista heeft nu die mooie beveiligingsvenstertjes, en iedereen zeurt hoe je het uit kan zetten 'want zo werk ik niet'. Zo zijn er ook meer dan genoeg voorbeelden in vrijwel elke andere industrie die je tegenkomt.

Fuzzillogic schreef op zondag 04 november 2007 @ 16:16:De mogelijkheid om thick-client/stand alone applicaties te maken. Niet alle apps lenen hiervoor, maar een fotobewerktool voor een online album is een typisch geval van thick client. Dit soort applicaties komen in een cache te staan, waaruit ze worden verwijderd als ze enige tijd niet gebruikt worden, tenzij de gebruiker aangeeft dat ze de app willen behouden.

Is opzich goed te verenigen met het idee van offline web applications. Lijkt me in ieder geval dat het heel krachtig kan zijn.

Fuzzillogic schreef op zondag 04 november 2007 @ 16:16:Integratie met de desktop. Niet alleen een suf icoontje op het bureaublad, maar echte integratie: drag&drop, lokale bestanden, file-handlers. Voorbeeldje: de mailto:-link werkt nu niet als je puur gebruik maakt van een webmailclient. Dat vind ik belachelijk.

De fantastische integratie van IE in Windows in het achterhoofd houdend, denk ik dat vooral OS-makers daar nog eens rustig de tijd voor nemen. Dus beveiliging zal een heel groot issue worden bij zoiets.

Fuzzillogic schreef op zondag 04 november 2007 @ 16:16:En valt het al op dat heel veel van deze punten eigenlijk gewoon al tijden tot de mogelijkheden behoren, met bestaande software? Er wordt nu ontzettend veel energie gestoken in EC4/WA1/HTML5, terwijl de mogelijkheden en flexibiliteit daarvan verbleken met (een combinatie van) bestaande technieken zoals XUL, XHTML, .NET en Java.

Ik denk dat dit wel te maken heeft met mn eerste punt: zoiets moet langzaam komen. Heeft dus volgens mij een hele grote overlap met je eerste punt.

[ Voor 5% gewijzigd door Toolskyn op 04-11-2007 17:03 ]

[BtM909]

Ik wil nog even een langere repliek samenstellen, maar even kort op je onderstaande punten:

Fuzzillogic schreef op zondag 04 november 2007 @ 16:16:
Overigens vergat ik nog wat punten voor mijn lijstje:

• De mogelijkheid om thick-client/stand alone applicaties te maken. Niet alle apps lenen hiervoor, maar een fotobewerktool voor een online album is een typisch geval van thick client. Dit soort applicaties komen in een cache te staan, waaruit ze worden verwijderd als ze enige tijd niet gebruikt worden, tenzij de gebruiker aangeeft dat ze de app willen behouden.
• Integratie met de desktop. Niet alleen een suf icoontje op het bureaublad, maar echte integratie: drag&drop, lokale bestanden, file-handlers. Voorbeeldje: de mailto:-link werkt nu niet als je puur gebruik maakt van een webmailclient. Dat vind ik belachelijk.

1. Dit kan straks met HTML5 en Google levert nu al API's voor offline webapps.

2. De vraag is of je dat wilt. Voor m'n gevoel maakt dit geen deur maar de gehele voorgevel open richting virussen en andere vervelende dingen

[Pelle]

* Pelle moest even reageren van BtM909

Veel is er al gezegd, dus ik houd het kort: Ik vind dat Microsoft niet moet zeuren. Jammer dan, dat 80-90% van de websites dan niet meer werkt. Is weer fijn voor ons webbouwers (tenminste, niet voor de stagairs, want die mogen de shit straks oplossen ).

Als je nooit een keer de stap durft te maken naar iets fatsoenlijks, dan blijf je verder aanmodderen en wordt de situatie alleen maar slechter. Het zou Microsoft sieren om IE8 of IE9 als standalone versie beschikbaar te maken. Laat deze een jaar lang buiten de updates van Windows, zodat webbouwers en site-eigenaren een jaar lang de tijd hebben om kritieke dingen om te schrijven naar wel-werkende code. En na dat jaar gaat de nieuwe IE het echte updates-traject in. Problem solved

[Clay]

* Clay moest ook reageren van BtM909

Onder de noemer van backwards compatibility niet meer vernieuwen is imo de dood van javascript, misschien is dat dan ook waar MS heenwil; ik iig niet. Flash is dankzij het pluginschap nu al weer bij actionscript 3 zijn, wat voor zover ik weet ook ES4 is, en daar kan ik als developer alleen maar likkebaardend naar kijken Hoe kan je ook aan de ene kant beweren dat het internet richting dikke applicaties moet gaan, en de core taal daarachter in het jaar 0 laten hangen? Die proprietary plugins zijn daar imo namelijk ook echt de oplossing niet voor.

Wat breder gezien is het eigenlijk treurig hoe langzaam browsers zich ontwikkelen. Of het nou Js, css of wat dan ook is; specs die er jaren liggen doen niets anders dan stof happen, en zodra ze een keer geimplementeerd worden is het een feature waar je niets aan hebt op een obscure browser die niemand gebruikt.

Maar het is aan alle kanten ook fout gegaan. Klanten zijn jarenlang gevoed (en nog steeds) in hun misvatting dat een site er altijd en overal hetzelfde op uit moet zien. Wat juist uitgelegd en verkocht moet worden is graceful degradability; het idee dat jouw content, danwel de beoogde functionaliteit van de app, het belangrijkst is. Daaromheen kan er vanalles wegvallen (of het nou script of css is) die niet anders doet dan bijdragen aan dat process, maar waar niks van stuk gaat als het er niet is. Niet per se of alleen voor oudere mediums, maar juist crossmediaal.

[crisp]

* crisp wil ook nog uitgebreider reageren, maar nu ook even kort:

ik denk dat het belangrijk is dat we in het oog houden dat technologieën op het web presentatie-onafhankelijk moeten blijven. Ik kijk daarom altijd met argus-ogen naar ontwikkelingen zoals Silverlight waar uiteindelijk clientside de content geen enkele semantiek heeft en doorspekt is met presentational en behavioral data. Uiteindelijk is dat een accessibility ramp. Accessibility is iets wat een uitgangspunt dient te zijn bij de ontwikkeling van technologie, niets iets wat je als een afterthought kan toevoegen. Daarom denk ik dat de huidige webtechnologie (HTML, CSS, JS) helemaal zo slecht nog niet is en nog steeds prima als basis kan dienen en waar uitbreidingen zoals WF2, microformats en nieuwe programming-paradigma's (OO en strongtyping in ES4) perfect op aan kunnen sluiten.

[user109731]

Chris Wilson heeft overigens nog een nieuwere blogpost: My opinion. Ik snap alleen niet waarom hij denkt dat ES4 slecht is voor het internet, als ES4 backwards compatible is maakt dat niet uit toch?

Maar goed, IMHO is Microsoft een wolf in schaapskleren i.c.m. open standaarden. Het gaat lijnrecht in tegen hun filosofie dat alles op Windows moet draaien, het liefst gesloten en met een lading patenten erachter. Het krachtiger maken van JS en een snelle engine ervoor maken, passen daar gewoon niet bij. MS weet denk ik ook donders goed dat een snelle, Tamarin-like JScript-omgeving in IE door Google gretig gebruikt zal worden.

Om diezelfde reden denk ik dat de engines van IE8/IE9 weinig verbetering zullen brengen. Goed, ze zullen wat extra CSS properties implementeren, er zullen bugs gefixt worden, net als in IE7, maar niet veel meer verwacht ik. Net genoeg om de thuisgebruikers en de wannabe-webdevelopers bij IE te houden. Sorry Alex), maar ik denk dat het naief is om te denken dat MS ineens pro-standards is geworden. We weten wat IE7 is geworden, ondanks die mooie beloftes. Crisp, ik snap daarom ook deze blogpost van jou niet. Je suggereert een Opera overname, maar helpen ze daarmee niet Google en co. verder in het zadel? Wil MS echt een goede, standards-compliant engine?

[crisp]

JanDM schreef op maandag 05 november 2007 @ 11:07:
Crisp, ik snap daarom ook deze blogpost van jou niet. Je suggereert een Opera overname, maar helpen ze daarmee niet Google en co. verder in het zadel? Wil MS echt een goede, standards-compliant engine?

Die suggestie was allerminst serieus bedoelt

[user109731]

crisp schreef op maandag 05 november 2007 @ 11:15:
[...]
Die suggestie was allerminst serieus bedoelt

Wat jammer, ik vond het een leuk scenario Maar wat verwacht jij dan van IE.Next? Wil MS echt een goede engine leveren, of vinden ze het wel best zo? Dat is IMHO het punt hier, in het eerste geval zal er wel een overeenkomst mbt ES4 bereikt worden, in het tweede geval zullen ze dit gaan rekken om zo lang mogelijk Mozilla, Opera en vrienden te dwarsbomen.

[Fuzzillogic]

BtM909 schreef op maandag 05 november 2007 @ 09:25:
1. Dit kan straks met HTML5 en Google levert nu al API's voor offline webapps.

WA1.0 bedoel je neem ik aan? Google Gears levert nu API's voor synchronisatie. Leuk, maar zulke basisdiensten moeten gewoon door het platform zelf geleverd worden en niet door e.o.a. library.

Bovendien gaat het veel verder dan een api'tje voor wat eenvoudige synchronisatie. Voor het offline draaien van complete applicaties ga je wel iets meer nodighebben

2. De vraag is of je dat wilt. Voor m'n gevoel maakt dit geen deur maar de gehele voorgevel open richting virussen en andere vervelende dingen

Natuurlijk (en helaas) moet beveiliging de allerhoogste prioriteit hebben. Dat was bij de ontwikkeling van het hedendaagse javascript niet aan de orde. De hacks die later gedaan zijn tegen XSS en andere ongein zijn niet gestandaardiseerd en vormen dus weer fijne browserafhankelijkheden voor wat wel en niet kan.

Maar om nieuwe methodes bij voorbaat al af te schrijven omdat het wel eens een magneet voor malware zou kunnen zijn lijkt mij een slechte zaak. Zo komen we nooit een serieuze stap verder.

[crisp]

Fuzzillogic schreef op maandag 05 november 2007 @ 11:54:
[...]
Maar om nieuwe methodes bij voorbaat al af te schrijven omdat het wel eens een magneet voor malware zou kunnen zijn lijkt mij een slechte zaak. Zo komen we nooit een serieuze stap verder.

Om herzieningen en uitbreidingen van huidige technologieën al bij voorbaat af te schrijven omdat het "toch allemaal kut is" (mijn interpretatie) lijkt mij een slechte zaak.

Ik ben niet overtuigd van de toegevoegde waarde van strictere syntax (geforceerd door draconische errorhandling, dus minder toegankelijk), en je kent mijn standpunt: markup is niet te vergelijken met een programmeertaal en dient te allen tijde toegankelijk te zijn, ongeacht fouten in de syntax. Error-correctie moet dus gedefinieerd zijn en backwards-compatibility is van groot belang.

Je praat hier over content, over kennis en inzichten, over alles wat het heden beschrijft en van belang kan zijn voor de toekomst. Wij kunnen nu nog aan de hand van oude geschriften ons een beeld vormen van oude beschavingen, maar als over 100 jaar onze hedendaagse digitale documenten niet eens meer geparsed kunnen worden omdat niemand meer weet hoe dan is alles van onze huidige beschaving verloren. Dat klinkt dramatisch, maar is een reëel risico.

Fuzzillogic schreef op zaterdag 03 november 2007 @ 23:55:
[...]

Klopt, ik constateerde ook slechts. Maar als ik een voorzetje mag doen:

• Weg met SGML, of welk castraat daarvan dan ook. Gewoon XML met namespaces. Duidelijk, zeer simpel te parsen.

XML is een data-interchange formaat en heeft van zichzelf geen universele semantiek. Verder zijn namespaces vaak onnodige complicaties voor simpele toepassingen. Draconische error-handling is vaak onwenselijk.

• Echte GUI-widgets voor webapps, in hun eigen namespace. Dus toolbars, date pickers, panels, menu's, combo boxes. Een enorme boost voor toegankelijkheid en gebruiksvriendelijkheid. XUL is een prima voorbeeld!
• Fatsoenlijke graphics mark-up language, in zijn eigen namespace (Goh ehhh, SVG?!) Bij voorkeur ook 3D (a la VRML, maar dan minder antiek)

Zoals ik al eerder aangaf moet je ervoor waken dat je het web zelf niet gaat zien als een visueel medium, daarmee breek je juist toegankelijkheid en gebruiksvriendelijkheid af. WebForms 2 en <canvas> bieden overigens al mogelijkheden in deze richting zonder afbreuk te doen aan dit principe (en zijn onderdeel van HTML5).

• Ditch javascript in zijn huidige vorm. Er zijn weinig hardware platformen tegenwoordig die NIET in staat zijn om een full-fledged JIT-compiling runtime met uitgebreide en veelzijdige RT-library, zodat je niet telkens het wiel hoeft uit te vinden. Script-taal hoeven niet helemaal te verdwijnen, het kan erg handig zijn voor RAD.
  De nieuwe programmeeromgeving moet natuurlijk eenvoudig de XML-DOM kunnen manipuleren en handige tools hebben voor XHTML, XUL, SVG e.d.
  Een Java-gebaseerd/achtige oplossing lijkt mij ideaal.

Tamarin?

• Maak van een webpagina/webapp weer een gestructureerde package. De hedendaagse PHP en Javascript-IDE's hebben de grootste moeite om te bepalen welke classes/methods/functions er beschikbaar zijn, omdat de plaatsen waar files geinclude kunnen worden echt veel te obscuur is (bijv: in een javascript kun je weer een andere library 'includen' door in de HTML-DOM een extra <script />-element te prikken. Een IDE kan daar niet mee omgaan!)

Volgens mij beschrijf je hier eerder een gebrek binnen IDE's dan een probleem an sich. Een meer universele methode om clientside code te includen zou handig zijn, maar dit argument is niet bijster sterk.

• Ditch weak-typing als 'primair systeem'. Echt. Weg ermee. Eventueel een 'variant'-type om weak-typed-variabele te kunnen gebruiken.

EcmaScript versie 4 dus?

[Fuzzillogic]

crisp schreef op maandag 05 november 2007 @ 23:39:
[...]

Om herzieningen en uitbreidingen van huidige technologieën al bij voorbaat af te schrijven omdat het "toch allemaal kut is" (mijn interpretatie) lijkt mij een slechte zaak.

Soms moet je slopen voor nieuwbouw en is renovatie zinloos.

...

Over veel punten hebben we het al eens gehad (HTML: keep the legacy of toch naar XHTML?). Laten we niet in herhaling vallen, dan komen toch alleen maar dezelfde argumenten naar boven.

Tamarin?

Kende ik nog niet. Het lijkt erop dat Tamarin 'enkel' een VM is, terwijl ik doelde op veel meer dan dat. Het gaat mij ook om de beschikbare (en gestandaardiseerde!) libraries.

Daarnaast is Tamarin eigenlijk niet meer dan een customprojectje van Mozilla. Ik wil dat niet afzeiken ofzo, maar waar het web mee gediend is, is een zeer breed gedragen standaard die niet door 1 bedrijf wordt opgedrongen aan de rest. Java en .NET hebben deze nadelen dus wel.

Ik had het over "Java-achtige", waarbij ik een taal + RT-omgeving bedoel die lijkt op Java (of .NET.. whutevah) maar die dan ook gestandaardiseerd wordt door bijv ECMA, ISO of W3C. Veel bedrijven hebben last van het 'not invented here'-syndroom, en zullen geen dingen gebruiken die door de 'concurrent' zijn ontwikkeld. Daar moeten we van af.

Volgens mij beschrijf je hier eerder een gebrek binnen IDE's dan een probleem an sich. Een meer universele methode om clientside code te includen zou handig zijn, maar dit argument is niet bijster sterk.

Pas sinds kort komen er redelijke javascript- en PHP IDE's op de markt, terwijl IDE's voor C, C++, Java van een vergelijkbaar niveau al veel en veel langer bestaan. En die IDE's voor C, C++ en Java steken nu weer met kop en schouders boven Javascript uit met veel betere debugging-mogelijkheden en ondersteuning voor de programmeur (refactorting, type checking, profiling etc). M.i. heeft dat heel veel te maken met het gebrek aan goede structuur binnen Javascript.

EcmaScript versie 4 dus?

Nee. EC4 heeft optionele strong-typing, terwijl ik veel meer zie in optionele weak-typing, of liever nog: afwezigheid van weak-typing.

[Verwijderd]

Fuzzillogic schreef op dinsdag 06 november 2007 @ 10:17:

Nee. EC4 heeft optionele strong-typing, terwijl ik veel meer zie in optionele weak-typing, of liever nog: afwezigheid van weak-typing.

Daar gaat je backward compatibility... Het idee is juist dat je met ES4/AS3/JS2 in principe gewoon de bestaande scripts moet kunnen interpreteren. Alle "toevoegingen" van de nieuwere talen maken daarbij verder niet uit. Het "oude content" probleem is hiermee opgelost, op voorwaarde dat zometeen elke browser wél ondersteuning gaat bieden voor de nieuwere versies.

Kortom, als je ineens de engine zo verandert dat het uitgangspunt strong-typing is, zijn in één keer alle bestaande scripts broken, en is het hele backward compatibility verhaal een non-issue.

Dat bestaande browsers c.q. scripting engines niet met "nieuwe" scripts kunnen omgaan lijkt me sowieso al helder.

Strong-typing is ook een feature die de geavanceerde developer wel zal willen gebruiken voor een framework/codebase. Voor eenvoudige functies wil je je niet vermoeien met types.

[Icelus]

Van Slashdot:

ECMAScript 4.0 Is Dead
"Brendan Eich, creator of the JavaScript programming language, has announced that ECMA Technical Committee 39 has abandoned the proposed ECMAScript 4.0 language specification in favor of a more limited specification dubbed 'Harmony,' or ECMAScript 3.1. A split has existed among the members of this committee, including Adobe and Microsoft, regarding the future of what most of us know as JavaScript. Adobe had been promulgating their ActionScript 3 language as the next ECMAScript 4.0 proposal. As some point out, the split that has prevented this may be the result of Microsoft's interests. What does the future hold for Mozilla's Tamarin Project, based on Adobe's open source ActionScript virtual machine?"

[Clay]

Dat ziet er meteen wel heel negatief uit Dood, ... dood, wat is er nou dood, en is dat wel zo slecht eigenlijk? Als je het verhaal van Brendan leest ziet het er eigenlijk best constructief uit.

Check ook:
http://ejohn.org/blog/ecmascript-harmony/

En nog een boeiende:
http://joshblog.net/2008/...ny-affect-actionscript-3/

Misschien gebeurt er nou eindelijk eens wat

[ Voor 6% gewijzigd door Clay op 17-08-2008 12:36 ]

[Icelus]

‘Let’-keyword: (oud keyword met nieuwe betekenis):
Why is there a "let" statement in JavaScript 1.7?

[Verwijderd]

Breken met het huidige web is voor Microsoft een publicitaire ramp. Dat zal nooit gebeuren. Persoonlijk zie ik het probleem van een DOCTYPE switch echt niet. Door een nieuwe browser te ontwikkelen, die getriggerd kan worden m.b.v. een DOCTYPE switch, is het eenvoudig om het huidige web niet te breken. Ondersteuning voor de oude browser kan gestopt worden zodat je niet dubbel aan het onderhouden bent. Op die manier voorkom je dat oude meuk breekt. De nieuwe browser kan vervolgens gebruik maken van de laatste standaarden, zonder zich zorgen te hoeven maken om het huidige web te breken.
Ontwikkelaars die nieuwe state of the art webapplicaties willen maken, zullen dan automatisch voor de nieuwe browser ontwikkelen. Alleen je browser wordt twee keer zo groot, omdat je impliciet twee browsers verscheept. De beste oplossing gezien het feit dat het huidige web toch niet gebroken zal worden door Microsoft.
Wanneer na een aantal jaar uit metingen blijkt dat de oude browser haast niet meer getriggerd wordt, is het mogelijk om de ondersteuning eruit te slopen. Die paar geocities sites die dan kapot gaan, maakt niemand zich druk over. Net zoals niemand zich nu nog druk maakt over het feit dat een paar antieke dos games niet meer vlekkeloos werken.