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.
Javascript kom til verden som et server-sprog med navnet Livescript, opfundet af Brendan Eich, der dengang var ansat af Netscape – Mozilla og Firefox’ forgænger. Javascript debuterede på klient-siden i Netscape Navigator 2 i 1995. Internet Explorer 3 kom med på vognen året efter, under navnet Jscript.
Også i 1996 begyndte Netscape at arbejde med standardiseringsorganisationen Ecma International for at gøre sproget til en industristandard.
Navnet kunne firmaerne ikke blive enige om, så officielt hedder det standardiserede sprog Ecmascript. Det er der næppe nogen, der siger til daglig, og selv Microsoft omtaler sproget som Javascript i disse dage, hvor især fælles cloud-interesser har skabt stor forbrødring mellem tidligere rivaler.
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.
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.
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.
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 :-)
Jeg har vist ret tydeligt gjort klart hvad jeg foretrækker.
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.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.
"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.
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
Der er ikke mange andre mainstream sprog, der anvender := i stedet for = til assignment.
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.
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æh, det var mere for at understrege compilerens adfærd.Ikke andet end hvad jeg før skrev om at en casefejl i keywords ikke er et tilfælde.Jeg vil ikke kalde det en svaghed, men vi kan blive enige om at det kan være noget rod.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.).??Decimal med to eller fire decimaler er en mulighed i nogle sprog.
Compileren ignorerer case af keywords ved at sætte dem til lower case, inden den parser sourcen.
Derved kan compileren ignorere forskelle i case.
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.
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.
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.
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.
The first rule: Never talk about Javascript.
Det er nu heller ikke min livret. Så hellere fiskefrikadeller og stegt lever.
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.
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.
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.
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.Jeg lægger ikke skjul på mine præferencer, som Peter også er inde på.99%, jamen det er da fedt.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).
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 :-)
Jeg vil ikke svare for Christian, men det tror jeg til gengæld gerne Gary Bernhardt vil.
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.
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.
Formuleringen er nu OK, men eksemplet er så bare lodret forkert. Det var ikke til at vide.
Det hænger bedre sammen nu. Tak for forklaringen.
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).
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:
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.
Motivationen er ikke det samme som forslaget. Motivationen er et afsnit i forslaget, som beskriver hvorfor forslagsstilleren mener ændringen er en god idé.
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.
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)
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"?