Building Linux Applications With JavaScript

crankymonkey writes "The GNOME desktop environment could soon gain support for building and extending applications with JavaScript thanks to an experimental new project called Seed. Ars Technica has written a detailed tutorial about Seed with several code examples. The article demonstrates how to make a GTK+ application for Linux with JavaScript and explains how Seed could influence the future of GNOME development. In some ways, it's an evolution of the strategy that was pioneered long ago by GNU with embedded Scheme. Ars Technica concludes: 'The availability of a desktop-wide embeddable scripting language for application extension and plugin writing will enable users to add lots of rich new functionality to the environment. As this technology matures and it becomes more tightly integrated with other language frameworks such as Vala, it could change the way that GNOME programmers approach application development. JavaScript could be used as high-level glue for user interface manipulation and rapid prototyping while Vala or C are used for performance-sensitive tasks.'"

Comments

What about Python?

[Anonymous Coward]

Doesn't this already exist with Python? What advantage would there be to using JavaScript over Python? Python is a much cleaner language...

Re:What about Python?

[nurb432]

Same thing, different flavor.

Besides, you know people, they have to keep re-inventing the wheel, in their favorite color.

Its why we never get anywhere.

Perl and Python

[perlhacker14]

Is this not already present with Perl and Python? I mean, both support GTK and are fairly powerful and efficient...
But, JavaScript for desktop GUIs? That just gives me an odd feeling inside...

Re:Takes the idea of "open source" to a new level

[ianezz]

Since javascript is interpreted code and you need the source to actually run it.

Well, the same is true also for Perl, PHP, Python and even Lua, so that's nothing radically new.

Re:God no!

[sydneyfong]

Javascript is actually a nice and clean language.

The reason why it has a bad reputation is because of "web developers" writing generally horrible hacks with it. Nothing to do with the language.

Re:Bringing new devs into GNOME, that's why.

[Chabo]

I don't want a web programmer coding my GUI apps. I wouldn't be able to get Firefox to render correctly in Gnome unless I ran it inside IE!

Re:God no!

[pavon]

The main purpose of this project is to enable easy embedding of Javascript into a GNOME application for scripting purposes, on the basis that lots of people know javascript so it makes a good extension language. The fact that you can write entire applications with it is just a (disturbing) side-effect.

But if you really want to frighten yourself notice that these applications are run just like any scripting language in unix - with a shebang header line. So javascript init scripts are now yours to have.

Re:Didn't RTFA....

[siride]

C++ is awfully convoluted, maybe. JavaScript is pretty simple and straightforward, aside from a few minor gotchas. Most of the problems with JavaScript are browser API issues and not with the core language itself. It's pretty much the opposite of convoluted.

Re:If happens: KDE here I come!

[TD-Linux]

You're too late. Some KDE apps already support QtScript, which supports ECMAScript in applications.

Re:Takes the idea of "open source" to a new level

[Rei]

C++ and javascript aren't mutually exclusive. In fact, I'm checking slashdot right now during a break from debugging a home project that makes use of both of them. I'm quite fond of the mixture of a C++ backend with a javascript frontend that can be used over the web. In this particular case, it's an electric vehicle simulator that lets you specify your vehicle details and plot a route over Google Maps. The frontend uses form POST requests to call the simulator to run the CPU-intensive simulation on the backend (where it has access to many gigs of heightmap data). The backend talks to the frontend by returning javascript function calls with the results asynchronously.

I've done several projects of this nature before. One weakness is that if the backend takes longer than two minutes, the connection gets dropped. Not a problem on this project, but on a web-based Povray interface I did in the past (lets you customize car paint jobs, then renders the car in a variety of scenes), it was. The solution is simply to have the frontend take responsibility for periodically fetching the results from the backend.

All in all, I find it a very nice balance between the cross-platform web-accessible functionality of an HTML/Javascript frontend and the extreme speed of a C++ blackend.

Re:Takes the idea of "open source" to a new level

[FishWithAHammer]

There's nothing stopping you from writing a JavaScript compiler. Hell, there's an ECMAScript 4.0 JavaScript implementation for .NET.

Re:Convoluted how?

[Sancho]

Javascript gets a bad rap for a lot of reasons. Most notably is the fact that Javascript and the DOM are conflated in most people's minds, despite the fact that the DOM is not a part of the Javascript specifications--in fact, while Javascript can manipulate the DOM, it's the browser which provides the bindings. It's not Javascript causing the incompatibility, it's the browser. An analogue might be having incompatible implementations of libc--you wouldn't blame the C compiler for the problem, would you?

There's also a developer problem. People see the C-like syntax and start coding as they would in C. Javascript is functional language, and it makes use of that in significant ways. Worse, the expected semantics of block-level scope differ from C, and that's a very big gotcha for a new programmer.

That's not to say that Javascript is without problems. There are numerous quirks which I consider errors in the specification. Nonetheless, it's really quite an elegant language for the most part, and it's certainly possible to develop libraries to handle the quirky cases.

Re:Takes the idea of "open source" to a new level

[caseih]

Umm, because it's precisely the *right* language for the job. C++ restricts your binding options to other languages pretty dramatically, especially if you use parts of C++'s object model such as multiple inheritance. In short, no C++ is the wrong too for the job, Qt's use of it notwithstanding. Although it's true that Qt does have bindings for many languages, the simple fact is that these bindings, such as PyQT, are against the *C* wrapper on the C++ api. So an entire extra layer in the way. Gnome and GTK's gobject-based object model is just about one-to-one with most models of object-oriented languages. Hence you can use just about any language under the sun to develop Gnome apps. All without losing any features of the API.

If you do want to program in C with GTK, you can and it's very easy, actually. Memory leaks are minimized because of the coolness in glib. However, if you're not a C programmer then you shouldn't be programming GTK/Gnome apps in C at all. Use something more powerful like Python. In fact I can't think of any reason (except embedding on small systems, or core libraries and programs) where it's appropriate to write a Gnome app in C. There are tons of awesome bindings available. Use them. Write in C++ (which is a much nicer API at times than Qt's moc-ified native apis) if you want.

So yes. Gnome is able to target the languages that normal developers want to use. Whether that's C#/.Net, Python, C++, Ruby, or C.

If Gnome wasn't written in C, what language would you suggest? How would you provide extensive, 100% coverage of the API in any arbitrary language? Writing GTK itself in C# seems pretty silly. Same for Python, Ruby, etc, unless you want to restrict the entire toolkit to just one language.

Dear Gnome

[stoicio]

Dear Gnome project. I am a long term linux user and
also a long term gnome user.

Let me make this perfectly clear. If you script things on my desktop
with either javascript or scheme I will wipe my hard disk and install
Microsoft Windows.

Ps.

I program in both scheme and javascript.

PPs.
You're morons.

Re:Takes the idea of "open source" to a new level

[AKAImBatman]

Javascript is just one more language, but it's a VERY popular language and a hell of a lot more people know it and use it then C# or GNU-C or anything else.

While the language is VERY popular, I disagree that a "hell of a lot more people know it" than most other GNU languages. The vast majority of coders have no idea how to correctly write Javascript. In fact, you can't even say that Javascript is an Object Oriented, LISP-like functional language on Slashdot (of all places) without ten or twelve people trying to tell you you're wrong.

Which sucks. Because Javascript is an AWESOME language. Plus the modern VMs (as opposed to the last-generation interpreters) are getting quite fast. Fast enough to use JS for anything short of compute-intensive applications. Even professional video games could use it as a scripting language with the right underlying APIs. (See my sig for how far it's come with Web games.)

My hope is that as Javascript shows up in more places, developers will take the time to sit down and truly understand the language. And maybe we can even get a few books on the market that don't suck. ;-)

Re:Didn't RTFA....

[AKAImBatman]

It would be more accurate to say it's object-oriented, except that implies OOP, which it isn't.

I think you're confusing "class based" with "object oriented". Javascript is very much an Object Oriented language. Otherwise, how would this code work?

function MyObject()
{
    var value = 0; //private
 
    this.getValue = function() { return value; };
    this.setValue = function(newValue) { value = newValue; };
}
 
var obj = new MyObject();
 
obj.setValue(10);
alert("Value = "+obj.getValue());

(You can save yourself the trouble of creating an HTML file by using this page to test it.)

Prototype-based OOP can do almost everything Class-based OOP can do, except that it is far more flexible at runtime. You lose some compile-time checking, but it's been found that strict compile-time checking doesn't offer nearly as much error-catching benefit as was originally envisioned.

If you're absolutely in love with compile-time checking, consider a Javascript 2.0/ECMAScript 4.0 compiler. That will help catch typing errors up front while still creating code that's deployable in Javascript 1.x/ECMAScript 3 VMs.