It-fagfolk: Flere bør lære Javascript

...at JavaScript er så møg-elendigt et sprog. Jeg lagde jeg det bag mig for 7-8 år siden, og håbede, jeg aldrig skulle se en anden linje JS kode igen. Det er jeg så blevet tvunget tilbage i fornylig, og det har været en drøj omgang at skulle vænne sig til typeløse variable, næsten ikke-eksisterende separation af UI fra funktionel kode, manglende kontrol over brugerens miljø (vil det her også virke om 3 måneder når browser X kommer i ny version?) osv. jQuery er kommet til i mellemtiden - som sendt fra himlen, det har reddet nogle af de sidste hår på mit hovede.

Hvem er det der har brug for at lære assembler? Hvis man har noget kode i C der ikke køre hurtigt nok, så kompiler man til assembler-source og kigger på det. Ofte kan man så rette lidt i C, og få prøvet sig frem til en hurtigere kørsel. Hvis ikke C-oversætteren kan gøre det fornuftigt, så kan man blive nødt til at skrive en enkelt lille rutine i assembler, og så resten i C.

Kun hvis man skriver compilere, har man reelt brug for assembler.

Ingen tvivl om at JavaScript slet ikke er optimalt! Men der er kommet mange gode frameworks indenfor de sidste par år, som gør det noget mere behageligt at arbejde med. Med AngularJS og TypeScript så begynder det at ligne noget, og man kan faktisk lave store veldesignede web-applikationer...

Fra artiklen:

Fagfolk peger på, at leverandørene har spenderet enorme ressourcer på at optimere motoren i Javascript, hvilket har gjort sproget utrolig hurtigt.

Ganske vist er Javascript hurtigere end det var engang, men at pege på det som et højtydende sprog er ret fjollet. Hvorfra kommer denne idé om at Javascript som sprog skulle være specielt hurtigt i sin afvikling?

Som Mogens så fint kommer ind på, så er der rigtig mange designvalg i JavaScript der er knapt så heldige, specielt set med moderne briller.

Som gammel Object Pacal mand (hvilket jeg stadig bruger dagligt) må jeg sige at Smart Pascal dialekten som er blevet udviklet i forbindelse med værktøjet Smart Mobile Studio virkelig fjerner kompleksiteten fra JavaScript og samtidig tilføjer features til JavaScript som jeg endnu ikke har set i andre populære JS frameworks. fx partial classes, ægte VMT, objekt nedarving, datatyper, generics mm. - Outputtet er så optimeret JavaScript.

Som bonusinfo er dialekten i store træk kompatibel med Delphi og Free Pascal hvilket betyder man kan flytte mindre komplekse desktop applikationer til browseren med minimalt arbejde.

Eller bare skrive en app og benytte Cordova / Phonegap til indpakning

Nooooo mit elskede perl er blevet forvist til en plads under Cobol, nu må jeg nok hellere lære mere assembler for at blive mere attraktiv, hvis jeg skal til at søge job :D.

Gad vide hvilken slags assembler det dækker over, mips, arm, x86 eller andre?

PS.

Note: Mange svarede HTML, som dog pr. definition ikke er et programmeringssprog.

Så det er den slags fagfolk der er blevet spurgt?

Som Mogens så fint kommer ind på, så er der rigtig mange designvalg i JavaScript der er knapt så heldige, specielt set med moderne briller.

Egentligt ikke blot med moderne briller. Selv da JavaScript udkom var de uheldige designvalg. Men det er også fordi JavaScript er blevet til noget det aldrig var tænkt det skulle blive. Det var kun fordi Netscape skulle have et eller andet som Internet Explorer ikke havde. Noget hvor man kunne lave dumme små animationer, fordi det var så hot i 1990erne.

Sidenhen fandt folk på at bruge det til at lave dissiderede programmer, hvilket det aldrig var tiltænkt. Men set ud fra at JavaScript skulle være et reelt programmeringssprog, så var dets designvalg også uheldige tilbage i 1990erne.

Pascal er jo et gennemtænkt programmeringssprog. Det har kun få mindre heldige designvalg, for Pascal lider mest af alt af sin alder (det gør C og C++ i øvrigt også). Og at der er kommet meget viden omkring programmeringssprogsdesign som kan være svært at få ind i Pascal uden at det bliver lidt uheldigt,[0] osv.

[...] Smart Mobile Studio [...] fjerner kompleksiteten fra JavaScript og samtidig tilføjer features til JavaScript som jeg endnu ikke har set i andre populære JS frameworks. fx partial classes, ægte VMT, objekt nedarving, datatyper, generics mm. - Outputtet er så optimeret JavaScript.

Hmm... jeg synes godt nok jeg har set objekt nedarving, datatyper, generics, mm. i andre JavaScript-frameworks. Nu har jeg ikke brugt dem selv, så jeg har blot gået igennem deres funktionalitetsliste og set hvad de kan. Og det virker ikke som om Smart Pascal er særligt i denne forstand. Det skal dog på ingen måde anses som en kritik. Det er bare ikke revolutionerende, men det er også svært når det er Pascal... høhø.

Men spøg til side, så bruger jeg personligt ikke JavaScript-frameworks. Jeg synes generelt de er tunge og dumme. Og selvom JavaScript mildest talt er noget lort, så er jeg ikke vild med at pakke det jeg laver væk. Det er en kognitiv kompleksitet jeg ikke kan lide. Det er selvfølgelig fuldstændigt subjektivt det her, men jeg foretrækker at kode rå JavaScript, så man faktisk lærer JavaScript og ikke blot et framework. Det også derfor jeg ikke gider Django i Python. (Dog vil jeg hellere skrive en webserver i Go, så det er vist lidt et sidespring.)

[0] Skiftet fra ANSI til Unicode er et godt eksempel på noget der gav stod ballade i Object Pascal, selvom de egentligt gjorde overgange så godt som de kunne. Men når folk bruger (forhåbentligt brugte nu om dage) string til binær databehandling, så får man jo problemer når de nu kan indeholde Unicode-tegn.

Efter at jeg for nogle år siden fandt Dart, så har jeg ikke skrevet én eneste linie Javascript. Min livskvalitet er kraftigt forbedret. :D

Så det er den slags fagfolk der er blevet spurgt?

En nordmand (som kan læse og forstå norsk) forklarer mig at der faktisk er tale om en popularitetsmåling fremfor en anbefalingsmåling. Version2 har bare fået gøglere på internettet til at blive it-fagfolk. Det er topjournalistik.

Ahh ok fair nok David, og tak for afklaringen, det passer godt med at det er de sprog folk har hørt mest om der topper listen.

Hvem er det der har brug for at lære assembler?

Det er da et krav for at kunne blive programmør. Vidste du ikke det? Man skal kunne assembler på fem forskellige arkitekturer og COBOL. Lidt lige som man skal have et godt kendskab til græsk, aramæisk, hebræisk og latin for at blive en god præst. ;-)

Salve errore et omissione!

Men jeg må da indrømme, at jeg vist ikke har set assembler siden 1996. BALR

Det passer også bedre med Pythons popularitet blandt hjemmeprogrammørere der har fået fingerene i en Raspberry Pi.

Skiftet fra ANSI til Unicode er et godt eksempel på noget der gav stod ballade i Object Pascal, selvom de egentligt gjorde overgange så godt som de kunne.

Det er vel egentlig ikke et problem ved sproget som så, men et compiler problem. Men er det ikke et problem alle "gamle" sprog har været udsat for?

Men når folk bruger (forhåbentligt brugte nu om dage) string til binær databehandling, så får man jo problemer når de nu kan indeholde Unicode-tegn.

Hvordan mener du bruge en string til binær databehandling?

Det er vel egentlig ikke et problem ved sproget som så, men et compiler problem. Men er det ikke et problem alle "gamle" sprog har været udsat for?

Det mener jeg da også jeg nævner i en sidebemærkning, at C og C++ også er et eksempler på sprog der lider af samme problem. Jeg har det samme problem med de to sprog som jeg har med Pascal. Pascal, C og C++ er selvfølgelig ikke de eneste der er tale om, men jeg gider ikke producere en komplet liste af sprog.

Jeg kan sagtens forstå hvorfor at string i Pascal originalt var en række af bytes (med længden på position 0), fordi Unicode ikke fandtes den gang. Men lidt lige som *char i C, så gør det processen fra det gamle til det nye lidt træg. Faktisk til et niveau hvor man kunne overveje om det ikke ville være nemmere at kaste sig over et nyt sprog med Unicode-håndtering bygget ind fra starten.

Dog vil jeg mene at det sgu' er først på det seneste at Unicode-håndtering i nyere programmeringssprog er blevet god (se Go og Rust). Det var jo ikke før Python 3 at man forstod hvad fanden der foregik. Og Javas valg af UTF-16 har altid være en del af Javas meget store Akilleshæl.

Hvordan mener du bruge en string til binær databehandling?

Før TBytes var det normalt at bruge string til samme formål. Hvert element var altid et byte, og så man kunne bare forvente at de var uden faktisk at tjekke. Så kunne man bruge Copy() og Pos() til at finde det relevante data. Det var da skidesmart at kunne arbejde på rådata som om det var tekstfølger.

Det passer også bedre med Pythons popularitet blandt hjemmeprogrammørere der har fået fingerene i en Raspberry Pi.

Det forklarer også hvorfor Visual Basic ligger så højt på listen. VB er i mine øjne programmeringssprogenes svar på Frankensteins monster: En vederstyggelighed syet sammen af forskellige lig.

Det forklarer også hvorfor Visual Basic ligger så højt på listen. VB er i mine øjne programmeringssprogenes svar på Frankensteins monster: En vederstyggelighed syet sammen af forskellige lig.

VB.NET er stort set bare C# med en grim syntaks. Tidligere VB var, om ikke elegant, så da rimeligt stilrent. Følgeligt er det mere end styg varulv end Frankenstein's monster (som mere passende er C++ eller Common Lisp).

Pascal er en mumie der har været død i 3000 år, og godt for det.

Hej Troels, med fare for et ubehageligt svar hvordan vil du kategorisere perl?

..at JavaScript er så møg-elendigt et sprog

Jeg synes at typeløse variable og apply er som sendt fra himlen. Til gengæld synes jeg ikke specielt godt om typescript, der forsøger at få Javascript til at ligne det noget mere primitive kompilerede sprog Java (sic) komplet med masser af unødig ceremoniel omkring interface definitioner osv. Men sådan er vi så forskellige.

Son andre har påpeget bør du/I prøve AngularJS, hver dog opmærksom på, at Angular2 desværre bliver tæt bundet op til ES6 / typescript. Der er allerede en del tutorials der viser, hvordan man med Javascript ES5 + Angular1.x kan gøre sin kode klar til Angular2 + ES6. Så for de der ikke kan udholde Javascript i dets nuværende form, er det vel en form for trøst. Bare trist at se et så dejlig dynamisk sprog gå den vej ...

Tidligere VB var, om ikke elegant, så da rimeligt stilrent.

Pascal er en mumie der har været død i 3000 år, og godt for det.

Pascal har blokke, det har VB ikke. Det er en af grundene til at det er grimt. For skal afsluttes med Next, Do While skal afsluttes med Loop, While skal minsandten afsluttes med Wend. Det fikser Pascal elegant ved at have Begin og End. Hos mig vinder mumien den skønhedskonkurrence. Når det er sagt har jeg hverken kodet Pascal eller VB de sidste 15 år.

Salve errore et omissione!

Suk. Errare humanum est. Eller som Brian villa have udtrykt det: Romanum eunt domus.

Men jeg må da indrømme, at jeg vist ikke har set assembler siden 1996. BALR

Ikke siden 1986 hvor jeg lavede mit første space invaders i ren 6502 maskinkode. Ikke assembler, som er snyd - maskinkode. Dvs. jeg kunne de decimale koder, som møjsommeligt blev strikket sammen først i hånden på papir, så direkte i datalinjer.

jeg kan stadig lave et lille program i hovedet.

162,255,169,160,157,0,4,202,208,250,96

Fylder de første 255 tegn på skærmen med et inverst space (lagt i accumulator). Ved brug af et lille "hack", som automatisk trigger, når tælleren (X-registret) når "under" nul.

Ah, de tider. Det siges, at Linus Thorvald lærte sig maskinkode på samme måde. På en C64. Uden MC monitor.

Smart Pascal dialekten som er blevet udviklet i forbindelse med værktøjet Smart Mobile Studio virkelig fjerner kompleksiteten fra JavaScript og samtidig tilføjer features til JavaScript som jeg endnu ikke har set i andre populære JS frameworks. fx partial classes, ægte VMT, objekt nedarving, datatyper, generics mm. - Outputtet er så optimeret JavaScript.

Scala-JS: http://lihaoyi.github.io/hands-on-scala-js/

En sjov ting er at mindre kodestumper ofte kan oversættes som både Scala og JavaScript da der er mange ligheder mellem sprogene på overfladen.

Det har også gjort det muligt at få en meget høj interoperabilitet. Således kan næsten alle JavaScript frameworks bruges fra Scala-JS ligesom at Scala-JS kan eksportere funktioner der kaldes helt naturligt fra JavaScript.

Det er dejligt at kunne udvikle i det samme sprog på både server og klient. Vi har autowire, så at det bliver super naturligt at definere server API og kalde dette fra klienten, helt uden boilerplate. Da det er samme sprog, så kan man skrive kode der kan eksikveres på både server og klient. Smart når man skal validere noget på en sikker måde. Smart så man helt enkelt kan flytte funktionalitet mellem server og klient alt efter hvad der lige passer her. Smart da der efterhånden er en del biblioteker der kan bruges både på klient og server. Mange eksisterende Scala biblioteker er blevet porteret til Scala-JS og kan nu bruges i browseren.

næsten ikke-eksisterende separation af UI fra funktionel kode

Man kan nu godt separere javascript fra sin markup og CSS vha unobtrusive javascript. Det er vel egentlig også hvad man bør gøre, hvis man vil have en side eller lave en APP, som også er funktionel uden JS.

Med AngularJS og TypeScript så begynder det at ligne noget, og man kan faktisk lave store veldesignede web-applikationer...

Du mener at Typescript er kommet, tvivler på at nogen bruger Angular2 når Angular-killeren kommer ud :)

Aurelia, personligt kunne jeg aldrig finde på at sidde med Angular, det er noget bras, men derimod Aurelia... det styrer.

Lever manden i en anden verden?

Når browserstandarden nærmer sig ECMASCRIPT 2015 så er der ingen der gider javascript længere.

Og hvad er det for noget vrøvl flere poster om javascript frameworks? Der er vel ingen ved deres fulde fem der sidder med frameworks længere efter man har transpilere.

// angularjs  .js snippet  
$scope.tellme = function () {  
  return btoa ("RGVyIGVyIGZvciBtYW5nZSBub29wcyBww6UgZGV0dGUgZm9ydW0=");  
};  
// end snippet

<!-- angularjs HTML snippet -->  
<h1>{{tellme();}}</h1>  
<!-- end snippet -->

Ha' en go' tirsdag :)

@Palle Simonsen.

Og du skal lære at bruge den rigtige metode, før du kan udtale dig om det!! ;-)

Hint: btoa (encode) atob (decode)...

Og du skal lære at bruge den rigtige metode, før du kan udtale dig om det

@Mikkel: LOL - ja det var lige hurtig nok - en slags 'instant karma'. Men så er der i det mindste en læser af kommentaren, der ikke svarer til den tiltænkte returværdi af kaldet :)

Man kan selvfølgelig prøve at redde tellme (og face) med:

// Untested kludge to try and fix problem rather than admit error :)  
$scope fix = function () {atob(atob($scope.tellme()));};

oao

Det er da et krav for at kunne blive programmør.

Assembler er i hvert fald udmærket til at lære hvordan en computer faktisk udfører programmer, uanset hvad de er skrevet i.

Og den viden er essentiel for en programmør.

Tør vi overhovedet prøve på det? :-)

Vil vi ikke ende over i noget Lovecraft agtigt noget..

Søren

PS: Jeg koder selv i Perl til dagligt, og ja det kan faktisk gøres så det er genkendeligt fra 'line noise' :-)

Hvis fremtiden platform er WEB, så er jeg sikker på at JavaScript er et godt valg! men er fremtidens platform WEB?

Og Javas valg af UTF-16 har altid være en del af Javas meget store Akilleshæl

Ok kan du lige uddybe det? Hvordan skulle intern encoding være en meget stor Akilleshæl? Du antyder et problem her, kan du ikke venligst forklare hvad problemet består i?

Platformen kan også være node. Der findes en del sprog (TypeScript, CoffeeScript, ScalaJS, ClojureScript osv.), som gør det meget nemmere at udvikle i JavaScript. Jeg vil hellere se JavaScript som assembleren/maskinkoden (lidt ligesom Java bytecode), og de andre sprog som de egentlige udviklingssprog, der så oversættes til JavaScript. JavaScript er både alt for verbose og fuld af faldgruber (var der nogen der sage manglende var erklæring som gør en variabel global - tak CoffeeScript for at løse dette).

Man kan sagtens lave fine JavaScript programmer, der ligesom programmer i alle mulige andre sprog separere de forskellige dele af en applikation.

Typeløse variable er en smagssag, men tænk over hvad der er billigst for dem som i sidste ende betaler for at i laver en løsning. Er det at i bruger en masse tid med at slås med en Compiler (Scala) om typerne, eller er det en helt typeløs verden (JavaScript), eller et mix (Java/C#/C osv.). Dog er det altid vigtigt at holde sig for øje hvilket problem man forsøger at løse inden man vælger værktøj, for det er det et programmeringssprog er. Så at afskrive JavaScript som nogen gør her, som noget muggent bras, forstår jeg ikke. Det er det eneste programmeringssprog som kan afvikles cross-browser, og det ser ikke ud til at ændre sig synderligt.

Der bliver gentagne gange nævnt uheldige designvalg ved JavaScript. Er der ikke nogen af dem som nævner dette, som kan kaste lidt lys over, hvilke designvalg der er uheldige, og så samtidigt nævne nogle af de glimrende designvalg der trods alt er i JavaScript, som mangler i andre programmeringssprog.

Undskyld hvis jeg var lidt for indirekte. jeg taler så meget om javascript, men mere om fremtidig platform!

En anden ting jeg synes er p... irriterende er at JavaScript er case sensitive, uden nogen egentlig logik, eksempelvis:

document.getElementById(returnid).style.display

virker, men

document.getElementById(returnId).style.display

virker ikke - men hvorfor må id'et i returnid ikke være stort, når det skal være det i getElementById?

Og så en lille OT ting - sidder og bøvler med en drop down menu i flere niveauer, hvor et onmouseover event ændrer en div med en række knapper fra display:none til display:inline-block.

Det fungerer fint på en computer med mus, men når jeg så prøver på en tablet, så fyres den endnu ikke synlige ("bagvedliggende") knap af så snart jeg rører feltet, fordi touchstart-touchend også fyrer et click af.

Jeg er ikke interesseret i at disable alle touchfunktioner, kun undgå clicket for det ene felt.

Ok kan du lige uddybe det? Hvordan skulle intern encoding være en meget stor Akilleshæl? Du antyder et problem her, kan du ikke venligst forklare hvad problemet består i?

Jeg er ikke enig i at det er en stor akilleshæl. Men UTF-8 havde været et bedre valg. Man valgte UCS-2 (ikke UTF-16) så at man hurtigt kan finde længden af en string (antal tegn). Først i Java 5 skiftede man UCS-2 ud med UTF-16, hvorefter man ikke længere har fordelen af at hurtigt at kunne finde længden af en string. Men man har stadig ulempen af at strings fylder unødigt meget i forhold til UTF-8.

For de uindviede så er UCS-2 en to byte kodning der kan gemme tegn fra 0x0000 til 0xFFFF. Et tegn fylder altid præcis to bytes, så antal tegn er lig med antal bytes divideret med 2.

UTF-8 er en variabel længde kodning, hvor de mest almindelige tegn fra ASCII fylder 1 byte. Hvis mest betydende bit er sat, så skal næste byte også tages med, og så fremdeles, så et tegn kan fylde fra 1 til 4 bytes. UTF-16 er samme system, blot så fylder et tegn enten to bytes (16 bits) eller 4 bytes (32 bits).

Da UTF-8 og UTF-16 er variabel længde kodning, så kan man ikke finde antal tegn ud fra antal bytes. Man er nødt til at tælle tegnene ved at løbe strengen igennem tegn for tegn. Der findes stadig meget Java kode som ikke tager korrekt hensyn til dette og som derfor regner forkert hvis programmet ser et af de sjældne tegn som fylder dobbelt.

Ud over string length, så er det også et problem hvis man eksempelvis vil hoppe ind i en string på en bestemt position eller hvis man skal udlæse en substring.

De fleste nyere sprog (eksempelvis Rust) har valgt UTF-8.

virker ikke - men hvorfor må id'et i returnid ikke være stort, når det skal være det i getElementById?

Argh, hjerneprut, det er jo mig selv der har defineret returnid uden stort i - men det ændrer nu stadigvæk ikke ved at jeg mener, at det at JavaScript er case sensitive er apinta, nærmest som at prøve at modellere en klump gele.

Pascal er jo et gennemtænkt programmeringssprog. Det har kun få mindre heldige designvalg, for Pascal lider mest af alt af sin alder (det gør C og C++ i øvrigt også).

Gennemtænkt??

Algol 68 er et gennemtænkt programmeringssprog. Med en enkelt tilføjelse, som var på beddingen (Charles Lindsey 1974, Algol Bulletin, 37.4.2) ville sproget have været fuldt funktionelt med closures. Havde et mindretal omfattende bl.a. Naur og Wirth ikke saboteret sproget, så man fik Algol-W, Pascal, C..., ville man i 1974 have programmeret i et sprog som var fuldt på højde med de bedste vi har i dag (og med en større udbredelse ville fx en opgradering med avanceret OOP have været tilgængelig medio-70erne).

Pascal er et hack. Et ganske nydeligt hack, men et hack - lige som C og alle de sprog der er fulgt efter.

Argh, hjerneprut, det er jo mig selv der har defineret returnid uden stort i - men det ændrer nu stadigvæk ikke ved at jeg mener, at det at JavaScript er case sensitive er apinta, nærmest som at prøve at modellere en klump gele.

Mener du at versalfølsomhed er en god eller skidt ting? Indrømmelse: Jeg har primært erfaring med versalfølsomme sprog (med nogle års Lisp-erfaring som undtagelse), men jeg har aldrig set fidusen ved versalufølsomhed. Det virker ikke som noget der kan bruges i en god sags tjeneste, men kun til at skabe gråd og tænders gnidsel.

I Lisp var versalufølsomhed primært et resultat af at sproget blev opfundet på et tidspunkt (og til systemer) hvor der kun fandtes store bogstaver, så man senere af bagudkompatibilitetshensyn var nødsaget til at se lidt stort(!) på det. Jeg tror det samme gør sig gældende for andre gamle sprog, såsom det Pascal jeg ved ligger dig nært.

Mener du at versalfølsomhed er en god eller skidt ting? Indrømmelse: Jeg har primært erfaring med versalfølsomme sprog (med nogle års Lisp-erfaring som undtagelse), men jeg har aldrig set fidusen ved versalufølsomhed. Det virker ikke som noget der kan bruges i en god sags tjeneste, men kun til at skabe gråd og tænders gnidsel.

Jeg mener det er en smart ting (vi taler ikke om strenge osv, kun sproget), da jeg ikke ser nogen som helst fornuftig grund til at f.eks. getElementById ikke ligeså godt kunne skrives som GetElementById (hvorfor skal den første versal udelades?) eller getelementbyid (jeg er enig i at læsbarheden er lavere, men funktionen burde være den samme).

Og især når vi taler om sådan noget skrammel som JavaScript (ups var der en versal for meget?) som afvikles i en browser, uden man har en compiler der fanger syntaksfejl.

Kan du fortælle mig hvad er den rationelle grund til at have versalfølsomheden?

Kan du fortælle mig hvad er den rationelle grund til at have versalfølsomheden?

Der er en række grunde:

0) For mig virker det oplagt og rart at den samme ting ikke kan skrives på mere end én måde. Det gør det nemmere at scanne kode visuelt, og har nok noget at gøre med hvordan det menneskelige øje opfanger forskelle.

1) Versalufølsomhed er mere komplekst, hvilket kan medføre dumme fejl i dumme sprog. Jeg er generelt tilhænger af at holde ting enkle. Kode der ikke er skrevet er fejlfri, og features der ikke findes er ikke fejlimplementeret.

2) Visse moderne sprog udnytter forskellen i versaler syntaktisk. I Haskell er type- og data-konstruktører f.eks. indikeret ved at første tegn er en versal (og funktions- og variabel-navne skal starte med småt). Det tillader en letvægts-grammatik for f.eks. mønstergenkendelse der stadigvæk er entydig og kontekstfri. Go benytter versaler til at indikere om et navn er eksporteret eller ej.

Det fungerer fint på en computer med mus, men når jeg så prøver på en tablet, så fyres den endnu ikke synlige ("bagvedliggende") knap af så snart jeg rører feltet, fordi touchstart-touchend også fyrer et click af.

Jeg er ikke interesseret i at disable alle touchfunktioner, kun undgå clicket for det ene felt.

First off, så kunne jeg godt tænke mig at vide, hvorfor man vil lægge design ind via javascript og ikke CSS... Men derudover, så er der måske en løsning. Kommer lidt an på, om jeg har forstået spørgsmålet korrekt...

https://gist.github.com/vasilisvg/1275792

Men det bedste ville nok være at få et link til siden, hvor problemet er... alt andet lige. Jeg forstår i hvert fald bedre, når jeg kan se den bagvedliggende kode.

Og især når vi taler om sådan noget skrammel som JavaScript (ups var der en versal for meget?) som afvikles i en browser, uden man har en compiler der fanger syntaksfejl.

Brugt "use strict" og så Firefox indbyggede logger i "Webkonsol" til at kontrollere for js-fejl, CSS-fejl mv. Jeg ved ikke rigtigt, hvordan man ellers kan gøre, for jeg er ikke på den måde en JS-haj.

Men det bedste ville nok være at få et link til siden, hvor problemet er... alt andet lige. Jeg forstår i hvert fald bedre, når jeg kan se den bagvedliggende kode.

Nu ligger det hele kun på min maskine lokalt, men jeg kan klippe lidt ud:

<nav id="navbar" class="navbar ">  
<div class="mainnavbtncont w20">  
<div id="ak1" class="mainnavbtnfill bgcolwhwhitesmoke" onmouseover="showdiv('PopUp1')" onmouseout="noshow('PopUp1')">   
<div class="mainnavbtn">  
<div class="mainnavbtninner">  
Forside  
</div>  
</div>  
<div id="PopUp1" class="subnavbtngroup bgcollightgray">  
<div class="subnavbtncont">  
<button id="11" type="submit" formaction="standard" formmethod="get" name="menuid" value="1" class="subnavbtn bgcolwhlightyellow" onclick="sethidden0('submenuid','1')">Forside</button>  
</div>  
...

Scriptdelen er ret simpel, bare for at sætte display for PopUp(x):

function showdiv(returnid)   
{  
    document.getElementById(returnid).style.display = "inline-block";   
}  
   
function noshow(returnid)  
{  
    document.getElementById(returnid).style.display = "none";   
}

Og CSS'en for den div der vises/ikke vises:

.subnavbtngroup  
{  
    display: none;   
    position:relative;  
    margin-top: 35px;  
    padding-top: 25px;  
    width: -moz-calc(100% + 1px);  
    width: -webkit-calc(100% + 1px);  
    width: calc(100% + 1px);  
    text-align: justify;   
    font-size: 12px;   
    z-index: 5;  
    border-style: outset;  
    border-color: white;  
    border-width: 1px;  
}

Min ide er at lave en drop down undermenu, men da de gøres dynamisk bruger jeg onmouseover til at gøre den underliggende div synlig via showdiv funktionen. Oprindelig var min ide at menuen så skulle se sådan ud:

----------------------------------------------------------------  
|                               |                               |  
|            Side 1             | ------------------------------|  
|                               |              Side 2-1         |  
--------------------------------|                               |  
                                 -------------------------------  
                                |              Side 2-2         |  
 

Mouseover fungerer fint, når musen køres hen over Side 1, så kommer undermenuen med Side 2-1 osv fint frem. Men når man så gør det samme med touch, så sker der det at når man berører det område der er fællesmængde for Side 2 og Side 2-1, så fyres der jo en touchstart af, som helt automatisk også laver click, og dermed trykker på Side 2-1 - og det var det jeg gerne ville undgå.

Jeg har i første omgang lavet en workaround, således at margin-top og padding-top sørger for at min dropdown kommer ned under bunden af hovedmenuen, så trækkes eventet nemlig ikke.

Men allerhelst ville jeg at touchstart ikke flød videre til den underliggende div.

PS, hvor ville det være fedt hvis V2 lavede 21'århundrede muligheder for ordentlig editering af kommentarer.

Nu ligger det hele kun på min maskine lokalt, men jeg kan klippe l

Fedt at der er én der tør vise rigtig kode, man arbejder med!

Overvej onclick istedet for mouseover på touchskærm - ellers er der f.eks. JQueryMobile, som du relativ hurtig kan konstruerer noget nogenlunde pænt med til en touchskærm.

Overvej onclick istedet for mouseover på touchskærm

Nu foretages valget mellem onclick eller mouseover jo i HTML delen, hvordan skal det kunne gøres afhængig af hvilken type enhed man sidder ved?

Jeg kunne selvfølgelig bare vælge onclick i stedet for mouseover, så ville det fungere fint på touch, men så ville det være nødvendigt at klikke på en almindelig maskine, og det ville jeg helst undgå.

Og jeg viger altså bort fra at bruge jQuery, da jeg gerne vil undgå at sovse mine ting ind i frameworks og yderligere abstraktionslag - derfor vil jeg heller ikke rode med SmartPascal, selv om tanken måske i første omgang kunne lyde besnærende.

@christian, kender kun preventdefault (og måske stopproagation), men jeg har leget med det første, og umiddelbart er det et hack, og hacks er alt andet lige ikke det bedste. Hvis man er nødt til at omgøre den naturlige afvikling, så må der være noget andet galt.

Jeg kigger på din kode, når jeg kommer hjem. Men umiddelbart, hvorfor ikke få et domæne kun til test, hvis ikke du vil offentliggøre endnu det originale domæne, det kan jo være gode grunde til.

Men få et domæne, hvor du kan isolere kun den del af koden, som volder problemer, sådan man visuelt kan se og afprøve, hvad der går galt...

Nu foretages valget mellem onclick eller mouseover jo i HTML delen, hvordan skal det kunne gøres afhængig af hvilken type enhed man sidder ved?

Registrer dine event handlers i JS i stedet, så er du også fri for at din HTML skal kende en global JS-funktion..

https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventLis...

Jeg er ikke enig i at det er en stor akilleshæl. Men UTF-8 havde været et bedre valg.

Hmm, det er der vidst stor uenighed omkring. .NET; Java, Windows API, mm. bruger alle UTF-16. Muligvis på grund af at det er den mest pladsbesparende encoding på verdensplan (når man tæller med at de største befolkningsgrupper bruger code points der ligger udenfor ASCII-7. UTF-16 er iøvrigt videreudviklingen af UCS-2, som ikke kan rumme codepoints nok, til at være Unicode.

Man valgte UCS-2 (ikke UTF-16) så at man hurtigt kan finde længden af en string (antal tegn). Først i Java 5 skiftede man UCS-2 ud med UTF-16, hvorefter man ikke længere har fordelen af at hurtigt at kunne finde længden af en string. Men man har stadig ulempen af at strings fylder unødigt meget i forhold til UTF-8.

For vestlige sprog er dette for det meste korrekt (set i forhold til UTF-8). Man valgte UCS-2, fordi det var standarden på det tidspunkt man lavede Java, ligesom det var i Windows og alt muligt andet software, IKKE for hurtigt at kunne finde længden af en string.

Da UTF-8 og UTF-16 er variabel længde kodning, så kan man ikke finde antal tegn ud fra antal bytes. Man er nødt til at tælle tegnene ved at løbe strengen igennem tegn for tegn. Der findes stadig meget Java kode som ikke tager korrekt hensyn til dette og som derfor regner forkert hvis programmet ser et af de sjældne tegn som fylder dobbelt.

Java har indbygget strings i sit API, så man benytter selvfølgelig metoderne stillet til rådighed af platformen. At selv "regne" længden på byte arrays ud som længden af en string er jo helt i skoven, og ikke en property af platformen, mere end et udtryk for programmørens kompetencer. Jeg er endnu ikke stødt på så megen kode, man kan da livligt forestille mig, at der muligvis er nogle projekter hvor dette er tilfældet.

Ud over string length, så er det også et problem hvis man eksempelvis vil hoppe ind i en string på en bestemt position eller hvis man skal udlæse en substring.

Korrekt, men det er jo et generelt problem, med space vs. computational efficiency. Man kunne have valgt UTF-32 (eller UCS-4) og fået hurtigt opslag, men sikkert en masse spildt plads.

De fleste nyere sprog (eksempelvis Rust) har valgt UTF-8.

Jeg ville også selv have valgt UTF-8, for at ungår LE, BE problematikkerne, Men UTF-16 er "mere" kompatibel med UCS-2, og derfor har Java og Windows sikkert valgt disse. Linux benytter vist UTF-8 eller UTF-32. JavaScript, iOS, .NET, Qualcomm BREW, Qt benytter alle UTF-16, så for interop. reasons er det en god ide at benytte samme encoding, da der så ikke skal ske translations.

Nu foretages valget mellem onclick eller mouseover jo i HTML delen, hvordan skal det kunne gøres afhængig af hvilken type enhed man sidder ved?

Sæt eventhandlers på i JavaScript i stedet for hårdt kodet i HTML delen. F.eks. i en Document ready event handler.

Registrer dine event handlers i JS i stedet, så er du også fri for at din HTML skal kende en global JS-funktion..

Som jeg ser det, så kræver det at der laves en specifik, på forhånd skrevet hårdt ind i JS, eventhandler til hver id.

Når jeg så genererer mit HTML dynamisk, så kan jeg have f.eks. fra 1 til 6 hovedmenu "knapper", med id fra ak1 til ak6, som så respektiv gør fra PopUp1 til PopUp6 synlig.

Så hvis det skal kunne gøre på den måde er jeg forlods nødt til i JS at have defineret eventhandler 1-6 for mouseover, mouseout, touchstart og touchend.

Helst ikke den vej jeg vil gå, da jeg foretrækker at holde min JS del så lille som overhovedet mulig.

Men selvfølgelig, hvis man kunne lave en eventhandler med wildcard ala: document.getElementById("ak*") så ville det være en mulighed.

Men selvfølgelig, hvis man kunne lave en eventhandler med wildcard ala: document.getElementById("ak*") så ville det være en mulighed.

Det kan du godt, se fx getElementsByTagName eller getElementsByClassName funktionerne. Hvis du vil have fuld fleksibilitet er du nødt til at bruge et bibliotek som fx jQuery der kan finde elementer ud fra en CSS selector, og det vil du jo ikke :-)

Så hvis det skal kunne gøre på den måde er jeg forlods nødt til i JS at have defineret eventhandler 1-6 for mouseover, mouseout, touchstart og touchend.

Det er ikke nødvendigt at have 6 eventhandlers fordi du har 6 menupunkter - der er mange måder at parametrisere dem på. Du kunne fx bibeholde associationen mellem popuppen og det klikbare element i en custom html-attribut på det klikbare element:

<div id="ak1" class="..." data-menupopup="PopUp1">

Du kunne fx bibeholde associationen mellem popuppen og det klikbare element i en custom html-attribut på det klikbare element:

<div id="ak1" class="..." data-menupopup="PopUp1">

Den må jeg så indrømme jeg ikke fangede, for der skal vel stadig være defineret en eventhandler for hver af id="ak1" til "ak6"?

Kan selvfølgelig godt se at custom html-attributten hiver en reference med over jeg kan bruge i JS, men stadig skal eventhandlerne vel være unikke?

Kan selvfølgelig godt se at custom html-attributten hiver en reference med over jeg kan bruge i JS, men stadig skal eventhandlerne vel være unikke?

Du kan godt erklære eventhandler-funktionen én gang, hente listen med menupunkter via getElementsByXX, iterere over den, og kalde addEventListener med den samme funktion som argument i hver iteration.

Du kan godt erklære eventhandler-funktionen én gang, hente listen med menupunkter via getElementsByXX, iterere over den, og kalde addEventListener med den samme funktion som argument i hver iteration.

Ok, jeg må prøve at lege lidt med det - tak for hintet.

For mig virker det oplagt og rart at den samme ting ikke kan skrives på mere end én måde. Det gør det nemmere at scanne kode visuelt, og har nok noget at gøre med hvordan det menneskelige øje opfanger forskelle.

Det kan du så have ret i, men eksempelvis CSS og JS, som jo er to ting man bruger for at nå et samlet mål når man lave websites, kan ikke engang blive enige om at tingene hedder det samme, så man skal rode rundt efter den rigtige skrivemåde:

CSS: background-color: lightgray;

JS: document.getElementById(returnid).style.backgroundColor= "lightgray";

Virkelig logisk og intuitivt.

Vi har lavet et modul til rettelse af tekster på skærmen, der automatisk påsætter events til de elementer på skærmen der indeholder tekst (det er dynamisk for hver side, og for hvem der tilgår siden - rollebaseret). Der kaldes en JavaScript eventhandler - editText, som så laver ContentEditable for det givne element og står for Ajax delen med at opdatere tekster til og fra CMS for det enkelte felt på skærmen. Du må kunne gøre noget lignende. attachEvents(); kører som en funktion på document ready eventet. Der benyttes muligheden for at opsætte egne attributter på felterne, som angiver metadata om feltet (f.eks. tekstnøgle osv.), dette læses så fra feltet når eventet aktiveres. Vi benytter jQuery til at finde de felter der er på siden som skal have event påsat, da det er klart simplest, og vi ikke selv har lyst at vedligeholde al den boilerplate som jQuery nu en gang befrier en for, omkring selectors - men dette kan sagtens implementeres uden brug af jQuery:

HINT: document.body.getElementsByTagName("*"); og filtrer så listen, evt. med hjælp at en class (det er hvad vi benytter for at markere et element som værende editerbart).

Håber det er en hjælp.

Desuden har vi konverteret 100% til CoffeeScript, da vi har fundet at det højner produktivitet, læsbarhed og minimerer fejl kraftigt. JavaScriptet der produceres er 100% læsbart og formatteret fint, og det kan man så debugge hvis man vil i browseren. Desuden kan der genereres Source Maps fra CoffeeScript compileren (transpileren?).

Nu kan man jo godt se at du er ny til spindelprogrammering. Så jeg kondolerer. Der ingen der påstår at det ligefrem er godt gennemtænkt, især når de forskellige teknologier oprindeligt nærmest var udviklet uafhængigt af hinanden.

Personligt ville jeg være trist hvis CSS brugte CamelCase til sine attributter. CSS er et beskrivelsessprog, ikke et programmeringssprog og det bør ligne derefter. JavaScript kan jo ikke håndtere bindestreger i navnene, da det er et programmeringssprog hvor minus er en operator.

Heldigvis er navnene fra CSS til JavaScript enormt forudsigelige. background-position er style.backgroundPosition, text-align er style.textAlign, osv., så i det mindste behøver du faktisk kun slå det op én gang. (Der er selvfølgelig undtagelser.)

Desuden kan dit problem klares med HTML og CSS alene. JavaScript behøver slet ikke blive involveret.

Desuden kan dit problem klares med HTML og CSS alene. JavaScript behøver slet ikke blive involveret.

Javel ja, og kunne du så løfte sløret for hvordan det lige skulle kunne lade sig gøre?

http://line25.com/tutorials/how-to-create-a-pure-css-dropdown-menu

http://line25.com/tutorials/how-to-create-a-pure-css-dropdown-menu

Mjaee, men nu skulle det jo også gerne virke responsive - prøv lige at gå ind på demo'en til dit eksempel.

Ahh come on - vær lidt positiv :-) Du har fået en pointer til en idé til hvordan det kan lade sig gøre på en elegant måde. At lave responsivt design er jo dit arbejde. Bootstrap kan hjælpe men kræver jQuery.

Du spurgte specifikt hvordan man laver en dropdown menu i pure CSS/HTML.

Responsivt kan man se på dette link fundet i Google: http://www.cssscript.com/demo/pure-css-mobile-compatible-responsive-drop... Det burde være en start.

Ahh come on - vær lidt positiv :-) Du har fået en pointer til en idé til hvordan det kan lade sig gøre på en elegant måde. At lave responsivt design er jo dit arbejde. Bootstrap kan hjælpe men kræver jQuery.

Du spurgte specifikt hvordan man laver en dropdown menu i pure CSS/HTML.

Responsivt kan man se på dette link fundet i Google: http://www.cssscript.com/demo/pure-css-mobile-compatible-responsive-drop... Det burde være en start.

Men men men, jeg har sådan set fået det jeg har lavet til at fungere fint, bare min dropdown menu ikke overlapper den ovenliggende menu.

Og når jeg ser på dine eksempler, er CSS dropdownerne jo også lavet så de ikke overlapper, så ville de ikke også lide af samme problem hvis dropdown menuen overlappede den ovenliggende, nemlig at touchstart i overmenuen fyrer et click af i undermenuen - og så er vi jo lige vidt.

.. kommentar skulle i anden tråd.

Der bliver gentagne gange nævnt uheldige designvalg ved JavaScript. Er der ikke nogen af dem som nævner dette, som kan kaste lidt lys over, hvilke designvalg der er uheldige, og så samtidigt nævne nogle af de glimrende designvalg der trods alt er i JavaScript, som mangler i andre programmeringssprog.

Der er skrevet en glimrende bog om præcis det emne, 'JavaScript: The Good Parts'. Blandt det der bliver nævnt som de gode ting er dets funktionelle natur og måden nedarvning er implementeret, men det er selvfølgelig en smagssag.

Bland det dårlige kan nævnes: Der er to ligheds operatorer, == og ===, og de opfører sig forskelligt. == er ikke transitive, det vil sige: false == undefined // false false == null // false null == undefined // true

'void' betyder normalt 'ingen værdi'. I Javascript er det en funktion der returnerer undefined.

Hvilke problemer der i det hele taget er med undefined kan du læse mere om her: https://javascriptweblog.wordpress.com/2010/08/16/understanding-undefine...

Men med hele den smøre vil jeg gerne tilføje at jeg godt kan lide at programmere i JavaScript - det kræver bare lidt mere end så mange andre sprog at man kender finurlighederne.

Der er skrevet en glimrende bog om præcis det emne, 'JavaScript: The Good Parts'.

+20 :)

Bemærk iøvrigt at emnet ikke længere er blandt mest debaterede - et andet emne, med 15 svar er nu i toppen på forsiden af v2 - men nu slår jeg på en død hest ...