Dansk web-succes skrottede Java og fløj afsted med Node.js

Fildelingstjenesten Ge.tt startede for et år siden helt forfra og skiftede Java-koden ud med det Javascript-baserede Node.js. Det har været en massiv teknologisk succes, forklarer stifterne.

»Jeg elsker Node.js.«

Begejstringen er ikke til at tage fejl af hos Mathias Buus, der er en af iværksætterne bag fildelingenssiden Ge.tt.

Som teknisk ansvarlig i det unge firma er hans arbejde blevet meget sjovere og nemmere, siden hele kodebasen for tjenesten for et år siden blev skrottet og skiftet ud med en helt ny teknologi: Node.js.

Her bruger man Javascript-kode på serveren, og ved hjælp af Googles V8-motor, som blev udviklet til Chrome, kan en webapplikation kodet i Node.js give alvorligt baghjul til mere traditionelle sprog.

»Vi lavede først Ge.tt i Java, men det skalerede ikke ret godt. Vi løb tør for RAM, bare der var ti samtidige brugere. For et år siden fandt vi så Node.js, og nu virker det bare og skalerer helt vildt. Det er ren magi,« siger Mathias Buus, som har det meste af en datalogi-kandidatgrad på bagen, før han gik fuldtids med Ge.tt.

Al Java-koden blev smidt over bord, og det blev en stor lettelse, for Node.js var nærmest som skabt til behovet hos Ge.tt, hvor brugerne deler små og store filer.

»Node.js passer rigtig godt til at streame data, store mængder data, og det er lige netop det, vores tjeneste går ud på. Det er lige i skabet for os,« siger Mathias Buus.

Læs også: Webudvikler begejstret for Node.js: Lynhurtig Javascript på serveren

Kodebasen blev 70 procent mindre

Han har altid været glad for Javascript, og alene derfor er Node.js dejligt at arbejde med for ham. Men ud over personlige præferencer, så er de kontante fordele mange, fortæller han.

»Vores Java-kode var bøvlet og noget spaghetti-kode. I dag er vores kodebase på 30 procent af, hvad den var engang, og vores site kan meget mere end dengang. Derudover er det nemt at bruge, der er nogle fede biblioteker - så i min optik er det nærmest perfekt hele vejen,« siger han.

Den største fordel er dog ydelsen. Ge.tt bruger Amazons sky til at drive tjenesten, som med tiden skal kunne håndtere store mængder brugere fra hele verden.

Hvor et normalt web-setup ville have en tråd til hver bruger, er Node.js eventbaseret, og det kan mærkes i RAM-regnskabet.

»Hver thread koster rigtig meget RAM, op til fire megabyte i stack overhead. I et normalt web framework har du en thread pr. forbindelse, så hvis du har tusind besøgende, bruger du fire gigabyte RAM bare på at holde serveren kørende. Og fire gigabyte RAM er faktisk ret dyrt hos Amazon,« forklarer Mathias Buus.

Nu, med Node.js under motorhjelmen, er det en helt anden verden. Tusind parallelle forbindelser koster kun 60-70 megabyte RAM

»Der er ikke noget overhead, og det er helt fantastisk, hvad det giver dig. Så kan du bruge RAM på noget andet,« siger han.

Ingen chefer til at stoppe dem

Beslutningen om at starte forfra og kode firmaets produkt i et sprog, som dengang var ganske nyt og uprøvet, var ikke noget stort problem hos Ge.tt, som blev startet af Mathias Buus og Tobias Baunbæk, der også er datalog-uddannet.

»Både Tobias og jeg er ’hackere’, så det ligger i vores natur at prøve noget nyt. Men jeg er glad for, at vi ikke havde nogen chefer. Så havde skiftet nok været svært at sælge. Det er nok også det største problem andre steder. Vi gjorde det jo bare,« siger han.

Udviklingen af Ge.tt i Node.js var de to iværksætteres første projekt med den nye teknologi, så meget blev lært hen ad vejen. Koden er faktisk blevet skrevet om flere gange undervejs.

Det skyldes ikke kun, at de to udviklere lærte nyt undervejs, men også at Node.js har ændret sig markant i løbet af det år.

»Da vi startede, var Node i version 0.2. Nu er det i 0.4 og API’erne er fuldstændig ændret siden dengang. Vi ville slet ikke kunne køre vores gamle kode. På en eller anden måde er det fedt, at de tør lave det om og ikke være bundet af gammel kode. På den anden side er det også det, der gør det svært at sælge til en virksomhed,« vurderer Mathias Buus.

Nu er Node.js kommet i brug mange andre steder, blandt andet hos Facebook, så der vil ikke længere ske samme radikale ændringer, mener han, men som alt anden beta-software er der bugs undervejs. Grundlæggende er Node.js dog yderst stabilt.

»Jeg kan slet ikke huske, hvornår vi sidst er crashet på grund af en bug i Node.js,« siger han.

Træerne vokser ikke ind i himlen

Selvom han er stor fan af teknologien, kan han også godt hive nogle problemer med Node.js frem. For eksempel mangler der stadig mulighed for at bruge andre databaser end de mere gængse.

»Node.js er stadig nyt, og det betyder, at der mangler mange libraries. Det mangler rigtig hårdt. Vi var heldige at finde et godt modul til den mongodb-database, vi bruger, men det mangler til de mere obskure som for eksempel Cassandra,« forklarer Mathias Buus.

Der bliver også kodet nye moduler til Node.js hos Ge.tt, som er blevet lagt op på Ge.tt's Github-side.

Og så er der et mere specifikt problem med ydelsen i forbindelse med garbage collection.

Men bortset fra det, er Node.js i høj kurs hos Ge.tt-fyrene, som stormer derudaf med tjenesten, som alskens store internationale it-medier har rost.

Lige nu arbejder de med et API til Ge.tt, så andre kan koble sig direkte på tjenesten. Udviklere, der ønsker at være med i en betatest, er velkomne til at kontakte Ge.tt - eller skrive i debatten herunder. Og så er der kommet en ’business angel’ indover til at hjælpe med at få Ge.tt styret sikkert igennem vokseværket.

»Vi vokser, og det går rigtig godt. Og jeg får dagligt beskeder fra folk, som skriver, at Ge.tt har ændret deres liv,« siger Mathias Buus.

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

Nu er det jo faktisk ikke sproget, som giver skaleringsforskellen, men arkitekturen.
Den afgørende forskel er at Node.js er baseret på eventlib, ikke sproget. Man kan det samme i Java med non-blocking IO, hvis man vil - men folk er desværre langt hen ad vejen oplært med "én tråd per X".

Langt de fleste programmer kunne være lavet med én tråd (eller i det mindste være indelt i flere processer med hver én tråd). Desværre er folk blevet skreget hovederne fulde af multitrådet programmering så API'er og frameworks er præget af det. Resultatet er ikke deterministiske, ustabile programmer, som er meget svære at vedligeholde - og bruger alt for mange resourcer.

  • 10
  • 0
Mikael Kjær

Men at droppe tråde komplet fordi noget ikke er helt deterministisk eller "svært" er heller ikke en god ide. Uanset så scheduler OS'et jo også din process' timeslices (sig farvel til determinisme i CPU og IO på en server især i skyen, det får man kun på RTOSer af høj kvalitet).

Node.js har en stor mangel ved reelt set at være single-threaded og til en vis grad cooperative scheduled, hvilket egentlig er et langt skridt bagud. Det smarte ved node er dens Async/IO og dens HTTP stak. Og det underlige er at det ikke ville være specielt svært at forbedre det hele ved at lave en statisk pool af tråde (en eller to pr. kerne) med hver sin V8 inden i (Google gutterne var så smarte at gøre V8 trådbar for ca. et halvt år siden) og lade dem være klare til at tage sig af arbejdet (man kunne sætte en tråd til at være main så nuværende programmer ikke skulle laves om). Det eneste man skulle tilføje der ud over til node.js ville være et slags message queue system (så blev node.js lidt mere ala Erlang og Go). Men som den er nu er Node ikke noget specielt set i sammenholdt med ting som Erlang, programmer skrevet i Go eller D, eller Python programmer lavet med Twisted, Ruby programmer lavet med EventMachine eller Java programmer skrevet til at bruge Netty fra Jboss projektet.

  • 0
  • 0
Casper Bang

Selv om jeg ikke ligefrem fan af Java's syntaks, så er det alt andet lige væsentligt nemmere at refactor og arbejde med end JavaScript, grundet dets statiske natur og de værktøj der er til rådighed (IDE's, profilers, statiske checkere osv.). Det er 10 gange nemmere at komme til at skrive spaghetti kode i JavaScript frem for Java.

Java platformen er enormt stabil og efterhånden så optimeret at man ofte kommer meget tæt på native performance, men det kræver jo at man programmerer til platformen (f.eks. bruger tråd pools, work stealing, non-blocking NIO osv.) og ikke bare naivt forsøger at starte n antal tråde.

Historien minder mig og lignende, hvor Ruby mf. bliver udnævnt som overlegen, men hvor det viser sig at handle mere om arkitektur end implementationsprog. Og i dag er der flere og flere af disse, der er på vej over til statiske sprog (LinkedIn, Twitter, FourSquare mf. er f.eks. for længe gået over til Scala).

  • 7
  • 0
Esben Nielsen

To emner i ét:

Et single trådet program ER mere deterministisk idet tilstanden er en ren funktion af de input (mere generelt events) programmet har fået. Hvordan programmet har fået tildelt CPU er i ligegyldigt. Selvfølgelig influere det de events der kommer ind (de kan komme i andre rækkefølger, være noget andet etc.). Det betyder, at det er meget mere overkommeligt at skrive unittest. At skrive unittest til en klasse, som har en tråd inde i maven er derimod meget svært, da man skal kunne kontrollere, hvornår denne køre, har haft en chance for at køre etc.

Jeg siger heller ikke man skal droppe tråde fuldstændigt - men i rigtigt mange tilfælde er de unødvendige og gør programmet unødvendigt komplekst. Og koster i performance, da man nødvendigvis også skal bruge låse og besked-køer og mere indviklede datastrukture.

Mht. Node.js og tråde: Node.js er baseret på libev (http://software.schmorp.de/pkg/libev), som allerede supportere flere tråde. Det vil være rigtigt at have én tråd per CPU. Jeg ved dog ikke om libev selv kan fordele arbejdet...

  • 3
  • 0
Casper Bang

Jeg siger heller ikke man skal droppe tråde fuldstændigt - men i rigtigt mange tilfælde er de unødvendige og gør programmet unødvendigt komplekst. Og koster i performance, da man nødvendigvis også skal bruge låse og besked-køer og mere indviklede datastrukture.

Men altså, vi snakker server udvikling her... og så kommer du altså ikke langt med én tråd. Der er aaaaalt for meget blokerende ventetid til at det giver mening. Ydermere, så skal CPU'en jo også gerne have noget af lave, en moderne Xeon CPU understøtter 20 samtidige tråde alene i hardware.

  • 4
  • 0
Claus Junker Jørgensen

...de er datalogi-uddannede, men kan ikke skrive Java uden det bliver spaghetti? Og har blindt brugt en tråd per connection, i stedet for "et fornuftigt antal tråde ifht. cores" kombineret med async I/O?

Nu handler datalogi jo slet ikke om programmering. Jeg er sikker på de kan alle de matematiske beviser for hvordan du laver ordenlig async programmering.

Men det er jo ikke ensbetydende med at de har lært mere programmering end deres 1. semester kursus i Java.

Anyway, problemet her er dog åbenlyst, og det er at Java som standard ikke tilbyder alverden i gode paralleliseringsmuligheder, medmindre man bruger 3. parts biblioteker, som typisk er komplekse at sætte sig ind i.

F.eks. tror jeg sagtens man kunne matche performance ved f.eks. at bruge Scala, eller sågar .NET som kommer med bedre standard-muligheder.

Men at skifte til Node.js fordi det er nemmere at lære, og måske sjovere for "hackere" er vel også fint fint. Hver til sit. Jeg er bare glad for det ikke er mig som skal maintaine en stor kodebase i JavaScript. Det er ikke just verdens mest læsbare sprog.

  • 1
  • 0
Sune Marcher

Nu handler datalogi jo slet ikke om programmering. Jeg er sikker på de kan alle de matematiske beviser for hvordan du laver ordenlig async programmering.

Men det er jo ikke ensbetydende med at de har lært mere programmering end deres 1. semester kursus i Java.

Ganske sandt, datalogi er teoretisk funderet - og sådan bør det også være. Men jeg vil stadig fastholde at der er en brist et eller andet sted hvis man er ude af stand til at se hvor problemet ligger og finde en løsning på det.

(At identificere Java som 'problemet' er dårlig problemanalyse, og at skifte til en helt ny platform er ikke nødvendigvis en hensigtsmæssig løsning - omend det lyder som om det ikke var en dårlig idé med rewrite af deres kodebase ;))

  • 1
  • 0
Henrik Schmidt
  • 0
  • 0
Robert Larsen

Men altså, vi snakker server udvikling her... og så kommer du altså ikke langt med én tråd. Der er aaaaalt for meget blokerende ventetid til at det giver mening.

I Node er der ingen blokerende ventetid. Alt er asynkront.

Det er så en lille løgn, for visse kald kan ikke gøres asynkront, men der bruger Node så en thread pool af (for mig) ukendt størrelse, men al brugerens kode bliver udført af én tråd. Når den så laver et blokerende kald, så bliver der smidt et job efter thread poolen, og main tråden kan køre videre, som om kaldet var asynkront.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Servlet 3.0 understøtter NIO. Tomcat implementerer Servlet 3.0.

Når det så er sagt, så er det en relativ ny ting, da Tomcat 7 kun er 1 1/2 år gammel.


Der har været mulighed for non-blocking IO på servlet fronten i laaaang tid. BEA WebLogic har haft deres egen performance enhancements, som bla. giver mulighed for at parkere IO requests og genbruge tråden. Derudover har de selvfølgelig har non-blocking IO, før Java NIO kom i 2002 med Java 1.4

Første version af Tomcat med NIO var version 6.0 (2007)

Denne artikel beskriver hvorledes man kan konstruere sin egen server (servlet baseret) med NIO. http://www.ibm.com/developerworks/library/j-nioserver/ (2004)

Derudover er det i mine øjne ikke specielt besværligt at benytte hverken MINA eller Netty.

Jeg tror der er sket en fejl i artiklen, for NIO og Node.js er ca. på omgangshøjde. Det der nødvendigvis må sammenlignes med er Legacy Servlet modellen (-2.5)?
Man kan ikke sammenligne Java og Node.js, på området concurrency, uden at komme frem til at Java har langt flere strenge at spille på i denne sammenhæng.

Alex Payne (co-author of Programming Scala: Scalability = Functional Programming + Objects):
[i]If you’re deeply invested in Node, you’re stuck with one way of approaching concurrency; one way of modeling your problems and solutions. If it doesn’t fit into an event-based model, you’re hosed. If, on the other hand, you’re working with a system that allows for a variety of concurrency approaches (the JVM, the CLR, C, C++, GHC, etc.), you have the flexibility to change your concurrency model as your system evolves.[/i]

  • 0
  • 0
Tobias Baunbaek

Tillader mig lige at svare her. Mathias og mig udviklede Ge.tt så vil da lige give nogle af de grunde til at skifte sprog som muligvis ikke kom med her. Det er i øvrigt bare mine egne grunde, så Mathias har måske andre.

I Java så lærer du til at starte med hvordan man laver en synkron server. En tråd per connection. Så, naturligvis, da vi laver den første prototype så er det det vi går igang med. Vi ser at serveren benytter mange RAM og overheadet per ny bruger er forholdsvis høj. Da det var en prototype havde vi lært meget af at skrive den, så vi vidste vi skulle skrive den om fra bunden af igen. Her kunne vi have valgt Java og så gået mere ind i hvordan man skriver en "rigtig" server i Java. Men vi havde lyst til at lære noget nyt. Det føltes ikke som om at Java var det bedste sprog til det vi havde gang i, og bare fordi man KAN gøre noget i sprog, betyder det ikke at man skal.

Vi havde på dette tidspunkt læst lidt om Node. Det passede perfekt til det vi ville, og det så ud til at performe rigtig godt. Her kan man sagtens finde benchmarks der viser at Java kan være med. Men sagen er samtidig at kode skrevet i Node ofte er lettere at læse end det i Java. Nu skal vi ikke have en filosofisk diskussion, så lad mig tilføje et "jeg synes" til den sætning.

Mikael kommer ovenover med nogle gode pointer som jeg gerne vil kommentere på.

"Node ikke noget specielt set i sammenholdt med ting som .... Python programmer lavet med Twisted, Ruby programmer lavet med EventMachine eller Java programmer skrevet til at bruge Netty fra Jboss projektet".

Jeg kender ikke alle de libs du nævner, men sagen er at de er libs. Det som fungerer rigtig fint ved Node er at det er skreve til netop servere. Sproget er ikke lavet til at kunne alt muligt andet. Det kan det selvfølgelig, men det kan alle Turing-komplette sprog. Jeg ved bare at jeg ikke selv har lyst til at skrive en server i C eller skrive et GUI program med Node. Desuden er jeg meget glad for at der ikke er tråde. Det tog mig noget tid at vende mig til - og overbevise mig selv om - men Brendan Eich, skaberen af JavaScript, som har lavet JavaScript, forklarer det bedre her end jeg ville kunne - http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html

Videre skriver Mikael også "Node ikke noget specielt set i sammenholdt med ting som Erlang, programmer skrevet i Go eller D".

Her tenderer jeg til at være enig selvom mit kendskab til Go og D er ret lille. Erlang ville helt sikkert passe rigtig godt til Ge.tt men det virker bare lidt som om et lidt lukket land. Jeg kender hvertfald ikke mange der udvikler til det, hvor der er mange der kan JavaScript så det er ikke så svært at hyre nye folk til det. Men message systemet i Erlang ville være så perfekt i Node og jeg ved der arbejdes på noget der gør det lettere at sætte nye processer+maskiner sammen i et netværk så man kan få det.

Så ja, summa summarum... Grunden til at skifte var flere. Dels fordi vi var kommet til et stadie hvor vi skulle skrive en stor del af vores kodebase om og følte at Java blev ret verbost. Så hørte vi om det her nye Node som var lavet til netop det vi skulle og det ville vi prøve. I dag er jeg meget glad for at vi har skiftet. Nu koder vi i et dynamisk sprog som jeg i forvejen var ret glad for.

Slutteligt: Node er rigtig sjovt at kode i og det gør mig glad at kode i. Java havde ikke altid den effekt. Men det er så blot et personligt valg.

Mvh
Tobias Baunbæk,
Co-founder, Ge.tt

  • 5
  • 0
Casper Bang

Ja, servlet API'en mv. er håbløs

Hvad er der galt med lige netop servlet API'et? Det er noget af det mere elegante i Java verdenen, og ligger til grund for en masse uafhængige implementationer (Glassfish, Grizzly, Tomcat, Jetty, JBoss...) og applikationer ovenpå (JSP, Jersey, JSF, Wicket, Tapestry...).

Og af nysgerrighed må jeg simpelthen også bare vide, hvor har du lært at sige API'en istedet for API'et, er det jysk?

  • 2
  • 2
Erik Corry

Ang. API'en vs. API'et så kan man Google sig frem til at "En af de enkleste tommelfingerregler er at 90% af alle fremmedord får fælleskøn." så spørgsmålet er måske snarere hvordan du er kommet frem til at API skal have intetkøn. Er det en Københavnisme som "oversætter" og "fast pladelager"?

  • 5
  • 1
Casper Bang

På dansk hedder det "et API" da substantivet i API er "interface". [http://retskrivningsordbogen.dk/ro/ro.htm?q=interface].

Danske wikipedia artikler er iøvrigt enig med dansk sprognævn [http://da.wikipedia.org/wiki/Application_programming_interface].

Det er faktisk kun i fora som disse, man ind imellem støder på "API'en", hvorfor jeg spurgte ind til årsagen hertil. Jeg er hverken Københavner eller Jyde, men jeg bemærkede bare da jeg læste på AUC at mange jyder bruger "-en" på alt.

  • 3
  • 2
Michael Lykke

@Tobis - Tag det med et smil - Der er så mange folk der trutter i Java-trompeten dagen lang at de til tider har svært ved at forstå at Java ikke er "end-all, be-all".

Java har uden tvivl en masse kvaliteter, men det har mange andre sprog og platforme også - Ligeledes har Java absolut også sine problemer og at vælge noget som Node.js der kan performe super godt med et meget let-tilgængeligt sprog som Javascript er kun et plus.
Java verdenen er voldsomt "bloatet" og personligt synes jeg ofte at man ser over-komplicerede Java løsninger som implementere en hær af relaterede teknologier for at løse simple opgaver og man ender med alle ulemperne uden nogen af fordelene.

Så respekt for at i vælger noget i synes er sjovt men som også er simpelt og effektivt uden at falde i buzz-word fælden og uden at forfalde til den sørgelige tankegang om at Java og .NET er det eneste rigtige som mange danske udviklere gør.

  • 7
  • 0
Sune Marcher

Så respekt for at i vælger noget i synes er sjovt men som også er simpelt og effektivt uden at falde i buzz-word fælden og uden at forfalde til den sørgelige tankegang om at Java og .NET er det eneste rigtige som mange danske udviklere gør.

Helt enig - vælg et fornuftigt værktøj til opgaven. Node.js er garanteret godt til visse projekter, personligt foretrækker jeg typestærke sprog når kodebasen når en vis størrelse... omvendt er jeg ikke begejstret for den voldsomme enterpriseyness en del Java projekter ender i (det' altså ikke nødvendigt).

Det jeg opponerer mod er "Hvor et normalt web-setup ville have en tråd til hver bruger", og den manglende smule research på hvad man BØR gøre for at kunne skalere, før man har hacket et projekt halvvejs færdigt ;)

  • 1
  • 0
Martin Kofoed

Play! er et full stack framework, med embedded webserver (ligesom node.js) der bruger threadpools (ligesom node.js).

Jeg ser ikke lige noget i Play!, som ikke allerede adresseres af Java EE 6 og JSF2. Modellen ligner på en prik. Jeg har lige lavet et eksempel med en JSF2-grænseflade, som abonnerer på en WebSocket publisher. Det kan gøres vældigt elegant og overskueligt med meget lidt kode. Og udvikling uden container-restart, som forhåbentlig har været passé for de fleste i meget lang tid. Glassfish 3.1 holder endda session state på tværs af deployments, hvis man måtte ønske det ...

Når det er sagt, må jeg tilføje, at jeg er tilhænger af en stor underskov af frameworks, som hele tiden udfordrer de kendte teknologier. En del af dem finder endda vej direkte ind i eksempelvis Java EE (CDI, JAX-RS, O/R-mapping etc.). Der er masser af bleeding edge derude, noget af det får vind i sejlene, andet hører man kun om én gang (eksempelvis http://rifers.org/ og en lille million andre, til trods for at de indeholder banebrydende nyskabninger - i RIFE's tilfælde webflow continuation).

  • 0
  • 0
Esben Nielsen

Du skal netop IKKE have blokerende ventetid rundt om i koden. Brug libev, select, poll etc., så tråden kun blokere, når der ikke er mere at lave.

Har du flere CPU'er giver det mening at have en tråd per CPU/hyperthread. Men af hensyn til performance bør de være meget afkoblede, så overvej at udskift "tråd" med "proces."

Jeg ved godt det ikke er så simpelt i praksis. Der er desværre en del funktioner, som bare er blokerende og ikke findes i en ikke-blokerende udgave. Enten skal du skrive dem om selv, eller pakke dem ind i en tråd :-(

  • 0
  • 0
Casper Bang

Hvordan siger du "CD" (du ved, de dér forældede musiklagringsmedier) i flertal?

"CD'er", men hvad har flertal med sagen at gøre? Jeg har linket til den danske retskrivningsordbog samt wikipedia, men ellers ved jeg ikke hvordan jeg skal få dig overbevist!

Prøv at se hvorledes selv Dansk Sprognævn skriver "... få et stadig mere brugervenligt interface..." på side 5 i følgende dokument:
http://dsn.dk/nyt/nyt-fra-sprognaevnet/2006-1.pdf

  • 1
  • 2
Adam Tulinius

@Martin Kofoed: Okay. Det er meget muligt. Men i dag vil de unge ikke bøvle med opsætning af en servlet container for at hoste en simpel applikation, og alt det xml-snask som der ofte er nødvendigt.

Det er meget muligt at det er en overdrivelse at kalde servlets for håbløse. Men jeg er sikker på vi er enige i at begrundelsen for skiftet væk fra Java til node.js er noget tyndt. Det var sådan set mest det jeg ville påpege, når der findes java-frameworks der er lige så hurtige at få op at køre som Rails/Django/node.js mv, og tilbyder features langt ud over hvad node.js formår.

(PS: Jeg beklager at jeg var så uheldig at skrive noget der fik Carsten Bang til at deraile hele diskussionen. Om man skriver API'en eller API'et kan da for pokker være irrelevant: Engelske fagudtryk passer generelt dårligt i det danske sprog.)

  • 5
  • 1
Log ind eller Opret konto for at kommentere