JavaScript eller ej, igen igen

Javascript er hele verdens web-scripting sprog, færdig bum. Alle de gamle klienter som ikke vil dø, afgør om du kan tillade dig at skrive JS i den nyeste version af sproget ECMAScript 6 / ES 2015 eller hvad de kalder den i denne uge. Men faktum er at hvis man vil være sikker skal man bruge ECMAScript5.

Visual Studio har nogle enormt gode værktøjer til både Javascript og Typescript, så hvis man ikke er helt sindssyg (besat af opensource), så brug Visual Studio.

Typescript er jeg ikke helt blevet venner med endnu, syntaxen er for tung og da man manuelt ofte skal side og deklarere typer og interfaces, samt type-definitions for 3rd party JS libs, så mister man meget hurtigt fordelene ved TypeScript.

En ting jeg på ingen måde fatter er hvorfor Typescript ikke bliver skrevet i C# - forhelved da, hvis koden alligevel SKAL kompileres til Javascript, hvorfor så ikke lave sproget pænere ? og så ved jeg godt at argumenet er at Typescript er validt Javascript, YADA YADA.. det bare en dårlig undskyldning !!

Det næste man bør tage stilling til er SPA eller bare Binding Framework og her findes der en krig man skal tage stilling til:

• Skriver man HTML/CSS med databinding drysset ud hist of pist bare for at øge funktionaliteten en smule eller
• Skriver man en meget tung SPA klient med routing, URL rewrite, domænemodeller og what not ?...

Aurelia , Angular, Ember, Knockout osv osv.. man skal vælge den rigtige.. FRA STARTEN !

Måske er det fordi han antyder at Javascript er et prototype baseret sprog, og ikke decideret et objekt orienteret sprog. Måske ligger problemet i virkeligheden i ens egen tilgang til Javascript, hvis man benytter samme programmerings metodologi og tankegang som man benytter sig af når man skriver Java (eller C# for den sags skyld), og tingene ikke er som de plejer at være.

Det er endnu ikke lykkedes mig at finde en JavaScript-erstatning som løser flere problemer end det skaber. Kompilering gør kode-test cyklussen lidt langsommere, og fejlmeddelelser er et eller andet sted mellem rimelige og helt hen i vejret, det svære er ikke at skrive en kompiler som oversætter X til JavaScript, det svære er at få nogenlunde ordentlige debug funktioner med.

De dynamiske rædsler i JavaScript begrænser sig primært til at plus-operatoren har lidt for mange funktioner, når man først har lært at håndtere den del giver statiske typer ikke nogen særlig fordel.

ES6 ser ud til at være bunke syntaktisk sukker, mest henvendt til folk som tror at det er vigtigt at fortælle kompileren hvordan variable ikke vil blive brugt, det flytter ikke rigtigt noget.

Hvis du anvender et bibliotek som ikke kan holde sit API nogenlunde konstant, så har du nok valgt det forkerte bibliotek til at starte med. Det er selvfølgelig lettere at vide bagefter, men man kan komme langt ved lige at overveje en ekstra gang om den funktion nu er et bibliotek værd, og så i øvrigt holde sig fra alt som er under to år gammelt.

men det er på grund af sikkerheden.

Har som standard slået det "mest" fra, også giver jeg "lidt" tilladelser hvis siden ikke vises eller fungere korrekt, men kun hvis siden har noget vigtigt indhold. Eller finder jeg bare en anden siden. Det betyder også man slipper for meget tracking, og lignende.

Hvis siden kommer op med, du skal slå Java APPLETS eller FLASH til for at virke, så bliver den blacklistet. Det er enten tåbelige programmørerne, gammel hjemmeside eller forsøg på malware og virus inject. Den bedste måde at få det til at dø på, et fravalg af de sider.

Ellers er uBlock Origin og Privacy Badger gode programmer til at "slåt" mængten af java og tracking og lignende ned. Især uBlock Origin virker efterhånden ualmindeligt velpoleret, hvor de fleste hjemmesider bare køre, og hvis man skal bruge Nemid eller kortbetaling, så er det klaret med få klik de første par gange. Hvis noget alligevel skulle poppe igennem, så er det væk med et klik. Privacy Badger bloker mest for tracking. Men tilsammen køre de perfekt på chrome, noget som ikke altid er tilfældet. Nogen tilføjelser ender et samarbejde med et Catch-22.

Udover at slippe for støjende videoreklame, malware/virus og tracking så betyder det også meget mindre CPU, og RAM forbrug, hvis du har mange vinduer åben. Noget som jeg før oplevet fik chrome/windows til at gå "død", som brug for en genstart.

Men lever med java til HTML5 er mere moden, og de seriøse hjemmesider byger har fået flyttet/porteret deres sider. Det tager nok nogle år, herefter vil java sammen med flash og java APPLETS få sparket.

Har du overhovedet læst artiklen?

Ja, Java og andre sprog som ikke er HELT åben, og hvor det er en "ejer" skal udfases så hurtigt som muligt.

Det har google også indset, efter det sidste søgsmål fra Oracle.

Om der så ikke lige nu, er et sprog, som kan nemt kan alt erstat det som Java kan. Det har jo ingen betydning for at have den mening. Og hvis man som (for)bruger gerne vil have at proprietære programer, med sikkerhedshuller, licens problemmer og bagdøre skal ud af vagten. Så skal man fravælge platform som bruger det.

Har du læst hvad jeg skriv ?

I den først i dette indlæg linkede artikel nævner forfatteren "freedom and expressiveness of JavaScript" som årsagerne til, at han godt kan lide sproget, men uden at give konkrete eksempler. Er der nogen i dette kompetente forum, som har et lignende syn på JavaScript/TypeScript, og som kan uddybe og eksemplificere det? Hvorfor bruge JavaScript som andet end runtimeplatform?

Du har selv givet en del af svaret - JavaScript er ret dynamisk, så det er utrolig nemt at komme igang med. Larry Wall (ophavsmanden til Perl) er en rigtig god kilde til mange citater og han har sagt noget som passer godt i denne sammenhæng: "Perl is designed to make simple things easy and hard things possible". Sådan er JavaScript også. Hvis du har et meget lille problem, kan du ofte skrive et script som kun er på en enkelt linie eller to, der løser det. Den slags er ikke muligt med klassisk Java.

Ud over det så har mange JavaScriptmiljøer ultrakort responsetid, så når du har gemt din fil, så kører dine tdd-tests automatisk og er færdige på under et sekund. Når du laver en ændring i din React-applikation, sker ændringerne live i din browser (jeg er sikker på at andre miljøer også har den slags, men jeg ved ikke hvilke).

Det handler ikke om at Java ikke kan noget tilsvarende, men at fokus måske bare ligger et andet sted. I JavaScript er der meget fokus på lave responsetider overfor udvikleren, så man hurtigt får feedback.

Endelig er der det ved JavaScript som med så mange andre dynamiske sprog at man kan lave nogle smarte konstruktioner, de statiske sprog ikke tillader. Det er klart at man taber muligheden for at bruge værktøjer der netop forudsætter statisk typning, men bagsiden af den mønt er at man som udvikler har langt større frihed når man designer sit program.

For eksempel kan man i JavaScript dynamisk generere klasser, inspicere og ændre på objektinstanser, lave om i arvehierarkier og den slags. Det er klart at med den slags ret potente værktøjer, kan man lave nogle frygtelige ulykker, men på det punkt er min filosofi at de fleste elendige udviklere nok skal ødelægge det for alle os andre, uanset hvor stive værktøjer, vi prøver at pakke dem ind i.

Så bundlinien er at jeg er rigtig glad for de fleste JavaScript-varianter. I øjeblikket bruger jeg ES6 (med Babel) ovenpå node.js og transpilet in browseren sammen med React, men jeg roder også med mange andre relaterede teknologier.

På den anden side er jeg slet ikke religøs - jeg mener at det er vigtigt at vælge det rigtige værktøj til den rigtige opgave. Jeg ville til en hver tid fraråde at skrive det næste styresystem til Nasas rumraketter i JavaScript.

"Har du overhovedet læst artiklen?"

Ja, Java og andre sprog som ikke er HELT åben, og hvor det er en "ejer" skal udfases så hurtigt som muligt.

Hvis du har læst artiklen, hvorfor ævler du så løs om Java, Flash og tracking? Det er ikke emnet og ingen af delene er nævnt med så meget som et ord i blog indlægget. Du er off topic.

Her er lidt hjælp: Artiklen er et oplæg til at debattere hvorvidt man bør bruge JavaScript direkte eller om man bør bruge et sprog der kan oversættes til JavaScript.

Languages that Compile to JavaScript lister godt 30, heriblandt selvfølgelig TypeScript og andre JavaScript-varianter, men hvorfor ikke fx bruge Scala, Haskell eller et af de andre alternativer?

Jeg bruger Scala-JS og kan kun anbefale det. Jeg har tidligere brugt GWT (oversætter Java til JavaScript) men det er helt dødt og kan ikke anbefales.

En af fordelene ved Scala-JS er at der er et ret godt impedans match. Scala og JavaScript ligner hinanden nok til at man kan skrive ikke trivielle stykker kode der er validt i begge sprog. Scala-JS giver nær perfekt integration, så at alt eksisterende JavaScript kan bruges uden sværdslag og på en pæn måde fra Scala. Tilsvarende kan man fra JavaScript bruge dine Scala definerede funktioner og objekter på en måde så at JavaScript brugeren ikke behøver vide at han kalder Scala defineret ting. Du kan således også gøre brug af JavaScript frameworks der benytter call backs etc. Det er helt almindeligt at benytte JavaScript frameworks (Angular et al) i kombination med Scala-JS.

Der er løsninger på de fleste ting der nævnes i tråden ovenover. Eksempelvis vil din browser vise fejl direkte i din Scala kode via source map featuren.

Det er klart at der er en ekstra compile cyklus i forhold til rå JavaScript. Men du kan sætte systemet til at overvåge dine filer, så at det sker automatisk i baggrunden så snart du trykker save. Der er også support for live update i browseren. Ja det tager nogle sekunder ekstra, men så har du argumentet overfor chefen for hvorfor du skal have en ny hurtigere computer :-).

Her er et godt blog indlæg om Scala-JS: http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScalajs.html

There are many compile-to-Javascript languages in the world: virtually every widely-used language has a compile-to-Javascript version of some level of quality (Google Web Toolkit, PyJS, Opal Ruby, ...), and then there are those languages that were designed specifically with Javascript as a target (Coffeescript, TypeScript, ...). Scala.js is one of them, probably one of the most robust and production-ready of the compile-to-JS languages.

For lige at uddybe lidt, så er en af mine yndlingskæpheste this, som er virkeligt svær at holde styr på. Ja, ES2015 har arrow functions med leksikalt scope, som hjælper noget, men det kommer til at tage noget tid, før al kode er skrevet om til den nye form.

Personligt bruger jeg stort set ikke this, det er, sammen med new, den der underlige rest fra Javas typesystem. Prototype-inheritance lyder så fint, men i praksis er det ret sjældent at man har brug for det når man har duck-typing. En constructor behøver ikke at være andet end en funktion som returnerer et objekt, og i de fleste tilfælde er det ret ligegyldigt om en funktion kan kaldes som member, eller blot som en funktion uden særlige tilhørsforhold.

Forstår jeg det korrekt at du har tænkt dig at skrive din kode om blot fordi der er kommet en ny standard som lader dig skrive på en lidt anden måde? Det forekommer umiddelbart unødvendigt.

Det er lettere sagt end gjort. Vi bruger React, og selv om det ikke har været lige så slemt som Angular (som jeg er rigtig glad for ikke at have introduceret i version 1), så har react-router fx allerede været igennem tre API-versioner.

De to år starter selvfølgelig forfra hver gang et bibliotek laver sådan et nummer.

En ting jeg på ingen måde fatter er hvorfor Typescript ikke bliver skrevet i C# - forhelved da, hvis koden alligevel SKAL kompileres til Javascript, hvorfor så ikke lave sproget pænere ?

Simpelt, målgruppen for TypeScript er JavaScript udviklere og IKKE C# udviklere...

Der findes flere C# til JavaScript transpilere der ude, så "Go nuts" med dem hvis du har lyst til mere C#...

Simpelt, målgruppen for TypeScript er JavaScript udviklere og IKKE C# udviklere...

Der findes flere C# til JavaScript transpilere der ude, så "Go nuts" med dem hvis du har lyst til mere C#...

Sagen er jo at man med ES2015 og lign prøver at opgradere Javascript til noget der minder om et objekt orienteret sprog og lige præcis med TypeScript prøver man at lave en typestærk variant.

Alle de udviklere jeg kender som laver kæmpestore, teknisk avancerede Javascript løsninger, bruger sproget som om det var typestærkt dvs:

• variable bliver oprettet og opdateret med objekter af samme type end-2-end - ingen steder undervejs bliver en String brugt som Number og omvendt.
• casting til String foregår til nødt ved at append en tom streng (implicit cast)
• Equality ender som regel med at være '==' frem for '===' idet 'loose compare' som regel gør det man forventer hvorimod 'strict compare' ofte introducere fejl (fx: undefined !== null )

med den størrelse web-applikationer har i dag og med den sum af penge disse generere, så er det fuldstændig vanvittigt at de bliver skrevet i et sprog som er så horribelt og utilregneligt (det samme gælder i øvrigt PHP) læs : https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Javascript og dens mange mærkeligt implementeringer på tværs af browsere, falder fuldstændig til jorden så snart man prøver at lave noget avanceret med f.eks. en komplet keyboard event handler , eller en komplet touch-event handler det kun fordi folk uden et liv har siddet i månedsvis og implementeret libs som Hammer.js og lign at det kan lade sig gøre og selv med de libs er man ikke i mål.

Det er ligefør jeg vil væde med at der ikke findes et JS lib / framework som virker på tværs af alle browsere og klienter. antallet kan i hvert fald ikke være mange

Lidt en fortsættelse af hvorfor sprog som kompilere til Javascript kan være en dårlig ide:

Jeg var lidt interesseret i CoffeeScript, i cirka 2 timer, indtil jeg faldt over den her blog post: http://walkercoderanger.com/blog/2014/03/coffeescript-isnt-the-answer/

Dét som Jeff kommer ind på i sin "rant" er bl.a. at man ofte ender med at skulle kende Syntax A bedre end output Syntax B.

der gives flere eksempler på at bitte små fejl har store konsekvenser for outputtet af CoffeeScript

Jeg siger ikke at det samme gør sig gældende for TypeScript og deslign, men præmissen gælder stadig.

som udvikler af TypeScript er man NØDT til at kigge på det Javascript som kommer ud i den anden ende, og man er NØDT til at lære den rette syntax for at få det ønskede output i Javascript.

umiddelbart betyder det så at man på nogle punkter er nødt til at kende 2 sprog virkelig godt i stedet for kun 1.

Javascript kan nogle ting med let hed, som er en udfordring i andre programmeringssprog. Det er fx fantastisk til at lave asynkront programmering i, grundet dets opbygning med first-class functions og v8´s event loop, og dets prototyping tilgang.

Bruger det selv hvis jeg har med et distribueret system at gøre, eller andet som er meget dataintensiv, da det er her dets styrke ligger.

Ved ikke helt om det var det du efterspurgte, men Javascript er også blevet til mange ting efterhånden.

Du er off topic.

Er jeg, ikke ifølge overskriften "JavaScript eller ej, igen igen"

Er helt med på at javascript er nemt, køre på mange platforme, og som sådan virker. Forfatteren mener ikke at der findes brugbare alternativer.

Er også helt med på at vi nok må leve med java,på hjemmesider, minimum de næste 5-10 år. Men jeg mener der er alternativer, og at en fastlåsning til en leverandører, især en med Oracle's historik ikke er god ide, eller faktisk en rigtigt dårlig. Når man ser på bagdøre, lukning af sikkerhedshuller, og retssager om rettigheder og patenter. Når man laver løsninger som måske skal køre om til 15-20 år frem, så er java ikke en god løsning, på grund af ovenstående. Man risikere, at tæppet trækkes væk, på grund af en eller anden uenighed, eller måske bliver oracle bare træt af at vedligeholde det, hvis der ikke er penge i det.

Så det har da meget at gøre med om man skal vælge java eller ej, hvis man også ser lidt fremad.

Det var det jeg mente med et ej

Java har ikke meget med javascript at gøre bortset fra navnet.

Bent du må lige læse op på hvad javascript går ud på.

Det er så mærkeligt at det er morsomt :))

Typescript er en vinder fordi det er et super-set af Javascript og dermed tillader at interagere med alle eksisterende Javascript libraries. Det er her de fleste andre sprog-transpilere taber og derfor selv Google har valgt at anbefale Typescript til Angular2 over deres eget Dart.

Derudover hjælper det også at man implementere ES6 og ES7 features så tæt som muligt på det der pt. er specificeret, hvilket betyder at sproget ikke afviger meget fra det der ender med at blive fremtidens javascript - Typescript betyder blot vi kan bruge disse features allerede idag og det sammen med alle fordelene ved typesupport. Det betyder altså at man kan anvende de ting man lærer fra Typescript i mange andre sammenhænge også, f.eks. hvis man foretrækker en Babel ES6 compiler med Flow.

Det betyder tilgengæld også at sproget arver nogle af de mindre hensigtsmæssige ting fra Javascript, men alternativet er at man ender med sit eget lille lukkede eco-miljø sådan som det er tilfældet for alle de andre sprog-transpilere hvor populære libraries er nød til at blive konverteret før de kan anvendes.

Og så skal man jo heller ikke undervurdere betydningen af at det ledes af Microsoft og vores eget sprog-geni Anders Hejlsberg, det åbner altså døre i forhold til at få det indenfor i Enterprise verdenen og betyder også dokumentation og support er i top, da Microsoft bruger betydelige ressourcer på projektet.

JavaScript kommer vi ikke udenom, sådan er det! (Alternativet er jo Silverlight/Flash, og selv Microsoft har jo bukket sig ned og accepteret HTML5/JavaScript som fremtiden)

Syntes derfor det er fedt, at f.eks. TypeScript tillader udvikling i ES6, så man derfor allerede kan kode et project i ES6 standarden, men transpile jacascript til ES5 on-the-fly. Den dag alle browsere understøtter ES6, kan man jo NETOP på 5 sekunder skifte hele sin JavaScript kodebase ud til det nye format uden problemer. Så kan ikke se, hvorfor folk nævner dette som en ulempe (de har sikkert ikke helt 100% sat sig ind i ideen med TypeScript). :)

Som jeg ser så er det største problem med Javascript at det de designet til at være 'skriv kun'. I forhold til andre sprog så lider javascript af at ikke alle fatter hvordan de ultra avancerede funktioner fungere, og det er vel også til derfor at sprog som f.eks. Typescript er opstået kunne jeg umiddelbart forestille mig.

Klasser: Jeg har tit tænke på hvorfor man ikke bare tager skridtet videre og implementere klasser ligesom i f.eks. c++, det vil formentlig gøre en del ting nemmere kunne jeg forestille mig.

Klasser kommer jo netop med ES6 og de fleste frontend udviklere gør allerede brug af dem idag, enten via en ES6 transpiler eller Typescript.

http://www.seguetech.com/java-vs-javascript-difference/

Sagen er jo at man med ES2015 og lign prøver at opgradere Javascript til noget der minder om et objekt orienteret sprog og lige præcis med TypeScript prøver man at lave en typestærk variant.

Alle de udviklere jeg kender som laver kæmpestore, teknisk avancerede Javascript løsninger, bruger sproget som om det var typestærkt dvs:

variable bliver oprettet og opdateret med objekter af samme type end-2-end - ingen steder undervejs bliver en String brugt som Number og omvendt. casting til String foregår til nødt ved at append en tom streng (implicit cast) Equality ender som regel med at være '==' frem for '===' idet 'loose compare' som regel gør det man forventer hvorimod 'strict compare' ofte introducere fejl (fx: undefined !== null ) med den størrelse web-applikationer har i dag og med den sum af penge disse generere, så er det fuldstændig vanvittigt at de bliver skrevet i et sprog som er så horribelt og utilregneligt (det samme gælder i øvrigt PHP) læs : https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Javascript og dens mange mærkeligt implementeringer på tværs af browsere, falder fuldstændig til jorden så snart man prøver at lave noget avanceret med f.eks. en komplet keyboard event handler , eller en komplet touch-event handler det kun fordi folk uden et liv har siddet i månedsvis og implementeret libs som Hammer.js og lign at det kan lade sig gøre og selv med de libs er man ikke i mål.

Det er ligefør jeg vil væde med at der ikke findes et JS lib / framework som virker på tværs af alle browsere og klienter. antallet kan i hvert fald ikke være mange

Ud fra at mit svar var myntet på "hvorfor er det ikke C#", så er jeg ikke sikker på hvor du vil hen med dit svar her.

Alt det her ændre jo ikke på at målet for M$ og Anders er at give JavaScript udvilkere bedre værktøjer, det gør det jo ikke ved at give dem C# og sige "Nu kan i transpile det til JS"... for JavaScript udvikleren er vandt til - og - ofte meget glad for JavaScript som helhed, dette er til TRODS for alle de horrible fejl der er i JS som man skal navigere uden om.

Og en stor andel af disse mennesker vil formentlig slet ikke være ret glade for en "C#" lignende implementation.

Lidt en fortsættelse af hvorfor sprog som kompilere til Javascript kan være en dårlig ide:

Jeg var lidt interesseret i CoffeeScript, i cirka 2 timer, indtil jeg faldt over den her blog post: http://walkercoderanger.com/blog/2014/03/coffeescript-isnt-the-answer/

Dét som Jeff kommer ind på i sin "rant" er bl.a. at man ofte ender med at skulle kende Syntax A bedre end output Syntax B.

der gives flere eksempler på at bitte små fejl har store konsekvenser for outputtet af CoffeeScript

Jeg siger ikke at det samme gør sig gældende for TypeScript og deslign, men præmissen gælder stadig.

som udvikler af TypeScript er man NØDT til at kigge på det Javascript som kommer ud i den anden ende, og man er NØDT til at lære den rette syntax for at få det ønskede output i Javascript.

umiddelbart betyder det så at man på nogle punkter er nødt til at kende 2 sprog virkelig godt i stedet for kun 1.

Her var målet med TypeScript oprindeligt jo så ret æddelt, det skulle være JavaScript bare med optionelle type anoteringer mm.

Under den filosofi burde man faktisk kunne kigge på det resulterende JavaScript og straks genkende det.

Og features som class, module mm. ville jo komme så det var "OK". Ergo skulle man bare kende JS "Current" og JS "Future" hvilket jo var fair nok.

Det er naturligvis ikke helt realiteten og dermed ender man netop i den situation som du beskriver.

Skal måske nævnes at jeg selv arbejder med C# og ren JavaScript som arkitekt. Vi har dog ikke mere end 15.000 liniers JS som det ser ud nu.

dette er til TRODS for alle de horrible fejl der er i JS som man skal navigere uden om.

Altså... når man dropper forestillingen om at JavaScript skal være lissom Java eller C# bare fordi det ligner lidt, og istedet lærer sproget at kende, så er der altså ikke tale om "horrible fejl", blot områder hvor sproget er anderledes. Ville man mene at Ruby indeholder horrible fejl, fordi det ikke er magen til C++? Nej vel? Hvorfor insisterer så mange så på at JavaScript er forkert? Det er blot anderledes.

Altså... når man dropper forestillingen om at JavaScript skal være lissom Java eller C# bare fordi det ligner lidt, og istedet lærer sproget at kende, så er der altså ikke tale om "horrible fejl", blot områder hvor sproget er anderledes. Ville man mene at Ruby indeholder horrible fejl, fordi det ikke er magen til C++? Nej vel? Hvorfor insisterer så mange så på at JavaScript er forkert? Det er blot anderledes.

Her antager du noget forkert, nemlig at udtalelsen skal ses op mod andre sprog, det skal den dog ikke.

Det er ikke for sjov at en af JavaScripts egne store fortalere, Douglas Crockford, har udgivet bogen "JavaScript, the good parts (http://archive.oreilly.com/pub/a/javascript/excerpts/javascript-good-par...)" som netop behandler det emne at der er visse fejl i JavaScript der desværre er cementeret ind, såvel som laver JSLint som værktøj der hjælper med at sikre at man netop holder sig til de gode ting. Desuden er han ikke ret stor fan af flere af de ting der introduceres med Ecmascript 6.

Man kan så være enig eller uenig, jeg er enig i flere af hans betragtninger dog ikke nødvendigvis alle. Men det har ingen relation til andre sprog, snarer tværtimod.

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd...

I givet fald er der efter min erfaring ikke ret mange trediepartskomponenter, som man overhovedet kan bruge - to år er et århundrede i JavaScript-verdenen.

Det siger vist et eller andet om hvor grelt det står til i JavaScript-verdenen, det er jo ikke fordi der manglede smarte frameworks i 2014, hvis der ikke er noget af det der har holdt indtil nu, hvorfor skulle vi så tro på at det vil gå bedre for modeåret 2016?