Waarom lijkt Javascript de enige heerser te zijn?

[Hatsieflatsie]

In het speelveld van serverside talen struikel je over allerlei talen, zoals Java (servlets), ASP/C#, Perl, PHP en Python en nog talloze varianten.
Kijk je vervolgens naar clientside. Dan is het Javascript wat de klok slaat. Andere talen, zoals Google Closure of Actionscript, zijn nauwelijks im Frage.

Los van de technische aspecten/mogelijkheden, is het toch wel enigszins opmerkelijk dat het aan de server side enorm gefragmenteerd lijkt te zijn,en op clientside Javascript de facto standaard lijkt te zijn. Andere talen komen nauwelijks aan bod. Zijn er daar ook goede verklaringen voor?

[NMe]

Het werkt gewoon goed? En een nieuwe standaard moet door meerdere verschillende browservendors opgepakt worden wil het enigszins kans maken. Raad eens waar browsermakers geen zin in hebben als het succes van die standaard allesbehalve vast staat.

[Caelorum]

Dat verklaart uiteraard nog niet waarom niet ook Closure veel wordt gevraagd. Heb het even opgezocht en het compiled dus naar javascript en zou dus in theorie ook in elke browser moeten werken.
Voor AS is het op zich wel duidelijk, elke taal die alleen binnen een plugin werkt verliest het eigenlijk al meteen van JS. Net zoals elke taal die alleen in een paar browsers werken (bijv. alleen webkit gebasseerd of alleen IE of Firefox).

[ Voor 15% gewijzigd door Caelorum op 09-02-2014 22:40 ]

[Gomez12]

Javascript is gewoon een handige eindtaal voor de client, omdat "alle" browsers dat ondersteunen.

Je hebt ook nog wel een groot stuk actionscript, alleen zie je die niet omdat die alleen in een flash-container zit (menig video-player heeft bijv genoeg actionscript in zich zitten).
Google Closure ga je ook nergens aantreffen omdat dat ook gewoon compileert naar JS, dus jij gaat het als client niet herkennen.

Javascript is simpelweg een client-side naam waarbij er aan de dev-kant alle kanten opgegaan kan zijn.
Ik zie bijv steeds minder en minder Javascript op zichzelf, of je ziet dan mensen jquery / mootools / etc gebruiken bovenop javascript of men maakt het onherkenbaar door google closure / jslint / minimizers etc eroverheen te gooien, dan is het eindresultaat javascript maar dit kan net zo goed gegenereerd zijn vanuit node.js of vanuit javascript zelf.

[Hydra]

Hatsieflatsie schreef op zondag 09 februari 2014 @ 22:17:
Los van de technische aspecten/mogelijkheden, is het toch wel enigszins opmerkelijk dat het aan de server side enorm gefragmenteerd lijkt te zijn,en op clientside Javascript de facto standaard lijkt te zijn. Andere talen komen nauwelijks aan bod. Zijn er daar ook goede verklaringen voor?

Ik snap niet dat je dat opmerkelijk vindt. Het is een kip-ei probleem: zolang er geen aanbod is van software in <nieuwe taal X>, is er weinig incentive voor browsermakers dit native te gaan ondersteunen. Zolang er geen native ondersteuning is voor <nieuwe taal X>, is er voor developers geen incentive dit te ondersteunen.

Dit is ook de reden dat veel "javascript killers" zoals Dart in eerste instantie bedoeld zijn om naar JS te compileren: anders zou je eerst alle browsermakers zover moeten krijgen het te ondersteunen.

[Martijn19]

Tegenwoordig kan je ook prima javascript op de server draaien met bijvoorbeeld NodeJS. Ik vind programmeren in JS in elk geval een stuk fijner als PHP.

[Hydra]

m19 schreef op maandag 10 februari 2014 @ 09:22:
Tegenwoordig kan je ook prima javascript op de server draaien met bijvoorbeeld NodeJS.

Modbreak: het is hier niet de HK.

[ Voor 25% gewijzigd door NMe op 10-02-2014 10:26 ]

[Infinitive]

Interessanter is het om te vragen waarom houtje-touwtje programmeertalen zo populair zijn...

[Hydra]

Infinitive schreef op maandag 10 februari 2014 @ 09:37:
Interessanter is het om te vragen waarom houtje-touwtje programmeertalen zo populair zijn...

"Hindsight is 20/20". Destijds is JavaScript met een bepaald doel ontwikkeld. Nu zitten er 'rare' dingen in die destijds handig leken.

Maar dat heb je in ieder taal / framework. Kijk maar naar Java; zowel AWT als Swing zijn redelijk grote screwups en in het framework zitten wel meer van dat soort rare zaken.

[Blubber]

Ik vind het niet zo raar, zoals hierboven al een aantal keer gezegd is, de browsers ondersteunen JavaScript, dus dat is de taal die gebruikt wordt.

Het blijkt al aardig moeilijk te zijn om nieuwe versies van JavaScript te introduceren, laat staan compleet nieuw talen.

Overigens is Google Closure geen taal, maar een set tools om client-side applicaties te bouwen. De Closure compiler compiled javascript naar javascript.

Er zijn een paar alternatieven zoals CoffeeScript, Dart en ClojureScript (met een j), maar die compilen allemaal naar JS (alhoewel Chrome native Dart ondersteuning heeft volgens mij.)

[adis]

Blubber was me net voor met Dart...

Maar een grote poging was ook VBScript van MicroSoft, zij hebben ook een poging gedaan om een alternatief te bieden maar gelukkig blijft JavaScript goed overeind en proberen de browser-makers juist om de standaarden beter te volgen en uit te breiden volgens de standaarden..

[EfBe]

waar heb je het over? http://www.infoworld.com/...in-developer-index-224781

Javascript _lijkt_ populair omdat veel mensen op twitter, hacker news, reddit etc. die javascript gebruiken nu eenmaal veel lawaai maken, maar dat betekent niet dat het leeuwendeel van de software geschreven wordt in javascript.

[HuHu]

EfBe schreef op maandag 10 februari 2014 @ 10:14:
waar heb je het over? http://www.infoworld.com/...in-developer-index-224781

Javascript _lijkt_ populair omdat veel mensen op twitter, hacker news, reddit etc. die javascript gebruiken nu eenmaal veel lawaai maken, maar dat betekent niet dat het leeuwendeel van de software geschreven wordt in javascript.

Waar heb jij het over? Dit topic gaat over client-side talen in de browser.

[NMe]

Hydra schreef op maandag 10 februari 2014 @ 09:42:
[...]

"Hindsight is 20/20". Destijds is JavaScript met een bepaald doel ontwikkeld. Nu zitten er 'rare' dingen in die destijds handig leken.

Zelfs dat valt nog wel mee, IMO. Javascript werkt met wat andere paradigma's dan we gewend zijn van veel andere talen. Vooral prototyping is voor veel mensen die dénken dat ze javascript kennen nog een pittig concept. Er zijn echter veel minder dingen die ik "raar" zou willen noemen in javascript dan in veel andere talen, en dan heb ik het niet eens over PHP.

EfBe schreef op maandag 10 februari 2014 @ 10:14:
waar heb je het over? http://www.infoworld.com/...in-developer-index-224781

Javascript _lijkt_ populair omdat veel mensen op twitter, hacker news, reddit etc. die javascript gebruiken nu eenmaal veel lawaai maken, maar dat betekent niet dat het leeuwendeel van de software geschreven wordt in javascript.

Dat zegt dan ook niemand hier. Javascript is heer en meester als het op de clientkant neer komt. Op het web. In browsers.

[LOTG]

Het probleem is gewoon dat er niets anders draait in browsers dan javascript. Tenminste niet zonder plugin.

De meeste alternatieven spugen aan het eind ook gewoon javascript uit. En ja, javascript is gewoon zijn doel voorbij gestreefd waardoor je inderdaad van allerlei constructies krijgt die niet te lezen of slecht te onderhouden zijn. Waar veel mensen een probleem mee hebben in javascript is type inference, duck typing en de structuren voor events.

Veel frameworks proberen dan ook om javascript heen iets te fabriceren dat deze problemen oplost en uit eindelijk toch gewoon javascript eruit gooit.

[Miyamoto]

Infinitive schreef op maandag 10 februari 2014 @ 09:37:
Interessanter is het om te vragen waarom houtje-touwtje programmeertalen zo populair zijn...

Een onervaren programmeur kan zelf van een goed gestructureerde taal een houwtje-toutje oplossing maken... Staat los van de taal.

@TS: Je vraag wordt misschien beantwoord als je kunt noemen wat je mist aan Javascript?

[Hydra]

NMe schreef op maandag 10 februari 2014 @ 10:38:
Zelfs dat valt nog wel mee, IMO. Javascript werkt met wat andere paradigma's dan we gewend zijn van veel andere talen. Vooral prototyping is voor veel mensen die dénken dat ze javascript kennen nog een pittig concept. Er zijn echter veel minder dingen die ik "raar" zou willen noemen in javascript dan in veel andere talen, en dan heb ik het niet eens over PHP.

Het ging me niet om prototyping (wat inderdaad 'vreemd' is als je de meeste andere gangbare OO talen gewend bent) maar vooral om eigenaardigheden (scope van variabelen, == versus ===, typeof new String("hello") = 'object', hasOwnProperties, etc.) waar je als nietsvermoedende <insert taal> developer tegenaan gaat lopen. Maargoed, dat soort dingen zitten er in bijna elke taal/framework wel.

[BtM909]

Hatsieflatsie schreef op zondag 09 februari 2014 @ 22:17:

Los van de technische aspecten/mogelijkheden, is het toch wel enigszins opmerkelijk dat het aan de server side enorm gefragmenteerd lijkt te zijn,en op clientside Javascript de facto standaard lijkt te zijn. Andere talen komen nauwelijks aan bod. Zijn er daar ook goede verklaringen voor?

Vroeger was er ook nog VBScript en zijn er nog obscure browsers geweest met hun eigen scriptingtaal. Punt is het voornamelijk aan de browservendors heeft gelegen om iets te nemen wat algemeen standaard kon worden.

Voor serverside is het makkelijk om iets (extra's) te ondersteunen, maar je kan moeilijk aan bezoekers vragen om de plink plugin te installeren voor wat clientside-code.

[eL_Jay]

Ik denk deels doordat JS best krachtig en multifuctioneel is. Naast front-end web en app kun je er bijvoorbeeld ook games mee bouwen of animaties maken in Unity3d. M.a.w. met 1 taal ben je al een duizendpoot. Zijn verder volgens mij weinig talen waarmee je zo divers aan de slag kunt maar die toch zo'n lage instapdrempel hebben als JS.

offtopic:
Zitten wel een paar rare streken in zoals new Date(2014, 0, 1) ipv new Date (2014, 0, 0) voor 1 januari. Begin of consequent bij 0 of consequent bij 1 maar niet door elkaar

[ Voor 53% gewijzigd door eL_Jay op 10-02-2014 16:28 ]

[Hydra]

eL_Jay schreef op maandag 10 februari 2014 @ 12:06:
Ik denk deels doordat JS best krachtig en multifuctioneel is. Naast front-end web en app kun je er bijvoorbeeld ook games mee bouwen of animaties maken in Unity3d. M.a.w. met 1 taal ben je al een duizendpoot. Zijn verder volgens mij weinig talen waarmee je zo divers aan de slag kunt maar die toch zo'n lage instapdrempel hebben als JS.

Die lage instapdrempel is juist het gevaar: er zitten best een aantal eigenaardigheden aan die een hele boel developers niet kennen.

Niks tegen JS overigens, heb wel wat tegen developers die niet genoeg studeerwerk doen

[NMe]

Hydra schreef op maandag 10 februari 2014 @ 12:00:
[...]

Het ging me niet om prototyping (wat inderdaad 'vreemd' is als je de meeste andere gangbare OO talen gewend bent) maar vooral om eigenaardigheden (scope van variabelen, == versus ===, typeof new String("hello") = 'object', hasOwnProperties, etc.) waar je als nietsvermoedende <insert taal> developer tegenaan gaat lopen. Maargoed, dat soort dingen zitten er in bijna elke taal/framework wel.

Ik geloof niet dat we het daar oneens over zijn inderdaad. Overigens is === niet vreemd maar domweg een overblijfsel van het feit dat ook javascript weak typed is, zij het iets minder weak typed dan PHP. Als er geen onderscheid zou zijn en == zou doen wat === nu doet zit je in diezelfde weak typed taal uiteindelijk nog steeds over en weer te casten, en dat wilden ze waarschijnlijk juist niet toen ze de taal ontwikkelden. Dat het een pitfall is voor beginners ben ik wel met je eens.

[Soultaker]

PHP heeft dat probleem omdat ze slecht gejat hebben van Perl (en in mindere mate de shell). Javascript heeft het probleem omdat het om historische redenen een onsamenhangend zooitje is. Dat een array integer indices heeft bijvoorbeeld, maar dat je in een for-in loop die indices als strings terugkrijgt, slaat bijvoorbeeld nergens op.

De reden dat het verschil relevant is, is dat operators vervolgens overloaded zijn, waardoor "1" + 2 iets anders is dan 1 + 2; een probleem dat in Perl überhaupt niet voorkomt, omdat "1" en 1 dezelfde scalaire waarde representeren. In een taal als Python zijn operators ook overloaded (omdat het simpelweg methoden zijn) maar worden deze problemen grootendeels voorkomen doordat nooit impliciete conversies plaatsvinden, waardoor het praktisch niet voorkomt dat je met een integer begint die ergens anders een string blijkt te zijn.

Kortom, de problemen met equality en casting die je in PHP en Javascript hebt zijn misschien een symptoom van weak typing, maar weak typing zelf is een symptoom van slecht taalontwerp.

En om toch nog even op de topictitel in te haken: dat zo'n slechte taal alleenheerser kan worden, is natuurlijk te wijten aan het feit dat de enige taal die op alle gangbare browsers werkt natuurlijk vanzelf de de-facto standaard wordt voor sites met een breed publiek die hun bezoekers geen specifieke browser kunnen/willen opleggen. De enige manier om die hegemonie te doorbreken is door een laag boven JavaScript opnieuw te beginnen (Dart, Emscripten, enzovoorts).

[NMe]

Soultaker schreef op maandag 10 februari 2014 @ 15:31:
Kortom, de problemen met equality en casting die je in PHP en Javascript hebt zijn misschien een symptoom van weak typing, maar weak typing zelf is een symptoom van slecht taalontwerp.

Dat vind ik wat kort door de bocht. Wanneer je weak typing in je taal bouwt moet je verdomd goed nadenken over hoe je omgaat met (bijvoorbeeld) de probleemvoorbeelden die je noemt, maar je kan ook best voor weak typing kiezen zonder dat je die problemen in je taal verwerkt. En weak typing heeft natuurlijk ook weer zijn voordelen wat betreft ontwikkelsnelheid en leesbaarheid van code. Het domweg afdoen als een foute keuze per definitie vind ik enigszins flauw.

[afraca]

Overigens zijn sommige mensen natuurlijk een beetje koppig, en willen ze in hun "eigen" taal blijven schrijven, wat ik me best een beetje kan voorstellen.... (lees: enorm kan voorstellen ) Dus er zijn echt talloze compilers en translators voor diverse talen die omzetten naar javascript:

https://github.com/jashke...guages-that-compile-to-JS

[frickY]

Jong geleerd is oud gedaan.
Developers die nu heer en meester zijn in de wondere wereld van Javascript ruilen die expertises niet snel in voor iets onbekend. Dan begin je je hele carrière overnieuw.
Enige reden om zoiets te doen als is als er zwaarwegende voordelen zijn.

[Hydra]

frickY schreef op maandag 10 februari 2014 @ 16:02:
Jong geleerd is oud gedaan.
Developers die nu heer en meester zijn in de wondere wereld van Javascript ruilen die expertises niet snel in voor iets onbekend. Dan begin je je hele carrière overnieuw.

Lijkt me niet. Ieder developer leert dingen bij. Het punt is vooral dat er nu geen goeie alternatieven zijn. Dart komt nog het meest in de buurt.

Daarnaast: JS, met z'n quirks, werkt ook gewoon prima. Er is geen echte reden om over te stappen.

[crisp]

Soultaker schreef op maandag 10 februari 2014 @ 15:31:
[...]
maar dat je in een for-in loop die indices als strings terugkrijgt, slaat bijvoorbeeld nergens op.

Dan gebruik je ook domweg de verkeerde iteratie-methode

JavaScript:

var a = [1];

a.forEach(
    function(value, index)
    {
        alert(typeof index); // number
    }
);

[ Voor 17% gewijzigd door crisp op 10-02-2014 16:07 ]

[HuHu]

crisp schreef op maandag 10 februari 2014 @ 16:07:
[...]

Dan gebruik je ook domweg de verkeerde iteratie-methode

JavaScript:

var a = [1];

a.forEach(
    function(value, index)
    {
        alert(typeof index); // number
    }
);

Daar heb je gelijk in en het wordt hier ook mooi uitgelegd: http://stackoverflow.com/a/9329476. Maar het blijft wel "raar", want de semantiek van for-in in JavaScript is anders dan je op het eerste gezicht zou verwachten.

[NMe]

Het is vooral raar dat er voor een relatief zinloze constructie een language construct is gemaakt terwijl je voor de vaker voorkomende situatie steeds een functie aan moet roepen met veelal anonieme functies als parameter.

[Soultaker]

crisp schreef op maandag 10 februari 2014 @ 16:07:
Dan gebruik je ook domweg de verkeerde iteratie-methode

Als je een methode nodig hebt die pas in ECMAScript 5 is toegevoegd, terwijl de taalconstructie die al sinds ECMAScript 1 bestaat en speciaal een korte, handig syntax heeft de “domweg verkeerd” wordt genoemd, dan lijkt me dat des te meer bewijs dat de taal verkeerd ontworpen is.

Ik snap dat we er met z'n allen nog wat van proberen te maken aangezien we geen andere keuze hebben (en, toegegeven, met wat discipline van de programmeur is Javascript nog best bruikbaar) maar dat betekent niet dat de taal niet vol rariteiten, inconsistenties en ontwerpfouten zit.

[NMe]

Soultaker schreef op maandag 10 februari 2014 @ 18:12:
[...]

Als je een methode nodig hebt die pas in ECMAScript 5 is toegevoegd, terwijl de taalconstructie die al sinds ECMAScript 1 bestaat en speciaal een korte, handig syntax heeft de “domweg verkeerd” wordt genoemd, dan lijkt me dat des te meer bewijs dat de taal verkeerd ontworpen is.

De taal is ontworpen zonder een constructie voor foreach op arrays. For .. in is bedoeld om over members van een object heen te itereren, niet voor arrays. Daarvoor heb je, net als in C, oorspronkelijk ook alleen maar de "gewone" for.

[Hydra]

NMe schreef op maandag 10 februari 2014 @ 20:30:
[...]

De taal is ontworpen zonder een constructie voor foreach op arrays. For .. in is bedoeld om over members van een object heen te itereren, niet voor arrays. Daarvoor heb je, net als in C, oorspronkelijk ook alleen maar de "gewone" for.

Die heeft nogal een naar 'bijeffect' wat betreft het ophoesten van properties die bij een supertype horen trouwens. Keer flink m'n kop mee gestoten.

[crisp]

Soultaker schreef op maandag 10 februari 2014 @ 18:12:
[...]

Als je een methode nodig hebt die pas in ECMAScript 5 is toegevoegd, terwijl de taalconstructie die al sinds ECMAScript 1 bestaat en speciaal een korte, handig syntax heeft de “domweg verkeerd” wordt genoemd, dan lijkt me dat des te meer bewijs dat de taal verkeerd ontworpen is.

Ik snap dat we er met z'n allen nog wat van proberen te maken aangezien we geen andere keuze hebben (en, toegegeven, met wat discipline van de programmeur is Javascript nog best bruikbaar) maar dat betekent niet dat de taal niet vol rariteiten, inconsistenties en ontwerpfouten zit.

Voor een taal die in 10 dagen ontwikkeld is vind ik het zo slecht nog niet

Ja, JS is niet perfect (welke taal wel?) en heeft best wel wat rariteiten (die vaak ook wel weer een logische oorsprong hebben). Een goede reference gebruiken zoals MDN of O'Reilly's JavaScript: The Definitive Guide door David Flanagan is geen overbodige luxe als je je de taal echt eigen wilt maken. En vooral wegblijven van sites als w3schools

[- peter -]

Het lijkt me vrij logisch. Voor een client-side taal heb je ondersteuning nodig van alle browsers. Dat is moeilijk om voor elkaar te krijgen. Voor server side heb je alleen nodig dat de taal in kwestie HTML kan genereren. Dat is dus geen echt obstakel, en dat kan met elke taal. Vandaar dan ook dat je honderden talen en frameworks hebt die allemaal server-side gebruikt worden en maar een heel klein aantal talen/technieken die client-side beschikbaar zijn.

Nu ben ik zelf geen fan van javascript, maar t werkt goed genoeg voor de meeste mensen, en is ook niet heel complex. Dat laatste geeft t een grotere developerbase en zorgt ervoor dat er geen andere talen in t gat springen dat javascript achterlaat. Dat gat is er niet. Misschien wel voor meer complexere zaken, maar zoals gezegd, om een nieuwe taal daarvoor te introduceren is moeilijk en onzeker. Wel gewenst wat mij betreft, maar goed.

[ Voor 32% gewijzigd door - peter - op 10-02-2014 22:58 ]

[Douweegbertje]

Voor mij persoonlijk: omdat er geen alternatieven zijn die het zelfde gemak bieden. Ik pak bijvoorbeeld jquery en ik heb een enorm krachtige maar vooral makkelijke manier om bepaalde dingen te bewerkstelligen. Met de komst van CSS3 en html5 merk ik dat ik al een stuk minder hoef te doen, maar toch heb je het haast nodig. Je zou het haast ook moet uitbreiden, want javascript zelf kan nogal triviaal zijn, echter heb je "gewoon" JSON, Jquery, ajax/xajax etc. In feite "allemaal JS".

Dus tja, is JS op zich zelf een heerser, naar mijn mening niet. Maar alles wat er omheen zit zorgt wel voor iets leuks. Zonder bijvoorbeeld Jquery was JS niet zo "sterk" geweest.

[R4gnax]

Douweegbertje schreef op maandag 10 februari 2014 @ 23:04:
Voor mij persoonlijk: omdat er geen alternatieven zijn die het zelfde gemak bieden. Ik pak bijvoorbeeld jquery en ik heb een enorm krachtige maar vooral makkelijke manier om bepaalde dingen te bewerkstelligen. Met de komst van CSS3 en html5 merk ik dat ik al een stuk minder hoef te doen, maar toch heb je het haast nodig. Je zou het haast ook moet uitbreiden, want javascript zelf kan nogal triviaal zijn, echter heb je "gewoon" JSON, Jquery, ajax/xajax etc. In feite "allemaal JS".

Dus tja, is JS op zich zelf een heerser, naar mijn mening niet. Maar alles wat er omheen zit zorgt wel voor iets leuks. Zonder bijvoorbeeld Jquery was JS niet zo "sterk" geweest.

jQuery heeft weinig tot niets met JS als taal te maken. jQuery is voornamelijk aan abstractie over de DOM APIs heen die een heleboel bugs (ca. 100 unieke op het moment, geloof ik) in voornamelijk oude IE versies en brakke Webkit builds recht trekt.

Als mensen afgeven op JavaScript dan is ook heel vaak niet JavaScript het probleem, maar ongelukkig gekozen DOM APIs.

[ Voor 7% gewijzigd door R4gnax op 10-02-2014 23:49 ]

[Douweegbertje]

R4gnax schreef op maandag 10 februari 2014 @ 23:46:
[...]


jQuery heeft weinig tot niets met JS als taal te maken. jQuery is voornamelijk aan abstractie over de DOM APIs heen die een heleboel bugs (ca. 100 unieke op het moment, geloof ik) in voornamelijk oude IE versies en brakke Webkit builds recht trekt.

Als mensen afgeven op JavaScript dan is ook heel vaak niet JavaScript het probleem, maar ongelukkig gekozen DOM APIs.

jquery is een JS lib.

[BtM909]

NMe schreef op maandag 10 februari 2014 @ 20:30:
[...]

De taal is ontworpen zonder een constructie voor foreach op arrays. For .. in is bedoeld om over members van een object heen te itereren, niet voor arrays. Daarvoor heb je, net als in C, oorspronkelijk ook alleen maar de "gewone" for.

En aanvullend hierop, aangezien je toch niet weet in welke volgorde je het spul terugkrijgt, dat een index al helemaal niks zegt

[LOTG]

NMe schreef op maandag 10 februari 2014 @ 15:38:
[...]

Dat vind ik wat kort door de bocht. Wanneer je weak typing in je taal bouwt moet je verdomd goed nadenken over hoe je omgaat met (bijvoorbeeld) de probleemvoorbeelden die je noemt, maar je kan ook best voor weak typing kiezen zonder dat je die problemen in je taal verwerkt. En weak typing heeft natuurlijk ook weer zijn voordelen wat betreft ontwikkelsnelheid en leesbaarheid van code. Het domweg afdoen als een foute keuze per definitie vind ik enigszins flauw.

Volgens mij noem je daar juist een voordeel van strong typing tegenover weak typing.
Je ziet toch niet wat voor type je variabele heeft? Vooral als je parameters vraag

JavaScript:

    function(value, index)
    {
        alert(typeof index); // number
    } 

C#:

    function(string value, int index)
    {
        alert(typeof index); // number
    } 

Volgens mij is voorbeeld 2 toch echt leesbaarder.

Fan van TypeScript als het op javascript aan komt.

[ Voor 3% gewijzigd door LOTG op 11-02-2014 11:20 ]

[R4gnax]

Douweegbertje schreef op dinsdag 11 februari 2014 @ 09:20:
[...]


jquery is een JS lib.

En wat heeft dat de maken met de syntax van JavaScript als taal en de beschikbare basisfunctionaliteit in de standard library? Je kunt beter zeggen dat zonder jQuery de DOM niet zo sterk was geweest. Dat is feitelijk correct en inderdaad waarom een heleboel mensen JS altijd links hebben laten liggen; de slechte DOM APIs.

[ Voor 25% gewijzigd door R4gnax op 11-02-2014 21:00 ]

[crisp]

Tegenwoordig is jQuery niet veel meer dan een hele grote wrapper rond querySelectorAll

[Soultaker]

Dat, en classList.

[NMe]

R4gnax schreef op dinsdag 11 februari 2014 @ 20:58:
[...]

En wat heeft dat de maken met de syntax van JavaScript als taal en de beschikbare basisfunctionaliteit in de standard library? Je kunt beter zeggen dat zonder jQuery de DOM niet zo sterk was geweest. Dat is feitelijk correct en inderdaad waarom een heleboel mensen JS altijd links hebben laten liggen; de slechte DOM APIs.

Je geeft jQuery daar meer credit dan het verdient want het was noch de eerste, noch is het de beste oplossing daarvoor.

[Joostje123]

Heb paar maandjes terug wat tijd in Dart gestopt.
En dat werkt toch wel zeer uitstekend.
Hopelijk krijgt het snel support van de browsers, want dat kan JS toch wel even van de troon gaan kicken.
Of JS een heel eind in de goede richting gaan trappen.

Maar is wel de support ervoor nodig ook al heb je de compiler Dart2JS.

[BikkelZ]

JavaScript is ook voor het soort taal wat het probeert te zijn een beroerd uitgevoerd. Python zou vele malen beter zijn zonder echt flexibiliteit op te offeren, wat ik van Dart gezien heb is het ook al een enorme verbetering. JavaScript liefhebbers lijden wat mij betreft een beetje aan het Stockholm-syndroom, ze krijgen langzaam sympathie voor de taal die ze gegijzeld houdt wat betreft front-end development.

Ik werk er veel mee, kan er zonder veel moeite veel in bereiken maar ik zou het nooit vrijwillig gebruiken voor zoiets als een back-end en zou er keuze zijn wat betreft front-end talen zou ik waarschijnlijk niet voor JS kiezen (tenzij het alternatief VB is zoiets...)

crisp schreef op dinsdag 11 februari 2014 @ 21:34:
Tegenwoordig is jQuery niet veel meer dan een hele grote wrapper rond querySelectorAll

Inderdaad, ik heb het al langzaam overal uit aan het schrijven

[ Voor 16% gewijzigd door BikkelZ op 13-02-2014 19:33 ]

[alienfruit]

Als jullie querySelectorAll gebruiken polyfillen jullie het dan voor IE8 ofzo?

[crisp]

alienfruit schreef op vrijdag 14 februari 2014 @ 11:30:
Als jullie querySelectorAll gebruiken polyfillen jullie het dan voor IE8 ofzo?

Nee, want IE8 ondersteund dat al (voor CSS2 selectors)

[alienfruit]

Ja, precies, alleen voor CSS2 selectors

[crisp]

alienfruit schreef op vrijdag 14 februari 2014 @ 11:35:
Ja, precies, alleen voor CSS2 selectors

Ik ben nog niet echt in de situatie gekomen dat ik in JS echt per-sé een CSS3 selector nodig had; daar is vrijwel altijd omheen te werken. Zelfs met alleen getElementById en een (eventueel polyfilled) getElementsByClassName kom je doorgaans al een heel eind.

Ingewikkelde selectors gebruiken is meestal puur gemakszucht (en minder efficient).

Overigens wrappen wij QSA wel in een eigen 'Selector' functie die voor simpele selectors terugvalt op getElementById/getElementsByClassName - puur voor performance redenen.

[ Voor 17% gewijzigd door crisp op 14-02-2014 11:41 ]

[RayNbow]

LOTG schreef op dinsdag 11 februari 2014 @ 11:17:
[...]


Volgens mij noem je daar juist een voordeel van strong typing tegenover weak typing.
Je ziet toch niet wat voor type je variabele heeft? Vooral als je parameters vraag

JavaScript:

    function(value, index)
    {
        alert(typeof index); // number
    } 

C#:

    function(string value, int index)
    {
        alert(typeof index); // number
    } 

Volgens mij is voorbeeld 2 toch echt leesbaarder.

Fan van TypeScript als het op javascript aan komt.

Het expliciet opgeven van types is niet iets wat te maken heeft met weak of strong typing? Haskell heeft strong static typing en daar hoef je echt niet aan te geven wat de types van je variabelen en functies zijn (in 99% van de gevallen).

[BtM909]

alienfruit schreef op vrijdag 14 februari 2014 @ 11:30:
Als jullie querySelectorAll gebruiken polyfillen jullie het dan voor IE8 ofzo?

Als we het dan toch over jQuery vs native gaan hebben: http://youmightnotneedjquery.com/

[Verwijderd]

crisp schreef op dinsdag 11 februari 2014 @ 21:34:
Tegenwoordig is jQuery niet veel meer dan een hele grote wrapper rond querySelectorAll

ook niet helemaal waar. jQuery gebruikt al tijden sizzle als 'selector engine'. Dus als je puur een wrapper rondom querySelectorAll wil hebben, Gebruik dan: sizzlejs.com

[Zoijar]

RayNbow schreef op vrijdag 14 februari 2014 @ 13:14:
Het expliciet opgeven van types is niet iets wat te maken heeft met weak of strong typing? Haskell heeft strong static typing en daar hoef je echt niet aan te geven wat de types van je variabelen en functies zijn (in 99% van de gevallen).

Als je taal het zelf al kan deducen hoef je het niet op te geven inderdaad. Hoewel het wel nuttig kan zijn voor de duidelijkheid.

Dit is ook static type checking:

C++:

template<class T, class U>
auto add(T t, U u) -> decltype(t + u)
{
    return t + u;
}

Terwijl je hier alles in kan knallen dat samen de operator+ ondersteund, ook twee strings. (min of meer wat Haskell ook doet)

[R4gnax]

BtM909 schreef op vrijdag 14 februari 2014 @ 13:50:
[...]

Als we het dan toch over jQuery vs native gaan hebben: http://youmightnotneedjquery.com/

Laten we het dan niet vergeten het ook even over de lelijke kanten van full-native te hebben: https://docs.google.com/d...ePXm7oW02iiT6o/edit?pli=1

[ Voor 11% gewijzigd door R4gnax op 15-02-2014 18:41 ]

[Patriot]

R4gnax schreef op zaterdag 15 februari 2014 @ 18:40:
[...]


Laten we het dan niet vergeten het ook even over de lelijke kanten van full-native te hebben: https://docs.google.com/d...ePXm7oW02iiT6o/edit?pli=1

Daar hadden we het al over, want de allereerste link op de pagina waar BtM naar linkt is die exacte google doc

[RayNbow]

Zoijar schreef op zaterdag 15 februari 2014 @ 10:52:
Dit is ook static type checking:

C++:

template<class T, class U>
auto add(T t, U u) -> decltype(t + u)
{
    return t + u;
}

Terwijl je hier alles in kan knallen dat samen de operator+ ondersteund, ook twee strings. (min of meer wat Haskell ook doet)

Alleen de C++ variant is misschien wat flexibeler. In Haskell heb je een type class nodig en moet je zorgen dat alles wat optelbaar is een instance is van die type class.

Dit gaat in ieder geval niet werken:

Haskell:

{-# LANGUAGE FunctionalDependencies, FlexibleInstances #-}
import Prelude hiding ((+))
import qualified Prelude

class Add a b c | a b -> c where
  (+) :: a -> b -> c

instance Num a => Add a a a where
  (+) = (Prelude.+)

ghci> 1+2

<interactive>:2:1:
    Ambiguous type variable `a0' in the constraint:
      (Num a0) arising from the literal `1'
    Probable fix: add a type signature that fixes these type variable(s)
    In the first argument of `(+)', namely `1'
    In the expression: 1 + 2
    In an equation for `it': it = 1 + 2

<interactive>:2:2:
    Ambiguous type variables `a0', `b0', `c0' in the constraint:
      (Add a0 b0 c0) arising from a use of `+'
    Probable fix: add a type signature that fixes these type variable(s)
    In the expression: 1 + 2
    In an equation for `it': it = 1 + 2

<interactive>:2:3:
    Ambiguous type variable `b0' in the constraint:
      (Num b0) arising from the literal `2'
    Probable fix: add a type signature that fixes these type variable(s)
    In the second argument of `(+)', namely `2'
    In the expression: 1 + 2
    In an equation for `it': it = 1 + 2

Type inference wordt dus lastiger, dus je bent dan verplicht om de type checker te helpen:

Haskell:

x, y :: Int  -- verplicht
x = 2
y = 4
test = x + y