Slashdot Mirror
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.'"
Doesn't this already exist with Python? What advantage would there be to using JavaScript over Python? Python is a much cleaner language...
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...
Well, the same is true also for Perl, PHP, Python and even Lua, so that's nothing radically new.
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.
Don't quote me on this.
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.
Don't forget that C produces smaller and faster binaries than pretty much any other language except very good assembly. For code that's called hundred if not thousands of times per second, and where latency is a factor, you want small and fast. Good C delivers that.
C's biggest advantage is that you tend to work directly on the data, not a copy of it.
C's biggest weakness is that you tend to work directly on the data, not a copy of it.
You're too late. Some KDE apps already support QtScript, which supports ECMAScript in applications.
You better start packing your bags since a large number of Gnome GUI applications are already being written in Python these days.
Bye!
I'd actually say it's one of the cleaner of the C-syntax'd languages, and it's certainly less convoluted than, say, Perl....
Tweet, tweet.
You're about five years behind the times, bud.
Javascript lacks a clear way of enforcing interfaces. Any part of the program can extend or modify the prototype of any other object on the fly...
Many of us would consider that a feature, not a bug. But, actually, you can enforce interfaces fairly easily with closures, if you really need them.
More importantly:
invalidating reasonable assumptions which other programmers had about that object.
If you're making assumptions you want others to be aware of, the right place to do so is in documentation. Otherwise, you've got the unsolvable problem of idiot-proofing your code -- they will always build a better idiot.
If people are deliberately breaking the rules you've laid out, you're going to have problems anyway. No language can actually enforce interfaces -- it's always possible for people to go edit that source (or the binary, if they have to), perform reflection (with or without a debugger), or just scribble all over your application's address space.
Javascript also lacks multithreading support (no way to synchronize in the language itself).
Threads are evil.
More relevantly, this actually isn't much of an issue for most real applications of Javascript. I'm sorry, but when was the last time an AJAX application needed to use more than two cores?
Closures are nice if you know how to use them, but otherwise they are a serious memory leakage hazard.
...so learn how to use them.
Citation needed on the memory leakage, also.
Everybody and their mother pretends to know how to code with it.
This is true regardless of language.
Any language can be used to write horrible code. Any language can be used to write decent code. The real question is, how much work does it take to write decent code in one language versus another?
Don't thank God, thank a doctor!
There is no browser, only XUL.
Correct. In other words, this has already existed for years. Most of Firefox's user interface is written in XUL (read: JavaScript + XML)
My blog
Interpreted languages are just too slow
In some cases, "interpreted" languages outperform "compiled" languages.
In the more common case, if it takes a hundred cycles to perform an operation in C, and ten thousand cycles to perform the same operation in something else, it still took less than a millisecond. I don't know about you, but if a GUI app responds in a tenth of a second, it's fine.
Do you have any specific examples of interpreted programs that are "too slow"? Are you sure it's due to being interpreted?
in some cases, too flaky
Citation needed. Many systems that need to be much more reliable than desktops run in interpreted languages. You're posting on one right now, in fact -- not only is D2 written in JavaScript, but the Slashdot server code (Slashcode) is written in Perl!
Are you seriously telling me that what's fast enough to run Slashdot isn't fast enough for you?
But because there's less code to right, there's actually fewer bugs. There is, in fact, a study which shows that bugs per LOC is constant across languages -- therefore, if I can write the same program in 100 lines of Perl, Python, or Ruby, that might take 1000 lines or more of C, it probably has ten times fewer bugs.
If it runs ten times slower, but it's fast enough, I'll take that reliability any day.
Don't thank God, thank a doctor!
Are you nuts? You obviously don't understand how this framework is designed. This isn't even about web apps. Where is there any hint that this will run untrusted? Since when does anything in Linux run untrusted? Silverlight for great justice?
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.
and now those "web developers" will write horrible hacks for Gnome
Who logs in to gdm? Not I, said the duck.
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. ;-)
Javascript + Nintendo DSi = DSiCade
I refuse to get into what bad programmers can do.
To be fair, bad programmers can write crap in any language.
XML is a known as a key material required to create SMD: Software of Mass Destruction
I've been programming a lot in Actionscript 3.0 (the backend scripting language for the newest version of flash). This is basically a refined version of javascript, and I have to say it is the most pleasing language to program in I've touched in quite a while.
I think that breaking projects into two levels is often the way to go. Write the crucial, high-speed, massive-volume bits in C or C++, test them thoroughly, and then write the rest of the app (in which performance doesn't matter and reliability and ease of programming is key) in a high-level scripting language.
Embedded scripting isn't anything new even in the GNOME environment. Scheme is the scripting interface generally available for GNOME applications. This development just allows javascript to be embedded in applications. I think this is a good thing. First, javascript is a very good language. Most problems people associate with javascript have to do with the browser and NOT javascript. Second, javascript is known by a lot more people than scheme. It's probably the most well known and used scripting languages in existance. Combine that with the fact that we now have three high performance javascript implementations that are still improving and I think you have a pretty good case for javascript on the desktop. This will only make extending GNOME applications easier. I think GNOME is in good hands if development focuses on Vala/Javascript application programming.
Time makes more converts than reason
Hmmmm, and that is based on? :-
I wish people would drop this stupid bindings argument. It's brain dead. Firstly, bindings have to be maintained, properly, if they are to be of any use to developers. That takes effort. Secondly, why bother with binding object orientation and other languages on when you can have a language built with proper object orientation in the first place because that's what your software requires? Vala shouldn't even really be necessary.
Oh, and the Smoke bindings that KDE uses have proved you wrong. So pffffffffffffff.
Absolute WORD sir. C++ for fast shit, python calling the shots. Heaven.
I would argue that the two reasons to choose a language these days are A) Syntax B) Libraries. If the syntax frustrates you, is bloated, makes it difficult to write large apps (VB, COBOL, XML-languages, etc), you'll demonize it. However, even if you have a clean syntax, if there are insufficient libraries (that are practically trusted across different platforms), then you can't do much more then trivial hello-world apps, or bind tightly to a handful of platforms.
The fact that you can't reliably say, I'm at least version X, and thus I can make use of this suite of features is extremely disappointing in this day and age.. The XML processing library (which is a large part of data-exchange these days, like it or not), the insecurity of using the much cleaner data-exchange format of JSON. The nightmare that is the javascript event model (elegant on a handful of browsers, but nearly impractical in the open-wild).
Argue all you want about how the 'language' transcends these web-centric features - how do you initialize an app? How do you chain-load 'includes', how do you perform IPC, how do you push data-streams into and out of the VM, how do you access files, how do you handle threading (inside or outside the VM), how do you deal with syntax errors (abort, roll back before processing the new script, or skip the lines that failed - possibly to the end of the file (like browsers do)), how do you deal with unicode, how do you deal with date formating (yes there are some primitive routines build in), how do you deal with regular expressions (there is a built-in routine but it has browser differences - which one do you choose).
Ignoring the fact that the stock toolkit is a mixed bread mutt, is like handing off C with no reliable standard header files.. fopen works differently on different UNICIES.. shudder...
That being said, I think javascript is more than adequate for a given plugin.. I use grovy, beanshell,velocity for simple DB-stored/dynamically-modified scripts; no reason to not use javscript there as well.. But these scripting languages are assumed to be relearned from scratch every time they're put into use, because different microversions might have dramatically different ways of interfacing with them. More importantly, your container treats the script like a leperous child.. You carefully massage it's context both before and after execution (fearing memory leaks). It's easier to inject objects with callbacks into the native language than to trust most of it's built-in data processing capabilities.. God help us if they treat dates or matching expressions in an unexpected way. Easier to code something complex into a 'helper' object.
As for most known language 'javascript', I would argue that most people (myself included) do 90% of their javascript coding in copy/paste mode, or have only deeply memorized/internalized trivial onEvent='return myfunc();' where myfunc may be a thin wrapper around someone else's library. So I would hardly say there's a large 'expert' javascript community.
Javascript has a good C/Java base syntax, morphed into dynamic scripting. Has some more modern foreach syntax, but it would be nice to incorporate some ruby concepts.
My main point is that you can't really transfer javascript programming knowledge from the web over to system-programming. You're pretty much starting from scratch. So Javascript doesn't provide any advantage over other existing scripting languages.
-Michael