Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 56 reacties, 11.790 views •

De ontwikkelaars van de Gnome-desktopomgeving stellen dat applicaties bij voorkeur in JavaScript worden geschreven. Het Gnome Project belooft developers te zullen ondersteunen bij het schrijven van Gnome-apps in de scripttaal.

Volgens developer Travis Reitter ontstond er tijdens een recente bijeenkomst van Gnome-developers een discussie over de 'beste' programmeertaal voor het bouwen van applicaties binnen de Gnome-desktopomgeving. Nadat de nodige voorkeuren waren besproken, viel de keuze bij het Gnome Project op JavaScript, een scripttaal die al breed gebruikt wordt voor het bouwen van webapplicaties.

Gnome logoHet Gnome Project stelt dat het bij het opstellen van documentatie voor developers voorrang zal geven aan JavaScript. Daarnaast zullen ontwikkelaars worden aangemoedigd om apps in JavaScript te schrijven en het Gnome Project belooft developers de workflow voor het bouwen van Gnome-applicaties in deze scripttaal te optimaliseren.

De keuze zou op JavaScript zijn gevallen onder andere omdat de prestaties van moderne JavaScript-engines in de afgelopen jaren flink zijn verbeterd. Daarnaast wordt JavaScript breed gebruikt bij de bouw van webapplicaties en ook in bijvoorbeeld Windows 8 worden veel apps gebouwd met behulp van de scripttaal.

Reacties (56)

Reactiefilter:-156055+139+210+31
Moderatie-faq Wijzig weergave
Interessant hoe javascript als meest geschikte programmeertaal gekozen kan worden.

Toegegeven, de afgelopen jaren is de taal weer een heel stuk verder geevolueerd. Maar een volwaardige programmeertaal zou ik het toch nog niet durven noemen.

Waarschijnlijk bedoelen ze overigens ECMAScript.

[Reactie gewijzigd door frickY op 5 februari 2013 14:21]

Ik vind het een goede en verstandige keuze. Javascript is sneller dan python door de moderne engines, iedereen kan het schrijven, en het brengt geen gui security problems met zich mee zoals qt4 in c++. Daarnaast is customizability vaak lastig, maar met javascript kan dit prima.

De functionele backends zullen overigens nog gewoon in c en c++ geschreven worden dus met snelheid zit het echt wel in orde.
ECMAscript is Javascript. Het verschil is puur bureaucratisch, in de realiteit zijn de termen uitwisselbaar.

Verder is Javascript gewoon Turing complete en kun je er alles mee programmeren wat je ook in elke andere taal kunt bouwen, dus waarom zou het geen volwaardige programmeertaal zijn?

Javascript is al jaren de belangrijkste en meestgebruikte programmeertaal ter wereld, omdat er bijna geen omgeving of apparaat te vinden is waar het niet op draait. Van televisies tot tablets, van telefoons tot consoles, overal draait Javascript. Wil je een applicatie maken die echt platform onafhankelijk is, dan kun je bijna niet om Javascript heen.

De voornaamste reden dat Javascript door velen niet serieus genomen wordt is omdat bijna niemand de moeite neemt om de taal echt te leren. Genoeg programmeurs denken "ah, curly braces, dit ken ik wel", terwijl in feite Javascript totaal niet werkt zoals andere C-achtige talen. Alleen de syntax heeft er iets van weg, maar daar houden de overeenkomsten ook wel op.

Mensen zouden er goed aan doen de video's van Douglas Crockford te kijken of zijn boek "Javascript: the good parts" te lezen voordat ze afgeven op Javascript. Waarschijnlijk komen ze er dan achter dat er weliswaar zeker wel wat mis is met de taal, maar dat er ook een paar hele mooie features in zitten die je lang niet in elke taal tegenkomt.

Een goed beginpunt is deze Google Tech Talk: http://www.youtube.com/watch?v=hQVTIJBZook

Wil je er echt induiken, dan is deze serie een aanrader: http://yuiblog.com/crockford/

[Reactie gewijzigd door Dingen op 5 februari 2013 14:37]

Ad Turing-compleetheid: schrijf eerst eens een paar programma's in Brainfuck voordat je dit als argument aanvoert in een praktische discussie.
ECMAscript is Javascript. Het verschil is puur bureaucratisch, in de realiteit zijn de termen uitwisselbaar.
Dat is niet helemaal waar, anders was javascript en scripttaal ook uitwisselbaar.

JavaScript is EEN ECMAScript implementatie, net als ActionScript en TypeScript(wat dan weer wel nar JavaScript compiled).

En waar JavaScript bij mij tegen aan loopt is dat het nog altijd erg lastig te debuggen is, waar de meeste programmeer talen dat toch beter doen (veelal omdat er een compiler voor hangt). En dan hebben we het nog niet over gehad over typing in JavaScript (iets wat TypeScript mooi oplost, zoals veel andere dingen die JS onnodig moeilijk maken).

Je kunt er zeker hele leuke dingen mee doen, getuige HTML5 maar het draaid op even veel platformen als enige andere taal. Waarom? Omdat er nog altijd iemand een omgeving moet schrijven waar het in draait. Iets wat met de meeste "echte" programeer talen niet hoeft. Net als wat je er mee kunt. het kan wel op een TV draaien maar niet magisch dingen gaan doen die niet eerst in een andere taal geprogrameert zijn, namelijk een javascript engine en API.

De grens tussen scripting en programmeren word lastig te leggen door de managed talen zoals C# en Java, die veel gemeen hebben met script talen: ze worden niet rechtstreeks gecompileerd.

[Reactie gewijzigd door LOTG op 5 februari 2013 15:03]

JavaScript is EEN ECMAScript implementatie
Dat is alleen formeel zo. In de praktijk is Javascript dť implementatie van ECMAscript en zijn andere implementaties (zoals Actionscript) een variatie hierop.

ECMAscript bestaat alleen op papier. Wanneer ECMAscript in de realiteit wordt gebruikt, heet het Javascript, tenzij er een variant wordt bedoeld, dan heet het naar de variant.
Verder is Javascript gewoon Turing complete en kun je er alles mee programmeren wat je ook in elke andere taal kunt bouwen, dus waarom zou het geen volwaardige programmeertaal zijn?
Turing complete is niet het enige wat er toe doet, of wel?
Javascript is al jaren de belangrijkste en meestgebruikte programmeertaal ter wereld, omdat er bijna geen omgeving of apparaat te vinden is waar het niet op draait.
En dus is het gelijk de belangrijkste taal ter wereld? Ik begrijp je logica echt niet.

JS is leuk, maar ik wil er geen grote of kritische applicaties mee maken.
Als je echt weet hoe JS werkt (en niet zoals de meesten er maar vanuit gaat dat je wel weet hoe het zit), is er geen enkele reden om er geen grote of kritische applicaties mee te bouwen. Het is namelijk prima mogelijk om de goede onderdelen van JS uit te buiten en de slechte onderdelen juist te vermijden.
(..) dus waarom zou het geen volwaardige programmeertaal zijn?
Het voelt toch met veel dingen nog steeds niet efficiŽnt. Check de Dune 2 port of die Amiga Emulator. Dat je met javascript een chip van een kwart eeuw geleden alleen kan emuleren op cutting edge hardware, het lijkt wel alsof hardware steeds sneller wordt zodat de programmeertalen steeds langzamer kunnen worden.
Exact, dat is ook De Wet van Gates.

(Er was geen apart artikel op de Wiki, wel een vergelijkbare)

http://en.wikipedia.org/wiki/Wirth%27s_law

edit: Whoeps, dit was een reactie op Redsandro :P

[Reactie gewijzigd door ik.ben.iemand. op 5 februari 2013 15:39]

http://www.youtube.com/watch?v=NftT6HWFgq0
Dit is inderdaad wel waar het op neerkomt, hoewel het overall programma wel sneller word.
Dat heeft niet zoveel met Javascript te maken, maar vooral met de trage manier waarop browsers met beeld en geluid omgaan. De DOM helpt ook niet bepaald mee. Een implementatie als node.js (waarin je niks te maken hebt met deze vertragende factoren) is razendsnel.

Maar sowieso is efficiŽnt omgaan met hardware niet de heilige graal van computerwetenschap. Natuurlijk is het aardig als je applicatie ook op wat mindere hardware nog functioneert, maar veel belangrijker is dat je code testbaar, leesbaar en onderhoudbaar is. Wat dat betreft hebben we echt grote stappen vooruit gemaakt sinds de jaren '80.
Voor image processing, 3d of andere intensieve data processing kan je toch gewoon Webgl gebruiken, Webgl levert bijna native OpenGL snelheden zodat je zelfs de modernste graphics algoritmes vloeiend kan renderen in je browser, En dat gezeik over dat javascript niet in staat zou kunnen zijn volwaardige apps te draaien is echt nergens op gestoeld, Ik heb al tig c++ apps geport naar javascript, En het draaide gewoon perfect. zelfs zeer recente gpu demo's, je moet alleen weten hoe je het moet programmeren. Ik heb ooit nadat ik al een tijdje op de noob manier programmeerde een framework (geprogrammeerd door google) helemaal uitgeplozen en kwam er achter dat ik het helemaal verkeerd deed, sinds dien is het bijna 1 op 1 zoals elke andere machine taal. Het is vooral zaak dat je wanneer je in een andere taal een class maakt een function maakt, En de methodes kan je aanmaken met door prototype tussen de class naam en methode naam te zetten, Dan hoef je alleen nog een createObject( name ) parser te maken die de juiste class oproept en voila :)

Wel grappig ik heb al zoveel c++ en java software geport en vaak het enige wat ik hoef te doen is de qualifiers weghalen en in de body vervangen door var, parseint voor ints waar het echt iets dat is alles..

Ook hoor ik iemand zeuren over de gebrekkige debugging, Hah ik hoop dat deze persoon nooit Opengl/DirectX gaat programeren :P , Javascript geeft gewoon altijd direct de juiste line, Kheb nog nooit hoeven nadenken over een js fout :P Ook kan je in chrome tenminste, vet goed bladeren door de code vanuit een tree van funtie's als er een fout is zodat je altijd kan vinden waar de error door veroorzaakt is.

[Reactie gewijzigd door kajdijkstra op 5 februari 2013 19:19]

Belangrijk voor development van interactieve applicaties (bijvoorbeeld web-apps) zijn de "closures" die je in javascript kunt maken. Dit zijn eigenlijk functies die je kunt meegeven aan andere functies. Zo kun je makkelijk event-handlers definieren. Het leuke is dat je vanuit deze closures weer variabelen in de eigen scope kunt vangen en tegelijk variabelen in een hogere scope kunt benaderen. Dit maakt het heel natuurlijk.

In talen als C en C++ kan men alleen maar dromen van deze handige constructie, getuige ook de ingewikkelde constructies die men in de loop der jaren heeft bedacht om dit op te vangen (zie bijvoorbeeld Qt).

De laatste tijd is men ook aan het proberen om andere talen af te beelden op javascript, zie bijvoorbeeld het Emscripten project. Het is alleen jammer dat javascript _net_ niet de juiste primitieven heeft om alles op een efficiente manier te vertalen. Hopelijk gaat men daar wat aan doen, want dit kan weer leiden tot een hoop verbetering op het gebied van programmeertalen (onderzoekers kunnen dan immers hun talen afbeelden op javascript, en de resulterende programma's kunnen dan ineens op heel veel hardware efficient draaien).
closures zijn grotendeels ondersteund in de laatste versie van C++, toch? En QT vind ik best intuitief om in te programmeren. Layouts samenstellen in QT vind ik ook beter werken dan bijvoorbeeld HTML+CSS en Windows Forms.

Door de 'oneindige' flexibiliteit van Javascript vind ik het juist lastig om niet-triviale systemen te ontwikkelen. Ik heb aan een project gewerkt waarbij de GUI van een embedded systeem in Javascript werd opgebouwd. De constructies die nodig waren om inheritance etc te implementeren zijn niet echt eenvoudig te begrijpen. En ook als ik een keer de javascript-frameworks in ga met een debugger om te snappen wat er onder water fout gaat heb ik al heel snel geen idee meer wat er gebeurt. Geef mij maar een typed language, waarbij je in elk geval weet wat voor ding je als argument aan een functie moet meegeven. De type-checker kan je beste vriend zijn, mits hij duidelijke foutmeldingen geeft :)
Volgens mij wordt voorbij gegaan aan waar je het voor gebruikt. Heb je geen performance nodig kun je met JS prima werken. Maar laten we niet vergeten waarom de taal is uitgevonden en laten ze het daarbij laten.

C en C++ zijn de performance talen maar ja die hebben nou eenmaal het nadeel dat je wat meer kennis nodig hebt en dat het bouwen van een applicatie meer tijd kost.

De discussie was er eerder ook al tussen de VB en C++ mensen, VB lekker snel en simpel scherm ontwikkelen en C++ heeft de performance.

Waarschijnlijk zal deze discussie altijd wel blijven...
Het is zonder meer waar dat je voor C++ meer kennis en ervaring nodig hebt om een applicatie te bouwen. Dat het echter meer tijd kost is onzin, als je ervaren bent met C++ kun je daar zeer snel applicaties mee bouwen, en het resultaat is dan ook sneller dan dezelfde applicatie in eein scriptingtaal geschreven.

Scriptingtalen zijn gewoon wat laagdrempeliger voor mensen zonder al te veel programmeerervaring.
Waarom eigenlijk niet Gnome's eigen programmeertaal: Vala?
Ik vond het idee wel aardig: De syntax van Vala is grotendeels geleend van C# en het compileert onder water naar C, wat door GCC weer naar binaries gecompileerd word. Gebruiksvriendelijke syntax waar iedere C#/Java programmeur mee aan de slag kan en razendsnel. Al gaat dit natuurlijk wel ten koste van de portability en voor debuggen moet je terugvallen op gdb.
In het bron artikel is bij de reacties te lezen dat Vala zeker een goede optie was maar Javascript veel bredere steun heeft om de beschikbare engines sneller en stabieler te maken.

Er zijn enorme development teams bij Mozilla en Google bezig om de Javascript engines steeds maar sneller te krijgen. GNOME heeft niet genoeg mankracht om Vala net zo snel te verbeteren als Javascript nu gaat. Dus denken ze dat Javascript in the long run een betere keuze is dan Vala.

En die argumentatie vind ik zeker niet gek.
Toch wel opmerkelijk, omdat bij de ontwikkeling van versie 3 van GNOME zo zwaar werd ingezet op Vala.

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True