GNOME project picks JavaScript as "first class" dev language
theregister.co.uk
theregister.co.uk
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.
Maybe; how does that fit in with PhoneGap?
http://phonegap.com/2012/05/09/phonegap-beliefs-goals-and-ph...
> The ultimate purpose of PhoneGap is to cease to exist.
"Our second goal is not nihilistic but is rather a commitment to standardization of the web as a platform. We believe in a web open to everyone to participate however they will. No locked doors. No walls. The things we do with PhoneGap are directly influenced by the work we see at the W3C, WHATWG, and other research such as Mozilla's WebAPI, BONDI, WAC, Webinos, webOS, Tizen and the like."
It's much harder to figure those out than the usual bindings let's say http://docs.python.org/2/library/sqlite3.html . There is some Database class. But apart from function names no documentation is given at all.
With the python version (and most likely ruby, perl, C, etc.) i can start immediatly, there are examples and everything.
No, why should this be different with the gnome javascript bindings? What happens if there is no binding? You can find lots and lots of bindings for the major script languages and it is easy enough to create one yourself thanks to boost and SWIG and ctypes in python.
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.
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.
Oh my, your horse, it is so high!
I may not be close to the metal, but I write good software.
I have to admit that I'm a bit of a JS fan (warts and all), and with NodeJS and MongoDB it's been a far more fluid development experience than other groups of technologies I've had to work with over the past 17 years in software development. It's a pretty decent language to work with.
When it comes to language bindings GObject creates bindings for multiple languages. I know I'm only ever going to use Gtk via python personally.
Being able to reuse a chunk of code written for the web and integrate it into gnome could allow for rapid development of lightweight applications for the desktop.
Since the Linux desktop is still a minority platform, anything that makes it easier to port apps there without digging into python/mono/C++ is a win.
In fact with MS adding first class JS support for metro apps there might be an opening for a cross platform library that pops out Metro and Gnome apps.
As for code-reuse, most any web library you could care for has probably been done, better, locally. The only allure of Javascript libraries are that they can be utilized in the browser, and since GNOME JS code relies on GNOME-specific APIs you don't even get that benefit.
GTK already allows you to write cross-platform apps. Javascript isn't going to improve matters there.
From a business point of view you are likely looking at a considerable time sink on an existing developer, or possibly hiring an extra one.
This to develop for a platform with ~1% market share does not necessarily look like a great investment.
Javascript on the desktop allows you to take a bunch of the code that you may have already written for the web or for Metro or for phonegap , add GTK stuff for desktop integration and call it good.
Out of these millions of web developers, regardless of which stack they use Javascript is the one thing they have in common whether they love or hate it.
The lines between web and desktop are blurred to a point anyway, and there are plenty of people out there with experience developing rich applications in JS.
I'm guessing the play here isn't so much to get people to write gnome3 apps from the ground up but to focus on making it possible to give rich web apps first class gnome3 support with the minimum of extra code.
Of course other bindings will continue to exist for those who prefer to use them.
This move is bad precisely since a lot of web and native developers alike realize that Javascript is a terrible language, and rightly hate writing it. This move serves to alienate all those devs who would rather write in a sane language since desktop development gives them that choice, but instead see GNOME embracing the biggest wart of web development to date.
The same arguments could be made to PHP or Visual Basic and I remember people saying nasty things about the C++ WinAPI back in the day.
Unless you have the luxury of being Apple you don't really get to say "here's our blessed language , you will learn it" if you want to appeal to the masses.
Granted, hence why the GNOME devs didn't choose Vala. That doesn't explain why they didn't choose a cleaner, easier language, and it certainly doesn't explain why they chose the ass-end of web development.
> already know
The developers that Already Know only Javascript are not, in my opinion, the ones that GNOME will garner the most benefit in attracting.
Charging for software is somehow evil, but wallet gardens with "road tax" are somehow acceptable and people are getting used to them.
Makes sense for them I guess, but I'm going to continue ignoring Gnome as I've been doing since Gnome 3, as they have made very clear I'm "outside of their target demographic".
They are taking steps in that direction.
They are trying to become a channel just like Ubuntu and like every man and his dog seems to be doing lately. At this point their interests and those of the users don't necessarily align 100% of the time. The same applies to Google, Apple, Ubuntu, and a bunch of others really. If you just want the best possible desktop environment and nothing more, I'm sorry but that's not their priority now and compromises will continue to happen in that regard.
You can, theoretically, find apps outside of the "official" channels and install them. This is not what usually happens and this is not what's encouraged. The success and visibility of apps outside of these channels will always be limited at best, so de-facto they control what people run for the most part, and that's more than enough.
If you mean something different by "walled garden" then maybe we're discussing over semantics. Apple does go a step further though, if you mean that Apple's is the "only" walled garden.
In a walled garden, apps are taylored exclusively and you have to do it. They also impose conditions going further than licence and stability. Eventually they ask for a cut of anything you sell over there (which is something Debian hasn't ever done and won't do).
That's where they are going. Stay tuned.
Things that used not to belong in Gnome - it used to be a Desktop Environment with no more pretences than that.
Not only that there is a sane language like Python, there is Vala as well. There are already are good binding for both. GNOME should have marketed the hell of out of Vala, I think.
I think GNOME should have played ball better with Ubuntu. Now they sort of got pushed to the back a bit and they are trying to be "cool" again. But as you said, there is only one latest cool platform and that's the browser.
If I want to write a "app" for GNOME I would write it for Ubuntu's Software Store, I wouldn't write it for GNOME desktop.
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 ;) )
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.
Basically, the developers meet at GUADEC, whatever, think of an idea that directly affects users, then implement it without any communication or consultation.
If you're using GI to access GObject libraries like Gtk+, you can still use any library your language supports for anything you want to do.
[1] http://en.wikipedia.org/wiki/Vala_%28programming_language%29 [2] https://live.gnome.org/Vala/Documentation#Projects_Developed...
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.
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.
How JavaScript fits in this picture, however, is still beyond me.
I'm finding it hard to believe that you can woo quality desktop app developers using javascript.
Otherwise, I'd call the Free Software Movement a pretty neat ecosystem :P I'm sure at least some people will agree :)
By what numbers? Number of projects using the language? Number of lines of code in the wild in that language? Number of users using apps written in the language? Because I don't have the numbers in front of me, but I seriously doubt that that's correct. Firefox, Chrome, iTunes, Photoshop, Dreamweaver, Excel, Word, Powerpoint... None of these apps are written in C#. The most popular app dev language, period, is C++. (Maker help us all.)
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);
}
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.
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
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.
The irony is when Microsoft comes up with Typescript because they now think javascript is not good enough.
Eventually Javascript will look like Python.
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.
it's a coffeescript descendant rather than a haskell->js compiler, but it has a very pleasing haskell/ml surface.
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.
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.
Rhythmbox? C. Evolution? C. (Geary? Vala.) Shotwell? Vala. LibreOffice? C++. gnome-terminal? C.
There are no GNOME apps written in JavaScript yet. The fact that they're using it in the shell is promising, but if they want app developers to pick it up en masse they need to lead by example.
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.
My question is, what about people that like JavaScript derivatives like CoffeeScript or LiveScript?
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.
> "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.
Q: What do GNOME developers really want? A: Who cares?
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.
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.
Things were much better when it was C programmers doing the bulk of GNOME's design and implementation.
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.
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.
All of the business logic , AJAX requests etc should be fairly reusable.
I know there have been plenty of times building web apps where I have had to maintain separate front-end and back-end code in different languages that does exactly the same thing.
Time can also be a factor, if you are already maintaining a web client , a mac client in obj-C and possibly an android Java client having to learn yet another language and ecosystem is probably not what you want.
What would you expect in your example? A deep copy/merge, a shallow copy/merge... right merged with left and result returned?
I expect a type error, like I said before. Implicit coercion between types is the definition of weak typing, and is part of what separates Python from Javascript.
I guess my point is that growth doesn't matter when it's in another sector.
Funny how the number of languages a programmer can pick from is growing every day, but on the one HUGE platform that is the web, it's Javascript or nothing. And by funny, I really mean extremely annoying and a severe regression.
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.
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.
>> 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).
Recommending is all they are doing here (the title is quite inaccurate)
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?
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.
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.