Næste Javascript er lige om hjørnet - her er nyhederne

25. maj 2021 kl. 03:4531
Næste Javascript er lige om hjørnet - her er nyhederne
Illustration: Bigstock/REDPIXEL.PL.
Ecmascript 2021 kommer til juni og byder på forbedrede muligheder med strenge, promises, fejltyper, logiske operatorer og meget mere.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Go’e gamle Javascript. Det forkætrede sprog har efterhånden 25 år på bagen og ligger i toppen eller lige ved på flere lister over programmeringssprogs popularitet.

Ikke underligt, da sproget er en del af fundamentet for den allestedsnærværende webplatform.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
31 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
32
26. maj 2021 kl. 16:04

men her lyder det til at de kommer i vejen for "den bedste løsning": Det er meget meget langt fra altid en fordel at holde logik backend.

Ikke uenig, det kommer helt an på hvad det er for en logik vi taler om - simpel inputvalidering f.eks. er mest hensigtsmæssig at lave i front-enden, og der kan være funktionalitet (som f.eks. onblur og lignende) som helt naturligt ligger front-end.

Men der er også meget, hvor det kan være bedre givet ud at lave et ajaxkald (og her er js af gode grunde involveret) og så benytte regnekraften back-end til at lave det mere krævende, selv om det koster noget transport af data.

31
26. maj 2021 kl. 15:54

Derfor tilsigter jeg også at minimere brugen af javascript, og i stedet lave så meget som overhovedet muligt logik back-end - så kan jeg også styre uden om de værste kompabilitetsproblemer fsva. browsere.

Hm. Fint at have præferencer for hvad man foretrækker at arbejde med - men her lyder det til at de kommer i vejen for "den bedste løsning": Det er meget meget langt fra altid en fordel at holde logik backend.

I øvrigt (med mindre man er tvunget af løjerlig politik) så er kompabilitetsproblemer stort set en saga blot efter IE er lagt i graven og browsere flest er auto-opdateret.

30
26. maj 2021 kl. 15:39

Du foretrækker det du kender (pascal) og ikke har en ærlig interesse for at forstå noget der er anderledes (javascript).

Sikke noget vrøvl.

Der er intet odiøst i at have en præference, og for mit vedkommende er et af elementerne som jeg godt kan lide at Pascal er caseinsensitive.

Det er nu en mindre del af sagen, det har som så ikke så meget at gøre med funktion, men er mere et dagligt irritationsmoment.

Og jo, jeg er af gode grunde tvunget til at forstå javascript, men selv om jeg så efterhånden har fået en ret god forståelse for javascript, så betyder det ikke at jeg synes det er godt (keep your friends close, your enemies even closer).

Derfor tilsigter jeg også at minimere brugen af javascript, og i stedet lave så meget som overhovedet muligt logik back-end - så kan jeg også styre uden om de værste kompabilitetsproblemer fsva. browsere.

27
26. maj 2021 kl. 12:53

men ville du foretrække "innerHyperTextMarkupLanguage"? eller "innerHtml"?

Jeg har vist ret tydeligt gjort klart hvad jeg foretrækker.

Du kan få din browsers developer tools til at stoppe op når der opstår en exception, ligesom når du sætter et breakpoint:

Jeg har lidt svært ved at se hvad det skulle hjælpe fsva. hvilken værdi der forventes, det fortæller kun hvilken funktion der er kommet i vanskeligheder.

26
26. maj 2021 kl. 12:51

Til gengæld er mange fejl opstået fordi udviklere i andre sprog har taget fejl af = (assignment) og == (comparison). Det er ikke ofte jeg har set den type fejl i Pascal projekter.

Ok, det var det du mente, og ja, det er en løsning jeg er rigtig glad for i praksis, fordi det eliminerer mange muligheder for fejl.

Og lad os så lige dvæle ved JS i den forbindelse:

== betyder sammenligning af værdi

=== betyder sammenligning af værdi og type

Vorherre bevares.

25
26. maj 2021 kl. 12:51

99%, jamen det er da fedt.</p>
<ol><li>queryString - din camelCase.</li>
<li>innerHTML - jamen hov, hvad er nu det.</li>
<li>Promise.any - åh ja, sådan kan det også se ud (but who cares).

"Promise" er en klasse og derfor med stort forbogstav, og "any" er en utility-funktion på klassen. Hvad er problemet?

I.f.t. "innerHTML" kan vi godt blive enige om at der er en edge case, men ville du foretrække "innerHyperTextMarkupLanguage"? eller "innerHtml"?

Jeg synes ærligt talt at man har valgt den bedste løsning.

Nogen der har et godt bud på hvordan man får Webdeveloper til at komme med den feedback.

Du kan få din browsers developer tools til at stoppe op når der opstår en exception, ligesom når du sætter et breakpoint:

https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Breaking_on_exceptionshttps://developer.chrome.com/docs/devtools/javascript/breakpoints/#exceptions

23
26. maj 2021 kl. 11:55

Så snart man er flere udviklere på samme projekt, er det ikke længere en fordel, at de andre kan vælge den casing du synes er værst.

Ikke nødvendigvis uenig - men i modsætning til JS, så betyder det ikke så meget om der er brugt den ene eller den anden casing.

Dog vil jeg sige at jeg normalt holder mig til lowercase, og dermed lægger mig op ad C (uden dog at benytte keywords med uppercase som variable).

Når compileren spytter slutproduktet ud, skulle der ikke gerne være nogle keywords tilbage.

Næh, det var mere for at understrege compilerens adfærd.

Jeg ved ikke lige hvad jeg skulle få ud af at den i mellemtiden har ændret dem til lowercase, hvis min source stadig indeholder keywords i blandede cases.

Ikke andet end hvad jeg før skrev om at en casefejl i keywords ikke er et tilfælde.

Til gengæld kan jeg kun se det som en svaghed, at den samme identifier kan optræde flere steder i kildekoden med forskellige cases.

Jeg vil ikke kalde det en svaghed, men vi kan blive enige om at det kan være noget rod.

Tænker du på, at Pascal ikke tillader en expression hvor den forventer en statement?

Næh mere det at en variabel skal være tildelt, og man skal være konsekvent således at man ikke kan rode rundt i om hvorvidt en variabel er en streng eller ej (osv.).

Hvis du derimod hentyder til Pascals ukonventionelle assignment operator

??

19
26. maj 2021 kl. 11:45

Og hvor er den øgede læsbarhed i forhold til:</p>
<p>let amount = 123.4500; // 123.45 (4-fixed financial)

123.45 er ikke 4-fixed financial vel. Når man arbejder med penge ønsker man typisk ikke at floats tilfældige afrundinger kan medføre at der mangler en øre sidst i en beregning. Derfor gemmes alle beløb som heltal. Ofte bruger man at gemme antal øre i stedet for kroner, og så kan man eventuelt dividere med 100 før det vises på skærmen. Jeg kender ikke 4-fixed financial men man kan udlede at det er antal tusindedele af en krone gemt som heltal.

18
26. maj 2021 kl. 11:40

I Pascal kan man selv vælge den casing man føler er bedst, for dermed at få den største (synes man selv :-)) læsbarhed

Så snart man er flere udviklere på samme projekt, er det ikke længere en fordel, at de andre kan vælge den casing du synes er værst.

da alle keywords af compileren ændres til lowercase

Når compileren spytter slutproduktet ud, skulle der ikke gerne være nogle keywords tilbage. Jeg ved ikke lige hvad jeg skulle få ud af at den i mellemtiden har ændret dem til lowercase, hvis min source stadig indeholder keywords i blandede cases.

Til gengæld kan jeg kun se det som en svaghed, at den samme identifier kan optræde flere steder i kildekoden med forskellige cases.

Men til gengæld, så afregner den kontant hvis man prøver at skrive noget vrøvl som kurt=kurt;

Tænker du på, at Pascal ikke tillader en expression hvor den forventer en statement? Det betragter jeg som en lille ubetydelig detalje. Hvis du derimod hentyder til Pascals ukonventionelle assignment operator, så er jeg enig i at den kan eliminere nogle fejlkilder.

17
26. maj 2021 kl. 10:59

The first rule: Never talk about Javascript.

Det er nu heller ikke min livret. Så hellere fiskefrikadeller og stegt lever.

16
26. maj 2021 kl. 09:55

fejlsøgning er et helvede.

Apropos:

Hvis jeg kvajer mig, og referer til et ikke eksisterende element, så får jeg følgende fejlmeddelse i Webdeveloper:

Uncaught TypeError: document.getElementById(...) is null

Og det er sådan set meget godt, men hvis jeg har en side med mange kald og elementer, så kunne det jo være rigtig rart at få at vide hvilket navn på elementet der forventes.

Nogen der har et godt bud på hvordan man får Webdeveloper til at komme med den feedback.

15
26. maj 2021 kl. 09:43

Hmm Christian, så skulle du prøve Pascal.</p>
<p>Nu jeg tænker over det, tror jeg faktisk at du har en smule kendskab til det :-)

Nu kan jeg så ikke greje om du prøver at være ironisk, men du har da afgjort ret.

I Pascal kan man selv vælge den casing man føler er bedst, for dermed at få den største (synes man selv :-)) læsbarhed, da alle keywords af compileren ændres til lowercase.

Men til gengæld, så afregner den kontant hvis man prøver at skrive noget vrøvl som kurt=kurt;

Og et lille rant omkring C - en procedure hedder "den store tomhed" (void), hvorimod en funktion hedder .... ingenting.

14
26. maj 2021 kl. 09:30

Hvad har JavaScript dog gjort dig?

Det har gjort mig det, at det tager cirka 10 gange så lang tid at lave selv det mest banale i javascript, end det gør i Pascal - og fejlsøgning er et helvede.

Men jeg er nødt til at bruge det for at opnå funktionalitet på en webside - derfor har det "gjort" mig noget.

Svag typing = mere tilgængeligt hvilket i mine øjne er godt. Og hvis man er træt af det kan man eksempelvis bruge typescript.

Det set afhænger af brillerne, og i min optik er det kontraproduktivt at have noget som er "mere tilgængeligt" med den følge at compileren ikke fanger åbenlyse bøffer, som man så skal lede efter i en større sammenhæng under kørsel.

"Rædselsfuld syntax". Her synes jeg godt nok du strammer den, syntaksen minder da meget om andre C-/javaagtige sprog? Hvad tænker du helt konkret på?

Jeg lægger ikke skjul på mine præferencer, som Peter også er inde på.

Inkonsekvent casing... 99% er camelCase, og klasser starter med stort.

99%, jamen det er da fedt.

  1. queryString - din camelCase.
  2. innerHTML - jamen hov, hvad er nu det.
  3. Promise.any - åh ja, sådan kan det også se ud (but who cares).

Men gud stå dig bi, hvis ikke du har den helt præcise brug af case - så pyt med at resten af sproget sejler.

(OT - jeg brugte listeformen ovenfor, da dette forum jo ikke tillader enkeltlinje skift).

13
25. maj 2021 kl. 23:13

inkonsekvent casing

Hmm Christian, så skulle du prøve Pascal.

Nu jeg tænker over det, tror jeg faktisk at du har en smule kendskab til det :-)

11
25. maj 2021 kl. 23:03

Hvad har JavaScript dog gjort dig?

Svag typing = mere tilgængeligt hvilket i mine øjne er godt. Og hvis man er træt af det kan man eksempelvis bruge typescript.

"Rædselsfuld syntax". Her synes jeg godt nok du strammer den, syntaksen minder da meget om andre C-/javaagtige sprog? Hvad tænker du helt konkret på?

Inkonsekvent casing... 99% er camelCase, og klasser starter med stort. Så er der noget gammelt skrald som ikke følger de regler, men det er forbavsende lidt taget i betragtning af sprogets alder og popularitet.

Det er måske en populær holdning at JavaScript er noget lort, men det er også en noget unuanceret holdning i mine øjne.

10
25. maj 2021 kl. 15:31

ligger i toppen eller lige ved på flere lister over programmeringssprogs popularitet.

Takket være, at lige gyldig hvad man skal lave af funktionalitet for selv den mest simple HTML side, så kan man ikke undgå javascript.

Men javascript er og bliver noget lort med svag typing og rædselsfuld syntax (og inkonsekvent casing), og hvis det ikke var fordi det er uløseligt forbundet med webbrowsere, så ville det bare have været en parantes i historien.

Og at spørgsmål om javascript er det der fylder mest på Stackoverflow er da kun en indikation på at det er håbløst.

6
25. maj 2021 kl. 13:23

Som jeg forstår det, er det blot en separator der ignoreres af interpreteren.

Det kunne være OK, men det er den netop ikke. Her er den jo pludselig decimalseparator:

let amount = 123_4500; // 123.45 (4-fixed financial)

5
25. maj 2021 kl. 12:57

Den her ser farlig ud:</p>
<p>let amount = 123_4500; // 123.45 (4-fixed financial)

Ja, de ser alle farlige ud. Men det er nu nok mest kommentarerne udenfor kontekst der bidrager til forvirringen. I alle tre tilfælde er amount et heltal. Dit andet eksempel på amount (hvor du har fjernet et 0) kan ikke genfindes i artiklen.

Hvis eksemplerne i stedet havde været:

let amount = 1234500; // 12,345 (1234500 cents, apparently)

let amount = 1234500; // 123.45 (4-fixed financial)

let amount = 1234500; // 1,234,500

havde forvirringen vel ikke været mindre. Så alt i alt er en fri placering af separatorer i hel- og decimaltal en fordel for læsbarheden.

3
25. maj 2021 kl. 12:39

Som jeg forstår det, er det blot en separator der ignoreres af interpreteren. Følgende er det samme tal:

12345

1_2_3_4_5

123_45

1234_5

Det er blot for at øge læsbarheden i koden - særligt med store tal og financielle tal hvor man har valgt f.eks integer i 1/10 øre.

2
25. maj 2021 kl. 11:32

Den her ser farlig ud:

let amount = 123_4500; // 123.45 (4-fixed financial)

når denne også er sand:

let amount = 123_450; // 123,450 (12345000 cents, apparently)

Og hvor er den øgede læsbarhed i forhold til:

let amount = 123.4500; // 123.45 (4-fixed financial)

1
25. maj 2021 kl. 11:25

På svensk er det et forslag til en ændring. På dansk er det "tilskyndelse til at handle på en bestemt måde".

Det burde vel være "forslaget"?