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.'"
Takes the idea of "open source" to a new level (Score:2, Interesting)
Since javascript is interpreted code and you need the source to actually run it.
Re:Didn't RTFA.... (Score:4, Interesting)
But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?
Bringing new devs into GNOME, that's why. (Score:2, Interesting)
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 actually want to write applications, and that means somehow attracting back the people who ran off to write web applications. And what better way to do that then to allow them to use their existing knowledge?
Re:God no! (Score:5, Interesting)
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.
If happens: KDE here I come! (Score:1, Interesting)
Unlike many other scripting languages, JavaScript's standard library is very slim and doesn't come with very much additional infrastructure. Developers who build GTK+ applications with Seed will have to use other GObject-based libraries from the GNOME stack in order to produce full applications. For example, native file access and basic remote data retrieval can be done with the Gio library.
Scripts are pigs. They're good for little maintenance things or tools or whatever. Write a program, that I have to use, with it?! Oh God no!
Interpreted languages are just too slow and in some cases, too flaky for desktops or any other intense application - especially apps that have a UI. Can't stand them!
Been doing this for a while (Score:3, Interesting)
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).
Re:Takes the idea of "open source" to a new level (Score:5, Interesting)
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:God no! (Score:3, Interesting)
Semicolons as line endings, for example - in C++/php/perl you need them always, in python you don't. In javascript, sometimes you need them, sometimes you don't.
I really tried to give JS a shot, but when you have the guy that created it saying this or that part of it is a hack, it kinda dims your confidence.
Many programmers I have met, myself included, will pick up php, python, even perl or C++ faster and easier than JS. And it was created for the web, so if web developers have a hard time with it, it kind of defeats the purpose, don't you think?
Re:If happens: KDE here I come! (Score:3, Interesting)
from what ive read of Kde4, they also already have JS for alot of the plasma widgets
Re:Perl and Python (Score:4, Interesting)
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:Didn't RTFA.... (Score:4, Interesting)
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.
Re:Didn't RTFA.... (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.
No it isn't. (Score:1, Interesting)
The javascript core mechanisms are fairly clean, but the language syntax is a horrible mess (but it would be, since they were mimicing C/C++/Java). There is also no need for constructors, or new() or for .. in (with all its caveats). In other words, it isn't that bad, but you really need quite a lot of extra code to make it work effectively and cleanly, and even then it remains mostly ugly to look at.
Re:Takes the idea of "open source" to a new level (Score:4, Interesting)
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.
Re:Didn't RTFA.... (Score:5, Interesting)
I think you're confusing "class based" with "object oriented". Javascript is very much an Object Oriented language. Otherwise, how would this code work?
(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.
Re:Didn't RTFA.... (Score:2, Interesting)
Lol, gotta love slashdot. Citation please? Unless you can come up with a thoroughly researched and peer-reviewed paper which accounts for all the more recent approaches to static type checking (like typeful programming, dependent types, etc.) supporting this, I'd say you were full of shit. Hint: The static/dynamic type checking isn't anywhere close to settled.
Besides, JavaScript gets what is arguably the most important feature of any language, namely scoping, completely and utterly wrong.
Re:Didn't RTFA.... (Score:4, Interesting)
I'd say you weren't paying attention. I didn't say that static typing never catches errors, I said that it does not catch as many errors as originally envisioned. As nearly any programmer can attest, it's a rare treat to have a program operate correctly after the first compile. More often than not, you need to perform iterative development and debugging to ensure the correctness of the code. The unfortunate result is that developing for a statically-typed vs. dynamically-typed language makes little difference to this process.
That being said, there are some advantages to a statically-typed language. e.g. There are no untested code segments with typing errors waiting to blow up. The code may blow up for other reasons, but typing won't be one of them. (Unless you force a cast, that is. Casted objects can blow up quite nicely.)
The other area where it's a good idea is when your code will share out or access a standard interface outside your project. In such cases, typing can create a contract that ensures the correct use of all APIs.
That's why I suggested the use of a JS2.0 compiler for times when typing is important. JS2.0 is a softly typed language. Typing can be defined to ensure correctness, but typing is not required. This allows for interfaces and APIs to be exposed properly while leaving the individual developer a free hand to design his code in a classless fashion.
I'm not going to write an entire dissertation on this, so see Bruce Eckel's excellent article [mindview.net] on this issue for a decent introduction to the compile-time checking issue.
You've just pointed a finger at the very thing Javascript gets absolutely correct. While the scoping system may seem weird and even incorrect to coders with experience in other C-style languages, the Javascript scoping system is what welds the OOP aspects of the language together with the functional aspects of the language. If you changed the scoping system, you'd completely destroy Javascript's object system in addition to gimping its functional aspects. Which would leave you with the just the crappy procedural code that your average web developer creates for neat webpage effects.
Re:Takes the idea of "open source" to a new level (Score:3, Interesting)
(I won't even mention Objective C, which is an abomination unto Nuggan)
And why exactly if I may ask? I'm not an objective-C expert but to my knowledge it's exactly what most people think C++ is: C with support for objects, period. For many tasks it's actually a really nice language that combines some of the main advantages of C++ (objects, inheritance, etc) with the advantages of C (small and clean syntax, fast compilation, fast execution).
So if you don't need full-fledged C++ or know you aren't proficient enough using its powerful features properly (like so many developers that think they do, C++ is still pretty difficult to really master), Objective-C is the perfect middle ground.
Re:What about Python? (Score:4, Interesting)
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"
Re:Didn't RTFA.... (Score:3, Interesting)
I'd say you weren't paying attention. I didn't say that static typing never catches errors, I said that it does not catch as many errors as originally envisioned. As nearly any programmer can attest, it's a rare treat to have a program operate correctly after the first compile. More often than not, you need to perform iterative development and debugging to ensure the correctness of the code.
I'm not actually sure that's so. Yes, with many popular statically typed languages that's the case. On the other hand I've heard plenty of stories of Ada, Haskell, and other language programmers finding that, indeed, if they can get it to compile it works as they intended. This, of course, raises its own issues: you may have to do some hoop jumping and work to manage to get that compile to actually work. That means those languages might not be so ideal when you just want to muck out or quickly protoype some code (depending on exactly what you want to do of course). On the other hand, you are actually getting something for all that static typing.