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.'"
Since javascript is interpreted code and you need the source to actually run it.
Doesn't this already exist with Python? What advantage would there be to using JavaScript over Python? Python is a much cleaner language...
But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?
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.
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...
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 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?
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.
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.
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.
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).
Please tell me you didn't just call Perl "nice" or "clean".
The fact that you believe Perl is "cleaner" than Javascript tells me that you are already a victim of Perl Syndrome, and should report immediately to your local sanitarium.
You're too late. Some KDE apps already support QtScript, which supports ECMAScript in applications.
More to the point - this sounds very similar to QTScript which has been available for more than 18 months (since QT 4.3)
Don't you wish you hadn't wasted 3 seconds of your life reading this sig?
You better start packing your bags since a large number of Gnome GUI applications are already being written in Python these days.
Bye!
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 and wreak havoc by invalidating reasonable assumptions which other programmers had about that object. Javascript also lacks multithreading support (no way to synchronize in the language itself). Closures are nice if you know how to use them, but otherwise they are a serious memory leakage hazard. Last but not least there's the problem that Javascript is the VisualBasic of the web: Everybody and their mother pretends to know how to code with it. When real data is involved, it's definitely going to get ugly.
And even before QtScript there was KJSEmbed, which has mailing list archives dating back to 2003.
Of course TFA itself pointed out QtScript and how it is used by Amarok...
I can't tell you how many user are just chomping at the bit waiting for this development.
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.
Too many exceptions and too vague. No reliable standard implementation.
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?
from what ive read of Kde4, they also already have JS for alot of the plasma widgets
IranAir Flight 655 never forget!
You're about five years behind the times, bud.
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.
Don't thank God, thank a doctor!
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!
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.
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!
Right. But Python already has introspection without GObject. I think that was part of the original poster's point. And GObject and GTK have had very stable and mature Python bindings for years.
So the question remains: What does JavaScript bring to the table that Python or Perl or Lua or Scheme or Ruby do not?
IMHO, nothing other than the fact there are probably a lot more JavaScript programmers than all of those other languages combined. Of course, in general, they tend to be lower quality programmers.
If you ask me, this whole thing reaks of another language *cough*VBScript*cough* that has been the root cause of multiple security vulnerabilities on another operating system platform. Mostly, in fact, due to the high percentage of low-quality programmers said platform brings to the table.
My blog
What part of "Active Desktop" was a good idea? Why are we attempting to recreate that?
Seems more like Active Desktop was a bad implementation of a good idea. (For other examples, see UAC -- I use sudo, and I like it fine, but I can't stand UAC, which is the same idea.)
But this isn't even the same idea -- it is not about setting your desktop background to some website. It is about writing new applications in a different language.
At the very least, I hope steps and measures are taken to ensure that there is NO code that can be hidden and that a complete console allowing the viewing and editing of all Javascript code complete with the ability for users to DISABLE it.
...why? Do you expect the same thing from C or Python?
Because, as I understand it, that's all that's happening here -- you can develop a desktop application in JavaScript, just as you can in C, Python, Ruby, or whatever else.
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.
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.
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 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. That will help catch typing errors up front while still creating code that's deployable in Javascript 1.x/ECMAScript 3 VMs.
Javascript + Nintendo DSi = DSiCade
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:
This will not give any errors on the second var, but it won't print "123123" as expected, either. This is because the var declaration makes the variable local in the scope of entire function (despite the declaration itself being in a block), and the declaration applies to all references to that variable within the function, even those preceding the declaration.
If that's not a gotcha, I don't know what is. It's worse than VB6 scoping rules.
And no, it's not the only messy thing in JS.
If you really want to see what a clean, non-convoluted language with JS-like philosophy should look like, see Lua. It's no surprise that the latter is heavily used for scripting in many places where there's a lot of it (e.g. games).
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
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.
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 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.
Javascript + Nintendo DSi = DSiCade
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.
Craft Beer Programming T-shirts
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
But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?
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...
You know what I don't think this is accurate at all. Javascript is actually a very elegant language, what is convoluted is the "web" platform.