Gnome: apps in JavaScript hebben de voorkeur
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.
Het 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)
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/
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 dinsdag 5 februari 2013 14:37]
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
, Javascript geeft gewoon altijd direct de juiste line, Kheb nog nooit hoeven nadenken over een js fout 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.
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
, Javascript geeft gewoon altijd direct de juiste line, Kheb nog nooit hoeven nadenken over een js fout 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 dinsdag 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).
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
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
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.
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 dinsdag 5 februari 2013 14:25]
Er staat toch echt:
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
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."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"
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
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.
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.
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.
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.
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.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
