JavaScript viert vijfentwintigste verjaardag

Het is 4 december vijfentwintig jaar geleden dat Netscape Communications en Sun Microsystems JavaScript aankondigden. De scripttaal is nog altijd bijzonder populair, bij zowel websites als programmeurs.

Netscape en Sun noemden als voordelen van JavaScript bij de aankondiging op 4 december 1995 dat de scripttaal open en crossplatform was en dat deze aanvullend op en geïntegreerd in zowel HTML als Java was. De partijen wilden er een standaard zonder licentiekosten van maken en dienden daartoe voorstellen in bij het W3 Consortium en de Internet Engineering Task Force.

In 1997 kreeg JavaScript de status van standaard door European Computer Manufacturers Association als ECMAScript, dat sindsdien de specificatie bepaalt voor interoperabiliteit. De W3C beschouwt JavaScript als een van de drie pijlers voor de webstandaard, samen met HTML en CSS.

De voornaamste ontwerper van JavaScript en ECMAScript is Brendan Eich, die ook Mozilla startte en momenteel topman is van het bedrijf achter de Brave-browser. De talen kregen enkele afgeleiden zoals JScript van Microsoft, die de naam JavaScript niet voor zijn implementatie voor Internet Explorer wilde gebruiken, en ActionScript van Macromedia, die dit integreerde in zijn Flash-software voor webtoepassingen. In 2012 kondigde Microsoft ook TypeScript aan, met uitbreidingen voor het ontwikkelen van omvangrijkere programma's.

Nog altijd is JavaScript enorm populair. Niet alleen is de scripttaal alomtegenwoordig op het web en bij tal van toepassingen, maar ook is het onverminderd populair bij ontwikkelaars. Op GitHub en Stackoverflow is het bijvoorbeeld al jaren de meestgebruikte taal, al is het bij Stackoverflow wat betreft de meest geliefde talen ingehaald door onder andere Rust, TypeScript en Python.

GitHub languages

IT-banen

Reacties (97)

Jim80 4 december 2020 22:45

Er zijn 2 soorten devs:

De scriptkiddy's: deze groep vindt type safety maar niks en de runtime moet maar zoveel mogelijk fouten onder de mat vegen (dus geen error throwen). Dat je appelen met peren mag vergelijken is immers een voordeel, want je code “compileert” vrijwel altijd “foutloos”. Vervolgens begint de miserie, de ene runtime-error na de andere en begin dan maar iemands code te debuggen en de fout die pas 10 stappen later naar boven komt te backtracen naar de eigenlijke bug.
De bit-n*****s: deze devs zweren bij gecompileerde talen met classes en type safety. Als er nog maar code ruikt naar een fout of rare constructie, wordt je door de compiler bestookt met errors en warnings. Dat vinden ze goed, want elke fout die at compile time reeds ontdekt kan worden is immers zwaar debugwerk uitgespaard. Intellisense is je vriend, je moet immers niet alle members van één of ander duister object blijven onthouden als je een jaar later nog eens in de code duikt, want een goede IDE presenteert alles mooi op een blaadje. En zodra je runtime een exception krijgt, zit je meestal direct op de plaats waar de fout zit.

De tweede groep is duidelijk niet gediend met Javascript. Het is een noodzakelijk kwaad, want het is immers de enige taal die elke browser rechtstreeks begrijpt. Gelukkig kwam toen Typescript om de pijn te verzachten. Het is nog steeds Javascript, maar met extra “decoratie” om toch type safety en class design mogelijk te maken.

Iemand van de eerste groep, de Javascript lovers, moet ooit gedacht hebben: waarom brengen we deze prachtige taal niet naar de desktop en server? En zo geschiedde: nodejs was een feit. Als een alien die plots voet aan aarde zet om zich vervolgens razendsnel te verspreiden om de rest van de wereld te veroveren.

Ik vind het jammer dat er een decennia lange evolutie van robuuste type-safe code (c++, pascal, c#, Java, ...) is afgebrokkeld sinds het ontstaan van Javascript. Computers zijn nu honderden keren sneller dan in 2000, maar toch werken heel veel applicaties vandaag trager en met veel meer fouten.

YaPP @Jim80 • 5 december 2020 10:53

Er zijn 2 soorten devs:

* De scriptkiddy's: deze groep vindt type safety maar niks [...]
* De bit-n*****s: deze devs zweren bij gecompileerde talen met classes en type safety [...]

Ik hoor bij groep nummer 3. Die het beste van beide werelden zoeken. Mensen die kijken wat het beste past in de situatie. Die niet star iets het beste vinden. Mensen die niet eindeloos code optimaliseren als het kortdurend project is (extreem voorbeeld: reclame/actiesite). Mensen die rondkijken en zien wat de wereld te brengen heeft. /sarcasm.

Je verhaal is erg binair en zwart-wit. Voor iedere situatie is er iets beter. Nu neig ik ook naar TypeScript ipv JavaScript, en Python type-hints ipv untyped, maar het is geen must. Het probleem met gecompileerde talen is dat ze soms erg log en langzaam zijn om in te werken. Dat je hele ingewikkelde constructies nodig hebt voor dependency-injection of het overrulen van iets tijdens unit tests.

Met hetzelfde budget kan je in andere omgevingen soms 2x zoveel gedaan krijgen (oud voorbeeld: Django vs ASP.NET MVC) met dezelfde kwaliteit.

[Reactie gewijzigd door YaPP op 22 juli 2024 15:39]

Jim80 @YaPP • 5 december 2020 11:21

Dat je hele ingewikkelde constructies nodig hebt voor dependency-injection of het overrulen van iets tijdens unit tests.

Zo'n contructies haat ik ook enorm, maar dat is niet eigen aan de taal he. In c# kan je ook heel simpele en overzichtelijke code maken, maar sommigen vinden het inderdaad leuk om er 7 lagen van te maken (aka lasagna-code) met elk mogelijk design pattern.

Coebergh @Jim80 • 5 december 2020 08:54

Jeetje, wat een polariserend verhaal, is dat nou echt nodig? Zullen we alstublieft proberen de maatschappelijke polarisatie die in de wereld gaande is zoveel mogelijk buiten onze prachtige, globale, open ontwikkelaarscommunity proberen te houden?

Je zet twee ogenschijnlijke groepen tegenover elkaar, zonder blijkbaar ook maar te overwegen dat er ook een heleboel devs zijn die beide systemen prima vinden, waaronder ik.

Ik zie voordelen aan beide type talen, en het bewijs dat de een niet per se beter is dan de ander, blijkt wel dat er enorm veel goede applicaties/libraries/tools voor beide bestaan.

Jim80 @Coebergh • 5 december 2020 11:13

Het is maar een mening maar he, ludiek en luchtig bedoeld om te weten hoe mede-tweakers er tegenover staan. Ik zeg niet dat de ene groep beter is dan de andere. Verschillen horen nu eenmaal thuis in elke maaschappij. Anders mag je het ook niet meer over Win / Mac gebruikers hebben, Vleeseters / Vegetariers, Man / Vrouw..... Je kan altijd wel indelingen maken, en er zijn altijd wel mensen die zich tussen de 2 aansluiten. Allemaal perfect OK en zeker niet polariserend bedoeld.

Het is niet dat C# backend devs geen beste vriendjes kunnen zijn met frontend React/JS devs

Zoals je zegt, een prachtige, globale, open ontwikkelaarscommunity maar je kan moeilijk beweren dat er daar geen verschillende meningen of groeperingen zijn. Anders zouden we allemaal in de zelfde taal programmeren.

Coebergh @Jim80 • 5 december 2020 12:13

Sorry, misschien was het nog te vroeg en in het weekend, had het niet per se als ludiek verhaal gelezen

Ik beweer zeker niet dat er verschillende mening zijn, en al helemaal niet dat die er niet mogen zijn. Als we maar naar elkaar blijven luisteren

jvo @Jim80 • 4 december 2020 23:13

Ik heb niet helemaal het gevoel dat de evolutie van de "C-lijn" afgebrokkeld is door de komst van JavaScript. (Onder de C-lijn schaar ik zelf C, C++, Java en C#) Ja, C# biedt de mogelijkheid om niet type-safe te programmeren, maar ik zie het zelf vooral als een sterke combinatie van C++ en Java. Voor mij de reden om van Java overgestapt te zijn naar C#, in sommige gevallen zijn dingen in C# naar mijn gevoel eleganter op te lossen, en dat zie ik als evolutie. (Van na de komst van JavaScript.) Maar nog steeds type-safe (ik hoor bij de tweede groep) en met alle mogelijkheden uit de voorgangers C, C++ en Java. (Ok, Java is technisch geen voorganger, maar ik heb toch echt het gevoel dat C# ook wat lessen uit Java heeft getrokken.) En, de ontwikkeling van C# is absoluut nog gaande. Bij elke nieuwe versie ben ik weer blij met de nieuwe toevoegingen.

Wat betreft de matige vertaling van computersnelheid naar programmasnelheid ben ik het eens. Dat zit hem in mijn ogen ook in gebrekkige kennis van basale algoritmes. De nieuwere talen verbergen dit ook steeds meer. Een HashSet/HashMap uit Java komt neer op een Dictionary in C#. Maar als je niet weet dat en waarom je daarmee sneller af bent dan een for loop, dan komt dat de snelheid van de code niet ten goede.

ovek @Jim80 • 5 december 2020 08:21

je werkt mss dagelijks met 1'tjes en 0'len maar daarom zijn er niet enkel twee gepolariseerde set-in-stone kampen hoor. daartussenin vind je de gulden middenweg, wat voor heel goed draaiende software zorgt, zoals dat hoort. Erg kort door de bocht vind ik je reactie, maar van een nummer 2 dev verwacht ik ook niet meer/minder 🤤

Gamebuster @Jim80 • 5 december 2020 08:27

Ik ben het eens met je hele post, tot je begon over "trager": NodeJS is niet traag, en het is zeker niet traag omdat het niet type-safe is. Type-safety heeft weinig te maken met performance.

Google's V8, waar NodeJS op gebaseerd is, is zo ongeveer de snelste scripting runtime die er bestaat. NodeJS/V8 veegt de vloer met concurrerende talen zoals Ruby, Python of PHP qua performance.

Mijn primaire kritiek op moderne JS ontwikkeling is alles wat erbij komt kijken. NPM YARN GULP WEBPACK left-pad. Packages die bestaan uit 14 regels code en 10 dependencies komen maar al te vaak voor. Het compilen van javascript naar javascript is 1 bak ellende.

De meeste trage software is gewoon omdat er gekozen is voor gemak ipv efficientie. Moderne libraries zijn geschreven om het werk van de ontwikkelaar makkelijker te maken ten koste van runtime performance. De impact op performance van dit soort libraries en frameworks is tegenwoordig veel groter dan de impact van de taal zelf.

Jim80 @Gamebuster • 5 december 2020 10:56

Klopt helemaal.... trager was niet zozeer op Javascript gericht, maar eerder op de evolutie van software in het algemeen. Maar dat was inderdaad slecht verwoord

BoomSmurf @Jim80 • 5 december 2020 00:17

Naast TypeScript ben ik zelf ook fan van Kotlin, die naast JVM en Native ook JavaScript modules als compile target heeft. Het is nog relatief jong en zeker niet perfect, maar ik heb nu wat serieuzere dingen gedaan ermee en dat werkt stiekem toch wel heel erg lekker!

En natuurlijk is er WASM, waarmee talen zoals C++/C#/Go/Python in de browser gebruikt kunnen worden. Helaas werkt dat in de praktijk ook niet perfect. Voor veel doeleinden is de snelheidswinst ook minimaal of zelfs langzamer.

Omdat ik toch aan het Kotlin fanboien vandaag: deze heeft ook een traditionele WASM target via Native, maar deze is EOL en word vervangen door een nieuwe WASM target die Garbage Collection nodig heeft; GC op WASM staat nog in de kinderschoenen, en het zal nog jaren duren voor support daarvoor gemeengoed is in browserland, helaas.

Immutable @BoomSmurf • 6 december 2020 12:17

Het is echt een slecht plan om een GC te implementeren in WASM. Een Garbage Collector is geen "least resistance" oplossing. Daarom zou het een fout zijn om die te implementeren. Daarnaast heb je een GC in echt tientallen smaakjes, welke kies je dan? een GC is heel erg opinionated en dus heel fout om te implementeren. (Voorbeeld: Unity had eerst problemen met hun GC, omdat gewoon letterlijk je beeld gaat happeren omdat de GC de volledige runtime ging stoppen, om de boel op te ruimen. Daarom heeft Unity een eigen GC geschreven voor hun C# runtime... Elke GC heeft weer een mening en elke GC heeft zijn voor en nadelen... beste? Geen GC)

Ik zeg, voor elke taal die een GC heeft, bring your own GC.
GC's zijn soms een goede oplossing, soms. Heel soms. Bij sommige algorithmes, heb je met de implementatie van een GC dus performance winst. Maar, dit is maar bij sommige algorithmes.
Wat je dus wilt is, wanneer je zo'n algorithme gaan gebruiken dat je een soort "fenced" GC can implementeren speciaal voor die algorithme. En de rest van je code geen GC bevat, omdat een GC gewoon voor performance verliest zorgt in bijna alle gevallen.

WebAssembly moet een ultra dunne laag blijven, die ook op de webserver en microcontrollers kan gaan draaien. Daarmee moet je geen toeters en bellen gaan implementeren zoals een GC. Dan is de beerput opengetrokken en zijn straks alle voordelen van die dunne VM laag weg. Dan ga je weer naar die fat ass dikke VM lagen zoals van .NET en JVM. En die hebben we al, dus willen we niet "weer" die fout maken.

De snelheidswinsten op front-end zullen inderdaad voor de reguliere webapps minimaal zijn. Maar wel aanwezig. Echter ga je naar grotere front-end applicaties zul je daar meer profijt van hebben.
Preact is sneller als React, maar mogwai een front-end framework in Rust is weer sneller als Preact. (Met Rust kun je gewoon back-end en front-end, met performance op de eerste rij zowel back als front-end. Wat wil je nog meer...)

Het staat allemaal inderdaad in de kinderschoenen. Maar dat heeft niks met de GC te maken, die moet er gewoon nooit komen. Net zoals classes in javascript er nooit had moeten komen.

[Reactie gewijzigd door Immutable op 22 juli 2024 15:39]

BoomSmurf @Immutable • 6 december 2020 13:11

Ik ben het niet met je oneens hoor. Ik heb zelf genoeg ervaring met de performance problemen die GC op kan leveren, helaas.

Maar GC gaat komen in WASM, of je het daar nu mee eens bent of niet. Aangezien Kotlin ook non-GC Native target heeft (waar voorheen dus ook WASM uitkwam) is het mij niet geheel duidelijk waarom ze de keus gemaakt hebben om een nieuwe JVM-esque WASM target met GC te gebruiken. Maar ook daar is mijn eigen mening weinig relevant, het blijft wat ze gaan doen.

Als ik het me goed herinner is het performance probleem van nu met WASM vooral dat de communicatie tussen WASM code en JS relatief traag is. Komt op termijn ook vast goed.

Immutable @BoomSmurf • 6 december 2020 16:02

Gelukkig hoef je niet te communiceren met JS, maar puur tussen WebAssembly en de browser API's zoals de DOM(HTML), CSS en de andere tientallen API's.
Zat net even te lezen over de GC plannen, het idee is inderdaad nu om een GC optioneel aan te bieden als opt-in o.i.d. ben benieuwd.

BoomSmurf @Immutable • 6 december 2020 18:03

Dat ligt maar net aan de situatie natuurlijk. Als je al een platform hebt en dat in gedeeltes over wilt zetten dan zul je toch veel met JS communiceren tot alles over is. Of als je libraries gebruikt waar nog geen WASM alternatief voor is. Het is maar net waar je mee bezig bent

Ik weet verder ook niet of de interactie met andere APIs ook performance problemen heeft, veel is natuurlijk wel gemaakt met het oog op JS. Ik ben zelf afgehaakt op WASM nadat uit wat research bleek dat het voor mijn huidige projecten in ieder geval niet de oplossing was waar ik op hoopte. Ik wacht af wat de toekomst brengt.

Immutable @BoomSmurf • 6 december 2020 18:07

Daar ben ik het zeker mee eens, het zal ook zo gauw nog niet lopen. En omdat de performance winst maar minimaal is. En het makkelijk is mensen te krijgen die front-end programmeren met de huidige frameworks zal dat eerst wel zo blijven. Gaat uiteindelijk om geld.

Begrijp dus heel goed dat wanneer je nu naar de huidige staat kijkt, het niet direct enorm grote voordelen gaat bieden.

Fluttershy @Jim80 • 5 december 2020 02:03

Te simplistische manier van denken maar als lekkere flauwe grap houden we hem er in.

GamingZeUs @Jim80 • 5 december 2020 04:46

Javascript met de nieuwe strictheden zijn er zo lelijk ingewerkt dat ik het eigenlijk algeheel niet meer leuk
vinden kan.

Het interessante van het prototypische systeem / de invlechting met het DOM is niet doorgetrokken naar een classesysteem, maar de klassesysteem dingen zijn eroverheen geshoehorned.

De uitbreidingen voor byte manipulation/buffers zijn pijnlijk om mee te werken. Wel duidelijk, maar het blijft een tikkeltje foreign. Multicore is er gelukkig als uitbreiding en werkt mooi voor batch work, maar async op multicore is nog geen ding (geen freaky mutexes) terwijl dat duidelijk leuk zou kunnen zijn.

Ik zie veel in talen die tevens vaag kunnen zijn, die mooi schalen van 'weinig spec en werkt voor dat je duidelijk hebt gemaakt' naar het hebben toegevoegd van restricties om de betrouwbaarheid ten goede te komen. Let vs Var? En het loopt door elkaar?

Python is echt een librarylijm geworden - en net als ruby is het not-fast-even-if-you-try. C#/Java zijn nog altijd uitstekende werkpaarden, maar het blijft lomp hoe alles ergens hoort, hoe je veelal driemaal hetzelfde duidelijk maakt voor het duidelijk is. Haskell nogal cryptisch, maar welzeker prachtig wat dat betreft.

Hoop sterk op meer lef bij de Js developers. En misschien een C standaard die DOM.h standardiseert zodat 'web compatible' niet meer zo magic is.

exaltion @Jim80 • 5 december 2020 07:01

Het klinkt alsof je zelf moeite hebt de taal optimaal te benutten. Natuurlijk kan het ook zo dat je gewoon een slechte ervaring hebt met oudere versies van JavaScript. Tegenwoordig is het een stuk verbeterd.

Overigens kun je ook TypeScript gebruiken als je graag types gebruikt. Werkt heel goed.

Daarbij is je opmerking wat betreft NodeJS erg kort door de bocht. Er zijn situaties waarbij het gebruik van NodeJS absoluut geen verkeerde keuze is. En voor NodeJS kun je tegenwoordig ook TypeScript gebruiken.

Je zal mij niet horen zeggen dat het allemaal perfect is of geschikt voor elke situatie, maar JavaScript en het bijbehorende ecosysteem is verre van slecht.

[Reactie gewijzigd door exaltion op 22 juli 2024 15:39]

2green @exaltion • 5 december 2020 11:10

Het klinkt alsof je zelf moeite hebt de taal optimaal te benutten. Natuurlijk kan het ook zo dat je gewoon een slechte ervaring hebt met oudere versies van JavaScript. Tegenwoordig is het een stuk verbeterd.

Je speelt nogal op de persoon. Er staat letterlijk niets in zijn reactie waardoor je kunt concluderen dat hij moeite heeft de taal optimaal te benutten. Daarnaast kent iedere gedegen opgeleide ontwikkelaar de genoemde beperkingen en problemen met schaalbaarheid (type safe, performance, etc).

Overigens kun je ook TypeScript gebruiken als je graag types gebruikt. Werkt heel goed.

Dit stond al letterlijk in zijn tekst. Als je op de persoon speelt, neem dan wel even de moeite goed te lezen aub.

Daarbij is je opmerking wat betreft NodeJS erg kort door de bocht. Er zijn situaties waarbij het gebruik van NodeJS absoluut geen verkeerde keuze is. En voor NodeJS kun je tegenwoordig ook TypeScript gebruiken.

Wat een dood doener... er zijn altijd situatie waarbij het gebruik van taal a, b of c absoluut geen verkeerde keus is. dit is een Non argument

Je zal mij niet horen zeggen dat het allemaal perfect is of geschikt voor elke situatie, maar JavaScript en het bijbehorende ecosysteem is verre van slecht.

Volgens mij noemde hij het niet slecht, tekende enkele kritische kanttekeningen. Waar hij dit specifiek onderbouwd, blijf jij erg vaag.

berchtold @Jim80 • 5 december 2020 02:13

Ik categoriseer mezelf tot groep 2. De JavaScript mutatie is gevaarlijk. Laat dat maar lekker bij de browser en gebruik het niet als webserver.

spoonman @Jim80 • 5 december 2020 10:53

Ik doe graag frontend programming, maar je hebt zeker een punt. Je hebt al libraries nodig als je gewoon zonder problemen met komma getalletjes wil rekenen

https://github.com/MikeMcl/decimal.js

kidde @Jim80 • 6 december 2020 01:41

Voor de tweede groep is er ELM.
Versimpelde Haskell die naar JS compileert. En als het compileert is het meestal gewoon goed, nooit runtime errors en null-ellende. En godzijdank geen klassen en object georiënteerde drab!

Typescript heb ik een keer bekeken, zag er toch uit als lippenstift op een varken. Net zoals folds en lambdas in Python: Het is een gammele aanbouw, die altijd herkenbaar zal blijven als zijnde niet onderdeel van het origineel.

[Reactie gewijzigd door kidde op 22 juli 2024 15:39]

Laurens-R 4 december 2020 18:35

Wel bijzonder om te zien hoe JavaScript van een “suf taaltje” in de jaren 90 waar je popups en simpele inputvalidatie mee deed nu de motor is achter ZOVEEL van een moderne web ervaring. En ja daar zitten mooie en minder mooie dingen tussen, maar niemand kan ontkennen dat het super succesvol is.

gimbal @Laurens-R • 4 december 2020 23:29

Ja eens, ik kan me de tijd nog herinneren dat ik javascript gebruikte om handige fratsen uit te halen tijdens runtime en die werkten allemaal niet omdat men het zo nodig vond om Javascript als onveilig te bestempelen en blockers te installeren.

Maar verder wel gewoon volop Flash en Java applets blijven gebruiken die uiteindelijk de echte zwarte security gaten bleken te zijn

Skit3000

@Laurens-R • 4 december 2020 22:05

Nou, ik was in de jaren 90 nog wel niet zo heel oud maar zag er vanaf mijn eerste kennismaking wel gelijk de voordelen van in ook al was het toen nog heel beperkt. Zo kon je geen XMLHttpRequests uitvoeren dus was het behelpen met je dynamische content via een iframe laden en kon je de DOM ook nauwelijks manipuleren waardoor je uiteindelijk alle HTML in JavaScript moest genereren en zelf via objecten de status daarvan bij moest houden. En dan werkte alles ook nog net wat anders in elke browser, zonder duidelijke documentatie. Nu 25 jaar later is dat de basis waar je niet eens meer over na hoeven denken na alle standaardisatie en met alle beschikbare frameworks.

De grootste stap van de afgelopen jaren in mijn ogen, is die van NodeJS. Het is heerlijk om niet meer met twee (of drie) verschillende talen te hoeven werken. Niet omdat andere talen zoveel moeilijker of minder goed zijn, maar omdat het gewoon je projecten zo veel simpeler maakt als je bijvoorbeeld client side, server side én database validatie (als je een nosql database gebruikt die overweg kan met JavaScript of Json) allemaal van exact dezelfde code gebruik laat maken. Sterker nog, nosql werkt zo goed dat mijn laatste projecten "serverloos" zijn.

g4wx3 @Skit3000 • 5 december 2020 00:19

De grootste stap van Javascript is toch wel degelijk de implementartie van XMLHttpRequests.
Nog voordat er over ajax gesproken werd, was ik hiermee aan het experimentern IE (5, 6?) (met JScript, dia andere ECMA-variant.)
Het was geweldig, en het web zou helemaal anders zijn als dat er niet was.
Deze eigenste post zou veel omslachtiger zijn geweest.
Er bestond ook VBscript, waarmee je ook al mooie apps mee kon bouwen, en uitvoeren als HTA. Nog voordat er sprake was van digital signage, had ik op zo'n systeem uitgewerkt.

Skit3000

@g4wx3 • 5 december 2020 10:04

Mee eens dat de eerste grote stap XMLHttpRequests was, ik probeerde aan te geven dat er daarvoor al een (omslachtige) manier was om data heen en weer te sturen. JScript was ook een mooie tool toen het eenmaal beschikbaar was op elke Windowsmachine en mensen het net als VBscript zo konden draaien door gewoon op het bestand te dubbelklikken. Tegelijkertijd was gaf dat ook een eerste aanzet tot worm-virussen die zichzelf vooruit konden kopiëren met elke keer een variant op e broncode waardoor virusscanners ze niet konden detecteren.

Accretion 4 december 2020 18:26

Alleen jammer dat het over de jaren heen zo'n inconsistente ramp is.

Als je zoekt hoe je een class maakt, zijn er 100'en beun oplossingen en maar een paar sources die relevant zijn.

delphium

@Accretion • 4 december 2020 18:40

Dat geldt voor zo'n beetje alle talen toch? Ik heb JavaScript nog geleerd met het O'Reilly boek. Nog altijd een prima startpunt en naslagwerk.

Cyb @delphium • 4 december 2020 20:10

Het bestaan van de term "wtfjs", zegt genoeg over hoe er regelmatig over JavaScript gedacht wordt. JavaScript is daar vrij uniek in.

Het grote voordeel van JavaScript t.o.v. andere talen, is dat alle browsers het ondersteunen, en het gestandaardiseerd is in ECMAScript. Door de komst van JSON en Google V8 heeft JS ook op de serverside ook veel terrein veroverd, en wordt het zelfs in sommige databases gebruikt.
Er zijn daardoor zelfs opleidingen waar ze alleen maar JS als taal doceren.

Maar door het winnen van terrein op dit brede vlak, komen ook de nadelen naar voren: het ontbreken van type safety is een maintenance hell op de lange termijn. Dankzij JavaScript is TypeScript groot geworden. Met name enterprise developers kiezen liever voor een veilige taal als TypeScript (of een type-safe taal die er naar kan compileren), dan een dynamic typed taal als JavaScript. Sommige grote frameworks beginnen daarom interesse te tonen in TypeScript, en zijn aan het overstappen, of overgestapt. Zie bijv. AngularJS (Angular), Node.js (Deno) en Vue. Ook in React houdt men rekening dat TypeScript steeds meer populariteit wint, en verwijst men binnen React her en der naar TypeScript als een beter alternatief. Bij de meeste grote serieuze projecten, heeft TypeScript de voorkeur boven JavaScript.

Het nadeel van TypeScript is dat het grotere leercurve heeft. Met name code met veel generic type parameters kan aardig afschrikwekkend werken op front-end designers.

GijsVos @Cyb • 4 december 2020 20:21

Enter Blazor. ;-)

SilentLucidity @GijsVos • 4 december 2020 22:02

WebAssembly is nog lang niet de oplossing

GunterO @GijsVos • 4 december 2020 22:45

.net 5.0 was voor mij een ontgoocheling. Pas .net 6.0 zal brengen wat ze voor 5.0 ooit beloofd hadden.

m0h4life @GijsVos • 4 december 2020 22:58

Hoewel ook in Blazor onder de motorkap goed gebruik gemaakt wordt van JS. Maar van wat ik er tot nu toe mee heb kunnen experimenteren is Blazor echt heerlijk en ik ben zeer benieuwd naar de toekomst ervan.

Immutable @GijsVos • 6 december 2020 12:09

Leuk blazor webassembly, waarbij je de gehele .net runtime compileert naar webassembly waardoor je dus een extra computatie laag toevoegt. Waardoor het nog veel trager wordt dan Javascript.

Is dat niet hilarisch? Heb je wel eens gezien hoe traag dat is? En dat is fundamenteel he, om dat weg te krijgen moet je helemaal af van die gehele .net runtime.

Of je spul echt compileren naar native met .Net Native o.i.d. wat misschien later ooit komt. Maar zelfs dan gaat het niet de performance krijgen van huidige talen die compileren naar webassembly.
Ik zeg troep.

[Reactie gewijzigd door Immutable op 22 juli 2024 15:39]

exaltion @Cyb • 5 december 2020 07:08

Goede toevoeging

Nitpick: Tegenwoordig spreekt men in het algemeen niet meer van "front-end designers." Dat zijn ook gewoon developers. Zeker bij banen waarbij je voornamelijk met JavaScript bezig bent t.o.v. HTML en CSS.

elmuerte @delphium • 4 december 2020 18:46

JavaScript is hier behoorlijk uniek in. Om het maar even over O'Reilly boeken te hebben. Een boek over Java, C#, C, Python, Perl, ... van 10 of 20 jaar oud is nog goed bruikbaar. Maar een JavaScript boek van 5 jaar oud en bijna compleet nutteloos omdat veel zaken fout zijn, of niet meer bruikbaar is omdat die tooling al compleet dood is.

BramV @elmuerte • 4 december 2020 19:02

Ligt dan meer aan de tools/libs die het boek gebruikt (en daar kan Javascript niets aan doen).

JavaScript never removes old features – new versions are always backward compatible.

Benieuwd naar een voorbeeld boek.

GrooV @BramV • 4 december 2020 19:50

JavaScript misschien niet maar browsers ondersteunen niet alles uiteraard

ultimasnake @GrooV • 5 december 2020 08:32

Als een browser doorgaans iets niet ondersteund in een nieuwere versie van Javascript dan voeg je voor die browser ‘polyfills’ toe. Zo kan React(-native) nog prima draaien in veel IE browsers al mag je als developer gerust de echte oudjes naast je neerleggen vind ik

[Reactie gewijzigd door ultimasnake op 22 juli 2024 15:39]

CH4OS @BramV • 4 december 2020 20:59

Vervelende is alleen dat mensen die Javascript willen leren, dat niet zo gauw doorhebben en dan dus verkeerde dingen aanleren.

elmuerte @BramV • 4 december 2020 23:54

Zonder tools en libraries is een taal niet meer waard dan z'n syntax. Veel boeken over programmeren haken ook in op deze tools en (toenmalige) populaire libraries.
Maar neem bijvoorbeeld het boek dan enver63 noemde: "Javascript: The good parts".
Hoofdstuk 4, sectie "Scope"

Unfortunately, JavaScript does not have block scope even though its block syntax suggests that it does. This confusion can be a source of errors.

Ondertussen heeft JavaScript wel een vorm van block scoping lijkt. Ook al is het een van de beste boeken over JavaScript, het stuk over scoping leert mensen nu een compleet verkeerde aanpak. De introductie van "let" is niet slechts een nieuwe language feature, het is een fundamentele verandering in de taal die een bestaande constructie vervangt. Maar omdat je in talen niet echt constructies kan weghalen bestaat het er naast. (Dit is niet een special JavaScript eigenschap dat het nooit features weghaald, geen enkele taal doet dit.) Maar tegelijk met "let" hebben ze een bizarre "const" constructie geïntroduceerd die absoluut niet strookt met de definitie van const in zo'n beetje elke andere taal.
"Javascript: The good parts". heeft verder ook een groot stuk over jslint, wat natuurlijk niet meer de tool is die je moet gebruiken. Het is ondertussen al vervangen door jshint, en nu eslint (of hebben we nu al eshint?)
JavaScript heeft gewoon veel ellende van vroeger die niet uit de taal weg te krijgen is. Maar de nogal volatile ecosystem eromheen maakt boeken/artikelen van een aantal jaar oud gewoon gevaarlijk.

enver63

@delphium • 4 december 2020 19:56

En dan had je nog het dunnere O'Reilly boek "Javascript: The good parts.".

GamingZeUs @delphium • 5 december 2020 04:47

Prototype vs Class vs Object goodluckhavefun

Martinspire @Accretion • 5 december 2020 01:30

Er is anders de laatste jaren gewoon een ECMA-Script (6) standaard waar de browserbouwers zich aan houden en waar dus ook gewoon een class is gedefinieerd. Het probleem was vooral dat oude browsers die nog niet kenden, waardoor je omwegen nodig had. Dus dit is niet zozeer een probleem van JavaScript, maar meer van gebrek aan compatibiliteit omdat veel bedrijven en consumenten veel te traag zijn met updaten.

[Reactie gewijzigd door Martinspire op 22 juli 2024 15:39]

Accretion @Martinspire • 5 december 2020 09:29

Het is gewoon raar dat een programmeertaal z'n syntax zo hopeloos veel veranderd door de jaren heen.

https://stackoverflow.com...script-and-what-are-their

Martinspire @Accretion • 5 december 2020 11:21

Hoeveel talen ken jij die in de eerste plaats na 25 jaar door miljoenen gebruikers wordt toegepast? En in de tweede plaats die het van hobbykamerproject tot multinational projecttaal heeft gebracht?

Dit is precies de reden waarom open source ook gewoon zijn nadelen kan hebben en waarbij ook die projecten wat strakker moeten worden geleid om veel fouten te voorkomen. Veel lessen die men heeft geleerd uit JavaScript, hebben andere projecten geholpen zichzelf te verbeteren en niet dezelfde fouten te maken.

Daarnaast hak je op het gebruik van klassen, maar dat heeft er dus eerst 15 jaar niet in gezeten en hoewel dat voor sommigen duidelijk een probleem is, hoeft dat voor veel projecten gewoon helemaal geen probleem te zijn. De link toont dat er meerdere manieren zijn om iets te doen en dat eigenlijk de taal heel flexibel is om dit toe te staan. Wat weer goed past bij de manier waarop het gebruikt werd door de jaren heen. Het was eerst primair bedoelt voor het dynamisch aanpassen van de opmaak. Maar doordat het zo flexibel is en op elke machine draait, is het ook gewoon geëvolueerd. Daar hoort dus ook een berg bagage bij wat niet voor iedereen prettig werkt. Ik vind het jammer om de taal daarop af te branden, want dit heeft ook gewoon zijn voordelen. Voor de typische (backend) programmeur zul je zo je kanttekeningen zetten, maar veel front-enders leren er mee werken en ik denk dat de huidige staat van de taal zich prima staande kan houden. Zoals ik aangaf is de ecmascript standaard en de samenwerking van browserbouwers om hier ook naartoe te werken (wat een beetje gestart is door de benchmark tests een tijd geleden) een positieve draai geweest voor deze taal. Maar het heeft tot die samenwerking wel te lijden gehad om een paar rare keuzes en warrige benamingen van functies. Als je nu de taal binnenstapt heb je daar wellicht wat meer moeite mee, maar ook daar is gewoon aan te wennen. Als ik zie hoe projecten nu worden opgezet ivm 20 jaar geleden, dan kan ik alleen maar concluderen dat we al veel grote stappen hebben gezet en dat de komende jaren nog wel wat grote dingen gaan gebeuren (als veel devices weer eens up2date zijn), want gebrek aan support is voor JavaScript de laatste jaren het grootste struikelblok geweest. De wil om te veranderen is er wel, maar als de markt niet meebeweegt, dan gebeurt er nog niks.

daantje.nl @Accretion • 4 december 2020 18:29

Dat is de reden dat ik nu TypeScript gebruik.

Immutable @daantje.nl • 4 december 2020 19:29

Dit is de reden waarom ik nu webassembly gebruik.

vickypollard @Immutable • 4 december 2020 19:45

Ik schakel handmatig de transistors. Enige manier om zeker te zijn dat het goed gaat.

Ablaze @vickypollard • 4 december 2020 20:43

Webassembly gebruiken is niet low level. Je compileert het met een taal als Go, Rust, Python, C++, C# enzovoorts.

Immutable @Ablaze • 6 december 2020 11:30

C++ is een beetje te low level, en gaat niet echt handig om met web achtige zaken.(Het wil zeker wel!, maar het is makkelijker om front-end webframework elegant te bouwen in een andere taal) En Go, Python en C# hebben een garbage collector. De reden waarom Rust een match made in heaven is met WebAssembly.

[Reactie gewijzigd door Immutable op 22 juli 2024 15:39]

Fluttershy @vickypollard • 4 december 2020 20:32

Handmatige transistoren?

Dus... Knopjes?

ToolBee @Fluttershy • 5 december 2020 01:47

Nee, die schakeldingetjes in je CPU vermoed ik.

GamingZeUs @vickypollard • 5 december 2020 04:48

3d print Lego flippers voor m'n programmagatenplakken.

Rojod @Accretion • 4 december 2020 21:53

Kijk eens naar het JS boek van Jon Duckett. Deze boeken worden zelfs op HBO studies gebruikt, maar was er daarvoor al fan van.

yor111 4 december 2020 18:30

Is typescript niet Javascript? Of een super set

roysijnesael @yor111 • 4 december 2020 18:32

Is een superset inderdaad. Zorgt er voor dat je OO kan programmeren.

TheAcentra @roysijnesael • 4 december 2020 19:01

Met JavaScript ED6 kan je ook OO programmeren.

Het voor van TupeScript is dat de variabele types MOET initiëren.

Maakt functions, methods en Classes overzichtelijker en als je een class of function aanroept, kan je direct zien wat voor types variabelen verwacht woorden.

TypeScript wordt met tsc naar JavaScript gecompileerd.

Ikheetchris @TheAcentra • 4 december 2020 20:34

JavaScript is vanaf het begin al een Object-Geörienteerde programmeertaal geweest. In plaats van classes (voor de EcmaScript 6 specificatie althans) werkt het met prototypes.

Om een slecht voorbeeldje te geven:

function Persoon(naam) {
this.naam = naam;
}

Persoon.prototype.groet = function() [
alert("Hallo, ik ben " + this.naam);
}

var jan = new Person("Jan");
jan.groet(); // "Hallo, ik ben Jan"

// NederlandsPersoon
function NederlandsPersoon(naam) {
Persoon.call(this, naam);
}

NederlandsPersoon.prototype = Object.create(Persoon.prototype);
var klaas = new NederlandsPersoon("Klaas");
klaas.groet(); // "Hallo, ik ben Klaas"

function FransPersoon(naam) {
Persoon.call(this, naam);
}

FransPersoon.prototype = Object.create(Persoon.prototype);
FransPersoon.prototype.groet = function() {
alert("Bonjour, je m'appelle " + this.naam);
}

var pierre = new FransPersoon("Pierre");
pierre.groet(); // "Bonjour, je m'appelle Pierre"

Voor uitgebreider informatie is er altijd MDN: https://developer.mozilla.../Learn/JavaScript/Objects

[Reactie gewijzigd door Ikheetchris op 22 juli 2024 15:39]

R4gnax

Javascript

@Ikheetchris • 6 december 2020 00:18

JavaScript is vanaf het begin al een Object-Geörienteerde programmeertaal geweest. In plaats van classes (voor de EcmaScript 6 specificatie althans) werkt het met prototypes.

Klopt. JS is altijd Object-Oriented geweest. Alleen niet Class-Oriented.
Prototypal inheritance is veel ruimer als classical inheritance, getuige het feit dat je prototypal inheritance kunt gebruiken om classical inheritance te implementeren en als zodanig te misbruiken, maar dat classical inheritance niet zuiver prototypal inheritance kan implementeren zonder in rare inner-platform meta-programming te verzanden.

SilentLucidity @Ikheetchris • 4 december 2020 22:57

Ik zie wat fouten in je code, op regel 10 staat var jan; volgens mij moet dit const chris zijn, maar dat is slechts mijn mening

berchtold @Ikheetchris • 5 december 2020 02:16

Ik ben echt geen fan van nederlands programmeren. Is gewoon half engels en half nederlands. Klinkt gewoon niet vind ik. Programmeertalen zijn engels dus is het logischer om alles ook in het engels te doen.

Ikheetchris @berchtold • 5 december 2020 04:22

Ik ben het er mee eens dat het verschrikkelijk is, maar dat maakt het juist beter

Immutable @TheAcentra • 4 december 2020 19:27

Voor OO heb je geen classes nodig. Classes zijn juist een ouderwets concept met nadelen. Javascript had nooit classes nodig.

Sito @Immutable • 4 december 2020 19:32

Classes een ouderwets concept? In sommige situaties is object-oriented niet handig met classes, maar dat is een uitzondering...

Immutable @Sito • 4 december 2020 19:47

Classes heeft de minste weg qua weerstand naar overerving. Terwijl dat juist een patroon is wat je minder wil gebruiken als componeren. Een taal dat kiest voor classes als OOP manier, kiest als het ware een soort weg, met de minste weerstand voor een concept wat je juist zo veel mogelijk wil ontwijken. Daarom is een taal met classes niet het "beste" idee.
Een goede taal, heeft de beste en meest gebruikte manieren als weg met de minste weerstand, dus best practises die vloeiend aanvoelen. Niet de slechte praktijken die makkelijk gaan.

Javascript met Classes is dus behoorlijk onzin, had nooit gehoeven.

[Reactie gewijzigd door Immutable op 22 juli 2024 15:39]

Barsonax @Immutable • 4 december 2020 20:06

Ik lees vooral meningen en niet echte concrete redenen.

Niks forceert je om inheritance te gebruiken als je classes gebruikt.

R4gnax

Javascript

@Barsonax • 6 december 2020 00:09

Niks forceert je om inheritance te gebruiken als je classes gebruikt.

Dat is ook niet wat @Immutable schrijft. Wat er geschreven wordt is dat het niet de bedoeling is dat je richting slechte praktijken geduwd wordt door de syntax constructies van de taal zelf. En dat is met class en extend feitelijk wel het geval.

Als je wilt kijken naar betere patronen om applicaties samen te stellen, dan kijk je naar compositie en dat betekent dat je richting traits en mixins gaat. En dat is waar het basale prototypal inheritance van voor ES classes, juist weer heel goed mee samen gaat.

Immutable @R4gnax • 6 december 2020 11:36

Amen, hetzelfde geld voor Garbage collectors. Die hebben eigenlijk niet veel voordelen, maar bepaalde algorithmes worden sneller door het gebruik van Garbage Collection. Daarom heb je in bepaalde talen waar geen GC zit, dus de mogelijkheid om Arena's aan te maken waarbij je een gelocaliseerde GC hebt. Best of both worlds. (Echter is dit weer een 1 op 1000 qua algorithmes die voordeel hebben van een GC)

Ik zie inderdaad dat veel mensen niet begrijpen dat bepaalde gebruiken eigenlijk wel ok zijn zoals overerving, echter is 9 van de 10 keer dat nie zo. Veel talen drukken bad practises naar de voorgrond, waarschijnlijk niet actief maar gewoon omdat men vroeger niet beter wist.

Ik ben persoonlijk geen fan van Classes, en meer fan van Traits en Mixins omdat dat gewoon over het algemeen betere patronen zijn om te componeren. Vandaar dat ik blij was dat Rust afstapte van Classes en dus voor Traits ging.

Bij een goede taal zorgen ze ervoor dat best practises aanvoelt als de weg met de minste weerstand. En als je iets specifieks wil... dus die 1 op 10 keer dat je iets nodig hebt wat op dat moment beter is. (Want dat kan zeker met overerving!) dan moet je maar even wat meer moeite doen. Zelfs als het hele Garbage Collection verhaal.

Daarom moeten ze bij Webassembly dus ook nooit een standaard GC leveren, omdat er zoveel type GC's zijn. En een GC is opinionated. Als ze toch zo graag een GC willen hebben voor WebAssembly, lever dan je eigen GC mee !!

[Reactie gewijzigd door Immutable op 22 juli 2024 15:39]

Mayonaise @Immutable • 4 december 2020 20:15

Ik schrik van grote projecten zonder classes.

R4gnax

Javascript

@Mayonaise • 6 december 2020 19:18

Ik schrik van grote projecten zonder classes.

Ik schrik van projecten die alleen maar log en groot zijn omdat alles in classical inheritance classes geschreven is.

P_Tingen @Immutable • 4 december 2020 21:56

Welke taal doet dat dan beter volgens jou?

Immutable @P_Tingen • 6 december 2020 11:40

Talen die geen classes gebruiken, maar traits zoals Rust. Daarmee zet je componeren op de 1e plaats.
In Classes mix je state en logic in 1 object, en denk je dat het verstandig is om state en logic bij elkaar in te stoppen in 1 enkele object? Dat gaat tegen het componeren denken in. En moet je aan veel meer refactoring doen, als overerving niet bij jou code past.

Als je eenmaal snapt dat bepaalde concepten in de meeste gevallen niet goed zijn, terwijl vanwege de weg van de minste weerstand iedereen ze toch gaat gebruiken??
Dit is ook de reden waarom C programmeurs niet zo weg zijn van C++, maar wel van Rust.

Juist om die reden omdat classes irritant zijn. Zowel C en C++ programmeurs kunnen zich vinden in hoe Rust in elkaar zit. Waarom? Omdat ze beide polen bij elkaar brengen. Voor C programmeurs is de taal lekker low level op C niveau, en voor C++ programmeurs kun je heerlijk high level abstracties maken. Zelfs veel hoger als C++ richting talen als C# en Java. Rust is super rekbaar zowel in de breedte als in de hoogte. Rust wordt waarschijnlijk gewoon geaccepteerd in de Linux kernel(Linus heeft dit aangegeven daar open voor te staan), en C++ niet. Vanwege classes(en wat andere zaken).

Rust is daarom ook aantrekkelijk in de web wereld, ze lopen voor in de weg naar WebAssembly. Dus er zijn al front-end frameworks waar je puur je front-end in Rust kan programmeren met backend. Hier een voorbeeldje van TodoMvc: https://github.com/yewsta...amples/todomvc/src/lib.rs

Webassembly kan zelfs de default abstractie laag worden voor embedded systemen, en webservers. Het gaat heel groot worden in IOT bijvoorbeeld. Puur omdat de WebAssembly VM een streaming runtime is. Je kan je code gewoon er heen streamen. Dat is ook zo bedacht, zodat het op je client kan draaien. Je pusht als het ware zo overal code heen wat maar 1.5x langzamer is geworden in plaats van Native Rust (Wat snelheid heeft van C en C++)
Dit gaat heel groot worden voor code pushing naar edge computing.

We gaan steeds meer naar talen waar besef is van die weg van de minste weerstand naar performance en best practises. Daaruit komt dat classes geen best practise zijn, dat betekend niet dat classes ons slecht gedient hebben. Maar er zijn betere oplossingen voor de meeste situaties, waarvoor je de baan moet leggen betreft de minste weerstand.

Performance gaat weer heel belangrijk worden. We hadden een tijd waarbij dat niet zo was.(Met de opkomst van Java en C#. Maar we willen talen die en gemakkelijk te gebruiken zijn, en een compiler die ons wijst op zoveel mogelijk fouten. Overal op te draaien is, performance heeft op C/C++ niveau en ons wijst op performance issues, en er alles aan doet om de weg naar performance te vermakkelijken voor de programmeur. Dit omdat we tegen de fysieke limieten aanlopen van performance per core. Ook hier is Rust voor gemaakt betreft hun OO mode, en het geheugen model. Compiler die detecteert praktisch alle problemen vantevoren zoals data-races etc. We gaan in de toekomst naar duizenden cores, en daarvoor heb je een taal nodig die dat aan kan, en jou "helpt" hiermee te dealen en jou te helpen met best practises.

[Reactie gewijzigd door Immutable op 22 juli 2024 15:39]

P_Tingen @Immutable • 6 december 2020 19:40

Dank voor je uitgebreide antwoord, kudo's! Ik ken de taal alleen van naar maar zal me er eens wat meer in verdiepen

PainkillA @Immutable • 5 december 2020 12:45

ik ben het helemaal met je eens dat overerving zeer spaarzaam gebruikt moet worden (wat veel; beginners helaas niet snappen en het werkelijk overal gebruiken) maar objecten zelf blijven wel nodig voor encapsulatie en abstracties icm interfaces

Wat javascript voorzover ik weet compleet mist zijn interfaces. Die zijn enorm belangrijk omdat zonder interfaces je code als 1 bak spaghetti aan elkaar hard gekoppeld is waarbij verandering moeilijk is en grote impact heeft. SOLID principes volgen in javascript is naar mijn ervaring gewoon vervelend

R4gnax

Javascript

@PainkillA • 6 december 2020 00:11

Wat javascript voorzover ik weet compleet mist zijn interfaces. Die zijn enorm belangrijk omdat zonder interfaces je code als 1 bak spaghetti aan elkaar hard gekoppeld is.

JavaScript heeft geen compile-time types.
Een interface in JS is dus duck-typed:
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Wat zoveel wil zeggen als:
"Implementeert dit object een methode met de naam X, dan ..."

Met de komst van de Symbols API kun je hardere interface garanties afgeven, aangezien een symbol een zekere mate van uniekheid heeft die sterker is dan een gewone string name voor een property op een object.

Maar laat het nou juist Symbol zijn wat een enorme teringbende is qua ondersteuning in het type system van TypeScript. (Oh de ironie. "Super-set van JavaScript," mijn voet...)

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:39]

GamingZeUs @TheAcentra • 5 december 2020 04:48

Tubescript ♥

w3news @roysijnesael • 4 december 2020 18:55

Ik ben het niet helemaal met je eens.
Technisch gezien kan het met beide, alleen typescript bevat al een bepaalde basis om je meer te sturen naar OO.
Met beide kun je zowel wel als niet OO programmeren, alleen met typescript kunnen mensen het opeens wel omdat er al een betere basis ligt?

willyb @roysijnesael • 4 december 2020 19:08

Tijd dat browsers het gaan ondersteunen. Want die typesscipt -> javascript conversies zijn eigenlijk zonde (echt nuttige dingen gaan verloren).

Wordt het ook weer makkelijker om Angular te deployen.

svenk91 @yor111 • 4 december 2020 18:33

Superset idd, dus alles van Javascript is geldig in Typescript, maar typescript heeft toevoegingen die niet direct compatible zijn met javascript.

stefanhendriks 4 december 2020 22:14

Met webapps zijn we zowat fullcircle (of beter; hybride?) gegaan van mainframes->fat clients->browsers?

Al is het wel suf dat een browser draait in een OS maar feitelijk zowat zijn eigen “OS” is waar “apps” (html based) in draaien”. Zoveel inefficientie!

Javascript is als basic vroeger; maar dan “hip”. Tegelijkertijd kijk ik met verbazing naar al die node packages en debacles als je wat wil upgraden tov andere stacks (vooral de oudere, java en C#). Ik hoor toch vooral een hoop gezucht en gekreun - maar dat zijn wel mensen die uit een backend hoek komen en zwaar op statische, compileerbare talen hebben gezeten. Typescript komt dan in de buurt, maar dan kun je je afvragen waarom... want of je nu javascript draait in je V8 of je draait bytecode in een jvm...

Ofwel popcultuur ;-)

gimbal @stefanhendriks • 4 december 2020 23:34

"Zoveel inefficientie!" - Ach, anders heeft je hardware niets te doen. Processorkracht teveel tegenwoordig - zelfs in je telefoon, dus ik zie liever dat programmeren gemakkelijk is. Ik denk niet met liefde terug aan mijn C/C++ dagen.

Javascript projecten upgraden is echt een draak eerste klas, dat is zeker waar. Met Angular doet het tegenwoordig iets minder pijn, maar ik weerhou me ervan om los te gaan met het toevoegen van third party modules want je bent dan volledig afhankelijk van de gewilligheid van vaak 1 persoon om dat up to date te houden met de Angular releases.

stefanhendriks @gimbal • 5 december 2020 11:32

Grappig want volgens mij is C++ ook verbeterd. In het licht van energieconsumptie is dit ook een gemiste kans. Zelfs zonder javascript en browser hadden we dit probleem al “opgelost” - zie Java (en alle android telefoons).

De browser blijft een vreemde eend in de bijt

GamingZeUs @stefanhendriks • 5 december 2020 04:51

Soms zien websites er best bizar uit tov een desktop applicatie. Het duidelijke document model wat ooit bedacht was is vrijwel nooit meer van toepassing - en toch bouwt de theorie er op voort.

vespino 4 december 2020 19:57

document.write("Van harte gefeliciteerd!");

GamingZeUs @vespino • 5 december 2020 04:48

WAAR IS DE PAGINA HEEN

R4gnax

Javascript

@GamingZeUs • 6 december 2020 00:21

WAAR IS DE PAGINA HEEN

Echt niemand gaat die grap snappen tenzij ze zelf web-ontwikkelaar zijn.
And I love it...

Gopher @GamingZeUs • 7 december 2020 11:39

oh man, toen ik net leerde met JS te werken duurde het even voor ik dat door had.

TheBoneJarmer 4 december 2020 20:18

Voor zij die het willen weten, de grafiek is afkomstig van Octoverse. Iets naar beneden scrollen en dan zie je hem. Leuk feitje tussendoor, is een HTML5 canvas aangedreven door jawel, JavaScript

)

Dat gezegd hebbende, wil ik ook wel eens weten waarom deze grafiek zoveel verschilt van die van de TIOBE index. Daar staat JavaScript helemaal op nummer 7. Ik snap dat Octoverse gewoon de GitHub API gebruikt en TIOBE de gegevens van zoekmachines maar toch..

Ablaze @TheBoneJarmer • 4 december 2020 20:52

Js wordt veel in webprojecten gebruikt.
Bedrijven gebruiken en maken daarnaast desktopsoftware, webservices, tools, embedded software, scripts et cetera. Dat zijn vaak geen open source projecten die op Github staan.
Ook hebben bedrijven vaak jaren geleden al een taal gekozen, Java of C# bijvoorbeeld, en is er een megagrote legacy.

[Reactie gewijzigd door Ablaze op 22 juli 2024 15:39]

franssie 4 december 2020 18:30

Toen ooit wat mee gepeeld en nu gebruik ik het nog soms in node red om informatie strings uit mijn zonnepanelen en slimme meter om te bouwen naar iets dat ik gestructureerd naar een database kan knallen. Voor dat soort eenvoudige taken is het nog steeds een heerlijke ongecompliceerde taal.

Niosus 4 december 2020 18:43

Happy [object Object], JavaScript!

Mrlten 4 december 2020 18:54

alert('gefeliciteerd!');

Op dit item kan niet meer gereageerd worden.

JavaScript viert vijfentwintigste verjaardag

Lees meer

IT-banen

Reacties (97)

Sorteer op:

Weergave: