“At the GNOME Developer Experience Hackfest in Brussels, the GNOME developer community has tackled the problem of specifying a canonical development language for writing applications for the GNOME desktop. According to a blog post by Collabora engineer and GNOME developer Travis Reitter, members of the GNOME team are often asked what tools should be used when writing an application for the desktop environment and, up until now, there has been no definitive answer. The team has now apparently decided to standardise on JavaScript for user-facing applications while still recommending C as the language to write system libraries in.” Discuss.
Every single extension is JS, so it’s standard already. Most of 3rd party useful apps are extensions:
https://extensions.gnome.org/extension/111/calculator/
https://extensions.gnome.org/extension/55/media-player-indicator/
https://extensions.gnome.org/extension/120/system-monitor/
etc…
I never get tired of getting more.
The shell extension mechanism is not meant to be an application platform.
It is now.
No, it isn’t.
Stand by while Gnome slowly reinvents QML.
I’m currently a gnome 3 use (works great on new Ubuntu), but their “anything but Qt” adventure is starting to look old already.
Why can’t they just use QML? After all it’s a language, and not something bound to Qt only.
Edited 2013-02-04 20:02 UTC
I didn’t know that QML was invented before Javascript, oh and QML is also based in other set of technologies, is not the firsth onr of its class.
Edited 2013-02-04 20:23 UTC
By reinventing QML I mean creating the toolkit bindings and API’s for their javascript engine. QML is more than just javascript.
You are misinformed, GNOME started using javascript binding even before QML, the news is that it is now the official language, nothing else. And to dare to say that implementing javscript bindings is reinventing QML is an ignorant comment IMHO.
Edited 2013-02-04 20:30 UTC
Back in the day, Gnome started using Clutter bindings to implement Gnome 3. I’m not aware of them switching from Gtk to Clutter for app development, that would be even bigger news.
Clutter is a library, and is common that libraries have bindings in python, ruby or javascript, now what do you mean with “clutter bindings”? there is no such thing, now if you mean javascript bindind to clutter libraries may be.
Of course I mean javascript binding to Clutter library, because that’s what they did with Gnome shell.
See https://live.gnome.org/GnomeShell
Clutter, GTK+, GIO, GStreamer are all GObject libraries and can be used together in the same application, they are all bound to JS via the same mechanism (GObjectIntrospection).
Yep; so it appears they will focus on improving GJS bindings to Gtk et al.
I don’t see how is that related to QML, bacause QML is a meta languaje to create UI’s (that uses javascript for some tasks), GNOME’s javascript bindinds are for creating also bussiness logic, now tha fact that KDE developers are using it to put also bussiness logic in QML, witch I think is the wrong way is another story.
Edited 2013-02-04 22:48 UTC
Which is what Gnome is now advocating with JavaScript. However, they’re going to need more than just plain JavaScript. They’re going to need some kind of markup extension…………..
No they’re not. Read the summary.
Oh man, you againg (the VB6 developer), not they say they for low level stuff they will remain using C, so, bussiness logic in C is unlikely.
More information here:
http://www.j5live.com/2013/02/04/gnome-and-languages/
Javascript would be to GNOME what C++ is to KDE.
Edited 2013-02-05 00:18 UTC
Which is what Gnome is now advocating with JavaScript
no they didn’t say that, they said for applications, not UI exclusively, you do know the difference, right?
Edited 2013-02-05 00:22 UTC
Clutter is already used in Gnome/GTK applications, it’s not news. Clutter and GTK can be used together in the same application, they are complementary, just like QtGui and QtSceneGraph.
Edited 2013-02-04 21:04 UTC
Clutter has nothing to do with it. Gnome has supported application coding in JS for quite a few years now, via the ‘seed’ (WebKit) or ‘gjs’ (Mozilla) engines. Several of the games in the later Gnome 2.x releases were written in JS, with gtk widgets, and (I think) some embedded clutter stuff for the game itself.
That would be stupid, they do different things.
Clutter is a paint engine while GTK is a GUI library.
Clutter knows how to draw pixels (and lines, circles…) on a surface (like your screen).
GTK could use clutter to draw it’s widgets (buttons & stuff), but it also handles mouse and keyboard input, has events…
Does gnome still have apps? didn’t all abandon Gnome and go GTK?
There’s no difference anymore. Gnome got rid of libgnome* with 3.0 and consolidated the useful parts into GTK.
This is good news! Standardizing around a dynamic language will yield great improvements and increase developer involvement (hopefully).
But you still need to go further and just adopt HTML/CSS as the markup for defining UI. The existing gnome stuff is just shite. Really bad and old. HTML/CSS kills it in every way. Someone mentioned QML but why use QML? HTML/CSS is superior, more people know it so more developers will get involved.
If you want desktop consistency, provide templates, default css, and drop in widgets (as now, but in HTML/CSS).
Developing in gnome currently sucks. I would never consider making a gnome desktop app. I would always make a standalone node app with a web interface because it is just so much easier, robust, and strangely, FASTER.
It blows my mind how slow so many simple gnome features are, like starting up the settings. WTF?
Edited 2013-02-04 19:49 UTC
HTML/CSS is not superior to Clutter/CSS. Maybe one day with a good WebGL scene graph library, but not yet.
Edited 2013-02-04 20:05 UTC
It is less powerful if you are talking big features and only if you exclude WebGL, and why would you do that?
For little details, polish, maturity, tools, and existing developer base, HTML/CSS crushes Clutter/CSS.
In any case, there is no reason you can’t have your cake and eat it to. I’m not suggesting that they build gnome out of standards compliant web widgets. You can go nuts extending things and including custom, gnome-only widgets.
But the fundamental language for expressing things should HTML/CSS + DOM for traversal, manipulation and introspection. Drop jQuery into the mix and you have a powerful app development combo that no existing gnome (or Qt) tech can touch. And when I say powerful I don’t mean in terms of some specific feature, I just mean 95% of all potential apps can be built 50% faster, 2X more robustly by 10X more people.
Edited 2013-02-05 03:21 UTC
Sure, I just wish they hand’t standardised on the most awkward and badly designed language next to PHP.
(although admittedly JS has nifty object model)
JS is a pretty language with warts, not a fundamentally ugly language. Warts are easily cover up with a little makeup or just ignored. If you use JS a lot you’ll find it is actually an extremely expressive language, much more so than other prettier languages and certainly many times more expressive than C/C++ (or PHP) for application development. You never end up spending any thought or energy on these nasty details once you learn to avoid them.
It also is as powerful a language as more popular dynamic peers like Ruby or Python and as you mention is’t object model is very interesting and powerful, more akin to Lisp than Ruby.
Anyway, nowadays you can always use Coffeescript if you really can’t stomach JS in the buff. I personally find JS to be quite tasty.
As someone with little experience in other languages, I’m genuinely curious … what are the warts?
There are quite a few, probably two many to mention.
Most would quote the semi-colon insertion mechanism, how the “this” keyword works, and how equivalence works.
I would read JavaScript Patterns.
http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp/059680…
Edited 2013-02-05 08:25 UTC
In a way, they fully exploit the joys of irrelevance.
Of course unless they perceive only the very desktop extentions as “Gnome applications”, leaving the actuall stuff user is supposed to use on a computer unspecified. Given the fiasco linux desktop standarization that could be considered realistic approach.
I do all my apps in python and gtk3. (Gtk2 if it’s for Windows as well)
I’m glad they picked something, gobject was weird to start with but it shouldn’t be hard to translate what I’ve learnt to js.
Anyone who learnt vala is going to be pissed.
I’m a huge Vala fan and I’m not disappointed. It’s not like anyone is meant to be discouraged from writing an application in his favourite language, JS is just what will be recommended to noobs.
Edited 2013-02-04 20:15 UTC
As someone who has been recently working less with desktop apps and more with internet client webapps, I welcome to this change.
Edited 2013-02-04 20:24 UTC
Non-programmer question here: So where does it end? I mean, can the entire DE be rewritten in JS (I’m thinking not) or will there still have to be a ton of low-level C based stuff to hold it all together?
And if the latter is the case, why even bother moving to such a high level, browser engine dependent language for app development? Granted I’m far from an expert on these matters, but from what I’ve read over the years, moving JS outside the realm of browser executed web scripts is more of a hack than anything.
Don’t get me wrong, I’m all for using an easy to learn, simple but powerful language for future desktop apps, but I think the Gnome team is making a mistake here. They are building walls that they won’t be able to tear down in the future, limiting themselves to a very narrow path for future app development.
Then again, they’ve been doing that since Gnome 3 was first conceived.
The vision of Gnome has been from day one “C for low-level stuff + scripting language for high-level stuff”:
From https://mail.gnome.org/archives/gtk-list/1997-August/msg00123.html
Originally it was meant to be Scheme, now it’s JavaScript. Scheme is more beautiful, but JavaScript is more pragmatic.
Thank you! That puts things into perspective.
I guess Scheme excels in the area of ‘(beauty inner) and simplicity more than actual aesthetic side 😉
IT simply Atwood’s law in affect.
http://www.codinghorror.com/blog/2007/07/the-principle-of-least-pow…
First everyone was writing all their apps with pygtk. Now it’s javascript.
Watch as apps become increasingly unresponsive and sluggish just like they did with python.
Why can’t you just write apps using native, compiled languages? If C or C++ is too much hassle for a small GUI app, why not use Vala or D? Hell, Vala was created by gnome! (afaik)
https://live.gnome.org/Vala
http://dlang.org/
Today’s JavaScript engines are way faster than the standard Python implementation, see: http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fast…
I’m writing a Vala application. It’s quite nice in many ways… but its string manipulation functions are often pathetic. For example, I could find no way (short of coding the function myself) to concatenate an array of strings short of iterating through and doing it bit by bit.
Python: result = ”.join(strings)
Perl: my $result = join(”, @strings);
PHP: $result = implode(”, $strings);
…and, as with any language, the selection of readily-available libraries has its strengths and weaknesses.
For example, I don’t remember seeing an equivalent to Python’s highly-lenient, highly-unit-tested feedparser library in Vala, but Vala has access to an interesting SQLite ORM named SQLHeavy which Python only gained access to when it added GObject introspection support.
Edited 2013-02-05 00:23 UTC
When you do a default install of Ubuntu, you get lightdm, which is written in Vala and it is slow as hell on a lot of less powerful systems.
So my guess is Vala might not be all that great either.
Now I need 3GHz computer with 8GB of RAM and a quad core processor with a GPU just to run a calculator.
JS VMs are almost as fast as compiled code these days. I wish people would fact check this stuff.
Yes, I do wish they would. Because JavaScript is such a poorly defined language engines like V8 have to use heuristics on it over time. JavaScript didn’t suddenly become a world beating language environment because of V8. Those who do code shit like node.js.
Depends of what version of are you targering to, if you talk about an old version of javascript then yes, if it is a newer specification like Harmony then no.
Edited 2013-02-05 00:16 UTC
It not poorly defined. JavaScript is a proper programming language with a proper language specification.
JavaScript is simply dynamically typed.
There are some oddities that come up thanks to the JavaScript Semi-colon insertion mechanism and the function scope (i.e. Hoisting).
There are some evil things that the programming language allows you to do (some of the more evil things can be effectively disabled with “Use Strict”).
JavaScript has a pretty strong community and if you really get your head around it you can do some very neat things that you can’t do in other languages easily.
As another has said the newer specifications are pretty good.
As for the viability of things like node.js, Trello and other quite robust web apps that were developed in reckon time pretty much disproves the notion that it is rubbish.
Edited 2013-02-05 00:35 UTC
Well, it depends how you look at it.
It was created in 10 days and the specification came much later.
Actually, having Javascript being defined in a specification didn’t really improve the language.
It made it worse: http://www.livestream.com/etsy/video?clipId=pla_1463e546-47ed-4a93-…
It isn’t 1996 anymore.
The new spec is pretty decent, judging JavaScript by it back almost 2 decades ago now … is like judging C++ on the 1998 standard.
Well Javascript “the bad parts” is still in the spec.
And everyone worth their salt knows not to go near them.
The “almost” is the key word here.
As the original poster suggests, why should I (an end user) have to have poor performance (and a lot of resources uselessly being used) because the programmer of my applications did not know how to implement them in some native language?
Edited 2013-02-05 00:24 UTC
Why not, javascript is widely use for server side, mobile and desktop applications, and it is faster than Python BTW.
Edited 2013-02-05 00:29 UTC
That’s why I said: “native”
Edited 2013-02-05 00:30 UTC
Speed is not the only metric when writing applications.
Performance and programmer productivity are the two most important metrics when writing apps.
IMHO Qt provides a good trade-off between both of them: You can write cool and easy-to-write apps in a native language.
That’s your subjetive opinion, not mine.
Edited 2013-02-05 00:37 UTC
ERRR NO! While both are important I would argue quite strongly that performance isn’t as important as it was.
When we have more processor power and RAM than most of us can possibly use. The main bottleneck these days in Desktop applications is I/O (bar a few specialist applications).
I’d rather have something run slower that ran accurately and had a maintainable code base than something that ran fast.
Or have languages that are easy to understand like python (as opposed to JavaScript which I think is much more difficult to understand) and have the same sort of effort that has gone into JavaScript execution optimization in recent years.
Edited 2013-02-05 00:48 UTC
Watch this video:
http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
I agree with what Herb Sutter says here!
About “maintainable code”; it does not depend on the language but on the programmers, design, etc. I have seen unmaintainable/hard to read/hard to understand Java code and very beautiful C++ code… and viceversa.
Edited 2013-02-05 01:06 UTC
I have more reasons to avoid C++ than reasons to use it, so no.
It like everything else, there is the right tool for the right job.
We all know this, but give the same project I expect that managed language can be delivered quicker and will have more than acceptable performance for the vast majority of desktop applications which is really what this article is about.
Edited 2013-02-05 01:10 UTC
Firstly we must have a different definition of “almost”.
Secondly these days the main cost of any project is not the hardware, but rather the development costs. Most cheap mobile phones have more memory and processing power than we had a decade ago. I doubt you will even notice it.
Thirdly I expect there is more client side processing on a lot of webpages and applications that you probably aren’t aware of.
I been writing a Samsung TV applications. Everything is done via client side processing … it works fine on a TV’s which is running some flavour of Linux and probably has either MIPS or an ARM processor.
“JS VMs are almost as fast as compiled code these days. I wish people would fact check this stuff.”
That is a fantasy:
http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fast…
Also you will find most small JS applications spend a lot of time executing library functions written in C and as the application has more and more actual Javascript, performance really degrades. This degradation is both execution speed and memory usage.
What is really surprising is in that link it shows how the Go programing languaje that is suposed to be native is slower than javascript.
If you are talking about a large codebase with significant portions of execution time are in the application itself rather than the libraries used (which in nodes case are C), this is definitely not the case. I have ported node.js applications to Go and it was well worth it.
Also, keep in mind this is a single threaded test, Go scales much better on multiprocessor machines than V8 javascript.
(Also the version of Go used is 1.0.3 rather than tip. I switched to tip for a project yesterday and it had a surprising but appreciated 50% speed-up.)
Edited 2013-02-05 05:13 UTC
Hey, I’m just interpreting the table in the link, that’s all, you mean that table is flawed?
Well- yes every benchmark is flawed to some degree.
So that is always worth talking about; however, that does not make all benchmarking meaningless.
I was pointing out that:
1. Testing small JS programs that make a lot of library calls ends up being a benchmark of C with a little JS glue and the performance profile changes as a codebase grows and JS comes to represent where a larger percent of where the execution time is spent.
2. The benchmark linked is single threaded (that side has both, but JS data is only bailable to compare single threaded). This is esp. relevant since Go makes writing multithreaded applications easy (so most Go application are multithreaded from the start).
3. I was pointing out that the link is using Go used is 1.0.3 rather than tip. In the Go community tip is highly recommended for performance critical projects. I have seen tip be much faster than 1.0.3.
Include Python in that chart – as the high level dynamic glue language JavaScript is meant to replace in Gnome application development – and JS will indeed look in the same ballpark as C.
C to JS a factor 3.5, JS to Python a factor> 15
Plus, I expect the tooling and engines for JS to grow faster than those for Python
Depends what the code is compiled to doesn’t it?
There is native and there is byte code. I meant the latter. V8 performance doesn’t stack up bad against Mono and Java for something that is JIT compiled.
Edited 2013-02-05 09:33 UTC
Would like to see how it measures against native compilers for .NET/Java.
So would I
Obviously, it’s popular and most of developers put it on their CV (not only web developers). It’s hard to find a programmer who says “I don’t know JavaScript”.
However, JavaScript is difficult to program in *good*. It’s got different paradigm of Object Orientation than most (prototype based vs. classes). It has also very little and chaotic standard library (but there are projects that fix that), and finally, the language itself is not that great in terms of design, syntax and consistency.
Don’t get me wrong, if you use something like Coffeescript, and have deep knowledge on what is actualy going on, you can write good, complex apps in JavaScript. My feeling is that they chose it because it’s easy for newcomers to start developing, which is a mistake, and will be a painful one. You can shoot yourself easily in the foot in JavaScript, and people will.
Actually, it is easy.
I’m one, and I know quite a lot of such programmers.
Can one easily call C/C++ libraries from JavaScript? I have done quite a lot of Ruby coding and calling C libraries from Ruby Interpreter was pretty easy. Is this the case with GJS or Seed?