Forgot your password?
typodupeerror
GNOME GUI Programming Software IT Linux Technology

Building Linux Applications With JavaScript 288

Posted by kdawson
from the keeping-it-local dept.
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.'"
This discussion has been archived. No new comments can be posted.

Building Linux Applications With JavaScript

Comments Filter:
  • What about Python? (Score:5, Insightful)

    by Anonymous Coward on Monday January 19, 2009 @08:04PM (#26522657)

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

  • by nurb432 (527695) on Monday January 19, 2009 @08:08PM (#26522725) Homepage Journal

    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)

    by perlhacker14 (1056902) on Monday January 19, 2009 @08:14PM (#26522773)

    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...

  • by ianezz (31449) on Monday January 19, 2009 @08:14PM (#26522789) Homepage
    Since javascript is interpreted code and you need the source to actually run it.

    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)

    by sydneyfong (410107) on Monday January 19, 2009 @08:19PM (#26522857) Homepage Journal

    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)

    by siride (974284) on Monday January 19, 2009 @08:26PM (#26522941)
    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.
  • by arth1 (260657) on Monday January 19, 2009 @08:30PM (#26522971) Homepage Journal

    Gnome's base libraries are C and probably are always going to be programmed in C. This is because C is very universal.. it's relatively easy to port to other platforms and it's able to be included in most other langauges as modules.

    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.

  • by TD-Linux (1295697) on Monday January 19, 2009 @08:32PM (#26522985)
    You're too late. Some KDE apps already support QtScript, which supports ECMAScript in applications.
  • by ADRA (37398) on Monday January 19, 2009 @08:39PM (#26523079)

    You better start packing your bags since a large number of Gnome GUI applications are already being written in Python these days.

  • by irtza (893217) on Monday January 19, 2009 @08:55PM (#26523237) Homepage
    The wheel may have been invented, but different variations have their use - steering (car), scrolling (mice), tires (car), entertainmetn (ferris, of fortune, roulette), you know - let me check something... yup it exists: http://en.wikipedia.org/wiki/Wheel [wikipedia.org] - the people like you would have stopped after the first wiki page ;) (j/k - aiming for funny here my friend, don't think anybody has been enlightened by this post though some may have been flamed (by accident)).
  • Convoluted how? (Score:4, Insightful)

    by weston (16146) <westonsd.canncentral@org> on Monday January 19, 2009 @09:09PM (#26523385) Homepage

    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....

  • by shadwstalkr (111149) on Monday January 19, 2009 @09:17PM (#26523489) Homepage

    You're about five years behind the times, bud.

  • Re:Convoluted how? (Score:5, Insightful)

    by Sancho (17056) * on Monday January 19, 2009 @09:40PM (#26523683) Homepage

    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)

    by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday January 19, 2009 @09:47PM (#26523735) Journal

    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?

  • by Anonymous Coward on Monday January 19, 2009 @09:48PM (#26523743)

    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.

  • by morgan_greywolf (835522) on Monday January 19, 2009 @09:49PM (#26523759) Homepage Journal

    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)

  • by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday January 19, 2009 @09:56PM (#26523831) Journal

    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)

    by ChrisXS (816616) on Monday January 19, 2009 @10:04PM (#26523901) Homepage
    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?
  • Re:God no! (Score:3, Insightful)

    by citizenr (871508) on Monday January 19, 2009 @10:12PM (#26523995) Homepage

    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

  • 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:God no! (Score:2, Insightful)

    by H0p313ss (811249) on Monday January 19, 2009 @11:37PM (#26524659)

    I refuse to get into what bad programmers can do.

    To be fair, bad programmers can write crap in any language.

  • by Toonol (1057698) on Tuesday January 20, 2009 @01:23AM (#26525387)
    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.
  • by Toonol (1057698) on Tuesday January 20, 2009 @01:32AM (#26525455)
    I don't know Python, but the grandparent post seemed to indicate there was a syntax bug because of the presence of a tab in place of spaces. This means that two programs can, visually, be absolutely identical and yet not behave consistently? Who would design a language like that?
  • by Xabraxas (654195) on Tuesday January 20, 2009 @01:39AM (#26525491)
    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.
  • by chthonicdaemon (670385) on Tuesday January 20, 2009 @02:54AM (#26525829) Homepage Journal
    Actually, the reason for the brackets in print() is that it is now a function where it used to be a statement. All the other statements are still there (like return or def, etc). The decision had nothing to do with delimiters. The point the GP was trying to make is that most people who have coded for any amount of time indent consistently as part of their routine. I have been tripped up many times by code that was indented to look different from the actual flow of control. But then I prefer begin end to {}, too.

    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)

    by Ed Avis (5917) <ed@membled.com> on Tuesday January 20, 2009 @05:32AM (#26526527) Homepage

    JS is also much, much slower than Perl and Python

    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.)

  • by segedunum (883035) on Tuesday January 20, 2009 @07:01AM (#26526935)

    Umm, because it's precisely the *right* language for the job.

    Hmmmm, and that is based on? :-

    C++ restricts your binding options to other languages pretty dramatically

    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.

  • by nesstopher (1205894) on Tuesday January 20, 2009 @09:00AM (#26527561)
    Absolute WORD sir. C++ for fast shit, python calling the shots. Heaven.
  • by maraist (68387) * <michael...marais ... l...n0spam...com> on Tuesday January 20, 2009 @10:15AM (#26528207) Homepage

    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.

Our informal mission is to improve the love life of operators worldwide. -- Peter Behrendt, president of Exabyte

Working...