Ikke længere legetøj: Javascript er blevet nettets assemblersprog

GOTO: Hvorfor køre så meget på serversiden, når alle browsere i dag har et fuldt styresystem i form af Javascript? Scott Hanselman fra Microsoft slog i sit indlæg på Goto til lyd for mere respekt for Javascript.

Det er bygget ind i hver eneste browser. Det blev i lang tid betragtet som legetøj. Og det har overtaget internettet.

Javascript er fremtiden, lød det fra Scott Hanselman, principal program manager hos Microsoft, da han stod på scenen tirsdag til udviklerkonferencen GOTO i Aarhus.

»Javascript var det fjollede legetøj, som blev brugt til alert-bokse, eller hvis det skulle være rigtig avanceret, til inputvalidering af tekst. Så var der nogen, som kodede Pacman i Javascript, og det var fantastisk. Men det var ikke nok for alle,« forklarede han i en hurtig gennemgang af teknologien.

En Commodore 64-emulator kodet i Javascript var det, som personligt fik Scott Hanselman til at se anderledes på, hvad man kunne med Javascript, og så kom der en ny udvikling, som ’blæste hans hjerne ud’.

»Det var en komplet virtualisering af en x86-maskine i Javascript. Inklusive masser af processor-fejl,« sagde han og demonstrerede mulighederne.

»Hvad hvis jeg kan kompilere en C-applikation? Nu er jeg inde i en browser, der kører Javascript, som kører Linux, faking en x86 i user-mode, og kompilerer en C-applikation, der siger ’hello world’,« sagde han, mens kan kastede kodelinjer på storskærmen.

Budskabet var, at Javascript er blevet voksen og ikke længere er legetøj. Nu er det en virtuel maskine, et fuldt styresystem med hukommelseshåndtering og det hele, som findes i hver eneste browser. Og med masser af maskinkraft på selv smartphones nu til dages, er der ikke nogen grund til at flytte alle mulige beregninger til skyen og så servere dem for klienten.

»Vi bliver ved med at skalere serveren op, og sende mere og mere data til browseren, som om den er dum. Jeg tror godt, vi kan give den mere at lave. Og selv en billig Android-telefon har nu om dage en processor med to kerner,« forklarede han.

Selvom Javascript nu bliver brugt overalt, og man ikke længere kan ’være imod’ Javascript, men må acceptere den gigantiske succes, det er blevet, er det som om, at det ikke helt er gået op for alle, pointerede han.

»Javascript er i sig selv et helt operativsystem. Vi slås om, om vi bruger Mac, Linux eller Windows, og så har vi alle et helt styresystem i vores browser, der ikke kræver andet af os end at blive elsket. Du har et komplet styresystem på din telefon, der lever inde i browseren, som har sneget sig ind fra højre,« sagde Scott Hanselman

»Så hvis du ikke har indset, at Javascript er det største, siden Gud talte med Moses – var det for meget? – så har du ingen sjæl, sagt med al respekt. Det er stort,« sagde han med et glimt i øjet.

Men det er ikke nok at kunne bruge alle de smarte tilføjelser, der siden hen er kommet, lød beskeden fra Scott Hanselman.

»Javascript er assembler-sproget på nettet. Og hvad gør man så? Man bygger nye sprog oven på det. Intet er bedre end nye abstraktionslag. Men jeg vil opfordre folk til ikke at lade lagene skjule kompleksiteten. Ingen skriver Javascript længere, men jQuery. Du er nødt til at kunne skrive Javascript fra bunden.«

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

Javascript, som det er i dag, vil sandsynligvis ikke være en gangbar løsning i det lange løb. Der må ske noget nyt

http://www.version2.dk/artikel/googles-nye-dart-sprog-skal-afloese-javas...

I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native:

http://newz.dk/zuckerberg-anerkender-at-html5-app-var-en-fejl

As a result, JavaScript is missing many of the features necessary to be able to productively write and maintain large-scale applications:

http://blogs.msdn.com/b/somasegar/archive/2012/10/01/typescript-javascri...

Citater taget ud af kontekst er selvfølgelig fy, men jeg kunne ikke lade vær.

Jeg håber Google og Microsoft kun bruger disse hjemmelavede sprog (TypeScript, Dart) til at kunne høste erfaring til at lave en ny fælles standard version af Javascript (Ex. codename JStrict).

  • 7
  • 1
Torben Mogensen Blogger

En abstrakt maskine, der skal bruges som målsprog for oversættelse, bør opfylde flere kriterier:

  1. Den skal være relativt simpel.
  2. Det skal være veldefineret, hvad der sker i alle situationer.
  3. Den skal ikke have indbyggede elementer, der vanskeliggør effektiv eksekvering.

Javascript opfylder ingen af disse kriterier. Dens eneste fordel som abstrakt maskine er, at alle browsere kan udføre Javascript.

Så jeg så helst, at W3C (eller et konsortium af browserfirmaer) definerede en simpel abstrakt maskine, der kan erstatte Javascript som målmaskine for diverse browsersprog. De måtte i den forbindelse gerne lave standardoversættere fra Javascript og andre sprog til denne abstrakte maskine, så man slipper for at have et større antal køretidssystemer i sin browser.

  • 13
  • 1
Daniel Udsen

Grunden til at mere og mere kode ligger serverside er at mere og mere kode idag er tæt forbundet til en database samt at server miljøet er nemmere at teste/vefiricere end det mildst taget kaotiske browser miljø.

En standard er i teorien en løsning på browser kaos men al historisk praksis har vist at det er dybt urealistisk at forvente at en standard på web området bliver overholdt, så i praksis vil applikationer der er tunge serverside og lætte clientside ofte have færre alhvorlige fejl, simplelthen fordi du kan kontrolere og teste dit servermiljø til en langt højere grad end du kan dine kunders browsermiljø.

  • 5
  • 2
Peter Müller

Din antagelse af om hvorvidt man kan teste frontend kode er fejlagtig.

Moderne webapplikationer benytter mange af de dogmatiske design patterns som har vist deres værd i andre sammenhæng igennem de sidste mange år i andre programmeringssprog. MVC, MVVM, Objserver, PubSub og lignende er meget udbredte. Fælles for dem er modularisering og testbarhed.

Din indvending på manglende testmuligheder bør gå på test af ensartethed af rendering på tvært af browserplatforme. Selv dette er testbart, dog med noget mere arbejde.

TLDR; Du tager fejl

  • 5
  • 1
Troels Henriksen

Javascript opfylder ingen af disse kriterier. Dens eneste fordel som abstrakt maskine er, at alle browsere kan udføre Javascript.

Det virker sandsynligt at der med tiden vil opstå en ad-hoc delmængde af Javascript, som vil nyde høj ydelse i alle de moderne JIT-oversættere. Man kan så oversætte andre og bedre sprog til denne delmængde af Javascript, og få et acceptabelt resultat. Det er ikke så æstetisk, men det burde fungere fint i praksis.

Når det så er sagt, så er det morsomt at Javascript med V8 er begyndt at blive opfattet som et "hurtigt" sprog. Det er stadigvæk enormt langsomt i forhold til mere fornuftige sprog (inklusive andre dynamiske) - V8 har brugt klassiske VM-teknikker så det ikke længere er latterligt sløvt, men det er stadigvæk ret langsomt.

  • 3
  • 0
Torben Mogensen Blogger

Det virker sandsynligt at der med tiden vil opstå en ad-hoc delmængde af Javascript, som vil nyde høj ydelse i alle de moderne JIT-oversættere. Man kan så oversætte andre og bedre sprog til denne delmængde af Javascript, og få et acceptabelt resultat. Det er ikke så æstetisk, men det burde fungere fint i praksis.

Sålænge denne delmængde ikke er dokumenteret, og der er enighed om den blandt browserproducenter, så hjælper det ikke ret meget.

Jeg så på ICFP et foredrag om, hvordan man genererer Javascript fra sin compiler, sådan at V8 kan optimere det. Der var en del oplagte ting (undgå implicitte casts, undgå nedarvning, osv), men der var mange specieltilfælde, hvor man kunne tro, at V8 ville optimere, men hvor den ikke gjorde det.

  • 3
  • 0
Troels Henriksen

Sålænge denne delmængde ikke er dokumenteret, og der er enighed om den blandt browserproducenter, så hjælper det ikke ret meget.

Dokumentation kan opstå senere, baseret på empiriske observationer. I praksis er der en yderst begrænset mængde af Javascript-maskiner der har kommerciel interesse, så det burde være muligt at finde en delmængde af Javascript der håndteres effektivt af dem alle. Når først disse ydelsesdetaljer udnyttes i praksis, vil der være pres på Javascript-implementørerne til at vedlideholde dem.

Som sagt, det er ikke kønt, men det er en sandsynlig (og pragmatisk) mulighed. Det vil ikke just være første gang man optimerer efter en ad hoc ydelsesmodel.

  • 0
  • 1
Benni Bennetsen

JavaScript blev udviklet til alert boxe - Vi har drevet det langt ud over, hvad det er tænkt til.. Synes Dart er et frisk indspark, ved ikke om det er det rigtige, men MSs med at lave abstraktionslag i håb om at lappe videre er vist desværre bare at udsætte problemerne i årene der kommer.. Men interessant at de tilsyneladende er enige med Google i at fremtidens OS er webbaseret..

  • 1
  • 0
Allan Ebdrup

Rolf, ikke nok med at tage citater ude a kontekst, har du kigget på hvem du citerer?
To af indlægene er fra personer der er involveret i at pushe deres eget firmas "overbygning" til JavaScript, og det miderste indlæg handler om at bygge telefon apps i JavaScript (et område der har været i rivende udvikling).

Udfordringen ved den javascript-kode jeg har set på store projekter har været at man ikke har tænkt godt nok over kodestruktur, arkitektur, modularisering, test osv up front, men at projektet bare er vokset ved knopskydning.

At vedligeholde store kodebaser er svært i et vilkårligt programmeringssprog, og af en eller anden grund har mange brugt rigtig mange år på at genopdage alle de gode ting man kan gøre i andre programmeringssprog i JavaScript. Jeg må indrømme at det har været forunderligt at se til fra sidelinjen, når nogle folk har proklameret at JavaScript ikke dur, fordi man ikke kan bygge store applikationer med jQuery og ellers ikke meget struktur på sin kode. You don't say?

Men efterhånden er der kommet mange gode rammeværk, til også at bygge store applikationer, i JavaScript. Med dokumentation, tutorials, bøger, communities osv. Og de bliver hele tiden bedre. Nogle af rammeværkene har eksisteret i mange år, og jeg her ikke stødt på en eneste artikel fra nogen der har brugt et godt rammeværk til at bygge en stor applikation, som har proklameret at de simpelthen ikke kunne bygge deres applikation fordi JavaScript manglede sprogkonstruktioner.

Så hvis du vil bygge en stor applikation, er det er bare med at smøge ærmerne op og komme i gang. Hvis nogen tror at alle problemerne, der er med at vedligeholde en stor kodebase, løser sig med Dart eller TypeScript, bliver de fælt skuffede.
Tvært imod, du skal hellere vælge et godt rammeværk, end at kaste dig over Dart eller TypeScript, hvis du vil bygge noget stort.
Men der er givet nogle der bedre vil kunne lide de sprog, og fred være med det.

  • 6
  • 0
Peter Jensen

Kør det på serveren fordi det giver slutbrugeren en kvalitets oplevelse og ikke kræver det køber de seneste nyeste superhardware hele tiden.
Det forudsætter jo at udbyderen af servicen har noget ordentlig hardware, og det er jo nok der skoen trykker - det kan spares penge ved bare at køre services på noget billigt lort.

  • 2
  • 6
Mads Randstoft

Ikke at det undre mig hvad nogen brugere herinde skriver til dette. Hvis man ikke kan finde ud af javascript og prototype baseret programmering er det jo nemt at affærdige det som ubrugeligt, det er jo i hvert fald ikke jer, der burde lære noget nyt vel?

Javascript virker glimrende som programmeringssprog i browseren. Det er (med enkelte undtagelser, man bør tage højde for) dejligt isoleret. Det er hurtigt og giver brugeren den bedste oplevelse (Kære Peter Jensen, Nej det giver ikke brugeren en god oplevelse at skulle vente 8-10sec hver gang de indtaster noget for at få et svar fra serveren og kunne gå videre)

Der er nogle dogmer man skal tage til sig dog. Hver opmærksom på at alt kode køre hos brugeren! Alt data der sendes fra brugeren skal valideres (Det er der ikke noget nyt i, men nogen har ikke lært det endnu og ønsker derfor at holde alle beregninger på backend så man ikke behøver lave alle de valideringer etc.) Man skal også gøre sit arbejde bedre (Brugeren kan jo nemt følge med i hvad der bliver gjort, så alle de hacks man kan slippe af sted med i backend er ikke brugbare mere, tænk at man ligefrem skal lave sit arbejde!) Alt hvad man laver skal være event baseret og arbejde i små units. Det nytter ikke noget at lave batch jobs i javascript eller ignorere muligheden for at brugeren (eller hans plugins) kan køre kode sammen med din. Lad være med at kæmpe mod brugere, lær i stedet hvordan man laver god kode der kan køre i samarbejde med brugerens!

Til TypeScript og Dart etc brugere: Hvis man som programmør ikke kan lære nye ting (fx. prototypede sprog som javascript) og stædigt holder fast i det ene sprog man har lært (Java, C# eller hvad det nu er) er det så ikke fordi man er i den forkerte branche? Veteranbil mekanikere har muligheden for ikke at skulle lære noget overhovedet, måske var det et job at kaste sig over?

  • 2
  • 1
Troels Henriksen

Til TypeScript og Dart etc brugere: Hvis man som programmør ikke kan lære nye ting (fx. prototypede sprog som javascript) og stædigt holder fast i det ene sprog man har lært (Java, C# eller hvad det nu er) er det så ikke fordi man er i den forkerte branche?

Undskyld, men hvordan kan det være folk der foreslår nye sprog, der begår denne fejl? Det virker da som om Javascript-programmørerne er de mest stædige (hvis vi endelig skal gå i gang med personangrebene), da de afviser muligheden for andre sprog. Selv koryfæer som Lars Bak, manden bag V8, har sagt så sent som i går at velskrevne programmer i prototype-sprog (han brugte Self som eksempel) havde en klasselignende struktur.

Selv er jeg ikke udpræget tilhænger af klasser. Jeg vil bare have et sprog med fornuftige algebraiske datatyper, så man har noget at forholde sig til.

  • 1
  • 0
Jacob Christian Munch-Andersen

Sikke da noget vrøvl, JavaScript på klienten kan netop gøre oplevelsen meget hurtigere for brugeren da mange ting kan klares helt uden at vente på svar fra serveren.

I øvrigt er det min erfaring som udvikler at browsere generelt bruger meget mere CPU-tid på dom layout end på at afvikle JavaScript. Hvis din browser bruger lang tid på at vise en side er det i de fleste tilfælde fordi serveren er langsom, og i de fleste af de resterende tilfælde fordi siden har en kæmpe tidskrævende dom struktur.

  • 2
  • 0
Flemming Seerup

Til TypeScript og Dart etc brugere: Hvis man som programmør ikke kan lære nye ting (fx. prototypede sprog som javascript) og stædigt holder fast i det ene sprog man har lært (Java, C# eller hvad det nu er) er det så ikke fordi man er i den forkerte branche

TypeScript er en forbedring af JavaScript, og flere af de features som TypeScript tilbyder (men ikke alle), er med i den kommende version af javascript.

At mene man for enhver pris skal holde fast i den nuværende version, svarer til java udviklere at fastholde at kode til version 1.0 af java, og nægte at bruge nye features og værktøjer som understøttes af java 1.7.
Verden udvikler sig, og vi bruger heller ikke hulkort mere ;)

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize