Apple, Google, Microsoft en Mozilla gaan samenwerken aan webstandaard

Apple, Google, Microsoft en Mozilla gaan samenwerken aan een webstandaard om code te compileren op het web. Dankzij WebAssembly moeten sites sneller laden. Ontwikkelaars kunnen in eerste instantie code schrijven in C en C++.

Ontwikkelaars van Mozilla, Apples Webkit, Microsofts Edge-browser en Chromium werken samen aan WebAssembly, zegt Mozilla. Daarmee heeft het initiatief de grootste browserbouwers achter zich. Samen hebben de browsers van Mozilla, Microsoft, Google en Apple het leeuwendeel van de markt voor browsers, aangenomen dat ondersteuning voor WebAssembly in alle browsers van de bedrijven zal zitten.

WebAssembly is een methode voor het compileren van code op het web via bytecode. De bedrijven zullen de mogelijke toekomstige standaard ook ontwerpen met een browser voor mobiel en het internet-of-things in het achterhoofd, blijkt uit de gestelde doelen. WebAssembly heeft overeenkomsten met het huidige asm.js. De bedrijven claimen javascript niet te willen vervangen.

De engineers zijn nog niet al te ver met de ontwikkeling van WebAssembly. Wanneer het klaar zal zijn en in browsers zal zitten, is vooralsnog onduidelijk.

Reacties (120)

[anargeek]

NodeJS (en bijv. React) brengt javascript naar de server, dit brengt de servertaal naar de frontend. De tijden dat frontenders alleen HTML, CSS & Javascript moeten kennen komt ten einde.

Ik moest direct denken aan asm.js, en blijkbaar was die gedachte correct aangezien WebAssembly een soort doorborduurproject is op asm.js als ik Brendan Eich goed begrijp

[JoepD]

Dit brengt serverside talen toch niet naar de clientside? Want PHP/Python en consorten worden toch helemaal niet betrokken in dit verhaal. Waar Javascript nu clientside gecompileerd wordt, is WebAssembly net zo goed een clientside compiler.

[Left]

Dit brengt serverside talen toch niet naar de clientside?

De samenwerking gaat ervoor zorgen dat talen als C en C++ gaan draaien in je browser. Eerst nog met asm.js als tussenstap, later direct.

Dus, talen als C en C++, die nu nog veelal op de server draaien, gaan straks in je browser werken, in de client dus.

[Reactie gewijzigd door Left op 6 augustus 2024 23:29]

[Sebazzz]

De samenwerking gaat ervoor zorgen dat talen als C en C++ gaan draaien in je browser. Eerst nog met asm.js als tussenstap, later direct

Niet helemaal correct. Het is inderdaad zo als je Emscripten gebruikt maar als je iets anders gebruikt kan het prima direct naar WebAssembly compileren in plaats van asm.js.

[anargeek]

Yup, straks kan je dus je Backend schrijven in Node.js en je Frontend in PHP

[twilex]

Tjonge, revival of Silverlight (sort of)
Maar dan met low(er) level talen als C en C++.

Silverlight - dat waren nog eens tijden!
Gewoon web client development met C# en WPF / XAML.
Werd automatisch ge-jit-compiled op de client.
Cross browser, zelfs op de Mac en remote debugging vanuit Visual Studio!

En toen kwam HTML 5 die dat alles onnodig zou maken..

Silverlight heette eerst WPF/E wat staat voor Windows Presentation Foundation Everywhere. Gelukkig heeft marketing daarna een wat slimmere naam gekozen: Silverlight.
Silverlight bevat een subset van WPF en de .NET CLR. Subset want het moest wel in de browser draaien.

[Reactie gewijzigd door twilex op 6 augustus 2024 23:29]

[Verwijderd]

Maar dan heeft Microsoft een grote standaard in eigen hand. Dat gaat hedendaags niet meer werken.

Vandaar deze "gezamenlijke" opzet. Het gaat niet om de techniek, maar om adoptie en dat het een open standaard is die gezamenlijk onderhouden gaat worden. Waarom zie je steeds vaker desktop applicaties die HTML/CSS gebruiken voor de view? Het uiterlijk van de applicatie? Omdat je weet dat het makkelijk bij te houden is en platform onafhankelijk is en ook nog eens in de browser werkt als je ooit een browser client moet maken! Men pakt hedendaags gewoon de CEF (chrome embedded framework) en bouwt daar de gehele UI in. Kan je altijd je werk weer hergebruiken voor Linux/Windows/OSX en mobieltjes / tablets op elk platform. Want elk platform heeft wel een webview. Tevens kun je je applicatie gewoon op een server draaien waardoor je al je UI hebt. Enkel de backend nog maken als deze in een andere taal gemaakt is. Of je draait in de taal die je hebt een server.

Als de grote browser makers nu gezamenlijk een standaard op zetten. Dan maak je draagvlak. Als 1 partij dat zou doen, gaan andere partijen alleen maar tegenwerken. Hierbij is samenwerking de sleutel tot succes. En zo moet het ook!

[Reactie gewijzigd door Verwijderd op 6 augustus 2024 23:29]

[Gamebuster]

Ja, heerlijk. Weg met al die 30 duizend X-to-JS compilers.

[valvy]

Enigzins jammer. Want zo komt de transparantie van het web toch een beetje ten einde.

Zo zal het onmogelijk zijn om even naar de javascript te kijken om te zien wat er gebeurt. Door zulke byte code wordt het ook onmogelijk (of verrekt lastig) om addblock plugins / andere content filters te maken.

Ik juich een alternatief van javascript toe, maar vind een gecompileerde taal voor het web niet echt een goed idee

https://github.com/WebAss.../master/HighLevelGoals.md

Edit: volgens dit artikel staat dat er een portable binary format komt. Dus het lijkt me dat compilatie niet op de client gedaan wordt. (Compilatie kan bij grote programma"s erg lang duren)

[Reactie gewijzigd door valvy op 6 augustus 2024 23:29]

[geertdo]

Enigzins jammer. Want zo komt de transparantie van het web toch een beetje ten einde

Nee, die transparantie is één van de design goals:

◦define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.

Zo zal het onmogelijk zijn om even naar de javascript te kijken om te zien wat er gebeurt.

Dat is dus niet het geval. En er zal, welke taal de bron van de bytecode ook is, ook een binding zijn met Javascript.

execute in the same semantic universe as JavaScript; allow synchronous calls to and from JavaScript;

Ik juich een alternatief van javascript toe, maar vind een gecompileerde taal voor het web niet echt een goed idee

De bytecode is ook eigenlijk geen gecompileerde, direct uitvoerbare code, maar een intermediate dat pas op het laatst machine/platform specifiek omgezet wordt.

[Verwijderd]

Het is de bedoeling dat die bytecode gecompileerd kan worden naar JavaScript. Kun je toch de code nog lezen

Ik snap niet hoe dit addblock plugins in de weg zit.

[geertdo]

Het is de bedoeling dat de bytecode interactie kan hebben met Javascript.

[twilex]

Compileren van C of C++ naar Javascript is een zinloze exercitie met weinig/geen toegevoegde waarde. Compileren naar native code is een heel ander verhaal.

[Verwijderd]

C/C++ wordt eerst gecompileerd naar bytecode.
Bytecode werkt (hopelijk)efficienter dan JavaScript op browsers die dat ondersteunen
Bytecode kan worden omgezet naar JavaScript voor browsers die dat niet ondersteunen.
Dat deze nieuwe techniek geen toegevoegde waarde heeft voor browsers die deze techniek niet ondersteunen is geen probleem.

[aadje93]

adblock omzeilen kan bijvoorbeeld door het vanaf zelfde server te vertonen (ik weet ouderwets, maar werkt wel) Image met klik werkt prima voor affiliate marketing op een site die ik beheer, impressies zie je niet (gezien ik de image zelf host), maar de kliks registreert ie wel gezien het de affiliate link is. Hierdoor is de site ook sneller gezien de image niet een extra dns call vereist.

[nlvmark]

Het is natuurlijk net zo goed mogelijk om met addblock e.d. te blijven werken. Net als nu zal addblock dan met blacklists werken en content vanaf bepaalde domeinen blokkeren. De byte code moet net zo goed die domeinen benaderen. Als je addblock dus laat meeluisteren naar je verkeer dan kunnen de add-domeinen net zo goed geblokkeerd worden.

[bogy]

bytecode wordt toch gewoon op je computer verwerkt??

je krijgt dus net zoals met java/javascript de sourcecode en een VM op je computer zal die dan uitvoeren, aangezien ALLE grote browsers erachter staan denk ik niet dat het moeilijk moet zijn voor bedrijven als adblock om bv url's of domeinnamen in de broncode te vervangen door 127.0.0.1 ...

[Niemand_Anders]

Die mogelijkheden blijven gewoon bestaan. Voor alle VM gebaseerde talen zijn decompilers beschikbaar. Maar waarschijnlijk zullen er ook wel een aantal obfuscators welke decompilatie veel moeilijker of lastiger zullen maken..

[EG Mike]

Wat is hier de business case? Hoe gaan deze grote jongens zorgen dat consumenten voor hun product kiezen als de producten van de concurrent onder de motorkap hetzelfde werkt?

[Gopher]

Even goed inlezen wat standaarden zijn.

Naast dat ze bestaan hoef je ze niet te hanteren, maar het duid bevoorbeeld zaken aan, dat wanneer een <div> neergezet wordt dat deze standaard 100% breedte heeft en als block weergave gebruikt wordt. Dat je een input het type date kunt geven is bijv. een standaard.

Niet dat het ineens op IE een input veld wordt (hoewel dit uiteraard nog steeds kan nu). Gebruik van zelfde protocollen, deze op dezelfde manier aanspreken. Nog globaler, iemand zou kunnen bedenken dat JSON een betere structuur is om websites te renderen tegenover xml, nu wordt xml gebruikt en dat is uiteraard een stuk prettiger voor de devlopers!

Het wordt dus makkelijker voor developer om cross browser comptabiliteit te bieden mits deze standaarden gevolgd worden. men kan nog steeds hier van uitwijken.

Hoe gaan ze dan concurreren? Snelheid is geen standaard, de software die je gebruikt om je product te maken staat ook niet in de standaarden, zo kan een browser in Java geschreven worden of in C++, de interface om de viewport heen staat er ook nog steeds los van (dus hoe werken tabs, welke settings heb je, waar staan deze etc.)

Tevens kun je naast deze standaarden nog steeds dingen toevoegen maar op de standaarden kun je als developer bouwen zonder bang te zijn dat deze anders werken op een ander platform .

[Reactie gewijzigd door Gopher op 6 augustus 2024 23:29]

[Jerrythafast]

JSON gebruiken in de plaats van XML/HTML lijkt me nog niet eens zo'n heel maf idee. Het doet me een beetje denken aan Vega, dat JSON gebruikt om een grafiek/visualisatie te beschijven. Vega kan van zo'n JSON in combinatie met een dataset een SVG-afbeelding renderen (lees: een XML-document opbouwen) om de aangeleverde data te visualiseren. Ik zou me heel goed kunnen voorstellen dat je iets soortgelijks kunt opzetten om de visuele elementen van een website in JSON te beschijven. Om dat dan te renderen naar HTML is natuurlijk erg inefficiënt, d'r zou dan zo'n JSON-website-parser in de browser ingebouwd moeten worden.

De kans dat een (al dan niet op JSON gebaseerd) nieuw formaat op korte termijn HTML+CSS zou gaan vervangen lijkt me erg klein, maar als iemand een niet al te ingewikkeld formaat kan verzinnen wat bijvoorbeeld inherent een 'responsive design' oplevert, eenvoudiger/efficiënter is dan HTML+CSS en verder net zo flexibel is als HTML+CSS nu zie ik het best nog gebeuren dat we op termijn een alternatief voor HTML+CSS zouden kunnen krijgen.

[Gopher]

Op zich zal het overigens meevallen, uiteindelijk bouwt je browser een dom op aan de hand van je HTML, als je inspect met chrome zie je ook vaak extra tags en alle objecten zijn door middel van de DOM te benaderen, vaak ook met javascript, laat JSON nou eens Javascript Object Notation zijn, in principe dus niet zo heel moeilijk voor te stellen dat je het zou kunnen parsen naar een web pagina.

Mijn voorbeeld was echter alleen dat als iemand een browser zou ontwikkelen die enkel JSON zou ondersteunen dat het tricky zou worden. Uiteraard zal dit niet al te snel komen. Maar ook SOAP is weg aan het vallen, en is het parseren van xml nou zo veel anders dan JSON in dit geval? Meestal zwaarder hoezo zou dit niet voor websites kunnen .

En wat dacht je van Markdown, wordt dat niet nu al gesupport door sommige browsers (Zou me niet verbazen)?

[twilex]

Flash en Silverlight waren proprietary en hebben het om die reden niet gehaald (door de ontwikkelingen van HTML 5).
Technisch gezien was Silverlight behoorlijk goed en krachtig en had het nog veel langer gebruikt en doorontwikkeld kunnen worden. Maar omdat het geen standaard was en gebaseerd was op .NET en C# was er een grote groep (open source) developers die er niet voor/mee ontwikkelde. Javascript was wat dat betreft de language of choice (maar niet altijd beter).

Wel bijzonder dat ze nu opeens met C en C++ voor de browser gaan komen terwijl de tendens juist is om higher level languages te gebruiken.

Wéér een nieuwe discontinuïteit en weer een mogelijke 'impedance mismatch'.
Twee verschillende talen door elkaar in je client side web app
(Voelt als 'inline assembly' code.)
Ik zou eerder de voorkeur geven aan Typescript voor development (superset van en compileerd naar Javascript) en een nieuwe versie van Javascript die jit compilen naar native code op de client mogelijk gaat maken. Dan heb je tenminste niet meerdere talen nodig.

[Reactie gewijzigd door twilex op 6 augustus 2024 23:29]

[HerrPino]

Dat is idd de tendens, maar persoonlijk zou ik dit direct gebruiken als het er is. Vind C#, Java etc best leuk, maar mijn hart ligt nog altijd bij C/C++. Higher level talen hebben hun voordelen, maar ook zeker nadelen. Zeker als je grotere applicaties en games wil bouwen. Het kan wel, maar echt snel wordt het nooit. Je moet wel een bizar slechte C/C++ ontwikkelaar zijn om je code net zo traag te krijgen [of misschien wel een erg goede omdat het moeilijk is] ... whatever sommige zogenaamde benchmarks ook moge beweren ... als .NET/Java en vooral JS code)

[JoepD]

Mensen kiezen over het algemeen hun browser niet op basis van de motoren onder de motorkap (voor een Tweaker/developer ligt dit anders). Het gros van de mensen kiest een browser die ze altijd al gebruikt hebben of een browser die een fijne user interface heeft etc. Het zegt de gewone consument helemaal niets of een browser op Webkit of een andere engine draait.

[Reactie gewijzigd door JoepD op 6 augustus 2024 23:29]

[Shark.Bait]

Ik dacht altijd dat het gros van de mensen de browser gebruikten die ze op hun computer aatroffen...i.e. IE bij windows, en safari bij OS X.

[Verwijderd]

Is dat anders dan het nu is? Ken jij niet-developers die zo'n hekel aan WebKit hebben dat ze liever Firefox gebruiken? De browsers onderscheiden zich in interface en het ecosysteem waar ze bij passen, niet in wat er onder motorkap zit.

Ik kan me juist voorstellen dat verdere uniformering in die engines alleen maar wenselijk voor ze is. Dan kunnen mensen ook gewoon "hun" browser gaan gebruiken voor web-apps die eerst alleen met één bepaalde browser compatible waren.

[twilex]

Mmm, IE gebruikt geen webkit en Edge ook niet.
Ze onderscheiden zich wel degelijk met wat onder de motorkap zit.
Maar dat geld uiteraard niet voor browserfabrikanten die allemaal dezelfde (niet 100% standaard) motor onder hun motorkap stoppen.
Microsoft Edge onderscheid zich wat dat betreft wél.

[raymens]

UI, net zoals dat op dit moment is.

Alle browsers hebben ook HTML5 ondersteuning maar toch hebben mensen nog voorkeuren, dat zal in dit geval niet anders zijn.

[Maurits van Baerle]

Hoewel er enige concurrentie is tussen de verschillende browsers vindt het grote gevecht op dit moment plaats tussen het WWW aan de ene kant en apps aan de andere kant.

Als het Web (en dus browsers) relevant willen blijven dan moet er voortdurend gezorgd worden dat het Web doorontwikkeld om te voorkomen dat het hele internet straks alleen nog maar over apps loopt. Apps die bovendien in de meeste gevallen maar voor twee platforms uitkomen.

Daarom zie je dus allerlei zeer geavanceerde zaken opduiken in browsers, audio en videobewerking bijvoorbeeld maar ook WebRTC om te zorgen dat messaging/VOIP/Videoconferencing niet enkel iets voor apps is.

[Pataar]

Opera gebruikt dezelfde engine als Chrome. Zij zullen dit ook krijgen neem ik aan. Wel jammer voor onder andere Dolphin en CM browser.

[anandus]

Dolphin gebruikt gewoon WebKit, volgens mij

[Bosmonster]

CM ook. Geen enkel ander bedrijf waagt zich zomaar een een custom rendering engine.

[Gopher]

Is dit jammer? Gebruiken ze iets anders? Het gaat over de standaarden, deze mogen andere browsers uiteraard gewoon volgen, een Dolphin of CM (Ken ze stiekem niet) kan gewoon zijn eigen ding blijven doen, maar als je bruikbaar wilt zijn voldoe je nu al aan de standaarden, dat browsers hier aan samenwerken betekend alleen minder diversiteit van oplossingen.

Bepaalde niet goed gedefinieerde standaarden daarbuiten gelaten uiteraard.

[Niemand_Anders]

Een standaard hoeft in principe niet gratis te zijn. Er zijn genoeg standaarden welke een betaald lidmaatschap vereisen. Denk daarbij aan bijvoorbeeld h.264, jpeg, gif, etc.

Echter gelukkig zijn de meeste standaarden voor het internet wel gratis en openbaar.

[CAPSLOCK2000]

He, waarom? Ik snap het niet, wie wil dit nou?

Ik zit hier niet op te wachten. Ik was net zo blij dat we eindelijk van Flash, Java en (bibber) ActiveX af zijn. Nu gaan ze proberen dit dode paard te reanimeren.

Ik kan me haast niet voorstellen dat die browserbouwers er aners over denken. Kan iemand uitleggen waarin deze standaard fundamenteel verschilt van Flash of Java?

Het is bemoedigend dat ze in de specs rekening houden met oude systemen en een fallback naar Javascript doen maar eerlijk gezegd verwacht ik daar niet veel van. Ten eerste zullen ze het wel moeten bouwen (de praktijk is vaak weerbastig) en ten tweede zou er wel eens een zware performance penalty aan vast kunnen zitten. Juist op oude apparaten heb je daar het meeste last van.

[Martinspire]

Enige voordeel wat ik zie ten opzichte van Flash Java en andere dingen is dat dit dan meegeleverd moet worden, waardoor er geen plugins nodig zijn. Maar verder heb ik ook niet echt het idee dat de browser-fabrikanten hier veel aandacht aan gaan besteden. Het is meer dat ze de support ooit eens gaan inbouwen dan dat ze er heftig mee gaan ontwikkelen. Ik denk dat de meesten drukker bezig zijn met Ecmascript 6 dan met dit.

Ik zie ook niet echt wat de voordelen nou zijn als ze dit willen gaan gebruiken.

[Reactie gewijzigd door Martinspire op 6 augustus 2024 23:29]

[Gamebuster]

Het voordeel hiervan is dat je, als developer, je eigen vertrouwde taal kan gebruiken en die kan compileren naar een browser bytecode, iets dat nu grootschalig gebeurt in Javascript.

Als er eenmaal een bytecode bestaat, hoef je ook niet meer te wachten tot browsers nieuwe JS versies introduceren: ECMA6 (ES6, JS6, babel, whatever) kon dan direct naar de bytecode gecompileerd worden, net zoals "classic" JS dit zou kunnen. "Niemand" wil echt Javascript gebruiken, getuige de hoeveelheid X-to-JS compilers er de grond uit schieten. Het vervelende is dat het uiteindelijk nog JS wordt.

Een browser bytecode zal ook asset minification en obfuscation overbodig maken: De compiler kan efficient "kleine" binaries genereren o.b.v. de specs van de bytecode.

Ik kan echt niet begrijpen dat men hier niet super enthousiast op reageert. Het kan web ontwikkeling op ieder gebied verbeteren.

[Martinspire]

Het voordeel hiervan is dat je, als developer, je eigen vertrouwde taal kan gebruiken en die kan compileren naar een browser bytecode, iets dat nu grootschalig gebeurt in Javascript.

Dus vanaf code x naar y gaat het straks van x naar z. Nou wat een verbetering. Dat is dus een probleem oplossen wat er niet is. Zoals ik al meldde. En waar het om gaat is dat mensen zich niet willen interesseren/specialiseren in web om daar dingen mee te doen.

Als er eenmaal een bytecode bestaat, hoef je ook niet meer te wachten tot browsers nieuwe JS versies introduceren: ECMA6 (ES6, JS6, babel, whatever) kon dan direct naar de bytecode gecompileerd worden, net zoals "classic" JS dit zou kunnen.

Je moet nog steeds ondersteuning hebben voor de bytecode. En wat als je een nieuwere versie gebruikt met nieuwe API's e.d. Volgens mij moet je nog steeds zorgen dat er een deel van de browsers de nieuwste versie draait. Vrijwel elke taal die ook dergelijke compilatie gebruikt, heeft altijd wel ergens een aanpassing waardoor het niet meer werkt (of niet optimaal) op oudere devices/browsers/platformen. Helemaal versieloos krijg je het gewoon niet, of je verliest performance, features e.d.

"Niemand" wil echt Javascript gebruiken, getuige de hoeveelheid X-to-JS compilers er de grond uit schieten. Het vervelende is dat het uiteindelijk nog JS wordt.

Wat is dat nou weer voor opmerking? hoezo is Javascript ongewenst? Kijk eens naar al die mensen die juist dingen met NodeJS doen die ook met andere talen kunnen. Waarom denk je dat er nu full-stack Javascript is? Omdat niemand dat vervolgens gaat gebruiken? Bullshit en dat weet jij ook.

Een browser bytecode zal ook asset minification en obfuscation overbodig maken: De compiler kan efficient "kleine" binaries genereren o.b.v. de specs van de bytecode.

Het maakt het niet overbodig, het verplaatst het richting een ander proces. Dat je het straks niet meer handmatig hoeft te doen omdat de compiler dat doet, maakt het niet meteen overbodig. Plus wie zegt dat dat altijd de beste oplossing is? Je krijgt te maken met hele verschillende devices, verbindingen en doelen. Daar krijg je nooit een one-size-fits-all oplossing voor.

Ik kan echt niet begrijpen dat men hier niet super enthousiast op reageert. Het kan web ontwikkeling op ieder gebied verbeteren.

Waarom niet? Enig idee hoe vaak een nieuwe "standaard" uit de grond springt om het web te "verbeteren/vernieuwen/veranderen"?

Ze stellen leuke doelen maar het is nog afwachten in hoeverre ze dat ook daadwerkelijk gaan redden. En we moeten nog maar zien of ze het zelfontwikkelde probleem ook daadwerkelijk gaan oplossen.

[Reactie gewijzigd door Martinspire op 6 augustus 2024 23:29]

[Gamebuster]

[...]
Dus vanaf code x naar y gaat het straks van x naar z. Nou wat een verbetering. Dat is dus een probleem oplossen wat er niet is. Zoals ik al meldde. En waar het om gaat is dat mensen zich niet willen interesseren/specialiseren in web om daar dingen mee te doen.

Dat is heel gebruikelijk.

Java > JVM Bytecode > Machine Code
C/C++/Obj-C > LLVM Bytecode > Machine Code
.NET > ??? + .NET runtime > Machine Code

Al die X-to-JS talen compileren naar JS, waardoor je iets krijgt als:
X > JS > ??? > Machine Code

Een browser bytecode zorgt voor iets als:
X > Browser Bytecode > ??? > Machine Code

Je moet nog steeds ondersteuning hebben voor de bytecode. En wat als je een nieuwere versie gebruikt met nieuwe API's e.d. Volgens mij moet je nog steeds zorgen dat er een deel van de browsers de nieuwste versie draait. Vrijwel elke taal die ook dergelijke compilatie gebruikt, heeft altijd wel ergens een aanpassing waardoor het niet meer werkt (of niet optimaal) op oudere devices/browsers/platformen. Helemaal versieloos krijg je het gewoon niet, of je verliest performance, features e.d.

Er zijn altijd manieren om features sub-optimaal te realiseren in een verouderd API en optimaal te realiseren voor een nieuwer API. Neem bijv. voorbeeld aan JRuby, die eerst allerlei anonymous classes moest maken voor lambda's en tegenwoordig JVM's eigen methode daarvoor kan aanroepen. Ondanks dat de JVM het zelf niet makkelijk en/of efficient ondersteunde, was het wel te realiseren. Met een request header kan een browser zijn gewenste bytecode-versie aangeven, waardoor de server de meest efficiente (of gewoon de meest compatible) versie kan serveren tijdens een overgangs-fase. Dit is allemaal prima te automatiseren.

Wat is dat nou weer voor opmerking? hoezo is Javascript ongewenst? Kijk eens naar al die mensen die juist dingen met NodeJS doen die ook met andere talen kunnen. Waarom denk je dat er nu full-stack Javascript is? Omdat niemand dat vervolgens gaat gebruiken? Bullshit en dat weet jij ook.

NodeJS brengt iets in de wereld wat je niet met andere talen kan: Dezelfde taal gebruiken op de server als op de client. Ik weet vrijwel zeker dat 20% van de serieuze NodeJS developers geen plain Javascript gebruiken, maar een of ander meta taaltje die naar JS compileert, al is het maar ES6 of JSX. Ik weet ook vrijwel zeker dat als bijv. PHP, Ruby, Python of C native ondersteund zou worden door NodeJS EN browsers, net zo goed als Javascript dat nu is, dat die talen aanzienlijk meer gebruikt zouden worden op plaatsen waar Javascript nu "noodzakelijk" is. Sterker nog, ik weet vrijwel zeker dat Javascript direct dood neer valt in dat geval.

Het maakt het niet overbodig, het verplaatst het richting een ander proces. Dat je het straks niet meer handmatig hoeft te doen omdat de compiler dat doet, maakt het niet meteen overbodig. Plus wie zegt dat dat altijd de beste oplossing is? Je krijgt te maken met hele verschillende devices, verbindingen en doelen. Daar krijg je nooit een one-size-fits-all oplossing voor.

Ik snap niet helemaal wat je probeert te zeggen. Als je dezelfde code wil sturen naar verschillende devices, waarom zou je er dan andere bytecode heen willen sturen? Sure, in extreme gevallen wil je misschien kunnen configureren of meer bytes in ruil voor betere performance gewenst is, of juist andersom, maar dat lijkt me verwaarloosbaar.

Waarom niet? Enig idee hoe vaak een nieuwe "standaard" uit de grond springt om het web te "verbeteren/vernieuwen/veranderen"?

Ik kan me niet herinneren dat alle grote browser makers samen springen om te werken aan een alternatief voor Javascript. Dit is zover ik weet een first.

Ze stellen leuke doelen maar het is nog afwachten in hoeverre ze dat ook daadwerkelijk gaan redden. En we moeten nog maar zien of ze het zelfontwikkelde probleem ook daadwerkelijk gaan oplossen.

In jouw ogen is het misschien een zelf-ontwikkeld probleem. Ik vind het idioot dat we tegenwoordig 100en programmeertalen hebben, maar dat we op het web maar vast zitten met Javascript. Ik juich een oplossing daarvoor alleen maar toe. Een goede bytecode kan bijv. toegang bieden tot byte-strings (geen utf8), echte integers of threads.

Als we willen dat het web revolutionair blijft ontwikkelen, moeten browser-makers iets verzinnen waarmee developers met hun eigen favoriete programmeertaal kunnen werken.

[Martinspire]

[...]

Dat is heel gebruikelijk.

Java > JVM Bytecode > Machine Code
C/C++/Obj-C > LLVM Bytecode > Machine Code
.NET > ??? + .NET runtime > Machine Code

Al die X-to-JS talen compileren naar JS, waardoor je iets krijgt als:
X > JS > ??? > Machine Code

Een browser bytecode zorgt voor iets als:
X > Browser Bytecode > ??? > Machine Code

zucht
Dat is niet wat ik bedoel. Of het nou van C++ naar Javascript gaat of van C++ naar deze techniek (en weer naar Javascript), als het eindresultaat hetzelfde is, wat maakt het dan nog uit?
Jij hebt het puur over de compiler en ik niet

NodeJS brengt iets in de wereld wat je niet met andere talen kan: Dezelfde taal gebruiken op de server als op de client. Ik weet vrijwel zeker dat 20% van de serieuze NodeJS developers geen plain Javascript gebruiken, maar een of ander meta taaltje die naar JS compileert, al is het maar ES6 of JSX. Ik weet ook vrijwel zeker dat als bijv. PHP, Ruby, Python of C native ondersteund zou worden door NodeJS EN browsers, net zo goed als Javascript dat nu is, dat die talen aanzienlijk meer gebruikt zouden worden op plaatsen waar Javascript nu "noodzakelijk" is. Sterker nog, ik weet vrijwel zeker dat Javascript direct dood neer valt in dat geval.

ES6 is ook Javascript, maar je zit wel lekker te speculeren zonder daadwerkelijk met getallen te komen. Je maakt gebruik van onderbuikgevoel want je stellingen zijn ook nergens in terug te vinden.
Javascript valt niet zomaar dood neer en had ook nooit zomaar dood gevallen. Er is een reden waarom Javascript populair is en nog populairder wordt. Niet alleen omdat het verplicht is op enkele platformen, maar omdat het bepaalde dingen bevat die uniek zijn. Het doet een aantal dingen raar, maar ook een heleboel goed. Zonder Javascript had het huidige web nooit zo ver geweest en hadden minder mensen interesse gehad om iets voor het web te maken. En ja, daar zijn wel bronnen van

[...]

Ik snap niet helemaal wat je probeert te zeggen. Als je dezelfde code wil sturen naar verschillende devices, waarom zou je er dan andere bytecode heen willen sturen? Sure, in extreme gevallen wil je misschien kunnen configureren of meer bytes in ruil voor betere performance gewenst is, of juist andersom, maar dat lijkt me verwaarloosbaar.

Het is duidelijk dat je niet echt doorhebt waarom er verschillende minimalisatie-technieken bestaan of dat er verschillende manieren zijn om jouw code bij de client te krijgen, anders had je me prima begrepen. Waar het om draait is dat je voor het ene toestel de focus moet leggen op een zo klein mogelijke datapackage en zo klein mogelijke load. Op de ander gaat het juist weer om de snelheid van het laden maar maakt de grootte niet uit en bij een ander is het weer dat zowel de snelheid als grootte weinig uitmaakt omdat de verbinding en hardware snel genoeg is. Jij weet ook dat veel websites het beter kunnen doen als ze sneller laden of als ze bepaalde prioriteiten aangeven. Zo'n bytecode maakt het lastig om de gebruiker alvast een eerste deel te geven, zonder de ervaring te verminderen of waarbij je aanpassingen doet naargelang het apparaat en verbinding bepaalde verlangens heeft. Compileren zoals je voor apps doet is niet hetzelfde als dat je je website geschikt maakt voor meerdere platformen. Vooral de hele groten der web zijn daar erg goed in geworden en begint een vakgebied op zich te worden.

[...]

Ik kan me niet herinneren dat alle grote browser makers samen springen om te werken aan een alternatief voor Javascript. Dit is zover ik weet een first.

Maar je weet ook niet hoeveel moeite ze doen. Als dit puur een krabbel zetten is van "wij zullen de ondersteuning ter zijner tijd invoeren" dan betekend het werkelijk helemaal niks.

[...]

In jouw ogen is het misschien een zelf-ontwikkeld probleem. Ik vind het idioot dat we tegenwoordig 100en programmeertalen hebben, maar dat we op het web maar vast zitten met Javascript. Ik juich een oplossing daarvoor alleen maar toe. Een goede bytecode kan bijv. toegang bieden tot byte-strings (geen utf8), echte integers of threads.

Als we willen dat het web revolutionair blijft ontwikkelen, moeten browser-makers iets verzinnen waarmee developers met hun eigen favoriete programmeertaal kunnen werken.

Onzin, er zijn legio andere manieren om het web naar een hoger niveau te tillen. En volgens mij moet je even kijken wat ES6 nou eigenlijk brengt, want het is juist voor programmeurs van andere talen een makkelijkere stap.

Feit blijft dat huidige webdevelopers hier niet echt op zitten te wachten en appbouwers toch liever voor een app dan site kiezen. Met een andere taal iets voor web gaan maken betreft maar een hele kleine doelgroep.

[Gamebuster]

Ik weet heel goed wat ES6 brengt, ik werk er dagelijks mee. Ik heb erg gemengde gevoelens over ES6. De class-keyword verbergt features die Javascript juist sterk maken en laat het lijken op een "class-oriented taal" als Java, terwijl dat het eigenlijk niet echt is. Los daarvan, mijn gehele codebase bestaat nu grotendeels uit "ES6 classes". De rest van de features zijn wel leuk, met name die arrow functions enzo.

Javascript heeft leuke features, maar ik blijf bij mijn punt: Als browser-bakkers via de "bytecode" de mogelijkheid bieden om zelf compilers te schrijven naar die bytecode, kan iedereen lekker zijn eigen favoriete taal gebruiken zonder dit eerst naar Javascript te vertalen. Uiteraard, nu moet je het naar die bytecode vertalen, maar via zo'n bytecode kan je makkelijk features als integer math e.d. introduceren zonder de JS spec te wijzigen.

Javascript en de bytecode kunnen dan los van elkaar door ontwikkelen. Mensen met gezond verstand hoeven hun tijd niet meer te verspillen met het uitzoeken van JS wazigheidjes en lekker hun eigen taal gebruiken.

[twilex]

ActiveX (wat eigenlijk alleen een mooiere naam is voor COM automation + wat UI) is hier een minder goed voorbeeld, daar wilde je in de browser sowieso vanaf :-)
Silverlight past hier beter maar ik ben niet 'net zo blij dat we van Silverlight af zijn'.

Een goede reden die ik voor C (en deels voor C++) kan bedenken is dat ze 'light' zijn.
C heeft bijvoorbeeld geen specifieke runtime zoals .NET CLR of Java VM nodig en dat scheelt resources. Voor toepassing op 'light' devices (IoT) kan dat voordelen hebben.
Nadeel is wel dat high-level features als een garbage collector dan ontbreken.

[Reactie gewijzigd door twilex op 6 augustus 2024 23:29]

[svennd]

Zijn we niet net gestopt met compile talen omdat ze lastiger te debuggen/ontwikkelen zijn, en dat implementaties als javascript al behoorlijk snel is en de winst naar compile talen triviaal is ?

[84hannes]

"We" zijn niet gestopt. Er zijn platformen waarop niet meer naar native code wordt gecompileert, maar zowel Java (Android) als .net/c# (Windows, Windows Phone) worden gewoon gecompileert. JavaScript wordt meestal niet gecompileert, waardoor een mens fouten veel minder snel vindt. Gelukkig zijn er verschiedene talen die naar JavaScript toe compileren, zodat de kans op fouten afneemt.

[Martinspire]

Of je hebt gewoon goede hulpmiddelen die de fouten eruit halen, ondanks dat het dan niet gecompileert wordt. Met zaken als JSHint kun je de meeste fouten eruit halen, maar ook andere tools die weten hoe de frameworks werken die je gebruikt, zijn al vergevorderd. Maar compileren gaat niet alleen om het eruit halen van fouten.

[twilex]

Tja daarom is Javascript natuurlijk ook de language of choice voor omvangrijke web applicaties.. (niet dus).

Dit is nu juist de reden waarom Microsoft Typescript heeft ontwikkeld (wat vervolgens word gecompileerd naar een Javascript versie van keuze).

Het was heel treffend dat de (Google) developers van Angular-js op Microsoft's Build conference kwamen vertellen dat Angular-js tegenwoordig volledig in Typescript wordt ontwikkeld en niet in Javascript.

[Martinspire]

Typescript is een handige extra, maar hetgeen waar het om draaide komt al in zekere zin in Ecmascript 6 te zitten (en was ook de reden dat ze eerst Atscript gebruikten). Maar alsnog blijf ik het onhandig vinden.

Verder worden er al enorm veel complexe webapps in javascript gemaakt. En nee, dat is geen spaghetticode dan. Dus ja, Javascript is al de language of choice voor een bootlading van interessante complexe indrukwekkende apps. Het is niet voor niets de populairste taal op Github

[Reactie gewijzigd door Martinspire op 6 augustus 2024 23:29]

[Left]

Nee we zijn zeker niet gestopt met gecompileerde talen, verreweg de meeste talen worden nog steeds gecompileerd. Bv Java, C#, Go, etc.

Een voordeel van je code compileren is dat het resultaat sneller uitvoerbaar is. Maar het is niet het enige voordeel: tijdens de compilatie kun je fouten in je code vinden, een groot voordeel want je hebt liever dat je in de ontwikkelfase een fout vindt dan wanneer je applicatie al draait.
En een ander (kleiner) voordeel is dat de gecompileerde code minder groot is dan de ongecompileerde versie.

De snelheidswinst naar gecompileerde talen is zeker niet triviaal. Er zijn op het web allerlei mooie benchmarks te vinden waarin Javascript redelijk in de buurt komt van Java of zelfs C. Maar als je die code goed bekijkt dan zie je dat het bepaald niet de code is die je dagelijks op je werk voor een klant zou schrijven. Het is over het algemeen zeer geoptimaliseerde en moeilijk leesbare code.
Vaak wordt Javascript zelfs eerst gecompileerd naar asm.js, dat is een subset van Javascript die door speciale engines sneller is uit te voeren. Strict genomen is dat nog steeds Javascript, maar eigenlijk is dat dus ook al gecompileerd.

[twilex]

Dat voordeel heeft vooral te maken met dat talen als C# en Java typed / type-safe talen zijn en minder met het compileren. De compilatie zorgt vooral dat het veel sneller draait.

[Verwijderd]

ff voor de duidelijkheid...
Er zijn JIT talen (Just in Time -compiled) zoals Java, c# en vb.net en consorten
er zijn script talen Javascript en Vbscript.
Het belangrijkste verschil tussen "Talen" en "Script-talen" is dat de laatste encapsuleted zijn.
D.w.z. format c:\ gaat niet met een scripttaal omdat die geen toegang heeft tot dat niveau

Applicaties en serverside code is in "echte" talen geschreven en daar kan dus ook veel mee.
Documentje opslaan, wijzigen of wissen... no problem. Sertver-side moet dat ook kunnen.
Jij sleept je emailtje naar je (web)applicatie en het wordt opgeslagen op de server.
Script talen zijn bedoeld om client-side te functioneren en moeten dus beperkt kunnen worden.

Daarvoor moet de scripttaal anders zijn als de volledige taal, als je niet als OS steeds moet gaan controleren uit welke omgeving deze instructie komt.
Javascript en gek genoeg c++/c# lijken in syntax heel veel op elkaar daarvoor is het voor ontwikkelaars prettig om die combinatie te gebruiken.

Noot: VBscript kreeg teveel rechten/mogelijkheden en word daardoor standaard geblokkeerd.

m.v.g.
Vb.net, C# developer.

[twilex]

Daarom kun je in vbscript ook COM objecten (libraries / binaries in een COM jasje) gebruiken waarmee je bv wel een format C:\ zou kunnen uitvoeren (e.e.a. afhankelijk van de security context waarbinnen het draait).

[Hatsieflatsie]

Waarom C en C++? Dat zijn talen van de jaren '80. Maak er dan gelijk gebruik van Rust ofzo, dat daarop voortborduurt.

[mashell]

Omdat C en C++ zich bewezen hebben? Maar het is zeker merkwaardig om iets wat hetzelfde doet als Java te vervangen door iets wat gebaseerd is op de voorlopers van Java.

[twilex]

Apple zal hier mogelijk de voorkeur geven aan [Objective-C]

[Niemand_Anders]

Ik denk dat je eerder moet denken aan een gelimiteerde versie van deze talen zoals C++/CLR waarbij je een redelijk vaste library (toolkit) hebt..

Aangezien client side code een steeds belangrijkere positie inneemt, is het op zich niet raar dat de stap naar een gecompileerde taal wordt gemaakt..

[gast128]

C++ wordt nog veel gebruikt. Met name als je grote applicaties of games hebt. FireFox is bv voor een groot deel in C++ geschreven. Je argument dat C++ uit de jaren 80 is doet geen recht aan de recente ontwikkelingen (C++11 en C++14).

[Martinspire]

Rust lijkt me wat te onbekend, maar er zijn inderdaad legio talen die je daar gewoon voor kunt gebruiken. Daarom vraag ik me sterk af wat de doelgroep van deze taal nou eigenlijk moet zijn en wat ze precies aan het huidige web missen (en wat niet kan of nooit zal kunnen) waardoor dit nodig is.

[wpoely86]

Zoals het er nu uitziet, gaat dit ontwikkeld worden als een backend voor de LLVM. Dat betekend ook dat elke taal die de LLVM ondersteunt, of waarvoor een converter naar LLVM IR bestaat, kan worden gebruikt.

[Martinspire]

Toen ik gister dit nieuws zag had ik al meteen de vraag "maar wat voegt het toe?". De laatste jaren is het Web een stuk volwassener en uitgebreider geworden, waardoor er met dingen als Ecmascript 5 en 6 al meer mogelijk is en met de HTML5 standaarden ook. Flash en Java e.d. zijn prima te vervangen met web. Enige wat dit bied is clientside C/C++ scripten, maar dat is dan ook echt alles.

Bij Ecmascript 6 vind ik het al een groot nadeel dat je er eigenlijk nog wel lang mee moet wachten omdat zelfs nu nog geen enkele browser het volledig ondersteund en veel browsers nog helemaal niet. Want er zitten mooie dingen in, maar ik denk dat het nog te vroeg is om ermee te beginnen. Net als dat ik denk dat AngularJS 2.x te vroeg is met de implementatie ervan. En dat is met deze techniek straks niet anders. Hoe lang tot minimaal 50% het kan gebruiken? En wanneer bereikt het een significant aandeel? Terugcompileren naar Javascript klinkt leuk, maar dan had je daar net zo goed mee kunnen beginnen.

Ik heb niet het idee dat ze een groot probleem proberen op te lossen, maar er eerst 1 creeëren om die vervolgens op te lossen. En ja Javascript is niet de mooiste of beste taal ter wereld, maar er zit zeker progressie in en valt al aardig wat mee te doen. Dit zal waarschijnlijk niets extra's bieden dan dat je met een andere taal kunt werken. Nou joepie. We zullen zien waar ze staan over een jaar, maar iets zegt me dat de browserfabrikanten hier niet hun prioriteit van gaan maken en dat het uiteindelijk bij leuke ideeën blijft.

[Reactie gewijzigd door Martinspire op 6 augustus 2024 23:29]

[trab_78]

"Wat voegt het toe?" is inderdaad een voor de hand liggende reactie. Maar als je er nog eens over nadenkt: het voegt in ieder geval keuze toe. En dat is in principe goed. Op de server kan je kiezen uit tig talen en dus de taal kiezen die het meest geschikt is voor je taak, of waar je het meest productief mee kan zijn, of welk criterium je dan ook maar stelt. Op het web kan je alleen maar kiezen uit JavaScript of JavaScript. Als dit project die keuze uitbreidt, lijkt me dat een zeer goede zaak, al moeten we er nog een paar jaar op wachten.

[Martinspire]

Keuze om de keuze is niet bepaald een nuttige toevoeging. De verschillende talen op serverside hebben elk hun voor en nadelen en dat maakt ze interessant. Dit lijkt eerder "choice for the sake of choice" en dan lijkt me dat vrij nutteloos. Het is niet alsof webtechnieken zo gruwelijk lastig zijn dat je liever bij C of C++ blijft.

[trab_78]

Ik ga er vanuit dat C en C++ slechts het begin zijn. Als je eenmaal een goede bytecode-standaard hebt, kan je in principe elke taal compileren naar die bytecode. Als die standaard er eenmaal is, kan bij wijze van spreken iedereen er een compiler voor maken. Het gaat m.i. niet om "keuze om de keuze": er is nu helemaal geen keuze, dus het is wel degelijk goed om meer keuze toe te voegen.

[Rob Coops]

Das wel heel erg kort door de bocht, gezien het nog ontwikkeld moet worden kun je er van uitgaan dat veel dingen niet toegestaan zullen worden zo als bijvoorbeeld directe interactie met microfoon, disk, camera etc...
Websites worden steeds meer simpel weg applicaties worden die je start door simpel weg de code van de cloud te downloaden en uit te voeren. Je hoeft eigenlijk geen harde schijf meer te hebben omdat opslag steeds meer verhuisd naar de cloud. Het is een kwestie van tijd voor we de adoptie van bijvoorbeeld ChromeOS flink zien groeien omdat Google het eigenlijk best wel bij het juiste eind had.

Het grote gevaar van dit soort oplossingen is dat we allemaal steeds meer afhankelijk worden van de internet verbinding. Binnen kort kan een bedrijf dan wel een overheid beslissen dat jij die leuke foto van je vakantie van vorig jaar niet meer mag zien omdat er iemand opstaat die daar over geklaagd heeft dan wel een kind net uit de zee komt met een zwembroekje op de enkels... Om maar helemaal niet over de macht van de copyright maffia te spreken die steeds meer zal proberen alle files te scannen die op de cloud worden opgeslagen want je zou misschien wel eens een achtergrond muziekje kunnen horen waar zij geen geld voor gezien hebben.
Andere opties is dat deze bedrijven de macht krijgen over wat we wel en niet kunnen doen met onze systemen omdat zij simpel weg van het een op het andere moment applicaties onbeschikbaar kunnen maken bijvoorbeeld dan wel veranderen ook als jij of ik daar niet gelukkig van word.

[anargeek]

kun je er van uitgaan dat veel dingen niet toegestaan zullen worden zo als bijvoorbeeld directe interactie met microfoon, disk, camera etc...

Browsers ondersteunen al (of binnenkort) de Camera API voor webcams en de Web Audio API voor opnemen en afspelen van audio

[virtualite]

Mits goed uitgevoerd is dit natuurlijk erg gewenst.

[Gopher]

Zolang er een standaard is die ze allemaal hanteren is het altijd goed.

Is iets omslachtig? Dan is het tenminste omslachtig voor alle browsers, als ze het allemaal netjes hanteren hoef je straks niet eens meer op verschillende browsers te testen in theorie.

Dan is dat hele gezeur van mensen die dat niet kunnen en de schuld geven aan IE ook eindelijk eens afgelopen.

Vreemd dat dit niet eerder begonnen is.

[Loller1]

als ze het allemaal netjes hanteren hoef je straks niet eens meer op verschillende browsers te testen in theorie.

Iets wat je in theorie én praktijk nooit mag doen, nu ook niet, ook niet in de voorbije jaren. Feature detection werkt even goed en is future-proof.

[Gopher]

Ben ik het ook volledig mee eens, alleen als je nu nog aan het afvangen bent of een user IE6 gebruikt dan ben je raar bezig, zo bedoel ik dat wat jij nu bedoelt 'n stuk minder nodig kan zijn in de toekomst.

Uiteraard, niet nu maar over jaren.

[Iblies]

Er is al een standaard...
En daar zitten dezelfde partijen ook bij.

De vraag is waarom ze zelf niet aan de huidige afspraken houden,
en een nieuw groep beginnen.

Een andere bron voor zorgen is dat het helemaal US-based is, en een eventuele norm niet alleen privileges zal krijgen (buy american) maar ook nog eens moeilijker te controleren zal zijn.

Edit;
Vergeten, huidige normsteller is
https://en.wikipedia.org/wiki/World_Wide_Web_Consortium
en html5 is al een tijd de nieuwe richtlijn.

[Reactie gewijzigd door Iblies op 6 augustus 2024 23:29]

[twilex]

"Zolang er een standaard is die ze allemaal hanteren"

Daar vraag je wel heel wat.
In de IT en vooral in de browserwereld schijnt dit doorgaans op veel problemen te stuiten.

[Blokker_1999]

Maar hoe ga je dit goed uitvoeren? Krijg je dan straks websites die specifiek een x86 platform nodig hebben of die enkel werken onder Windows omdat er DX calls in voorkomen. Waar is dan het platform onafhankelijke internet naar toe?

[wjvds]

Het gaat hier om bytecode, niet om native code. Dit betekent dat er nog steeds een VM tussen zit en native calls niet mogelijk (en zeker niet wenselijk, i.v.m. security) zijn.

[Rudie_V]

Volgens mij is het aan de implementatie in de browser om de code weer te vertalen richting het onderliggende platform. Ze zeggen ook dat ze niet java willen vervangen, java is ook machine onafhankelijk.
Tevens gaat het om bytecode, uit die link:

Bytecode is computer object code that is processed by a program, usually referred to as a virtual machine, rather than by the "real" computer machine, the hardware processor. The virtual machine converts each generalized machine instruction into a specific machine instruction or instructions that this computer's processor will understand.

Edit: zinnetje geschrapt.

[Reactie gewijzigd door Rudie_V op 6 augustus 2024 23:29]

[Loller1]

Ze zeggen JavaScript niet te willen vervangen, ze zeggen niks over Java.

[Rudie_V]

Ah, die heb ik dus even door elkaar gehaald, ik heb het zinnetje geschrapt.