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


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.
- emailE-mail
- linkKopier link

Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
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 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.
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.
- more_vert
- insert_linkKopier link
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.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.
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.
- more_vert
- insert_linkKopier link
Sikke noget vrøvl.Du foretrækker det du kender (pascal) og ikke har en ærlig interesse for at forstå noget der er anderledes (javascript).
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.
- more_vert
- insert_linkKopier link
men ville du foretrække "innerHyperTextMarkupLanguage"? eller "innerHtml"?</p>
<p>Jeg har vist ret tydeligt gjort klart hvad jeg foretrækker.
Du foretrækker det du kender (pascal) og ikke har en ærlig interesse for at forstå noget der er anderledes (javascript).
Derfor er det også spild af tid at fortsætte denne snak :-)
- more_vert
- insert_linkKopier link
Jeg har vist ret tydeligt gjort klart hvad jeg foretrækker.men ville du foretrække "innerHyperTextMarkupLanguage"? eller "innerHtml"?
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.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:
- more_vert
- insert_linkKopier link
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.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.
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.
- more_vert
- insert_linkKopier link
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
- more_vert
- insert_linkKopier link
Der er ikke mange andre mainstream sprog, der anvender := i stedet for = til assignment.Hvis du derimod hentyder til Pascals ukonventionelle assignment operator</p>
<p>??
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.
- more_vert
- insert_linkKopier link
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.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.
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æh, det var mere for at understrege compilerens adfærd.Når compileren spytter slutproduktet ud, skulle der ikke gerne være nogle keywords tilbage.
Ikke andet end hvad jeg før skrev om at en casefejl i keywords ikke er et tilfælde.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.
Jeg vil ikke kalde det en svaghed, men vi kan blive enige om at det kan være noget rod.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.
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.).Tænker du på, at Pascal ikke tillader en expression hvor den forventer en statement?
??Hvis du derimod hentyder til Pascals ukonventionelle assignment operator
- more_vert
- insert_linkKopier link
Decimal med to eller fire decimaler er en mulighed i nogle sprog.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.
- more_vert
- insert_linkKopier link
Compileren ignorerer case af keywords ved at sætte dem til lower case, inden den parser sourcen.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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.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
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.da alle keywords af compileren ændres til lowercase
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.
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.Men til gengæld, så afregner den kontant hvis man prøver at skrive noget vrøvl som kurt=kurt;
- more_vert
- insert_linkKopier link
The first rule: Never talk about Javascript.
Det er nu heller ikke min livret. Så hellere fiskefrikadeller og stegt lever.
- more_vert
- insert_linkKopier link
Apropos:fejlsøgning er et helvede.
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.
- more_vert
- insert_linkKopier link
Nu kan jeg så ikke greje om du prøver at være ironisk, men du har da afgjort ret.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 :-)
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.
- more_vert
- insert_linkKopier link
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.Hvad har JavaScript dog gjort dig?
Men jeg er nødt til at bruge det for at opnå funktionalitet på en webside - derfor har det "gjort" mig noget.
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.Svag typing = mere tilgængeligt hvilket i mine øjne er godt. Og hvis man er træt af det kan man eksempelvis bruge typescript.
Jeg lægger ikke skjul på mine præferencer, som Peter også er inde på."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å?
99%, jamen det er da fedt.Inkonsekvent casing... 99% er camelCase, og klasser starter med stort.
- queryString - din camelCase.
- innerHTML - jamen hov, hvad er nu det.
- 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).
- more_vert
- insert_linkKopier link
Hmm Christian, så skulle du prøve Pascal.inkonsekvent casing
Nu jeg tænker over det, tror jeg faktisk at du har en smule kendskab til det :-)
- more_vert
- insert_linkKopier link
Jeg vil ikke svare for Christian, men det tror jeg til gengæld gerne Gary Bernhardt vil."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å?
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.ligger i toppen eller lige ved på flere lister over programmeringssprogs popularitet.
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.
- more_vert
- insert_linkKopier link
Formuleringen er nu OK, men eksemplet er så bare lodret forkert. Det var ikke til at vide.Det er bare eksemplet, som er tåbeligt formuleret.
Det hænger bedre sammen nu. Tak for forklaringen.
- more_vert
- insert_linkKopier link
Jeg tror du tillægger kommentaren for stor værdi. Det skal nok snarere opfattes som at 1234500 (før ES2021) angiver hundrededele af (cent/øre).Her er den jo pludselig decimalseparator
- more_vert
- insert_linkKopier link
Det er bare eksemplet, som er tåbeligt formuleret. Prøv at skrive 123_4500 i konsollen i den nyeste chrome - du får tallet 1234500 som forventet.Det kunne være OK, men det er den netop ikke. Her er den jo pludselig decimalseparator:
- more_vert
- insert_linkKopier link
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)
- more_vert
- insert_linkKopier link
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.Den her ser farlig ud:</p>
<p>let amount = 123_4500; // 123.45 (4-fixed financial)
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.
- more_vert
- insert_linkKopier link
Motivationen er ikke det samme som forslaget. Motivationen er et afsnit i forslaget, som beskriver hvorfor forslagsstilleren mener ændringen er en god idé.På svensk er det et forslag til en ændring. På dansk er det "tilskyndelse til at handle på en bestemt måde".</p>
<p>Det burde vel være "forslaget"?
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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)
- more_vert
- insert_linkKopier link
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"?
- more_vert
- insert_linkKopier link