Building Linux Applications With JavaScript 288
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.'"
What about Python? (Score:5, Insightful)
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? (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
Well, the same is true also for Perl [sourceforge.net], PHP [php.net], Python [pygtk.org] and even Lua [luaforge.net], so that's nothing radically new.
Re:God no! (Score:5, Insightful)
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:Didn't RTFA.... (Score:5, Insightful)
Re:Takes the idea of "open source" to a new level (Score:3, Insightful)
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.
Re:If happens: KDE here I come! (Score:4, Insightful)
Re:If happens: KDE here I come! (Score:3, Insightful)
You better start packing your bags since a large number of Gnome GUI applications are already being written in Python these days.
Re:What about Python? (Score:3, Insightful)
Convoluted how? (Score:4, Insightful)
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....
Re:If happens: KDE here I come! (Score:3, Insightful)
You're about five years behind the times, bud.
Re:Convoluted how? (Score:5, Insightful)
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:God no! (Score:3, Insightful)
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 [thedailywtf.com].
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?
Re:What about Python? (Score:2, Insightful)
The source of your problem was the inconsistent use of tabs, not Python (and is a problem you will continue to experience until you do what every top notch developer eventually does in their career, which is to stop using tabs and ban them completely from all of your projects.)
I used to joke about Python: "friends don't let friends use white space for a control mechanism". I had the exact same attitude as you about Python but, since I am fairly intelligent, I was able to figure out that the curly braces are an unnecessary and distracting hassle and the indentation is going to be there anyway, and so I changed my mind. Too bad you are not able to do that.
Re:Bringing new devs into GNOME, that's why. (Score:2, Insightful)
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)
Re:If happens: KDE here I come! (Score:3, Insightful)
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.
Re:Security risks (Score:2, Insightful)
Re:God no! (Score:3, Insightful)
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
Re:Takes the idea of "open source" to a new level (Score:5, Insightful)
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:God no! (Score:2, Insightful)
I refuse to get into what bad programmers can do.
To be fair, bad programmers can write crap in any language.
Re:Takes the idea of "open source" to a new level (Score:3, Insightful)
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.
Re:What about Python? (Score:3, Insightful)
Some people are missing the point (Score:3, Insightful)
Re:What about Python? (Score:3, Insightful)
It is flawed to hold up C as the only language that got things right just because it's popular, and I would hold out on the "more absurd" comments until you have given python a fighting chance (and this means not using whatever brace language you are used to for about 3 months to retrain -- before then you'll just be fighting habits from the other language).
Re:Perl and Python (Score:2, Insightful)
Are you sure? Modern dynamic-recompiling Javascript engines like Tracemonkey, Squirrelfish or V8 are much faster than traditional bytecode interpreters such as perl5 and CPython. (Other Python implementations like Psyco will be faster.)
Re:Takes the idea of "open source" to a new level (Score:4, Insightful)
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.
Re:Takes the idea of "open source" to a new level (Score:2, Insightful)
Re:Convoluted how? -- libraries (Score:3, Insightful)
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.