Log in

No account? Create an account


Let's Push Things Forward

Maximizing social utility for fun and (modest) profit

Previous Entry Share Next Entry

Answering the question: "How do I develop an app for GNOME?"

During the GNOME Developer Experience Hackfest this week, one of the major goals we identified was the need to pick a single language to give a simple answer to "how do I write a GNOME app?".

Right now, if you ask that question, you'll get about 8 different personal-preference answers, which drives people away from our platform. Having to potentially evaluate several different languages and their stacks gives potential developers a lot of unneeded extra work.

There was broad consensus in the hackfest for this goal because it allows us to:
  • It allows us to focus when we write developer documentation, fixing bugs in the development environment and the development of tools. This reduces our maintanence costs and enables us to be vastly more efficient.

  • It enables code and knowledge sharing to occur, so that people can easily copy and paste code from existing applications, or find information about common problems and challenges.

  • It provide a coherent and easy-to-follow path for new developers.

  • It allows us to include the full GNOME framework within the language itself.

We spent a long time discussing the different options that are available to us, and there were a variety of opinions. However, at the end of the day, we had to recognize that no language is perfect and there will always be disagreement. The important thing was that we had to make a decision.

It's critical that everyone understands this decision as a plan to elevate the language, bindings, tools, and documentation to a level of quality we have not yet achieved. It is not a decision to abandon any other language bindings. We will continue to distribute other bindings and documentation as we do now and compatibility for the other languages will continue to be developed as they are today by the developers involved with those modules.

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.

Why JavaScript?
  • Our language of choice needs to be dynamic and high level.

  • There is already momentum in the GNOME Project for JavaScript -- it's used in GNOME Shell and GNOME Documents.

  • There's a lot of work going into the language to make it especially fast, embeddable, and framework-agnostic.

  • JavaScript is increasingly being seen as a first class desktop programming language -- it us being used in Windows 8, mobile platforms, and for local web applications.

  • JavaScript is self-contained -- it doesn't come with its own set of core libraries, which makes it more convenient for us when integrating it into the platform.

This is the start of a process and there's obviously a lot of work ahead of us. However, prioritizing a single language will enable us to turn GNOME into a compelling platform for application developers in a much more effective and efficient manner.

Some fun questions:

- Did you guys choose a JS interpreter yet? Or do we use that API-incompatible unsupported mess that is GJS? Do we make a platform library out of it?

- Does this mean we will slowly port existing applications to Javascript? Will new GNOME apps have to be written in Javascript?

- Does this have any influence on introspection? Will introspection gain prototype-based inheritance? Or is introspection still lowest common denominator?

- You cannot write any library in Javascript. So I guess C is not just for "system libraries", but for all libraries?

- Will the libraries be tailored more towards Javascript or will stuff still randomly SEGV if you do something not quite right?

Note that this post was largely to pass on the message of our conclusion at the hackfest. I personally don't have experience with GJS and our JS bindings (though their experts and experts with Python, Vala, C#, C, and other languages were all involved in the discussion). But I'll do my best to explain given my understanding.

- Did you guys choose a JS interpreter yet? Or do we use that API-incompatible unsupported mess that is GJS? Do we make a platform library out of it?

There's no immediate change planned here. We'll continue using GJS.

- Does this mean we will slowly port existing applications to Javascript? Will new GNOME apps have to be written in Javascript?

Some application maintainers may choose to port to JavaScript, but it will be optional and I don't expect any of them to be ported in the near future. New core GNOME apps should be written in JavaScript, but we're mainly targeting third-party app developers who are new to GNOME in the first place. We didn't make a strict decision that only JavaScript-based applications would be considered for inclusion in GNOME.

- Does this have any influence on introspection? Will introspection gain prototype-based inheritance? Or is introspection still lowest common denominator?

I don't think this is affected.

- You cannot write any library in Javascript. So I guess C is not just for "system libraries", but for all libraries?

Sure, C is recommended for any libraries recommended to be shared by other modules (which is essentially what I meant by "system libraries". But if applications ship an internal library written in JavaScript, that'd be fine.

- Will the libraries be tailored more towards Javascript or will stuff still randomly SEGV if you do something not quite right?

I don't think we would make any changes to g-i or the way we write libraries in a way that would be incompatible for the other introspected language bindings.

If you're getting segfaults from JavaScript applications, that sounds like a library or interpreter bug.

Edited at 2013-02-02 05:56 pm (UTC)

I'm so happy you chose a poorly specified 'OO' language whose great strength is its inability to run consistently even on only 2 popular interpreters.

You might see a lot of fart apps, online TODO webapps, and local webapps (wtf is this BTW?) written in Javascript, but serious people just laugh.

I agree with the anonymous poster above

Yeah, Travis, let me read your mind for a second: "you will think, these guys are just the typical trolls; if you care, you should have come to the hackfest..."

And I understand that. I understand also what you explain in the beginning of your post: there has to be "a language", to avoid confusion for newcomers. There has to be consensus inside so much diversity. I agree.

But the decision you made I think has been the worst of the ones that you could have possibly had done. Seriously, if I were to choose such a crappy language, I would have come around again to the initial question and said: ok, maybe instead of choosing one language between hundreds of languages, why not choose 2? It would still mean focusing more, 2 is much less than the number of languages/platforms that are out there (around the Gnome ecosystem).

And then if you do that, you could choose a 2nd language that overcomes the disadvantages of the 1st selection: poor OO paradigm, dynamically typed, garbage-collected (runtime required)... How about if the 2nd is Vala?

Just my 2cents as always.
Thanks for spending your time improving the ecosystem in the hackfest, guys.

(no subject) (Anonymous) Expand


Decision is made, so doesn't make much sense to complain about but I kind of thing that with all python apps that are already available on GNOME and all the amazing work that has been doing on introspection, Python does look like a really good candidate to me.

Is not only a great language per se, but also widely used everywhere.

Still, as you said a decision had to be made, so props for making one!

Now we have to try to make that language the perfect citizen for GNOME development :)

Gil Forcada

Python is a great language, and none of us disagree with that. If you like it, please feel free to keep using it. The choice to promote JavaScript will not make Python any harder to use in GNOME than it is today.

Thank you for recognizing the importance of promoting a single, coherent stack.


JavaScript? Could you possibly have chosen a worse language?

Vala was specifically designed to work flawlessly with GObject and it's so close to Java and C# that any developer can learn it in a day. But you chose JavaScript, a language that uses a weird prototype object system that is inherently different from the object model of the GNOME libraries.

Seriously, what were you smoking?

By definition, JavaScript was decided to be the best choice. There's no need to be vitriolic.

The language syntax-level differences between Vala/C#/etc. and JavaScript really aren't as big as people like to make them out. JavaScript on top of GObject might not be quite as clean today as any of us would like (we certainly considered it a negative when evaluating our options), but it should improve significantly when ECMAScript 6 is finalized and the JavaScript world moves on to it.

Seriously, what were you smoking?

There's absolutely no excuse for this. You're putting down everyone who was involved with the hackfest who put a lot of effort and knowledge into this choice. I have no problem with you disagreeing but there's no reason to be so hateful (and it doesn't help your argument at all).

Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand
Re: SRSLY? (Anonymous) Expand

Heh, intersting choice.

Everytime when I talk with people who are interested in desktop development, javascript is their language of hate. Folks are learning java nowadays in college. A OO language would be a much better choice.

I strongly disagree with your choice. Not because I don't like javascript, but rather because I think the developer story is quite poor and is not going to be rich anytime soon. It's not even a tooling problem we can easily fix.

Re: Heh, intersting choice.

Uhm, how is javascript not an OO language? Basically everything you manipulate in it is an object.
It offers dynamic binding, polymorphism, encapsulation, inheritance... everything you need for OOP.
It's not like OOP starts and ends with Java and C++, or even with class inheritance.

A choice is a good choice

(first ... i have nothing to do with gnome. I'm only developping using the gnome platform)
I think many people in comments is this language is the best, or the other. I have to agree with the choice.
Javascript is becoming more and more popular with the web frameworks and web development these days. So, as *entry* language in the gnome ecosystem, it is a great choice.

Of course, who is actually used to program in the gnome libraries would choose python or vala ... if you want performance, or you like, you can choose C or C++. The ones used to program in java, will choose the java bidings. But the point here is ... to choose a language to make it easy for people to *start* developping with the gnome platform, so that all that n00b kids can easilly create an "hello world" message in a confortable way.

Re: A choice is a good choice

to choose a language to make it easy for people to *start* developping with the gnome platform, so that all that n00b kids can easilly create an "hello world" message in a confortable way.

Just to clarify, JavaScript application development on GNOME is intended to support applications up to the scale of iOS/Android/Mac App Store-sized apps at least because that's the approximate scale of application that makes sense on the desktop, tablets, and phones. We're not optimizing just for trivial applications.

Edited at 2013-02-03 03:27 pm (UTC)

Just my 5 cents.

Wow, some people really don't understand that "put a focus in Javascript" do not means "make Javascript the only one".

Anyway, thank you very much "Treiter" for your time and effort spent (and that of others involved as well) to improve our beloved Gnome.

And, Man, Gnome OS will be fucking awesome :)

Re: Just my 5 cents.

Thank you - I'm trying to see how many times I have to repeat this point for it to stick :)

In balance, a good decision

I whole heartedly agree with the reasoning behind the choice, despite being someone who has a strong dislike for writing software in JS, and the more I think about the announcement the more I agree with it.

I've oft lamented that Gnome/Gtk+ apps written in Python use a chaotic mixture of Gnome Platform and Python libraries, whereas in Gnome apps I write I prefer to use only the Gnome platform (where possible). In fact I've been spending some time recently porting a PyGtk app to PyGobject and the next items on my to do list are to switch from using Python API's (i.e. Pickle) to using Gnome Platform API's (i.e. GSettings).

Having a small, popular, high-level language which makes use of the entire platform is a fine goal and for that, and the increasing popularity of the language, JS seems like a good choice.

At first I was a little put-off by the statement "We will encourage new applications be written in JavaScript." however, I realise this just ties in with the idea of promoting JS as a first-class citizen in terms of documentation and tooling.

A sensible decision, I think, despite by dislike of JS. I look forward to seeing how this decision affects the Gnome developer experience, particularly tooling!

Re: In balance, a good decision

Thank you, and please help out and/or stay tuned. I'm confident we can work out the issues over time. No option is perfect, or it wouldn't have even required an in-depth discussion.

I'm interested in static analysis of programs to improve quality. Given that JavaScript is dynamic in just about every direction, and not at all amenable to static analysis, how can we expect to improve tooling so that programming errors are caught before release? (That was the reason I wanted to attend the DX hackfest.)

As an example, this is the kind of thing which I'm interested in: http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts. Possible with Python (as an arbitrary example), probably not possible with JavaScript.

(Note: linting is not the same as static analysis. Linting is useful, but has limitations.)

Re: Discussion question

Yeah, in the very least, I think we should make linting happen for JavaScript code in the same places we compile our compiled code to minimize risks of, eg, runtime compilation errors (the type that are caught earlier in static languages).

I'm not personally an experienced JavaScript developer (more C, Vala, Python, etc.), so maybe others can point out other areas we can bridge the gap between static and dynamic languages. I'd certainly welcome that.

I strongly disagree with the decision

(Sorry to be posting this anonymously...)

I strongly disagree with the decision. Just to give you some feedback based on my personal background (so maybe you could see why I'm a gnome user but not a gnome developer): I am a long time (amateur) developer. I've developed with GTK+, Gtkmm, Cocoa, some Windows stuff that I've forgotten, mostly C++, some experimenting with the D programming language and python, and some Java courses.

I've never developed with Vala, C#, JavaScript, or Go, but I've looked at each of them. I've never even done a whole app in python, just some Blender scripts.

I'm a long time Gnome user. I used KDE at first, somewhere around the year 2000, but I was unhappy with its design. I tested almost all of the alternatives too, but always came back to Gnome (even if it was not perfect!)
When Unity came, I found it to be awfully designed (and buggy). But... I really liked Gnome 3 (or Gnome Shell). It had its bugs, but it was greatly designed. I still have to tweak it (three round ubuntu style close etc. buttons on the LEFT side of the window header), but it is almost as good as Mac OS X! ;) And in some ways it is better.

But the Gnome developer story has never appealed to me. I didn't like C. I liked C++, but Gnome had so much better design than KDE, that as a user I chose Gnome.

Anyway, I'll probably keep on using C++, but I think Gnome should go with either Python or Vala. JavaScript has such a bad reputation, even though Gnome shell is great. And I think that a reputation in programming languages is usually a very good metric on deciding what is good and what is not.

There's a lot of experience with Python on Gnome, and I associate it as the semi-official language of Gnome. (And hey, Blender uses it!) I would never touch it myself, but it should be the language of Gnome.

Re: I strongly disagree with the decision

While i agree with you totally (except i prefer C over C++), python or vala would be a better choice.

BUT ... i think they intent to publicit javascript for new comers ... the old developpers already know gnome's corners so they can use what ever they like (c, c++, python, vala, java, C#). To make it easier for new developpers they will improve javascript documentation and tools, so that new developers can adapt easilly to the gnome platform (not only gnome, but mostly glib, gonject, gtk+, and so on). The reason to use javascript is because it is widely spread now, with so much web development.

Later, even the new developers will be bored with javascript and use other binding,

It is comical seeing people rant at this decision... in a browser running JavaScript. I'm not aware of *ANY* recently-developed Linux application that rises to the level of quality of fit, finish, polish, and innovation of recent browser-based applications (the greats like Audacity, Blender, Mozilla, vlc have all been around more than a decade). If Python, Ruby, Vala, whatever are so much better than JavaScript, where's the evidence?

I look forward to the next part of your process where GNOME delivers kick-ass compatible implementations of the additional Web APIs developed by Blackberry, Mozilla, Tizen, WAC et al for audio, camera, filesystem, notifications, sensors, etc. that are slouching towards standardization. Every computing platform that isn't Apple and Android is saying "Write HTML + JavaScript + CSS apps for us". It's only Linux desktops that persist with the fantasy that offering a multitude of languages and a bunch of Linux-only APIs will somehow deliver lots of competitive applications. Be realistic and humble and seek compatibility with all the other also-rans.

My only frustration with JavaScript apps is how they are tied to privacy-sucking web sites. There's no reason why a photo editor, text editor, ToDo manager, etc. has to involve logging into some social web site. _That's_ where free Linux desktops bring real value.

Good luck!

Thank you for taking the heat on this. >.>

Tell me what I or others can do to help with writing the developer documentation going forward, and how much of my and my mentor's work can be reused for it.

Hey! Thank you for volunteering! Much appreciated. I found someone else who is also interested in writing.. I bet we could come up wtih a good crowd to do this kind of stuff.

I know that Jakub was working on switching the documentation platform to using Mallard. We should probably figure out how to properly do this work. I'm clueless, but I can help coordinate.

Compelling choice

I think js was compelling choice given the large amount of apps that have been written with gjs since gnome3 was released and given the hordes of js developers that have joined the gnome ranks

Re: Compelling choice

I like this comment above :)

Ever since I first became involved in GNOME, people have complained that we have a confusing application developer story, and that we need a recommended language. I'm really thrilled that we've been able to make some progress on this issue and overcome one of our long-running historical problems.

Making decisions is hard. There will undoubtedly be people who disagree with the choice of language. You can't avoid making decisions if you want to make progress though. The worst outcome would have been no decision at all.

Other languages will still be available, of course, and the work that members of the community do to support those languages will continue to be valuable and important.

Cross-platform apps

Do you know if there is (or will be) a version of GJS for other desktop OS (Windows, MacOS mainly), so that GTK (or GNOME) apps could be run flawlessly on other platforms?

When I have to develop an application, I never develop it specifically for a given platform because I never know which platform my future clients will be using. So, currently I use Python 2.x and GTK...

Re: Cross-platform apps

That's an excellent point. I think (I wasn't at the hackfest, I'm extrapolating from what people have previously said) that one of the main advantages of JS is that developers will use the G* APIs throughout, because it doesn't have a platform of its own unlike e.g. Python. Those are intended to be portable and more or less are, although there are various issues with Gtk+ 3 currently (mostly because nobody has the time to fix them). That means that any portability work on the C APIs is automatically inherited by JavaScript. That's in contrast to Python where although different OS's are supported there's not much work done to abstract away the differences in the standard library (I think subprocess is the worst example of this, where several of its features could be emulated on Windows but aren't). SpiderMonkey should work on Windows and MacOS already, so it shouldn't be too hard to get GJS up on those platforms as well.

Re: Cross-platform apps (Anonymous) Expand