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

Swift er en klar vinder i iOS-verdenen, viser et rundspørge blandt norske it-fagfolk. Men Javascript er generelt set det mest populære programmeringssprog.
65

Javascript er det programmeringssprog, som it-folk mener, at flere burde lære, efterfuldt af C#, C/C++ og Python.

Det viser en stikprøve, som Version2's norske søstermedie, digi.no, har gennemført blandt læserne med 1.700 deltagere.

Hvilke programmeringssprog bør flere lære - svar blandt digi.no-læsere

Illustration: digi.no

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

Resultatet er temmelig tydeligt:

Næsten ingen stemte for Objective-C.

Swift er en klar vinder i iOS-verdenen.

.NET-sprog scorer meget højt. Slår man Visual Basic og C# sammen, har de to sprog fået 17,9 procent af stemmerne.

Færre fejl med Javascript i browsere

Ifølge digi.no er det en kuriøsitet, at Assembly og COBOL slår sprog som Go og Rust af banen.

Javascript vinder, fordi man ifølge læserne skal kunne dette programmeringssprog, hvis man arbejder med webudvikling. Og for mange er kompetencer inden for Javascrip et naturlig skridt, efter at man har lært grundlæggende HTML.

Fagfolk peger på, at leverandørene har spenderet enorme ressourcer på at optimere motoren i Javascript, hvilket har gjort sproget utrolig hurtigt. Standardisering har også spillet positivt ind: Der er nu færre fejl på tværs af forskellige browsere.

Men populariteten af Javascript kan også skyldes trenden i it-verdenen med stigende udvikling og anvendelse af webapplikationer, som er sket, fordi sprogene er blevet bedre og nettet hurtigere.

I modsætning til skrivebordsapplikationer slipper man for tunge udrulninger, og man får alle brugerne over på samme version.

Fra et norsk startupfirma, Ardoq, lyder det:

»Softwaren bliver nemt tilgængelig for brugeren, og det bliver meget enklere for os at distribuere den. Web er som platform blevet meget bedre de seneste år - for fem år siden ville det have været muligt,« siger Erik Bakstad, der er teknisk direktør Ardoq.

En app, der er udviklet med Javascript kan køre på næsten alle enheder, tilføjer han. Man slipper for at versionere til OS X, Linux og Windows.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (65)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mogens Hansen

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

Hans Schou

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.

Mikkel Bo Mikkelsen

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

Troels Henriksen

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?

Glenn Dufke

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

Peter Christiansen

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?

David Rechnagel Udsen

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.

Ditlev Petersen

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

Christian Nobel

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?

David Rechnagel Udsen

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.

Troels Henriksen

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.

Palle Simonsen

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

Palle Due Larsen

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.

Rune Jensen

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.

Baldur Norddahl

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.

Janus Knudsen

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.

Palle Simonsen

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

Nikolaj Brinch Jørgensen

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.

Christian Nobel

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.

Baldur Norddahl

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.

Lasse Hillerøe Petersen

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.

Troels Henriksen

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.

Christian Nobel

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?

Troels Henriksen

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.

Rune Jensen

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.

Rune Jensen

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.

Christian Nobel

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.

Christian Nobel

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.

Rune Jensen

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

Nikolaj Brinch Jørgensen

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.

Christian Nobel

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.

Jonas Høgh

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">
Christian Nobel

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?

Christian Nobel

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.

Nikolaj Brinch Jørgensen

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

David Rechnagel Udsen

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.

Nikolaj Brinch Jørgensen

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.

Christian Nobel

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.

Rasmus Kjær

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.

Log ind eller Opret konto for at kommentere

Disse programmerings­sprog har resulteret i flest kendte sårbarheder

6

Groovy er med kæmpehop tilbage på top-20

0

Her er Java 12’s nye Switch

10
I samarbejde med jobfinder logo - Danmarks største job- og karrieresite for ingeniører og it-professionelle.
Mest debatteredeMest læste
Jobfinder Logo
Upload dit CV
Få nye job via e-mail
Upload din jobannonce
Job fra Jobfinder