
GNOME project picks JavaScript as "first class" dev language - iProject
http://www.theregister.co.uk/2013/02/05/gnome_standardises_on_javascript/
======
kybernetyk
I think they (GNOME) would like to 'lure' more web-centered developers to
their platform so that's why they chose JS.

But there's a fault in their thinking IMHO. Web guys are web guys for one
reason: They sincerely believe web is the future and better than native
desktop software. (For some values of better.)

And then there's the other big group: The native desktop devs who don't think
JavaScript is a good choice for a native platform as there's already a big eco
system of C/C++ code supporting this platform and why make the extra work of
creating JS bindings? (I'm one of these guys - though I don't develop for
GNOME.)

So all the GNOME guys do with this decision is to alienate their existing
developer base while not really attracting any new devs to their platform.

Personally I think Vala was/is a perfect language for their platform. It's sad
they they gave up on that.

~~~
_pmf_
> Web guys are web guys for one reason: They sincerely believe web is the
> future and better than native desktop software.

That's probably only a very small, but very vocal group of developers; those
that seem to spend more of their time on writing about their work and their
unique insights into how software development should be done (all inferred
from their petty front-end dabbling) than actually doing something productive.
The vast majority of web developers is developing for the web out of
necessity, not because of some grandiose spiritual self-delusion.

I do of course agree with your view that this move will neither attract new
developers nor keep existing developers happy.

~~~
StavrosK
> The vast majority of web developers is developing for the web out of
> necessity.

I wouldn't call it _necessity_. I, for one, like the openness of the web, how
it allows me to deploy software to all my users at the same time, the
customization, etc. I don't believe it's the holy grail, but it's hardly out
of necessity that I develop for it.

------
CJefferson
While that is the title of theregister's piece, it is not true. The bindings
of no other language are being removed, the GNOME project has just decided
what answer they should give to the question "What should I write my new app
in", and to try to get one language's documentation up to really high
standards.

~~~
zapdrive
Yea, the title is misleading, as down there in the article they clearly say
that JavaScript will just be given priority, and work on other languages will
continue.

------
buster
I don't know if i really like that approach. I'd much rather prefer Python or
even C/C++. There are already so many desktop bindings for Python, why going
through the hazzle to support all this in javascript? The documentation will
be poor, many libraries will be missing, the learning curve will be high in
the beginning. My guess is that the Gnome team wants to take advantage of the
amount of Javascript capable developers. But seriously, will many of those
website/html/css/js developers write a desktop app where the overall community
spirit is to replace apps with websites?

~~~
matthiasv
You are probably not aware of the GObject Introspection mechanism that is
available for quite some time now. Any compliant GObject-based library can be
used by any language that supports GI through an intermediate representation
of the classes, interfaces etc. So, you don't need to write any bindings,
neither for Python, JS, Java, Go or whatever.

~~~
buster
Question is if there is a GObject based library for everything a developer
likes to do?

~~~
chris_wot
Give me a list of everything that a developer likes to do, and I'll try to
answer this.

~~~
buster
Ok, let me put it this way:

What do you estimate is bigger? The amount of plain C libraries or the amount
of GObject based libraries? Where would you put the amount of available
perl/python/ruby modules?

(The amount of C libraries not in GObject is my answer to your question ;) )

~~~
chris_wot
Your question confuses me. What exactly do you believe GObject does?

~~~
buster
Out of my head and with no experience in it i'd think it's a library/framework
to give plain C libraries more object oriented features, a type system and
overall the base for most or all Gnome libraries. Probably comparable to Qt in
that it probably has its own String implementation or container
implementations. Much like Qt but procedural. Is that far off?

~~~
phaylon
It does that, but that's not the important point. The fun part comes with the
GIR files, that abstractly describe the classes, functions, members, constants
and what have you in XML. Which means your language bindings are inflated from
that description. That minimizes the effort to build and manage bindings for
libraries developed on top of GObject.

~~~
buster
Well, i don't question that flexibility, i have high regards of Gnome and run
it for years now. I am not developer of Gnome, so i actually couldn't care
less, apart from concerns of how the development of gnome turns out in a few
years. Will JS in Gnome take off? Will there be more or less new developers?

What i question is the quality of documentation and the amount of 3rd party
libraries (partly based on what i have seen from vala and in comparison to the
whole C/C++ ecosystem and the amount and quality of 3rd party libraries for
python, which i surely know more of then of GJS and GObject). No doubt it will
be a massive amount of work to sort of replicate the efforts already put into
the existing projects. Does the Gnome development have those resources? It
will have to rely on other developers to join and work on that, for sure. It's
sort of a chicken/egg problem. Why would i choose to write my Gnome app in
Javascript when i have many well tested and well documented alternatives?

In the end, most interesting would be the point of view and experience of a
vala contributor or even a Mono developer.

I don't doubt that glib, gobject and everything starting with G is nice ;)

But, again, how does it compare to the superset that is the C eco system or to
a "direct competitor" that is python/ruby/perl/mono/whatever, _especially_
when it comes to desktop apps. Just take a look at how much is written for the
Linux desktop in perl/python/mono/ruby and how good it actually works.

What is wrong with C/C++/python/ruby/mono/perl that it REALLY REALLY REALLY is
beneficial to go down another road?

P.S.: Yes, i get that it is still (and will always be) possible to write apps
in those languages. It's most important what the primary and recommended way
is, though.

~~~
phaylon
I can't really comment on that, I'm in the Perl 5 category myself :) My first
assumption is they're trying to get some of the JavaScript crowd to do Gnome
application development by connecting the communities. In this case, by
actively working on the bindings.

------
sandGorgon
Does anyone know what happened to Vala[1] and why it was not picked ? It seems
to have a huge amount of traction[2] and generates compiled code (which seems
to me as performant than Javascript)

[1] <http://en.wikipedia.org/wiki/Vala_%28programming_language%29> [2]
[https://live.gnome.org/Vala/Documentation#Projects_Developed...](https://live.gnome.org/Vala/Documentation#Projects_Developed_in_Vala)

~~~
jitl
Mostly because Vala is a GNOME-only language with no external support or buy-
in. It'd be rather insular of GNOME to say "if you want to write apps, then
learn our new, GNOME-only language."

~~~
sandGorgon
Vala is modeled after C#, which probably is (empirically) the most popular
desktop app development language.

genuinely curious : In general, do we see a lot of desktop app developers
coming from the web world on Linux ? I'm pretty sure that is not the case in
the Windows world. In fact, more often than not I have seen die hard fanatics
("interpreted languages sucks for desktop apps!!" vs "C++ sucks") on both
sides unwilling to cross over.

~~~
riquito
"the most popular desktop app development language" on MS Windows only, where
GNOME doesn't run

~~~
sandGorgon
its the most popular desktop app dev language period - by sheer numbers. I see
these people as the target market for Linux, especially with the closed
marketplace of Windows 8 RT.

I am not sure these developers would come onboard with knowledge of javascript
- so the biggest advantage (ubiquity) is nullified.

I am not sure which developers is Gnome targeting by choosing javascript. At
this point in the evolution of OSes, its all about the app marketplace.

~~~
psionski
Linux has always had an app marketplace, it just wasn't called a "marketplace"
(when everything is free, the marketplace/store analogy isn't appropriate). At
least in Debian and derivatives, everything is a one-click install since '98.

How JavaScript fits in this picture, however, is still beyond me.

~~~
sandGorgon
an app marketplace is not simply about package managers. Its about an
ecosystem that allows developers to develop high quality apps. Additionally
its about payment systems, etc - but tgats not relevant fof this discussion.

I'm finding it hard to believe that you can woo quality desktop app developers
using javascript.

~~~
psionski
Yeah, I totally agree about JS.

Otherwise, I'd call the Free Software Movement a pretty neat ecosystem :P I'm
sure at least some people will agree :)

------
estavaro
It's an OK choice. I'd rather they picked Dart instead. Dart has a better OO
support and a cleaned up core language. But it's early days for Dart still.

Dart has a VM by the same folks who created the JavaScript V8 Engine and they
say that they expect Dart to be faster than JavaScript in a number of ways.
Part because Dart's code is less dynamic than JavaScript's. Part because
loading Dart files could use a pre-parsed file.

You can work on documenting Dart code by adding types to the APIs as it's
optionally typed. Dart on the browser gets translated into JavaScript for
deployment making the issue of not having a Dart VM everywhere less important.

One of the niceties of Dart is that before deploying, code gets reduced by
removing unused code with a tree-shaking algorithm based on Dart's less
dynamic features.

    
    
      class Dart extends JavaScript {
        var points;
        Dart(this.points = 10);
      }
    

That's a sample Dart class with default constructor parameter.

------
reidrac
Further info: <http://treitter.livejournal.com/14871.html>

In fact I recommend reading the comments.

EDIT: ah, I didn't notice the reg linked to the blog post (I got distracted by
the _inaccurate_ title). Well, that's the source anyway and my recommendation
stands.

Kudos to Travis Reitter for replying to the comments.

------
Andrex
I don't think I've seen a more inaccurate headline stay on HN for so long.

JS isn't the sole app dev language and it won't ever be. It's the language
they chose to prioritize resources for tooling, documentation, and
evangelizing of the platform to new developers.

A better, more thoughtful explanation is at the developer's blog, which I hope
the OP link is replaced with: <http://treitter.livejournal.com/14871.html>

------
tikhonj
Well, it's an answer to the paradox of choice.

Also, JavaScript is not a bad language for UI development at all. It certainly
has its warts, but I liked it more than the other frameworks I've done UIs in:
Java Swing, Perl/Python Tk or Haskell WX.

Admittedly, I really liked the FRP logic part with Haskell, but actually using
wxWidgets was pretty poor. Also, JavaScript has some very compelling FRP
libraries itself which could probably be adapted to work on Gnome.

~~~
camus
Well,I wish we had ES4 instead, which would have been even better but thanks
to Microsoft,Yahoo and Mozilla betrayal this will never happen.

The irony is when Microsoft comes up with Typescript because they now think
javascript is not good enough.

Eventually Javascript will look like Python.

~~~
psionski
...and Microsoft already had WPF... Isn't everything else VERY primitive
compared to it? Why would they go back to an inferior technology? Adoption
issue?

~~~
camus
Microsoft had JScript.NET even before C#, so this was purely a political move
not a technical one.

At that time , investing on javascript would not have made Windows sell more.

Now Javascript is seen as a way for MS to get more apps on their RT plateform
thus sell more Windows licenses.

However , i dont believe MS javascript move is a long term one.

------
apaprocki
Back in 2005 at Bloomberg we decided to move all Terminal app development to
server-side JS, using a homegrown system built on top of a custom GObject
(GObjectIntrospection didn't exist at the time, so we made our own) and
SpiderMonkey. IIRC, GNOME was starting to experiment with JS around the same
time. JS isn't for everyone, but it certainly makes app development faster
than writing apps in C/C++.

------
millstone
What is the most sophisticated GNOME app written in JavaScript thus far?
Honest question.

~~~
quarterto
Large parts of GNOME Shell are written in GJS using GIR hooks to LibMutter and
Clutter.

~~~
PommeDeTerre
Given that GNOME Shell is one of the most criticized and outright hated pieces
of open source software, it isn't a very comforting example.

~~~
adam-a
Most criticism centres on the design, not the technical aspects, I think it's
fair to say. It's an example of a fairly large, complex, and smooth
application written in Javascript for the Gnome platform.

I am looking forward to more apps using JS to see how well it all works in
practice though. More docs and support will help this I hope.

~~~
correnos
I think that the language is not necessarily so disconnected from the design
as you say. Language influences thought, and can thus have a large effect on
how people solve problems (ex. When's the last time you used a lightweight,
snappy feeling Java app?). If Javascript leads people to designs like the
GNOME shell, I'd much rather it be kept out of GNOME's toolkit.

~~~
PommeDeTerre
Very true.

I think it's also important to consider not only how JavaScript may influence
developers while they create software, but also what its voluntary use says
about the developers' experience, knowledge and judgment.

It's one thing to use JavaScript when you're doing client-side web
development, where it's basically the only option, even if it's dressed up as
CoffeeScript or TypeScript. But it makes absolutely no sense to voluntarily
use it when C, C++, Python and even C# and Vala are available. Doing so would
be a significant show of very bad judgment, in my opinion.

If you need performance or power, using C or C++ makes perfect sense. If
minimizing development time and effort is important, then Python will work
extremely well. Vala and C# generally fix somewhere in between. So there's
absolutely no place or need for JavaScript, which is inferior in every
respect. No intelligent developer should ever feel the need to choose it when
developing GNOME applications, given the much superior alternatives. Anyone
who does want to use it probably shouldn't be contributing to a project like
GNOME in the first place.

------
msie
Doing some work in Mono/C# and it rocks. That would make a way better choice
than JavaScript.

~~~
petercooper
It's been a long time since I looked into GNOME dev but that _was_ the main
choice for the last 10 years or so, wasn't it?

~~~
ebassi
no, it wasn't - mostly because of political bullcrap coming from the "I'm
purer than thou" crowd. obviously, the biased perception that gnome was using
C# exclusively was also due to the same crowd.

this also led to the C#/mono platform lagging behind, so that these days
writing gnome apps in C# means using deprecated libraries, which is
unfortunate.

~~~
petercooper
Ah right, maybe that's where I got the impression. I used to follow Nat
Friedman and Miguel de Icaza's work in the early/mid 2000s and picked up a 'C#
is the future of GNOME' vibe.

------
ilaksh
That is a misrepresentation. They are just going to recommend JavaScript if
people ask which to use and focus on supporting that. Not forcing people to
drop other languages.

My question is, what about people that like JavaScript derivatives like
CoffeeScript or LiveScript?

~~~
jiggy2011
I guess they just compile them to JS as they would for the web. On github I
have seen a few gnome3 mods written in coffeescript.

------
moron4hire
>>> Today, Reitter says that question has “about 8 different personal-
preference answers”. That's not helpful because “... it 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.”

That makes absolutely no sense. You aren't going to evaluate GNOME as a C
developer and thinking about whether or not you're going to use the Python
bindings--you're going to use the C bindings. This is just garbage.

------
urlwolf
I'm using gnome shell and I love it. I moved to it from awesomewm, so that
gives you an idea of the type of user that I am. They made some bold moves on
UX, and I was surprised I was agreeing with them. There's a tiling wm
extension, shellshape, that has advantages over awesome (!). I'm happy with
the move. This is just to say that gnome is not targeting grandmas and
teenager with their redesign. If you were used to gnome 2 desktop (which I
hated) give 3 a serious try.

------
pre
Sole?

> "We will continue to write documentation for other languages"

I think you mean 'primary'. Everyone who loves C or Python or whatever will
continue to be able to use C or Python or whatever.

------
AnthonBerg
I'm sorry, but the intuition-less "practical" decisions of GNOME of late only
make me think this now:

Q: What do GNOME developers really want? A: Who cares?

~~~
chris_wot
If you were a comedian, I'd heckle.

~~~
AnthonBerg
I'd understand.

------
xutopia
I don't understand why all the hate. Javascript is the fastest growing
language right now and there is no sign of slowing down. My question is why
would they pick another language over this one?

~~~
keeperofdakeys
Javascript became the language of the web because it was there, and people
adapted. While it may be secured in the web, I think it's a mistake to pick
such a, for lack of a better term, horrible language for programming on the
desktop.

As a language, javascript feels less complete when compared to other languages
(like python). The weak-typing is especially bad, leading to inconsistent
results. More time/effort is then required to write a good application, which
I think is unacceptable.

~~~
jiggy2011
Javascript has the advantage that most of the millions of web devs out there
have used it or a language that compiles to it at some point.

By comparison python is a relatively niche language.

It also has the advantage of allowing web devs to port their web code over
easily to a desktop app.

~~~
PommeDeTerre
It's best to keep those kind of developers isolated to the web, and away from
important, widely-used software projects like GNOME. I think a lot of the
problems with GNOME 3 were due to web developers and designers getting
involved, bringing in some dumb philosophies, and making decisions that were
quite terrible.

Things were much better when it was C programmers doing the bulk of GNOME's
design and implementation.

~~~
jiggy2011
A lot of web developers are working on things that are more widely used than
gnome.

This seems roughly equivalent to saying "This platform should only have
applications written by neckbeards for neckbeards"

I think if this brings programmers who would not traditionally target Linux
desktop to target gnome that is a good thing. if their apps suck it should be
straightforward to avoid them.

~~~
keeperofdakeys
I do agree that unix/linux was full applications written by neckbeards for
neckbeards at one point. The push to have applications that are more usable is
good. The problem is they have taken this too far, and the programs and DEs
that are being created now are truly annoying to use, and harder to learn for
anyone.

I think the biggest problem is that everything is being written for "The
N00b". I don't think anyone has a very clear picture of who this person
actually is, so they cut back functionality and UI elements to try to make it
more friendly for this person. What you end up with is a DE like Gnome Shell,
that is significantly different to what many people are used to, and takes
longer to learn how to use. I also think many developers wouldn't actually use
some of their applications, which leads to many more problems. There was a
talk at an Australian linux conference recently where a speaker told the story
of how he had tried to use evolution, but came across many bugs. After talking
to the developers, he found that none of them used/tested the features he was
using, so these kind of bugs can popup without soneone fixing them.

------
correnos
Fitting that the article should end with the "best tool for the job" defense.
This argument seems to be used almost monotonically to justify poor language
and design choices.

This move is bad for the GNOME project as it has the potential to knock the
quality of new GNOME apps down to the quality of the average web app. They're
robbing themselves of the benefits of native development and, due to their
GNOME-specific APIs, not even getting portability in return.

------
mariusmg
And thus the road to irrelevancy begins....

------
antihero
This is absolutely laughable. If you make an API, you make it language
agnostic.

I can understand if they are _recommending_ it, but I'm not sure lowering the
barrier to entry so low that you're going to have an absolute tonne of
horrendously written, likely insecure apps, is all that good.

~~~
maheart
The GNOME APIs are language agnostic. They're a fantastic example of language
agnotism. Anything written with the Glib library or libraries that have Glib
bindings for them, can be accessed from any language that is
GObjectIntrospection-able: currently this is Javascript and Python, but there
might be more.

>> lowering the barrier to entry so low that you're going to have an absolute
tonne of horrendously written, likely insecure apps, is all that good.

I disagree. One of the most common questions about opensource projects is
"where do I start contributing?", and the FOSS community admits that the
initial contribution barrier is high.

Horrendously written apps I can live with: I just won't use them. Regarding
insecurity, I'd much rather an insecure desktop app than an insecure web app
(that might be accessible to the world).

~~~
shawn-butler
RE: bindings other than javascript/python [0]. I have used the Go binding.

[0] <https://live.gnome.org/GObjectIntrospection/Users>

------
hcarvalhoalves
Problem: too much choices. Solution: let's introduce one more choice, and a
crappy one while at that.

------
josteink
They say Javascript is good because it's self-contained with no core library,
which is fair enough.

I'm curious what engine they've decided on using though. As far as I can see,
that has not been mentioned. Anyone got any intel?

~~~
adam-a
Spidermonkey I think. <https://live.gnome.org/Gjs>

------
jimmaswell
I thought when you were making a desktop application for linux distros it
wasn't supposed to only work on one DM. Why would you have to specifically
think about gnome when you're making one?

~~~
wmf
If you're writing an app that uses GNOME libraries you'll probably be thinking
about those libraries quite a lot.

------
chris_wot
I'd like to see LibreOffice rewritten entirely in JavaScript.

~~~
maheart
Hard to tell, but I'm guessing this is sarcasm.

This would definitely be possible. When GNOME say "Javascript", they actually
mean Javascript + GObjectIntrospection + any C libraries that are written with
Glib or libraries that have Glib bindings for them.

Javascript will end up calling C code.

~~~
chris_wot
Not at all. I'm quite serious. I'm actually interested to see if this could be
done.

But this is very interesting :-) Can you point to any documentation?

 _Edit:_ the issue with porting LibreOffice to Javascript is the sheer _size_
of the codebase. I don't suppose anyone has a block diagram anywhere of
OpenOffice/LibreOffice that divides it into modules?

I mean, how do you tackle such a massive codebase? It looks like Michael Meeks
has a good idea about this, but the biggest problem with the codebase is that
there isn't any high level, quality documentation that shows how it works.

Also... and this is probably just me, but I can't even find the entry-point to
the code. That's always been my issue with these apps, but that just shows my
exceeding lack of ability in C++ coding I suspect.

------
StudyAnimal
Oh man! I just learned Guile!

