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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 56 reacties

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
Verdorie, geen Ruby :-(
Heel logisch. Als Gnome dicht bij de web-wereld blijft, is straks niet alleen Android en Unity een kandidaat voor tablets, maar maakt Gnome ook een kans.

Als die-hard C/C++ programmeur ben ik de laatste tijden ook uitstapjes aan het maken naar node.js. Het lijkt mij vooral leuk om applicaties te schrijven die gebruik maken van een framewerk dat naadloos code migreert tussen de browser, mobiele telefoons, servers in de cloud, en gewone desktop PCs. Ik denk dat veel initiatieven in de javascript wereld dit uiteindelijk misschien nog wel mogelijk gaan maken ook. Het bouwen van multi-agent of multi-actor systemen is toch nog wel net ietsje minder flexibel dan straks code over V8 engines heen en weer sjouwen.

Enige opmerking: die engine moet nog veel kleiner. Javascript op een ARM 7 (in een Lego Mindstorms NXT) bijvoorbeeld.
Voor mensen met snelheidsproblemen, benchmarks als http://blog.famzah.net/20...php-performance-benchmark en vele andere geven aan dat de snelheid met engine's als v8 etc tegenwoordig erg snel zijn (sneller dan python etc in de meeste gevallen die ik gezien heb). Toegegeven, benchmarks zijn meer theorie dan praktijk, maar als nog laat het een trend zien.

Waarom javascript nogsteeds langzaam lijkt in browsers komt door de DOM, wat voor de rest volledig los staat van javascript zelf. Met dingen als node.js is de performance erg goed en het wordt tegenwoordig gebruikt door bedrijven als linkedIn en yahoo.
Interessant hoe mensen zich laten leiden door het gebruik van JavaScript in verschillende browsers, die verschillende API 's aanbieden.

JavaScript is een flexibele, elegante taal waarmee je redelijk vlug uit de voeten kan. Zie http://en.wikipedia.org/wiki/JavaScript voor een.aantal interessant features, zoals dat je als je wil volledig functioneel kan programmeren.

Bijv. NodeJs http://nodejs.org/ is een voorbeeld waar Javascript voor servergerichte zaken wordt gebruikt, en met succes

[Reactie gewijzigd door 12013 op 5 februari 2013 14:34]

"Wordt al door veel mensen gebruikt" is ook echt de enige reden die ik kan verzinnen om voor JavaScript te gaan. "De engines zijn beter geworden" is een non-argument.
Okee, een scripttaal is misschien ook handig voor platformonafhankelijkheid en om makkelijker en sneller applicaties te kunnen bouwen. Maar dan is Python volgens mij nog een logischer keuze.
Tijden veranderen. Ik kan er niet direct negatief over zijn. Wel wat huiverig daar gezien Javascript naar mijn mening (nog) niet volwassen genoeg is.

Ik denk persoonlijk dat het geen foute beslissing is, wel wat vroeg nog.
Gnome is zijn eigen graf aan het graven met dit soort onzinnige beslissingen. Op den duur gaat nog blijken dat Canonical gelijk heeft met zijn strategische keuzes van de laatste tijd.
Zou leuk zijn als je de andere reacties leest of tenminste uitlegt waarom dit onzinnig is. GNOME shell is grotendeels in javascript geschreven enzo.
alles is wel meteen echt opensource ;)
Daar heb je vrij weinig aan als er niet ook een open licentie aan hangt.
Niet helemaal waar. Exploits en bugs kunnen bijvoorbeeld sneller ontdekt worden.
Dus ook sneller door kwaadwillige n. Die melden een bug / exploit dus niet maar gebruiken het zelf.

/doomdenker
Ik zou eerder C(++) verwachten. Wel wat moeilijker programmeren maar wel bloedje snel.
Bloedje snel is niet echt nodig in de meeste desktop-applicaties. Maar volgens mij is het al een crime om een rich-text editor te maken met JavaScript, laat staan ingewikkelder applicaties.
Als je snel moet, kun je volgens mij nog steeds wel met C++ terecht. Het artikel zegt dat de voorkeur wordt gegeven aan JS.
Rich text editing is een van de meest ingewikkelde applicaties denkbaar.
Toch kun je rich text editors in alle soorten en maten voor niets krijgen, dus ik denk dat dat niet helemaal waar is.
Er zijn bijna geen rich text editors te vinden die ook daadwerkelijk goed werken. Sterker nog, eigenlijk alles wat wel goed werkt, valt op de een of andere manier terug op het weergeven van code (zoals wikitext, bbCode of HTML) en is dus geen echte WYSIWYG-oplossing.
Tegenwoordig zijn bijna alle GNOME apps nog in C geschreven. Maar GUI apps in C schrijven is geen pretje.

Tuurlijk, C is veel sneller dan Javascript of Python, of een andere geinterpreteerde taal, maar die snelheid heb je zelden nodig bij grafische apps. Daarnaast ben je veel sneller klaar als je een grafische app maakt in Javascript dan als je hem in C maakt. Mocht je echt de snelheid nodig hebben kan je altijd in C een library maken met de functies die echt performant moeten zijn, en die zijn dan vrij eenvoudig aan te roepen in Javascript, door middel van GObject introspection.

Persoonlijk vind ik Python een mooiere taal, maar Python is heel moeilijk te sandboxen. De GNOME ontwikkelaars willen namelijk graag de touwtjes in handen hebben, en willen dus dat je vooral de GNOME libraries gebruikt voor bijv. File I/O, networking en andere zaken. Bij Javascript kan je dit heel makkelijk forceren door simpelweg alleen de GNOME libraries beschikbaar te maken in de omgeving, by Python is dat veel moeilijker te forceren.
Persoonlijk vind ik Python een mooiere taal
Okee, dan daag ik je uit om het volgende stukje Python code te laten werken, zonder de variabele "count" global te maken en zonder functies te elimineren.

[code=python]
def test():
count = 0

def f(l):
for i in l:
count += i

f([10, 20, 30])
return count

print test()
[/code]
En deze constructie, hoevaak kom je dat tegen? Waarom zou ik hiervoor geen class gebruiken? Waarom wil je eigenlijk uberhaupt een variabele uit een andere functie wijzigen? Ik denk dat dat meer zegt over het ontwerp van jouw programma dan over het ontwerp van de taal Python.
Door de gebrekkige indentatie is het niet duidelijk (waarom werkt [code] niet op de frontpage?), maar het is niet zo zeer een variabele uit een andere functie dan een variabele uit een bovenliggende functie door een geneste functie. In Javascript is dit zeer gebruikelijk, en in zekere zin een ander programmeer-paradigma. In Python 3 kan dit zonder problemen, in Python 2 moet je iets beter je best doen.

Of je het wilt is een ander verhaal natuurlijk, maar in Javascript kom je dergelijke constructies ontzettend vaak tegen. En ook in closures, waar deze methode nog veel belangrijker is eigenlijk.
Geen probleem:
def test():
count = 0

def f(l):
nonlocal count
for i in l:
count += i

f([10, 20, 30])
return count

print(test())

[Reactie gewijzigd door MadEgg op 6 februari 2013 07:34]

Hmm... okee ik zie dat er een nieuw keyword aan python 3.0 is toegevoegd. Gefeliciteerd :)

Maar dit is natuurlijk een "hack" van de Python makers achteraf... het is niet dat ze hiermee rekening hebben gehouden bij het ontwerp van de taal. Dus "mooi" is wat mij betreft anders...

Volgende uitdaging: probeer dit dan eens in Python < 3.0
:)
In Python 2 kan het ook, maar dan wordt het wat hackier. In Python 3 is het nonlocal statement met een reden toegevoegd, om dit (beter) mogelijk te maken.

Ook in Python 2 heb je wel toegang tot variabelen in een hogere scope, maar dan (in beginsel) uitsluitend read-only. Doe je een assignment (zoals count += i) dan wordt aangenomen dat count een variabele in de huidige scope is. Dat kun je voorkomen door niet rechtstreeks aan count toe te kennen, maar aan onderdelen daarvan. Een oplossing is dan:
def test():
count = [0]

def f(l):
for i in l:
count[0] += i

f([10, 20, 30])
return count[0]

print test()
Doordat count een list is en je de teller in het eerste element in die lijst bijhoudt ziet hij de de statement 'count[0] += i' niet als een assignment aan count maar als assignment aan 'count[0]', waardoor dit wel werkt. Mooi is anders, maar extreem lelijk is het nou ook weer niet.
Je bent geslaagd :)

Maar idd mooi is anders, en dat was mijn oorspronkelijke punt :)

Dat "nonlocal" is er eigenlijk maar als een afterthought bijgeklust door de bedenkers van Python.
Grappenmakers. Na Mono en C# nu een nog tragere taal? Nog meer bloatware dus. Laat ze het gewoon bij gecompileerde talen houden. Ik zie geen reden waarom we van beproefde techniek af moeten.
Ja, kan het niet oneens zijn met je. Kost letterlijk op het programmeer werk de laatste jaren. De hoeveelheid resources die mening nauwelijks interessante apps nodig hebben is ronduit schokkend.

Het veel gehoorde argument is dat er toch genoeg resources zijn. Heel leuk, maar ik draai veelal veel spul tegelijk en dan is het zo op :(.

Als ik kijk naar wat ik vroeger met 1MB memory kon kan ik nog wel ff huilen.
Mono is geen taal maar de library die c# compileert.
Mono is nog veel meer, mono is/zijn ook de libraries die in wezen de CLR implementeren. Verder zijn het ook de tools die het dev'en vergemakkelijken onder Niet-windows omgevingen.
Nog trager? Javascript is razend snel. En iedere browser update maakt het sneller.

Java gemaakt in de gangbare IDE's is traag. Maar dat is iets heel anders dan javascript
Javascript apps hebben helemaal niet de voorkeur. Het artikel is misleidend in die zin dat voor beginnende programmeurs Gnome de voorkeur heeft aan javascript.

Een andere kandidaat was python. Uiteindelijk hebben ze voor javascript gekozen omdat ze er vanuit gaan dat zo'n mensen op zich al in contact zijn gekomen met javascript of met zo'n syntax.

Zelf gaan gnome onderdelen en apps nog altijd gebruik maken van C(++) De realiteit is minder gewaagd dan de titel doet vermoeden.

Misschien slecht voorbeeld gezien het ding voor geen meter verkoopt, maar het is niet omdat je in Windows 8 apps kunt schrijven met HTML5/Javascript dat je opeens geen andere talen meer kunt gebruiken of dat half metro in jscript is gebouwd.

[Reactie gewijzigd door simplicidad op 5 februari 2013 14:25]

Hoe zit het bij windows 8? Geven ze de voorkeur aan XAML of HTML en Javascript?
In Windows 8 is in de win rt runtime com based. C++ is weer terug van weggeweest. Andere talen kunnen erop in haken waaronser zelfs javascript...

Top dat Apple van begin af aan heeft gekozen voor native apps in iOS. Objective C is de taal van voorkeur. En dat native zie je terug aan de performance en snelle werking. Dit heeft ook geholpen in de populariteit van objective c en heeft ook weer invloed op de ontwikkeling voor mac os x.

Javascript mist belangrijke constructs die gewoon zijn in andere talen. En is natuurlijk trager. Heeft ook wat leuke uniekere features.. Daar niet van. Maar soms komt t gekunsteld over.
Ook Javascript. Er is een speciale lib daarvoor, WinJS, en die is best netjes.
Waar haal je precies vandaan dat ze bij Windows 8 de voorkeur geven aan Javascript?
Er staat toch echt:
"Our decision is to support JavaScript as the first class language for GNOME application development. This means:
- We will continue to write documentation for other languages, but we will also prioritize JavaScript when deciding what to work on.
- We will encourage new applications be written in JavaScript.
- We will be working to optimize the developer workflow around JavaScript.

C will remain the recommended language for system libraries"
Voor system libraries gebruiken ze nog steeds C, maar voor de rest is Javascript toch echt de eerste keus die ook vanuit het development ondersteund en gepromoot gaat worden.

Als ik het goed gebruik kun je prima apps schrijven zonder HTML5, dat staat ook in principe los van JavaScript. Je gebruikt dan de C-libs die andere talen ook gebruiken om een app te bouwen. Je kunt HTML apps wel includen in een native app, maar dat hoeft niet.

Zie ook:
http://developer.gnome.or...ble/hellognome.js.html.en
en
http://developer.gnome.or...me_to_the_grid.js.html.en

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 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