Javascript er populært til mobilapps

Illustration: Mehaniq/Bigstock
Krydsplatforms-miljøer har langt om længe gjort indhug i mobil udvikling.

Ifølge en ny undersøgelse beskæftiger ganske mange Javascript-udviklere sig med noget andet end frontend-webapplikationer.

Npm, der står bag Javascript-pakkeværktøjet af samme navn, er ophav til undersøgelsen, der består af 33.000 svar fra 194 lande, på tværs af 23 industrier. Det skriver Adtmag.

Undersøgelsen kommer frem til, at 46 procent af respondenterne bygger mobile apps og skrivebords-programmer. Det gælder eksempelvis samarbejdsværktøjet Slack.

Det er udviklingsmiljøer som React Native, Nativescript, Phonegap/Cordova, Ionic med videre, der har givet Javascript fodfæste på de ikke-webbaserede platforme.

Blandt andre nyheder i undersøgelsen er, at Reacts vækst fortsætter med at dominere. 63 procent af udviklerne bruger React, hvilket er en stigning på fem procent fra sidste år. Det gør React mere end dobbelt så populært som det næststørste miljø, der er Angular.

Typescript vinder også frem, med 61 procent af alle Javascript-udviklere i folden. Det er en stigning på 31 procent stigning i brugen siden sidste undersøgelse.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Magnus Jørgensen

Jeg synes at javscript er et udemærket sprog. Det mangler dog nogle få ting. Hvis man f.eks. skal håndtere en long variable (int64), så er der ikke nogle indbyggede typer til det. Man skal derfor ud i mystiske hacks for at lave helt almindelige operationer.

Christian Nobel

Jeg synes at javscript er et udemærket sprog.

Javascript er og bliver noget lort.

Elendig typingcasting (eller rettere totalt fravær af selvsamme).
Bizarre caseafhængige navne.
Umulig debugging
Scriptet, ikke compileret
.
.
.

Som er prøve at programmere en elastik.

Den eneste grund til at Javascript er "populært" er udelukkende fordi man ikke kan undgå det hvis man skal have funktionalitet på klientsiden af en webpage.

Magnus Jørgensen

Elendig typingcasting (eller rettere totalt fravær af selvsamme).


Type systemet i javascript er helt klart den største ulempe ved sproget.
Men det betyder ikke at det er et problem og at man ikke kan løse opgaver med sproget. Man skal blot være klar over det.

Bizarre caseafhængige navne.


Muligvis, men det vender man sig hurtigt til. Desuden skæmmer det ikke læsbarheden.

Umulig debugging


Javascript er da nemt at debugge. Kan du komme med et eksempel?

Scriptet, ikke compileret


Det er jo et fortolket sprog. Men det bliver jo faktisk JIT compilet i de fleste runtime miljøer. Desuden er javascript muligvis det hurtigste fortolkede sprog overhovedet. Prøv at benchmarke hastigheden med f.eks. CPython.

Du skal jo, klart nok, ikke sammenligne javascript med et kompileret sprog. Det ville være en fejl.

Christian Nobel

Men det betyder ikke at det er et problem og at man ikke kan løse opgaver med sproget. Man skal blot være klar over det.

Ja bevares, man kan også vænne sig til at bruge 3 gange så lang tid på en opgave, fordi man er nødt til at flette alle mulige forholdregler ind.

F.eks. tage højde for:

funktion blabla (variabel)
{
var helstettal = 1 + variabel
}

Nå og hvad bliver helstettal hvis man propper f.eks 22 ind i variabel?

Tja lidt efter forgodtbefindende bliver det enten 122 eller 23.

Virkelig fedt.

Muligvis, men det vender man sig hurtigt til. Desuden skæmmer det ikke læsbarheden.

Ja og man kan også vænne(!) sig til at skrive på russisk - men det gør det ikke lettere.

Javascript er da nemt at debugge. Kan du komme med et eksempel?

Ja hvis jeg høvler f.eks. et Freepascal program gennem compileren, så finder den alle triviel fejlene for mig.

Men med Javascript - puha.

Det er jo et fortolket sprog. Men det bliver jo faktisk JIT compilet i de fleste runtime miljøer.

Men jeg kan stadig ikke lave ordentlig binær kode ud af det, og jeg har stadig ikke en ordenlig compiler til at hjælpe med dummefejl.

Desuden er javascript muligvis det hurtigste fortolkede sprog overhovedet.

So what?

Prøv at benchmarke hastigheden med f.eks. CPython.

Man kan altid finde noget der er langsommere, men det er nu heller ikke hastigheden jeg bitcher over, men den generelle elendighed, og den kollossale mængde tid man skal bruge på at løse selv helt trivielle opgaver.

Du skal jo, klart nok, ikke sammenligne javascript med et kompileret sprog. Det ville være en fejl.

Hvorfor det?

Man påstår at Javascript er et programmeringssprog - så skal det da også kunne tåle sammenligning.

Magnus Jørgensen

Tja lidt efter forgodtbefindende bliver det enten 122 eller 23.

Virkelig fedt.

Jeg kan godt se hvad du mener, men det er efter min mening, normalt ikke et problem. Mængden af type checking i et javascript project er forsvindende lille.

Ja og man kan også vænne(!) sig til at skrive på russisk - men det gør det ikke lettere.

Det er vist en overdrivelse der hindrer forståelsen. Enhver der kan læse c, c++, C# eller Java har ikke problemer med at forstå disse ting.

Ja hvis jeg høvler f.eks. et Freepascal program gennem compileren, så finder den alle triviel fejlene for mig.

Men med Javascript - puha.

Du kan nemt forbinde Chrome Dev Tools til et nodejs runtime og få en udemærket debugger.

Men jeg kan stadig ikke lave ordentlig binær kode ud af det, og jeg har stadig ikke en ordenlig compiler til at hjælpe med dummefejl.

Hvilket fortolket sprog har denne mulighed?
Det lyder som om at du har noget imod fortolkede sprog.

Man kan altid finde noget der er langsommere, men det er nu heller ikke hastigheden jeg bitcher over, men den generelle elendighed, og den kollossale mængde tid man skal bruge på at løse selv helt trivielle opgaver.

Kan du ikke komme med et eksempel her?
En opgave der tager relativt lang tid at implementere i Javascript på grund af Javascripts ulemper.

Hvorfor det?

Man påstår at Javascript er et programmeringssprog - så skal det da også kunne tåle sammenligning.

Jo da, men de færreste fortolkede sprog har en kompiler der kan finde fejl.

Jeg vil give dig ret i alle dine pointer om Javascripts mangler og fejl, men personligt mener jeg bare ikke at det er et stort problem. Personligt synes jeg faktisk at man løser trivielle opgaver hurtigt i Javascript. Der er dog nogle opgaver som jeg aldrig ville vælge javscript til at løse. Jeg kunne ALDRIG finde på at skrive en driver i Javascript. Men jeg kunne heller aldrig finde på at skrive en web backend i Fortran.

Javascript er en udemærket løsning til et bestemt opgave rum. Sproget overlapper med en del andre sprog i dette rum. Hvis du skal lave en simpel app til en mobil telefon er det en udemærket løsning, efter min mening.

Christian Nobel

Jeg kan godt se hvad du mener, men det er efter min mening, normalt ikke et problem. Mængden af type checking i et javascript project er forsvindende lille.

Tænk, jeg vil så afgjort kalde det et ret så stor problem.

Eksempelvis: jeg laver en beregning når jeg forlader et inputfelt, som skal lægge værdien af det til et andet - der er min tolerancetærskel lidt for lavt til at jeg kan acceptere at udfaldet enten kan være 122, eller de 23 det vitterlig skal være.

Baldur Norddahl

Jeg skulle til at liste en række Javascript ord op, og så ender jeg bare med en fejl.

Så det stinker langt væk at at der vitterlig er et problem med Javascript.

Nej det er en server fejl der opstår, i forbindelse med at de forsøger escape "farlige" ord, eksempelvis "javascript". Det har været her i årevis og gør det meget svært at skrive indlæg om visse sprog.

Det er lidt bekymrende omkring kodekvaliteten bag sitet...

Hint: indsæt nogle ekstra tegn, eksempelvis skriv java_script for at fixe det. Man kan ofte skrive ordet én gang men flere gange får den til at fejle. Brug Gennemse funktionen til at verificere at det ikke fejler.

Bjarne Nielsen

Altså, nu er det her ikke et debatforum for IT-professionelle, vel, så vi kan vel ikke forvente at kunne skrive om IT-relaterede spidsfindigheder. Det må vi gøre i vores fagmedier; her kan vi diskutere politik og andet samfundsfagligt.

...hov, vent lige et øjeblik!

Christian Nobel

Nej det er en server fejl der opstår, i forbindelse med at de forsøger escape "farlige" ord, eksempelvis "javascript". Det har været her i årevis og gør det meget svært at skrive indlæg om visse sprog.

Det havde jeg sådan set også luret at det var noget i den stil - hvorfor Javascript ord så skulle være et specielt problem lugter at at der er skrevet noget i NodeJS.

Det er lidt bekymrende omkring kodekvaliteten bag sitet...

Det må anses for ret uprofessionelt at et site der hævder at være for IT professionelle, som Bjarne også skriver, kan stå bag noget så ringe.

Men det er vel slet ikke meningen at man skal debattere noget så politisk ukorrekt som programmering.

Hint: indsæt nogle ekstra tegn, eksempelvis skriv java_script for at fixe det. Man kan ofte skrive ordet én gang men flere gange får den til at fejle.

Jeg kan prøve at obskuficere teksten, så kan det være jeg har heldet med mig

Brug Gennemse funktionen til at verificere at det ikke fejler.

Gør jeg så sandelig også - hver gang!

Christian Nobel

Jeg kan godt se hvad du mener, men det er efter min mening, normalt ikke et problem. Mængden af type checking i et javascript project er forsvindende lille.

Tænk, jeg vil så afgjort kalde det et ret så stor problem.

Eksempelvis: jeg laver en beregning når jeg forlader et inputfelt, som skal lægge værdien af det til et andet - der er min tolerancetærskel lidt for lavt til at jeg kan acceptere at udfaldet enten kan være 122, eller de 23 det vitterlig skal være.

Det er vist en overdrivelse der hindrer forståelsen. Enhver der kan læse c, c++, C# eller Java har ikke problemer med at forstå disse ting.

Nej bevares, man kan da godt læse det, og det er jo helt logisk (at jeg så har været nødt til at proppe nogle x'er ind i Javascript udtrykkene, for at kompensere for dette forums håbløse funktionalitet, jævnfør ovenfor, skal så dog ikke ligge Javascript til last - så man skal lige selv fjerne alle de små x'er jeg har proppet ind - suk):

xdocument:
Nå vi skriver åbenbart med småt.

getxElementxByxId:
Nåeh, nej vi starter med småt, og så bruger vi versaler til at indikere "orddeling".

onxreadyxstatexchange:
Nej, og så åbenbart alligevel ikke.

innerxHTML:
Nåeh ja, vi kan selvfølgelig også lade et helt delord være med versaler.

XMLxHttpxRequest():
Jamen hov, vi kan jo godt lade noget starte med versaler også.

Osv, osv.

Du kan nemt forbinde Chrome Dev Tools til et nodejs

Dut - dut - dut ....

Hvem kan i ædru tilstand finde på at bruge noget så tåbeligt som JavaScript til at lave serverside programmering?

Hvilket fortolket sprog har denne mulighed?

Nu er det mange dekader siden, men som jeg husker det var selv en urbasic væsentlig mere hjælpsom.

Det lyder som om at du har noget imod fortolkede sprog.

Som udgangspunkt - ja.

En opgave der tager relativt lang tid at implementere i Javascript på grund af Javascripts ulemper.

F.eks. som nævnt ovenfor, noget helt så banalt som at lægge to tal samme, og være 100% sikker på at resultatet også er hvad man kan forvente.

Det er ikke uden grund at Javascript er det mest "populære" sprog på StackExchange - så sandelig ikke fordi det er godt, men fordi det er det der er mest bøvl med.

Jo da, men de færreste fortolkede sprog har en kompiler der kan finde fejl.

Sådan set kun en understregning af min pointe!

Hvis du skal lave en simpel app til en mobil telefon

Så vil jeg lave det som en HTML5 applikation - at jeg så skal slås med at man stadig efter 25 år ikke kan blive enige om fælles standarder for browsere, og deres adfærd er dybt tragisk.

Magnus Jørgensen

Hej Christian

Tak for svar.

Eksempelvis: jeg laver en beregning når jeg forlader et inputfelt, som skal lægge værdien af det til et andet - der er min tolerancetærskel lidt for lavt til at jeg kan acceptere at udfaldet enten kan være 122, eller de 23 det vitterlig skal være.

Et hvert sprog der læser en input værdi fra en Textbox skal vel parse inputet fra streng til double/int. Det er vel ikke anderledes her.

De property og functions navne der her nævnes er en del af Browser API og ikke Javascript. Du kan vel næppe klandre Javascript for det.

Hvem kan i ædru tilstand finde på at bruge noget så tåbeligt som JavaScript til at lave serverside programmering?

Hvis det skal være noget simpelt så, jo da, det kunne jeg da godt finde på.

Som udgangspunkt - ja.

Ok. Så giver det hele jo mere mening. Ville det så ikke være bedre et argumentere for/imod fortolkede sprog?

Christian Nobel

Et hvert sprog der læser en input værdi fra en Textbox skal vel parse inputet fra streng til double/int. Det er vel ikke anderledes her.

Når nu der ikke findes nogen typing som så i Javascript?

For hvis jeg i et andet sprog definerer en variabel som f.eks. et heltal, så vil det selvføgelig (fordi input kun kan være en streng) være nødvendigt at lave en strtoint, men da jeg ikke ved hvad en variabel ender som i Javascript, så er det op af bakke.

Men hvad vil du konkret gøre?

De property og functions navne der her nævnes er en del af Browser API og ikke Javascript. Du kan vel næppe klandre Javascript for det.

Jeg ser tingene som tæt forbundet, da jeg som sagt kun benytter Javascript til forbedring af browserfunktionalitet.

Hvor går skillelinjen?

Og hvis der var nogen der så lavede et begavet ikke casefølsomt funktionssprog, så kan de for min sags skyld kalde det hvad de vil, men jeg (og givetvis 99% af resten af kloden) anser ovenstående som Javascript.

Hvis det skal være noget simpelt så, jo da, det kunne jeg da godt finde på.

Der er vi så så forskellige, men fred være med det.

Ok. Så giver det hele jo mere mening. Ville det så ikke være bedre et argumentere for/imod fortolkede sprog?

Nej for det var så bare en sidekommentar der kom med undervejs, jeg vil stadig holde fast i mit hovedudgangspunkt om elendig typing, ulogisk syntaks og uforudsigelighed, uagtet vi taler kompileret eller fortolket.

Magnus Jørgensen

Når nu der ikke findes nogen typing som så i Javascript?

Hvis du parser en streng til et number I JavaScript så forbliver den et number I det runtime. Så du vil ikke få 122 hvis du har sikret dig at typen korrekt.

Hvor går skillelinjen?

Det svarer vel lidt til framework I andre sprog. Der findes sandsynligvis ikke noget der er så rodet og inkonsekvent som browser API til JavaScript, men du må jo huske på at standardiseringen har lidt under de forskellige browser krige. Microsoft nægtede i lang tid at efterleve HTML standarden, så imens nogle ting blev pioneret af MS, andre ting af Netscape/Firefox og andre ting af Google så var der i lang tid ingen enighed om tingene. Men JavaScript sproget er standardiseret i ECMAScript 262. Den første standard blev udgivet i 1997. Disse ting kunne jo muligvis blive rettet uden at JavaScript standarden blev involveret.

Bjarne Nielsen

parseInt("25")

Her vil jeg så gerne have set det andet parameter, radix, være angivet. Det gør måske ikke så meget lige med den streng (bortset fra at jeg ser mange tal encoded som strenge i hexadecimal notation, så jeg bliver altid mistænksom for, om der menes 25 i decimal notation eller 25 i hexadecimal notation).

Men hvis du nu står med noget input, som har foranstillede nuller, som f.eks. "025", er det så i oktal eller decimal notation? Ja, det er så implementationsafhængigt.

PS: Og få mig ikke igang med, hvad der sker, når man konverterer fra byte[] og til String. F.eks. har Java en constructor til String, som kun tager byte[] som parameter, og jeg citerer: "Constructs a new String by decoding the specified array of bytes using the platform's default charset." og "The behavior of this constructor when the given bytes are not valid in the default charset is unspecified". What could possibly go wrong...!

Log ind eller Opret konto for at kommentere