Javascript werkt niet in IE

[Verwijderd]

Goedendag,

Momenteel ben ik bezig om een quiz te maken met Javascript, zie: https://jsfiddle.net/noefuxh5/.

Het is redelijk recht toe recht aan: je krijgt een paar vragen en op het laatst krijg je te zien hoeveel antwoorden je goed hebt. Alles werkt op zich prima. Alleen werkt het script niet in Internet Explorer.

Good to know: als basis heb ik gebruik gemaakt van de volgende example code.
-> https://www.sitepoint.com/simple-javascript-quiz/

Wat moet ik doen om het script toch om IE te laten werken?

Ben niet echt een java man dus als iemand me op weg kan helpen...

[TripleQ]

Wat werkt er dan niet aan in IE?
Krijg je een error in de console? Heb je er al met de debugger doorheen gelopen?

[S.O.]

Vermoedelijk gebruik je code die niet (meer) ondersteund wordt door IE.
Hier een link die veel verteld over of een bepaalde code gesupport wordt of niet door diverse browsers.
https://caniuse.com/

[Klaasvaak]

Vanaf welke MSIE versie moet het werken? Template literals en 'const' werken in geen enkele versie van MSIE. Dus alle 'const' door 'var' vervangen en alle template literals door normale strings. De rest zou vanaf MSIE9 moeten werken.

code:

answers.push('<label><input type="radio" name="question' + questionNumber + '" value="' + letter +'">' + letter + ': ' + currentQuestion.answers[letter] + '</label>');

output.push('<div class="slide"><div class="question"> ' + currentQuestion.question + ' </div><div class="answers"> ' +answers.join("")+ ' </div></div>');

var selector = 'input[name=question' + questionNumber +']:checked';

resultsContainer.innerHTML = '<i> Leuk dat je mee hebt gedaan. Je hebt ' + numCorrect + ' van de ' + myQuestions.length + ' vragen goed. &#x263A;</i>';

[CurlyMo]

Gewoon minder exotisch spul toepassen

Noem me conservatief, maar ik had nog nooit gehoord van
- gebruik van ` backticks
- classList
- ${}
- foreach en de =>

Het lijkt wel PHP.

Het voordeel van mijn javascript is dan weer wel dat het overal werkt Als ik al dat exotische spul eruit sloop en vervang door de conservatieve alternatieven, dan werkt ook jouw script.

Overigens, als je de foreach documentatie leest, dan hoort het ook anders geïmplementeerd te worden:

Overigens, de in-browser debugger is bijna altijd je vriend => F12.
https://developer.mozilla...bal_Objects/Array/forEach

[ Voor 16% gewijzigd door CurlyMo op 21-01-2019 21:24 ]

[418O2]

CurlyMo schreef op maandag 21 januari 2019 @ 21:24:
Gewoon minder exotisch spul toepassen

Noem me conservatief, maar ik had nog nooit gehoord van
- gebruik van ` backticks
- classList
- ${}
- foreach en de =>

Het lijkt wel PHP.

Het voordeel van mijn javascript is dan weer wel dat het overal werkt Als ik al dat exotische spul eruit sloop en vervang door de conservatieve alternatieven, dan werkt ook jouw script.

Overigens, als je de foreach documentatie leest, dan hoort het ook anders geïmplementeerd te worden:

Overigens, de in-browser debugger is bijna altijd je vriend => F12.
https://developer.mozilla...bal_Objects/Array/forEach

Dit is gewoon valide js dat in bijna alle browsers werkt.

Als je ie support wil moet je het transpilen met Babel, of niet gebruiken. Je kan eventueel ook polyfills gebruiken als dat kan.

[CurlyMo]

418O2 schreef op maandag 21 januari 2019 @ 21:36:
[...]

Dit is gewoon valide js dat in bijna alle browsers werkt.

Dit sluit inderdaad aan bij ervaring van TS

[418O2]

CurlyMo schreef op maandag 21 januari 2019 @ 21:37:
[...]

Dit sluit inderdaad aan bij ervaring van TS

Ja, omdat ts probeert te leren met matige tutorials zonder voorkennis.

Waar dit letterlijk in staat

The code in this article uses ES2015 syntax, meaning the code will not be compatible with any versions of Internet Explorer. However it does work for modern browsers, including Microsoft Edge.

[ Voor 33% gewijzigd door 418O2 op 21-01-2019 21:39 ]

[MueR]

CurlyMo schreef op maandag 21 januari 2019 @ 21:24:
Gewoon minder exotisch spul toepassen

Noem me conservatief, maar ik had nog nooit gehoord van
- gebruik van ` backticks
- classList
- ${}
- foreach en de =>

Het lijkt wel PHP.

Het voordeel van mijn javascript is dan weer wel dat het overal werkt Als ik al dat exotische spul eruit sloop en vervang door de conservatieve alternatieven, dan werkt ook jouw script.

Overigens, als je de foreach documentatie leest, dan hoort het ook anders geïmplementeerd te worden:

Overigens, de in-browser debugger is bijna altijd je vriend => F12.
https://developer.mozilla...bal_Objects/Array/forEach

Welkom in 2015. Helaas werkt het nog altijd niet in IE, alle andere browsers doen dit. ES6 ftw

[CurlyMo]

MueR schreef op maandag 21 januari 2019 @ 21:39:
[...]

Welkom in 2015. Helaas werkt het nog altijd niet in IE, alle andere browsers doen dit. ES6 ftw

Dan heb je er toch gewoon niks aan, al 4 jaar ondersteund of niet.

[418O2]

CurlyMo schreef op maandag 21 januari 2019 @ 21:42:
[...]

Dan heb je er toch gewoon niks aan, al 4 jaar ondersteund of niet.

Of je transpiled.

IE11 ondersteund overigens ook al redelijk veel. En IE10 support wordt zo'n beetje nergens meer gegarandeerd, dus die kan je best laten vallen.

[CurlyMo]

418O2 schreef op maandag 21 januari 2019 @ 21:54:
[...]

Of je transpiled.

Veel te modern voor mij

[418O2]

CurlyMo schreef op maandag 21 januari 2019 @ 21:58:
[...]

Veel te modern voor mij

Wat is precies het doel van je aanwezigheid in dit topic? Of ga je voorstellen een postduif met de vragen naar de gebruikers te sturen?

[ Voor 15% gewijzigd door 418O2 op 21-01-2019 21:59 ]

[CurlyMo]

418O2 schreef op maandag 21 januari 2019 @ 21:58:
[...]

Wat is precies het doel van je aanwezigheid in dit topic? Of ga je voorstellen een postduif met de vragen naar de gebruikers te sturen?

Ik geef toch aan welke onderdelen problemen geven in IE. Dat was de vraag van TS.

[R4gnax]

CurlyMo schreef op maandag 21 januari 2019 @ 22:01:
[...]

Ik geef toch aan welke onderdelen problemen geven in IE. Dat was de vraag van TS.

En als antwoord stel je voor om de klok 4 à 5 jaar terug te draaien.
Ja doei; dat soort sturend antwoord heeft de TS natuurlijk weinig aan, heh?

[ Voor 11% gewijzigd door R4gnax op 21-01-2019 23:51 ]

[CurlyMo]

R4gnax schreef op maandag 21 januari 2019 @ 23:50:
[...]


En als antwoord stel je voor om de klok 4 à 5 jaar terug te draaien.
Ja doei; dat soort sturend antwoord heeft de TS natuurlijk weinig aan, heh?

Dan mag je me uitleggen waarom onderstaande voorbeeld (een aangepast stukje van TS) zoveel brakker is dan wat TS heeft gedaan. Terwijl mijn versie wel gewoon werkt in IE. Als we het hebben over een nieuwe functionaliteit zoals matchMedia dan kan ik meegaan in jullie betoog dat het niet gebruiken van die nieuwe functies brakke alternatieven oplevert, maar ik vind dat nieuw niet per definitie beter is.

JavaScript:

for(questionNumber in myQuestions) {
        var currentQuestion = myQuestions[questionNumber];
        // we'll want to store the list of answer choices
        var answers = [];
        
        // and for each available answer...
        for (letter in currentQuestion.answers) {
                // ...add an HTML radio button
                answers.push(
                                '<label> \
                                <input type="radio" name="question' + questionNumber + '" value="' + letter +'"> \
                                 ' + letter + ': \
                                 ' + currentQuestion.answers[letter] + ' \
                                </label>'
                                );
        }

        // add this question and its answers to the output
        output.push(
                        '<div class="slide"> \
                                <div class="question">' + currentQuestion.question + '</div> \
                                <div class="answers">' + answers.join("") + '</div> \
                            </div>' 
                        );
};

i.p.v.

JavaScript:

// for each question...
myQuestions.forEach((currentQuestion, questionNumber) => {
        // we'll want to store the list of answer choices
        const answers = [];
        
        // and for each available answer...
        for (letter in currentQuestion.answers) {
                // ...add an HTML radio button
                answers.push(
                                `<label>
                                <input type="radio" name="question${questionNumber}" value="${letter}">
                                 ${letter} :
                                 ${currentQuestion.answers[letter]}
                            </label>`
                                );
        }

        // add this question and its answers to the output
        output.push(
                        `<div class="slide">
                                <div class="question"> ${currentQuestion.question} </div>
                                <div class="answers"> ${answers.join("")} </div>
                            </div>`
                        );
});

Als de eerste versie gewoon werkt in IE?

[Kettrick]

R4gnax schreef op maandag 21 januari 2019 @ 23:50:
[...]


En als antwoord stel je voor om de klok 4 à 5 jaar terug te draaien.
Ja doei; dat soort sturend antwoord heeft de TS natuurlijk weinig aan, heh?

Daar tegenover staat dan weer dat de JavaScript build tools zodanig slecht zijn dat ts verwarren met babel en transpilers waarschijnlijk meer verwarring zaait dan een eenvoudige traditionele JavaScript oplossing.

[R4gnax]

CurlyMo schreef op dinsdag 22 januari 2019 @ 00:37:
[...]

Dan mag je me uitleggen waarom onderstaande voorbeeld (een aangepast stukje van TS) zoveel brakker is dan wat TS heeft gedaan.

Omdat wat TS heeft gedaan ook een stuk compacter en meer leesbaar kan.
Bijv. zoiets als:

JavaScript:

function iterate(obj, fn) {
  return Array.isArray(obj)
    ? obj.map(fn)
    : Object.entries(obj).map(([key, value]) => fn( key, value, obj ));
}

quizContainer.innerHTML =
  `${iterate(myQuestions, ({question, answers}, nr) => 
    `<div class="slide">
      <div class="question">${question}</div>
      <div class="answers">
        ${iterate(answers, (letter, answer) =>
          `<label>
            <input type="radio" name="question${nr}" value="${letter}" />
            ${letter} : ${answer}
          </label>`
        )}
      </div>
    </div>`
  )}`;

Hah! En zo te zien is de language highlighter die Tweakers gebruikt voor JavaScript ook niet 100% geschikt.
Kan niet overweg met alternatief gebruik van brace constructies binnen in een template literal token.

[CurlyMo]

@R4gnax OK, over compact kunnen we het eens zijn. Wat betreft leesbaarheid ben ik een andere mening toegedaan. Maar zo vind ik python pip adviezen vaak ook niet leesbaarder met hun vele variaties van lambda functies. Ik vind de traditionele manier veel meer self documenting.

Kunnen we nog iets zeggen over performance?

En als brede compatibiliteit een harde eis is, dan valt dit sowieso af.

Als compactheid het enige is dat mijn voorbeeld bakker maakt, dan ben ik tevreden. Over leesbaarheid kunnen we namelijk van mening verschillen

[ Voor 17% gewijzigd door CurlyMo op 22-01-2019 08:49 ]

[MueR]

CurlyMo schreef op dinsdag 22 januari 2019 @ 08:45:
@R4gnax OK, over compact kunnen we het eens zijn. Wat betreft leesbaarheid ben ik een andere mening toegedaan. Maar zo vind ik python pip adviezen vaak ook niet leesbaarder met hun vele variaties van lambda functies. Ik vind de traditionele manier veel meer self documenting.

Kunnen we nog iets zeggen over performance?

En als brede compatibiliteit een harde eis is, dan valt dit sowieso af.

Als compactheid het enige is dat mijn voorbeeld bakker maakt, dan ben ik tevreden. Over leesbaarheid kunnen we namelijk van mening verschillen

Als brede compatibiliteit is kan je altijd een "legacy" versie transpilen en die ook in je html opnemen. Moderne browsers negeren de legacy script files en downloaden de modules. De ondersteuning van browsers (ook IE11 for the most part) is best wel compleet.

Een hoop nieuwe mogelijkheden niet gebruiken omdat er nog geen 100% native ondersteuning is (en het alternatief negeren), is imo gewoon stilstand. Volgens die logica zouden we IE6/7 ook nog moeten ondersteunen namelijk. Arrow functions (met fatsoenlijke scoping), classes (met fatsoenlijke scoping), array/object destructing, spread operators en weet ik wat nog meer zijn allemaal super handige, nuttige toevoegingen, die je werk stukken makkelijker maken in complexe projecten.

[CurlyMo]

MueR schreef op dinsdag 22 januari 2019 @ 10:18:
[...]
Als brede compatibiliteit is kan je altijd een "legacy" versie transpilen en die ook in je html opnemen.

Niet elk probleem vraagt deze oplossing. Gewoon direct legacy programmeren is in vele gevallen voldoende voor het doel. Een deel van mijn vak is data-visualisatie. Daarin werk ik gewoon met D3 omgeven door legacy javascript. Ik heb dan helemaal geen behoefte om aan transpilers te gaan. Legacy is goed en snel (genoeg).

Een hoop nieuwe mogelijkheden niet gebruiken omdat er nog geen 100% native ondersteuning is (en het alternatief negeren), is imo gewoon stilstand.

Die mening deel ik niet. Het is stilstand als er goede redenen zijn om het te gebruiken. Dat is niet altijd zo. Een matchMedia is gewoon vele malen sneller dan een onresize event. Daar is weinig discussie aan. Ik vraag me of dat bij de foreach ook op gaat t.o.v. de for in. Programmeren in C is ook geen stilstand nu we C++ hebben. Het implementeren van threadpools in C is ook geen stilstand ondanks dat standaard in de C++ boost library zit.

Volgens die logica zouden we IE6/7 ook nog moeten ondersteunen namelijk.

Dat is natuurlijk onzin. Ik zeg ook niet dat we netscape moeten ondersteunen.

Arrow functions (met fatsoenlijke scoping),

Zie mijn mening over de python lambda functies. Ik vind het de leesbaarheid niet vergroten. Wat ik er wel handig aan vind is dat het de this in tact laat. Maar een var self = this zag ik ook niet als een groot issue.

classes (met fatsoenlijke scoping)

Voor 90% van mijn werk is de originele prototype structuur voldoende en flexibel genoeg.

array/object destructing

Eens

spread operators

9 van de 10 keer voldoet apply voor mij. Waar dat niet zo is, is spread zeker handig.

Die je werk stukken makkelijker maken in complexe projecten.

TS positioneert geen complex project (in onze ogen ) Dat is het punt. Is dat wel zo, dan ben ik het helemaal met jullie eens.

[MueR]

CurlyMo schreef op dinsdag 22 januari 2019 @ 10:42:
Zie mijn mening over de python lambda functies. Ik vind het de leesbaarheid niet vergroten. Wat ik er wel handig aan vind is dat het de this in tact laat. Maar een var self = this zag ik ook niet als een groot issue.

Dat was nou juist het grootste issue met CommonJS, het scope geneuzel. Overal te pas en te onpas var _self, _this, $this of weet ik welke variant geprefereerd wordt, overal apply of bind gebruiken, gek werd ik er van. In complexere stukken code zat je soms met 3 of 4 "this" referenties.

Voor 90% van mijn werk is de originele prototype structuur voldoende en flexibel genoeg.

Voor 99% van de automobilisten is een Lada ook genoeg om ze van A naar B te brengen, maar we hebben graag wat comfort enzo.

9 van de 10 keer voldoet apply voor mij. Waar dat niet zo is, is spread zeker handig.

Je gaat me toch niet vertellen dat dit niet 100 keer beter wegleest dan de apply/object.assign/array.concat ongein?

JavaScript:

class Foo {
    constructor(options = {}) {
        const defaults = {
            some: 'options',
            are: 'nice',
        }
        this.options = {
            ...defaults,
            ...options,
        }
    }
}

TS positioneert geen complex project (in onze ogen ) Dat is het punt. Is dat wel zo, dan ben ik het helemaal met jullie eens.

Nee, TS wil het leren. Beter leert hij meteen de features van ES6 gebruiken, dan vastgeroest blijven in CJS.

[ThomasG]

CurlyMo schreef op dinsdag 22 januari 2019 @ 10:42:
[...]

Niet elk probleem vraagt deze oplossing. Gewoon direct legacy programmeren is in vele gevallen voldoende voor het doel. Een deel van mijn vak is data-visualisatie. Daarin werk ik gewoon met D3 omgeven door legacy javascript. Ik heb dan helemaal geen behoefte om aan transpilers te gaan. Legacy is goed en snel (genoeg).


[...]

Die mening deel ik niet. Het is stilstand als er goede redenen zijn om het te gebruiken. Dat is niet altijd zo. Een matchMedia is gewoon vele malen sneller dan een onresize event. Daar is weinig discussie aan. Ik vraag me of dat bij de foreach ook op gaat t.o.v. de for in. Programmeren in C is ook geen stilstand nu we C++ hebben. Het implementeren van threadpools in C is ook geen stilstand ondanks dat standaard in de C++ boost library zit.


[...]

Dat is natuurlijk onzin. Ik zeg ook niet dat we netscape moeten ondersteunen.


[...]

Zie mijn mening over de python lambda functies. Ik vind het de leesbaarheid niet vergroten. Wat ik er wel handig aan vind is dat het de this in tact laat. Maar een var self = this zag ik ook niet als een groot issue.


[...]

Voor 90% van mijn werk is de originele prototype structuur voldoende en flexibel genoeg.


[...]

Eens


[...]

9 van de 10 keer voldoet apply voor mij. Waar dat niet zo is, is spread zeker handig.


[...]

TS positioneert geen complex project (in onze ogen ) Dat is het punt. Is dat wel zo, dan ben ik het helemaal met jullie eens.

Je bent nu vooral aan het "dit heb ik niet nodig, want het kan ook zus en zo". Ja, inderdaad. Het kan ook op manieren die al sinds jaar en dag in Javascript zitten. Wat jij echter vergeet, of wellicht gewoon niet realiseert, is dat de "moderne" manieren een veel grotere maintainability hebben.

Ik kan natuurlijk het volgende schrijven:

JavaScript:

const bar = [1, 2, 3, 4];
foo.apply(null, arguments);

Maar dat is veel slechter onderhoudbaar dan:

JavaScript:

const bar = [1, 2, 3, 4];
foo(...bar);

Je wilt code produceren wat goed onderhoudbaar is, en dus zo min mogelijk "noise" in je code hebben, tenzij er een specifieke reden voor is om dat wel te hebben. Dingen als het kon al, namelijk zus en zo zijn geen valide reden. Ja, in veel gevallen wil je ook oude browsers ondersteuen, maar er zijn genoeg tools die dat automagisch voor je regelen.

[CurlyMo]

MueR schreef op dinsdag 22 januari 2019 @ 10:58:
Nee, TS wil het leren. Beter leert hij meteen de features van ES6 gebruiken, dan vastgeroest blijven in CJS.

Dat zeg ik toch nergens. Ik geef alleen aan dat het ook goed is om CJS te kennen. En de vraag van TS was nog steeds

Wat moet ik doen om het script toch om IE te laten werken?

Daar geef ik antwoord op. Het antwoord had ook kunnen zijn: "Geen IE meer gebruiken". Prima, maar daar leert TS niks van.

ThomasG schreef op dinsdag 22 januari 2019 @ 11:00:
[...]
Je bent nu vooral aan het "dit heb ik niet nodig, want het kan ook zus en zo". Ja, inderdaad. Het kan ook op manieren die al sinds jaar en dag in Javascript zitten. Wat jij echter vergeet, of wellicht gewoon niet realiseert, is dat de "moderne" manieren een veel grotere maintainability hebben.

Nee, ik betoog dat de nieuwere manieren zeker nut hebben, maar niet heiligmakend zijn in elke situatie. Net zoals C++ nut heeft boven C, maar dat C niet waardeloos maakt. Of nog preciezer, ANSI C over C99, C11 of C18. Ik mis de nuance in dit topic.

Ik kan natuurlijk het volgende schrijven:

JavaScript:

const bar = [1, 2, 3, 4];
foo.apply(null, arguments);

Maar dat is veel slechter onderhoudbaar dan:

JavaScript:

const bar = [1, 2, 3, 4];
foo(...bar);

Veel slechter onderhoudbaar zonder dat te onderbouwen is niet leerzaam Ook voor mij niet. Voor alsnog zie ik in dit voorbeeld vooral een mening verschil en geen feitelijkheid. Zo vind ik D3 geen waardeloze library, omdat het met apply werkt i.p.v. spread.

[ Voor 8% gewijzigd door CurlyMo op 22-01-2019 12:54 ]

[R4gnax]

CurlyMo schreef op dinsdag 22 januari 2019 @ 12:47:
Veel slechter onderhoudbaar zonder dat te onderbouwen is niet leerzaam Ook voor mij niet. Voor alsnog zie ik in dit voorbeeld vooral een mening verschil en geen feitelijkheid. Zo vind ik D3 geen waardeloze library, omdat het met apply werkt i.p.v. spread.

Dat een library intern apply gebruikt zegt niets over de publieke API surface waar de grote buitenwereld mee van doen heeft. Dus het argument wat je daar voert snijdt totaal geen hout.

Verder is de spread operator objectief beter onderhoudbaar dan apply, om de simpele reden dat apply altijd gepaard moet gaan met een context en je daarmee een leaky abstraction creeërt: jij moet als programmeur extra bijhouden wat de internals van een functie verwachten dat hun this zal zijn, en moet extra er zorg voor dragen dat deze als eerste argument aan apply meegegeven wordt.

[CurlyMo]

R4gnax schreef op dinsdag 22 januari 2019 @ 19:23:
[...]
Dat een library intern apply gebruikt zegt niets over de publieke API surface waar de grote buitenwereld mee van doen heeft. Dus het argument wat je daar voert snijdt totaal geen hout.

Maar het zegt wel dat je prima onderhoudbare en bruikbare libraries kunt bouwen op basis van die legacy functies.

Verder is de spread operator objectief beter onderhoudbaar dan apply, om de simpele reden dat apply altijd gepaard moet gaan met een context en je daarmee een leaky abstraction creeërt: jij moet als programmeur extra bijhouden wat de internals van een functie verwachten dat hun this zal zijn, en moet extra er zorg voor dragen dat deze als eerste argument aan apply meegegeven wordt.

Goed argument.

[TripleQ]

2 pagina's aan reacties, maar de topic starter is nog niet weer online geweest sinds zijn eerste post...

[CurlyMo]

TripleQ schreef op dinsdag 22 januari 2019 @ 20:19:
2 pagina's aan reacties, maar de topic starter is nog niet weer online geweest sinds zijn eerste post...

Welkom in de beginnersvragen topics op tweakers