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

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.

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.

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.

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 :-)

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

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:

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.

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

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.

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å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?

Hvis du derimod hentyder til Pascals ukonventionelle assignment operator

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.

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.

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.

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.

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

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;

The first rule: Never talk about Javascript.

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

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.

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.

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.

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.

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).

inkonsekvent casing

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

"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å?

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.

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.

Det er bare eksemplet, som er tåbeligt formuleret.

Det hænger bedre sammen nu. Tak for forklaringen.

Her er den jo pludselig decimalseparator

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

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)

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.

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"?

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"?