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:
  • Since javascript is interpreted code and you need the source to actually run it.

    • Re: (Score:3, Informative)

      by gravos (912628)
      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. Gnome is about providing a programming environment for normal people to use and if Javascript allows that then they will use it. However...

      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 lan
      • Re: (Score:3, Insightful)

        by arth1 (260657)

        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

        • by Rei (128717) on Monday January 19, 2009 @08:38PM (#26523067) Homepage

          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.

          • by Pseudonym (62607) on Monday January 19, 2009 @10:16PM (#26524037)

            I'm quite fond of the mixture of a C++ backend with a javascript frontend that can be used over the web.

            C++ has the advantage that, unlike C, there's less of an impedance mismatch between it and Javascript. Javascript is optimised for manipulating DOM-type structures which have a very natural expression in C++ and, with a small amount of template-assisted boilerplate, is fairly straightforward to bridge.

      • 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: (Score:3, Insightful)

          by Toonol (1057698)
          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 an
    • 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.

      • by erikdalen (99500)

        Well, Javascript isn't exactly radically new either (appeared in 1995 according to wikipedia). But sure some of those examples you gave have even been around a bit longer than that.

        • Perl goes back to the 80s, I think. Python... early 90s maybe? PHP is probably about the same age as JS. Lua seems very new but I feel like I heard it is much older than you would think.

    • by FishWithAHammer (957772) on Monday January 19, 2009 @08:51PM (#26523213)

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

  • by Chabo (880571)
    So, this is basically Seed uses Javascript to make GTK+ code easily, so you can move on to make the heart of the program faster?
    • Re:Didn't RTFA.... (Score:4, Interesting)

      by Bloater (12932) on Monday January 19, 2009 @08:10PM (#26522735) Homepage Journal

      But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?

      • by Anonymous Coward
        To put it bluntly: "Because a lot of people already know it."

        The problem with attracting developers is that so many of them these days have went on to develop web applications with awful scripting languages like Javascript, Python, Perl and PHP. Developers know these languages.

        Bringing developers to the platform is what's important right now. The libraries have gotten better and better, and now it's time to have some real, awesome applications to use them. Part of that means having developers that act
        • by Chabo (880571) on Monday January 19, 2009 @08:20PM (#26522871) Homepage Journal
          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!
          • Compatability issues between Firefox and IE are hardly Javascript's fault...
          • by 3dr (169908)
            The whole of JavaScript programming is NOT just web programming.

            The javascript engine is an embeddable interpreter (that is independent of a web browser), and it is common to combine it with C++ guts. The web browser is just the most well-known example of this combination.

            On many projects I export key data structures via SWIG into a scripting language, then use the scripting side to quickly develop and test new algorithms without the compile/link cycle. I've done this on numerous projects, with C++ scri

      • by Chabo (880571)
        I'm not defending it, I was just asking if I condensed the point of the project correctly.

        As for writing JS to make GTK+ code... if you've ever coded a GUI by hand, you know it's a pain. I realize that tools like Visual Studio, Eclipse, et al are supposed to take care of this, but some people like to code GUIs from the CLI for some perverted reason. I only had to for a class, and I never want to do so again.

        That said, if I understand the point of the project correctly, I think it's hugely pointless.
        • by Tetsujin (103070)

          As for writing JS to make GTK+ code... if you've ever coded a GUI by hand, you know it's a pain. I realize that tools like Visual Studio, Eclipse, et al are supposed to take care of this, but some people like to code GUIs from the CLI for some perverted reason. I only had to for a class, and I never want to do so again.

          I feel like the tough part is simply working out the layout of the thing - the nested containers, the widgets that go into 'em, etc. From there, hooking up code to the widgets seems like not such a big deal.

          You can get through the layout phase with a tool like Glade... Or you can code it by hand. I'd agree that coding it by hand is a real chore, but it's only really awful if you have the code/compile/test/fail/repeat cycle in there. (If it's just code/test/fail/repeat, that's not so bad... But I'd stil

        • some people like to code GUIs from the CLI for some perverted reason

          Some people might say that those people should not be allowed to program GUIs.

        • Re:Didn't RTFA.... (Score:4, Interesting)

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

          some people like to code GUIs from the CLI for some perverted reason.

          The main reason being, you then have an easily-scriptable commandline version, and an easily-usable GUI version. Bonus is that you won't need any GUI installed at all on a server in order to use the commandline version.

          You've also decoupled logic from presentation, which is generally considered A Good Thing -- it makes replacing the GUI easy, and it makes competing GUIs possible, without having to dig into any of the core logic.

          Granted, it would be better to take the whole system into account when writing either -- it's a lot easier to write a GUI for a commandline app which was written with that in mind, than one which was written with nothing beyond a VT100 in mind. But the advantage still stands.

          • by Otter (3800)
            The main reason being, you then have an easily-scriptable commandline version, and an easily-usable GUI version.

            Huh? Whether the application is scriptable has nothing whatsoever to do with whether a layout tool was used to create the GUI.

            • Whether the application is scriptable has nothing whatsoever to do with whether a layout tool was used to create the GUI.

              Ah, sorry -- I'm with you there, I'd much rather create the GUI with some kind of graphical assistance, even if it's just Firebug.

      • 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.
        • Re: (Score:3, Informative)

          Actually, yes, JS is much more convoluted than it has to be, partly because it pretends to be so many things at once. Non-local local scope is a good example. For a Java-looking language, you'd expect code blocks to introduce scope, but they don't. For example:

          var x = 123;

          function foo()
          {
          document.write(x);

          if (true)
          {
          var x = 456;
          }

          document.write(x);
          }

          foo();

          This will not give any errors on the second var, but it won't print "

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

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

          • 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 a

      • Re: (Score:3, Interesting)

        But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?

        I don't know, I used to think javascript was a mess, but having learned a good bit more of it recently, it's really a much more elegant, flexible, and well designed language than a lot of people give it credit for. Personally, if I wanted scripting built into my Desktop I would choose python for the documentation, ease of coding and power, but you could do a lot worse than javascript.

      • javascript is closer to lisp/scheme than to C in many ways. It supports closures, macros (functions that build functions), and evals. Rather than list oriented, it's dom oriented.

        Of course, it is convoluted. It's just far more subtle than it appears (or is often used).

        • It's not DOM oriented. DOM isn't even necessary for javascript. It would be more accurate to say it's object-oriented, except that implies OOP, which it isn't.

          • Re:Didn't RTFA.... (Score:5, Interesting)

            by AKAImBatman (238306) * <akaimbatmanNO@SPAMgmail.com> on Monday January 19, 2009 @11:47PM (#26524743) Homepage Journal

            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 [tlarson.com] 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 [jangaroo.net]. That will help catch typing errors up front while still creating code that's deployable in Javascript 1.x/ECMAScript 3 VMs.

      • WTF are you talking about? There's nothing convoluted about it. It's quite simple & straightforward actually.
        Did you know that much of the code of Firefox is already JavaScript?

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

    • PyBank [gnome.org] is similar. It also uses GObject-Introspection to automatically bind GObject libraries.

      In fact, the Javascript side of this article is completely overlooking the technology that is GObject introspection; adding run-time dynamic introspection to C applications (and soon, reflection too).
      • Re: (Score:3, Informative)

        by segphault (724325)
        You need to read more carefully. There is a whole section about GObject introspection on the first page of the Ars tutorial. It even mentions PyBank.
    • 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.

      • Re: (Score:3, Insightful)

        by irtza (893217)
        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)).
      • by Tetsujin (103070)

        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.

        Well, really, the reason why we never seem to get anywhere is because accomplishing meaningful tasks is hard. Putting together a good app is a lot of work. Getting people to use it is more work. And without clear leadership, there could be a dozen people trying to solve the same task - and as a result, coming up with different solutions and competing with each other. "Getting somewhere" depends on clear leadership. Someone has to be able to take the available coding talent and steer it into a useful di

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

      Some people just have to be different.

    • by Urza9814 (883915)

      It'd be quite nice for people like me who _can't stand_ python. Purely a personal preference, but I just can't stand any language that has specific rules about where you can and cannot put a space. Hell, I had a python script I was writing the other day that wouldn't run because in one place I had used a tab to indent after an if statement rather than a series of spaces. I like my damn curly braces! They're easier!

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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

        • Re: (Score:3, Insightful)

          by Toonol (1057698)
          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?
          • Re: (Score:3, Informative)

            by Kidbro (80868)

            No. Inconsistently mixing tabs and spaces is a syntax error. The program simply won't run, and it will inform you as to why (much like how your C compiler will propably let you know when you've used a lower case l [wikipedia.org] rather than an upper case I [wikipedia.org], even though they look the same in your font).

    • by Yvanhoe (564877) on Tuesday January 20, 2009 @06:14AM (#26526725) Journal
      I discovered recently that the grudges I hold against Javascript (I used it when CSS was still science fiction) are no longer valid and that a lot of the features I like very much about python exist as well in Javascript:

      a={}
      a["this"]="is a hash table"
      l=[]
      l.push(a)

      this is both a valid python or javascript code. Both languages are very similar. Javascript's image suffer from its earlier implementations. It is now a much more convenient language than it used to be. Python is fine for a lot of things and is still my language of choice but Javascript has been promoted from "over my dead body" to "preferable to many other alternatives"

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

    • Re:Perl and Python (Score:4, Interesting)

      by bcrowell (177657) on Monday January 19, 2009 @09:29PM (#26523597) Homepage

      JavaScript is actually a sweet programming language. It's got a very clean design, nice straightforward syntax, and good support for both OO and FP. (I think people get a bad impression of it from seeing it used by people who learned to do stupid web page tricks from JavaScript for Dummies. Also, people who believe in the One True Way of OO tend not to like it because it doesn't do OO the same way as Java. There are also many horrible problems with DOM incompatibilities, none of which have anything to do with JS per se.)

      The thing is, I don't understand the logic of using JS for high-level tasks and Vala (basically glorified C) for low-level stuff. The thing is, JS is a very small, austere language. The whole advantage of having a high-level language is lost when you use something as bare-bones as JS. JS is also much, much slower than Perl and Python, so you'd end up having to do only a very small percentage of your programming in JS, and the rest in Vala, in order to get decent performance.

      To me it makes a lot more sense to write 100% of your program in, say, Perl. (s/Perl/Python/g or s/Perl/Ruby/g is that's what turns your crank.) You pull in some CPAN libraries, many of which have the time-critical stuff written in C for good performance, but you don't have to touch the C. If there does turn out to be some very time-critical loop that you really want to optimize, and it's not something generic that's available in CPAN, then you write it in C and interface it to your Perl program. You end up writing 99.9% of your own code in a nice high-level language, and 0.1% in a crufty low-level language, and you get good performance.

      To me the most interesting part of the whole article is the idea of using Vala rather than C as a low-level language. Manual memory management sucks.

    • Re: (Score:3, Funny)

      But, JavaScript for desktop GUIs? That just gives me an odd feeling inside...

      Maybe you have not heard of this new little app... It appears that there are a few people out there who even like it. It's a bit hard to find, because for various reasons it has been renamed way too many times... The last name, IIRC, is Firefox. Google should be able to find it for you.

  • by Anonymous Coward on Monday January 19, 2009 @08:28PM (#26522957)

    I actually have been doing this for a number of years and I have done commercial projects using it. I started with Lua but lately I have been using Javascript via Tracemonkey in an attempt to get more buy-in. Javascript looks good because of its widespread web use. Javascript is still a pretty crappy and convoluted language that will probably never be able to perform as well as Lua(JIT) though.

    I use it for Windows apps as well. I have my own custom bindings for Win32, FLTK, Gtk+, and Qt. Qt is my favorite right now since they're making it LGPL.

    Don't kid yourself though, it will not perform anywhere near as good as an old fashion C/C++ application. I still use C or C++ when I need top performance. A lot of applications don't need it though and the end-user can't tell (my scripted software runs fine even on old 266 Mhz laptops with 128 MB of RAM).

    • by david.given (6740)

      Javascript is still a pretty crappy and convoluted language that will probably never be able to perform as well as Lua(JIT) though.

      Actually, the modern JITs like V8 and Tracemonkey are a whole lot better than they used to be; V8 actually approaches the speed of LuaJIT for some tasks.

      Of course, V8 uses about two orders of magnitude more memory, and Mike Pall is currently working on LuaJIT 2 which will be faster and more lightweight, so it's very much damning with faint praise. But, while Javascript is still pretty awful, it's not nearly as awful as it used to be.

      (I want to know why nobody's tried statically converting Javascript into Lu

  • Hasn't KDE had this feature since the dark ages? :D

  • Gnome guys; don't consider extending or improving XUL. That javascript+gtk widgets model hasn't managed to produce anything worthwhile [wikipedia.org], now has it? Obviously, you can do it better! Probably 3-4 times over the next 15 years. Good luck!

  • by strangeattraction (1058568) on Monday January 19, 2009 @09:08PM (#26523377)
    I can't tell you how many user are just chomping at the bit waiting for this development.
  • The Horror. [whysanity.net]
  • The Qt API has QtScript, an ECMA scripting engine. While by default Qt isn't fully scriptable, there is a "bindings generator [trolltech.com]" that makes the whole Qt API available to the scripting engine.

  • Jakub Steiner has recently been wanting access to a CSS-type method of styling GTK apps rather than using the traditional widget-mangling stuff. I totally agree...in fact, look at some of the web apps out there that have already far eclipsed desktop applications in visual design, usability, and just overall experience.

    If the desktop is going to make a comeback, things like this JavaScript effort and ideas that have their roots in web-team-on-a-deadline-style efficiency are going to have to be ported over
  • Dear Gnome (Score:4, Funny)

    by stoicio (710327) on Monday January 19, 2009 @11:00PM (#26524405) Journal

    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.

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

FORTRAN is for pipe stress freaks and crystallography weenies.

Working...