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.'"
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?
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...
Well, the same is true also for Perl, PHP, Python and even Lua, so that's nothing radically new.
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.
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!
Convert FLACs to a portable format with FlacSquisher
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).
You're too late. Some KDE apps already support QtScript, which supports ECMAScript in applications.
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.
Tonight's Special: Leg of Salmon
There's nothing stopping you from writing a JavaScript compiler. Hell, there's an ECMAScript 4.0 JavaScript implementation for .NET.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
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.
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!
Umm, because it's precisely the *right* language for the job. C++ restricts your binding options to other languages pretty dramatically, especially if you use parts of C++'s object model such as multiple inheritance. In short, no C++ is the wrong too for the job, Qt's use of it notwithstanding. Although it's true that Qt does have bindings for many languages, the simple fact is that these bindings, such as PyQT, are against the *C* wrapper on the C++ api. So an entire extra layer in the way. Gnome and GTK's gobject-based object model is just about one-to-one with most models of object-oriented languages. Hence you can use just about any language under the sun to develop Gnome apps. All without losing any features of the API.
If you do want to program in C with GTK, you can and it's very easy, actually. Memory leaks are minimized because of the coolness in glib. However, if you're not a C programmer then you shouldn't be programming GTK/Gnome apps in C at all. Use something more powerful like Python. In fact I can't think of any reason (except embedding on small systems, or core libraries and programs) where it's appropriate to write a Gnome app in C. There are tons of awesome bindings available. Use them. Write in C++ (which is a much nicer API at times than Qt's moc-ified native apis) if you want.
So yes. Gnome is able to target the languages that normal developers want to use. Whether that's C#/.Net, Python, C++, Ruby, or C.
If Gnome wasn't written in C, what language would you suggest? How would you provide extensive, 100% coverage of the API in any arbitrary language? Writing GTK itself in C# seems pretty silly. Same for Python, Ruby, etc, unless you want to restrict the entire toolkit to just one language.
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!
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.
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.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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.
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. ;-)
Javascript + Nintendo DSi = DSiCade
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
There's a pervasive myth that C++ is just objects on top of C. Or that because you can use objects, that means that you *have* to use them everywhere.
C++ is useful for tons of things. Someone who doesn't know how to use templates will create a nightmare's worth of code in a situation that calls for them. People who don't use object data structures in areas that aren't performance critical (and oftentimes even where they are, since there are a lot of optimizations in the std libraries that a lot of people miss out on when reinventing the wheel) often create a memory management nightmare and leaky code. People who don't use const correctness slow down their code and are at more risk for bugs. And on and on down the line.
You misunderstand the concept of cache hits. Whether you get a cache hit or miss isn't dependent on how much memory your *program* loads up; it's based on what's being executed at a given point in time. If you have a core loop iterating through some data structure, if you're not calling any big libraries, then they're not affecting cache hits for your core loop; the cache is going to be dominated by that data structure. Quite the opposite, C++ actually often has a *greater* chance of cache hits because data stays local to an object, and when a block of data is read from memory to the cache, you're more likely to get variables that you need cached.
Again C != C++.
C is a subset of C++. If C can do it, so can C++. Anyways, why did this become a C vs. C++ thread?
Tonight's Special: Leg of Salmon
It exists today. Just add them to your foes list and then assign a negative modifier to foes.
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
Hmmmm, and that is based on? :-
I wish people would drop this stupid bindings argument. It's brain dead. Firstly, bindings have to be maintained, properly, if they are to be of any use to developers. That takes effort. Secondly, why bother with binding object orientation and other languages on when you can have a language built with proper object orientation in the first place because that's what your software requires? Vala shouldn't even really be necessary.
Oh, and the Smoke bindings that KDE uses have proved you wrong. So pffffffffffffff.