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.
Agreed with that, although i tried getting into fixing a bug in Geary (a Vala written mail client) and documentation was so scarce, i gave up on it early on, before wasting hours of trying to figure out Vala.
It seems to have gotten better, and they added lots of stuff on https://live.gnome.org/Vala/Documentation BUT for example, i'd like to open and write a sqlite database. There even is a vala binding: http://valadoc.org/#!api=sqlite3/Sqlite
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.
> 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.
> 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.
I can't speak for everyone else, but as somebody who writes a lot of Web software and very little blogs, I can say that I have plenty of grandiose spiritual self-delusion.
I may not be close to the metal, but I write good software.
I spend far more time writing back-end code (automation, data handling, and services) more than I do front-end code. Most of that code is so that the front end can be nicer. Just because the UI I develop is web-based, doesn't mean I don't know how to write effective code. I do think that JS is an acceptable language for UI development. It is hands down the most widely used language on the planet. Gnome isn't deprecating the other interfaces, it's just that they are steering new developers to the JS interfaces. I do think that the Python guys are having a pretty bad attitude about it though. They had to pick A language as their base for documentation purposes, and I think JS is probably the most pragmatic choice here.
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.
The web is great and all but there are times when I want something with better desktop workflow integration.
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.
The whole point of simplified languages like Python is that it isn't digging -- the basics of the language are super-easy to learn, and GNOME's bindigs make it easy to hammer out simple apps in it without fuss. If this move was purely choosing a "lightweight" language, Javascript would have scarcely been considered purely by virtue of its boatload of gotchas.
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.
You might underestimate the time required to really understand a new language and be as productive in it as you would with something you have used routinely for years. Bare in mind it is not just the language but the whole ecosystem and also that some programmers can adapt to new languages better than others.
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.
By your logic, the choice of JavaScript would only make sense if the majority of open source developers that GNOME is trying to attract work exclusively (or at least primarily) on web development. They should instead be focusing on the body of talented desktop developers, who on the whole are much better versed in c*, python, or any of the myriad of not-webtastic languages.
I think they are trying to attract web developers here, which makes sense since web developers or hybrid web/desktop devs probably outnumber desktop focused devs right now.
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.
A language you already know has lower (real or perceived) friction than something you don't. Some people may hate writing Javascript (though some subject themselves to it voluntarily, see node.js) but they still write increasing quantities of it.
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.
> 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
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.
You can still use C/C++. The headline and article are misleading. You can also use the other bindings available. However, they can't support everything under the sun.
You took it out of context totally. Here is the explanation they give:
"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."
PhoneGap is about marketing, not about software. For customers it's difficult to find a specific website, but it's easier to find an app in the app store. The devs are still web guys, but thought they will sell more if it looks like a "real app".
I disagree. I used PhoneGap to develop my cloud-storage app so that I don't have to develop the App for 4 different platforms (iOS, Android, Windows, BlackBerry). I believe most devs use PhoneGap to develop real apps, not just to pack their existing websites into native apps.
This makes sense, thank you for the insight :) Wouldn't it have worked as a normal website? Does PhoneGap offer access to native APIs that are not available from web?
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".
The wall is the "standard" store. Pretty much like Apple does, because you can also jailbreak an Apple and this doesn't make their ecosystem any less of a walled garden.
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 don't need to "hack" Android to install any app from any source you want. Same goes for Linux distros including Ubuntu. Package managers are not App-store type walled gardens.
It's a "walled garden" instead of just a prison camp, because it's not completely forceful but it's enough deterrent to keep control over the average user which is what moves the economy.
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.
On Debian, the standard packaging system is APT, and it is more work to install software from alternative sources than it is to run `apt-get install`. Is Debian a walled garden? Why or why not?
Please answer my question. If package management shares the characteristics of a "store" in that it is the "blessed" and easiest method of obtaining software, what makes it not a walled garden while app stores are?
Debian keeps a minimum imposition policy on their package management. Often they will do the packaging for you even.
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).
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.
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.
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?
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.
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 ;) )
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?
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.
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.
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.
The issue with Gnome has never been there libraries. They are lays consistently top notch. A lot of their UI is quite awesome as well. There issue is that there is a lack of consultation with their users when they make changes.
Basically, the developers meet at GUADEC, whatever, think of an idea that directly affects users, then implement it without any communication or consultation.
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)
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."
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.
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.
> its the most popular desktop app dev language period - by sheer numbers.
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.)
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.
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.
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.
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.
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.
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.
...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?
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++.
That's true, but also irrelevant. GNOME Shell isn't an app, it's part of the infrastructure.
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.
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.
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.
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.
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.
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.
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?
>>> 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.
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.
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?
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.
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.
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.
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.
Web applications are built around the DOM, using onClick methods and many other "web-only" apis. They can not be easily ported without almost a total rewrite, so you may as well use a different language. I also think that recommending a different language is better then recommending javascript, even if that's all the person knows (naturally I'm not suggesting they remove javascript support).
That will depend on the application in question and how much of the code is directly related to the GUI.
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.
Python is dynamically typed, but it is still strongly typed. It throws type errors consistently when you try to do things that don't make sense. Contrast with Javascript, where {} + {} is '[object Object][object Object]'.
Javascript when doing operations between to variables will try to coerce them into the strongest type that both support... in your example that is String, in this case ({}).toString() == "[object Object]" ... which is why you get the result. Your not understanding how a system works is not an error in the system.
What would you expect in your example? A deep copy/merge, a shallow copy/merge... right merged with left and result returned?
While the results are definitely deterministic, and play by a set of rules, most people don't bother learning these rules. This can lead to bugs in programs, if people do not take proper care. Since weak-typing doesn't give me any features, and could be a source of bugs in my program, I prefer to use languages that don't use it.
It's not even an issue in languages (C) that don't strongly type for performance reasons, or because you get closer hardware access as a result (though these count as features themselves). The problem is that in Javascript, you don't get either of these -- there's no benefits, there are only new bug vectors. This wouldn't be as big of an issue if the default coercion behaviour was generally helpful, but it's not. It's just a pain.
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.
Maybe because Javascript achieved that growth and subsequent ubiquity not on its technical merits but because and only because it was the de facto language of the web (and still is to this day for a reason that still eludes me).
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.
Bamboo is also very fast-growing, but we don't use it for desktop application development. We use it for making huts, preparing food and treating infections.
I guess my point is that growth doesn't matter when it's in another sector.
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.
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.
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).
Describing the title as "quite inaccurate" is very generous. "deliberately inflammatory in order to generate page views" is much closer to the mark given that the article came from the register.
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?
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.
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.
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.