×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Building Linux Applications With JavaScript

kdawson posted more than 5 years ago | from the keeping-it-local dept.

GNOME 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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

288 comments

Takes the idea of "open source" to a new level (2, Interesting)

Yvan256 (722131) | more than 5 years ago | (#26522627)

Since javascript is interpreted code and you need the source to actually run it.

Re:Takes the idea of "open source" to a new level (2, Informative)

gravos (912628) | more than 5 years ago | (#26522737)

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 langauges as modules.

Re:Takes the idea of "open source" to a new level (2, Insightful)

arth1 (260657) | more than 5 years ago | (#26522971)

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.

Re:Takes the idea of "open source" to a new level (5, Interesting)

Rei (128717) | more than 5 years ago | (#26523067)

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:Takes the idea of "open source" to a new level (0, Flamebait)

FishWithAHammer (957772) | more than 5 years ago | (#26523239)

Gnome is about providing a programming environment for normal people to use

Then why the fuck is its primary windowing library (and a lot of other stuff) written in something as absolutely cretinous as object-oriented C? You get the compatibility arguments, sure, until you start running into breaking ABI because you've run out of reserved values in the core structs (like they're facing now, hence the talk about GTK 3) and other problems related to old, problematic languages. C might be easy to port (and yes, it is), but holy shit, does it make transitions shit--and very much not "for normal people". (Or businesses, but hey, fuck them, they dare write proprietary code, etc.)

GNOME isn't about a programming environment or any sort of environment for normal people. I'm not sure what it's about, but that ain't it.

Re:Takes the idea of "open source" to a new level (4, Informative)

caseih (160668) | more than 5 years ago | (#26523723)

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.

Re:Takes the idea of "open source" to a new level (4, Insightful)

ianezz (31449) | more than 5 years ago | (#26522789)

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:Takes the idea of "open source" to a new level (1)

erikdalen (99500) | more than 5 years ago | (#26523303)

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.

Re:Takes the idea of "open source" to a new level (1)

maxume (22995) | more than 5 years ago | (#26523825)

Actually, you can compile python into an intermediate bytecode, and then distribute that (I imagine this is similar for the other languages you mention). It is relatively trivial to decompile/reverse engineer (the tools come with python), but you don't absolutely have to have the source.

Re:Takes the idea of "open source" to a new level (4, Informative)

FishWithAHammer (957772) | more than 5 years ago | (#26523213)

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

Re:Takes the idea of "open source" to a new level (0)

Anonymous Coward | more than 5 years ago | (#26523677)

Oh God...If Slashdot is any indication of Javascript gone to shit, why would anyone want to write an application in Javascript. These days any sort of decent Javascripted website is generated through a 3rd party compiler and not really suitable for hand editing. I mean really just look at the source code for some of these AJAX-type websites. It's a terrible mess and I really wouldn't want to see it run on the desktop. I think if somebody wants to run a scripting language as an interpreted language, python is a very suitable alternative.

Didn't RTFA.... (1, Funny)

Chabo (880571) | more than 5 years ago | (#26522643)

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

Chabo (880571) | more than 5 years ago | (#26522669)

Edit: Remove "this is basically"

Stupid lack of an "Edit" button... talk about user interfaces!

Re:Didn't RTFA.... (3, Interesting)

Bloater (12932) | more than 5 years ago | (#26522735)

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. (2, Interesting)

Anonymous Coward | more than 5 years ago | (#26522777)

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?

Re:Bringing new devs into GNOME, that's why. (5, Funny)

Chabo (880571) | more than 5 years ago | (#26522871)

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!

Re:Bringing new devs into GNOME, that's why. (0)

Anonymous Coward | more than 5 years ago | (#26523515)

There is no browser, only XUL.

Re:Bringing new devs into GNOME, that's why. (2, Insightful)

morgan_greywolf (835522) | more than 5 years ago | (#26523759)

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)

Re:Didn't RTFA.... (1)

Chabo (880571) | more than 5 years ago | (#26522831)

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.

Re:Didn't RTFA.... (1)

Tetsujin (103070) | more than 5 years ago | (#26523105)

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 still sooner use Glade.)

Re:Didn't RTFA.... (1)

FishWithAHammer (957772) | more than 5 years ago | (#26523253)

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.... (3, Interesting)

SanityInAnarchy (655584) | more than 5 years ago | (#26523609)

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

Otter (3800) | more than 5 years ago | (#26523815)

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.

Re:Didn't RTFA.... (4, Insightful)

siride (974284) | more than 5 years ago | (#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.

Convoluted how? (3, Insightful)

weston (16146) | more than 5 years ago | (#26523385)

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? (5, Insightful)

Sancho (17056) | more than 5 years ago | (#26523683)

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:Didn't RTFA.... (2, Interesting)

SleepingWaterBear (1152169) | more than 5 years ago | (#26523755)

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.

Re:Didn't RTFA.... (1)

Phantom of the Opera (1867) | more than 5 years ago | (#26523785)

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

What about Python? (5, Insightful)

Anonymous Coward | more than 5 years ago | (#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 (1)

ciroknight (601098) | more than 5 years ago | (#26522715)

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:PyBank (2, Informative)

segphault (724325) | more than 5 years ago | (#26522743)

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.

Re:PyBank (0)

Anonymous Coward | more than 5 years ago | (#26523139)

The entire point of Seed is to provide introspection bindings for JS.

Re:What about Python? (5, Insightful)

nurb432 (527695) | more than 5 years ago | (#26522725)

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:What about Python? (0)

Anonymous Coward | more than 5 years ago | (#26522959)

Golgafrinchans indeed.

Re:What about Python? (2, Insightful)

irtza (893217) | more than 5 years ago | (#26523237)

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

Re:What about Python? (1)

Tetsujin (103070) | more than 5 years ago | (#26523349)

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 direction. That's very hard to establish when the coders in question aren't being paid. :)

It's not quite true to say we "never get anywhere", though. These days, on Linux, we can play all kinds of different video formats, we've got word processors, vector and raster graphics editors, modeling software... we didn't always have all that.

Re:What about Python? (1)

icebraining (1313345) | more than 5 years ago | (#26522997)

Python? This already exits in javascript! Wasn't this the whole purpose of XUL? You can make a whole app with XUL, Javascript and XulRunner...

Re:What about Python? (1)

CarpetShark (865376) | more than 5 years ago | (#26523111)

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.

Re:What about Python? (1)

Dreen (1349993) | more than 5 years ago | (#26523137)

All popular scripting languages have GTK support. Perl, Python, PHP, Lua, Ruby, they all have it. Now they are making one for JavaScript. Why? Boredom and overhypeness I guess.

Re:What about Python? (0)

Anonymous Coward | more than 5 years ago | (#26523351)

Common myth, often repeated, in many variations, by people who only know Python.

Re:What about Python? (1)

Urza9814 (883915) | more than 5 years ago | (#26523589)

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:What about Python? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#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.

Perfect for my new keylogger project (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26522679)

n/t

God no! (-1, Flamebait)

_merlin (160982) | more than 5 years ago | (#26522727)

Why give people another reason to use the awful monstrosity known as JavaScript/ECMAScript? You can put lipstick on a pig, but it's still a pig. Isn't it enough that you can write Perl and Python applications if you want quick, interpreted code? Then there's Java and .NET/Mono if you'd prefer it JIT compiled. Why take the worst of the web and bring it to the desktop?

says who? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26522809)

Javascript is easy and useful. Perl and python have nothing to do with the functionality of javascript. Neither do .net or Java. What exactly are you talking about?

Re:says who? (1)

_merlin (160982) | more than 5 years ago | (#26522911)

Like JavaScript, Perl and Python (and Ruby, TCL and even PHP, for that matter) are interpreted, object-oriented languages that you can quickly build simple applications with. However, they're all a lot nicer and cleaner than JavaScript (with the possible exception of PHP). JavaScript desktop applications are trying to solve a problem that's already solved in a superior way.

Re:says who? (2, Funny)

schon (31600) | more than 5 years ago | (#26522967)

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, [urbandictionary.com] and should report immediately to your local sanitarium.

Re:says who? (1)

element-o.p. (939033) | more than 5 years ago | (#26523583)

Meh. Just because there exists an obtuse way of doing things in Perl doesn't mean you *have* to do it that way.

I *like* Perl. I've used it since ~2001 and it's my "go to" (not "goto" -- that's obviously bad :) language of choice. However, despite the fact that I'm comfortable with things I've written in Perl doesn't mean I can always read someone else's code.

However, the same can be said of JavaScript and pretty much any other language I've ever used...with the possible exception of Python, which from my limited experience *always* looks clean, no matter who wrote the code.

Re:says who? (0)

Anonymous Coward | more than 5 years ago | (#26523157)

First of all, calling JavaScript, Perl, and PHP OO languages is quite a bit of a stretch. JavaScript is a Prototype language, for instance. The others have had OO tacked on (rather badly).

And Perl, Ruby, and PHP are nowhere near as 'clean' as JavaScript can be when done correctly (Crockford style).

I use at least two of these languages on a daily basis, and of that list, my preference would be Python followed then by JavaScript. The rest I could chuck forever and be quite content.

Re:says who? (1)

Chabo (880571) | more than 5 years ago | (#26523243)

One of the lines in the book "Learning Perl":

"Yes, Perl has objects; it's buzzword compatible with all of those other languages."

Re:says who? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26523479)

Having objects does not make a language Object Oriented.

JavaScript has objects too, in fact everything in the language is an object. It's still not an OO language, though, as it doesn't (naturally) support all of the 'pillars.'

My statement still stands, Perl is a 'multi-paradigm' language that had objects hastily tacked on. (Perl 5, IIRC)

So, no, not an OOP language by design.

Re:God no! (5, Insightful)

sydneyfong (410107) | more than 5 years ago | (#26522857)

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:God no! (1)

fishbowl (7759) | more than 5 years ago | (#26523117)

>Javascript is actually a nice and clean language.

It is. I avoided it for years, just because I utterly hate that it was called Javascript. But AJAX forced me to use it. A good programmer can do good things with the language. I refuse to get into what bad programmers can do.

Re:God no! (2, Informative)

Anonymous Coward | more than 5 years ago | (#26523145)

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.

Re:God no! (2, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#26523735)

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?

Re:God no! (0)

Anonymous Coward | more than 5 years ago | (#26523149)

A good programmer can do good things with any language - That doesn't mean that the language itself is any better than the dung scraped from the bottom of a septic tank

Re:God no! (2, Interesting)

ianare (1132971) | more than 5 years ago | (#26523401)

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?

Re:God no! (0)

Anonymous Coward | more than 5 years ago | (#26523645)

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.

So, as a best practice, you always use them.

Just as with HTML4, sometimes you need closing tags, sometimes you don't. So, best practice is to develop mostly XHTML which is backwards-compatible with HTML4 -- and thus, to always close your tags.

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.

That's actually true of many good languages, and of many good systems. Carmack's Reverse is a brilliant hack, for example.

Many programmers I have met, myself included, will pick up php, python, even perl or C++ faster and easier than JS.

Odd -- I learned JS before any of those except C++. It seems as easy as any of the above -- perhaps easier, because if you already know HTML, you already have a GUI to play with, and things like Firebug.

My experience has been that the basics of Javascript are very easy to learn -- much easier than C++, for instance. The more advanced stuff may be hard, but I would argue that it's not hard to know Javascript thoroughly, whereas it is very hard to know C++ thoroughly.

Do you have any specific examples you'd like to talk about?

Re:God no! (1)

Sancho (17056) | more than 5 years ago | (#26523769)

Let's get pedantic for a bit.

You don't need semi-colons at the end of lines--you need them at the end of statements. And in Javascript, they're always required for the end of statements. What happens is that if the Javascript interpreter encounters an error condition in the parsing of the code, it will go in and see if adding a semi-colon would make the error go away. If so, it will automatically add the semi-colon for you.

This was a design decision that was implemented to make Javascript easier to use. It was also, by most accounts, a mistake. But then, when Javascript was created, I doubt that anyone ever expected huge libraries and programming tasks to be implemented with it.

Re:God no! (5, Interesting)

pavon (30274) | more than 5 years ago | (#26522883)

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.

Re:God no! (1)

ltmon (729486) | more than 5 years ago | (#26522907)

The monstrosity of JavaScript/ECMAScript is more a function of the browser/DOM and not the language. If you get the chance to use some nice prototype-based OO Javascript away from the browser, you'll find that it's actually got a lot going for it.

It could sure do with a nice standard library though, there's a lot of roll-your-own low level functionality going on, which adds to it's reputation as a pig.

Re:God no! (0)

Anonymous Coward | more than 5 years ago | (#26523047)

I'd go for Lua. But then again, that's my answer to anything

Re:God no! (1)

andy19 (1250844) | more than 5 years ago | (#26523185)

Why take the worst of the web and bring it to the desktop?

You must not have read the article. This is about JavaScript, not Flash.

Whut? What happened to AJAX? (0)

Anonymous Coward | more than 5 years ago | (#26522763)

Ahh.. nevermind... i don't take Slashdot serious either.. xD

Perl and Python (4, Insightful)

perlhacker14 (1056902) | more than 5 years ago | (#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 (0)

Anonymous Coward | more than 5 years ago | (#26523037)

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

Forget JavaScript desktop GUI applications-- the possibility of system utilities or init scripts in JavaScript makes me shudder.

Re:Perl and Python (3, Interesting)

bcrowell (177657) | more than 5 years ago | (#26523597)

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.

Big yawn (1)

Brandybuck (704397) | more than 5 years ago | (#26522841)

This is news? How is this news? Scripting applications with Javascript has been a feature of Qt for quite a while now.

Re:Big yawn (0)

Anonymous Coward | more than 5 years ago | (#26523511)

but now it's becoming part of the superior desktop environment

Python? (1)

ndansmith (582590) | more than 5 years ago | (#26522867)

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.

Why not Python? Seems like many Gnome apps already have Python bindings.

If happens: KDE here I come! (1, Interesting)

Samschnooks (1415697) | more than 5 years ago | (#26522939)

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!

Re:If happens: KDE here I come! (1)

icebraining (1313345) | more than 5 years ago | (#26522975)

Toontown uses Python for everything except the actual 3D rendering, which is handled by Panda3D, and it runs pretty well and fast.

Re:If happens: KDE here I come! (4, Insightful)

TD-Linux (1295697) | more than 5 years ago | (#26522985)

You're too late. Some KDE apps already support QtScript, which supports ECMAScript in applications.

Re:If happens: KDE here I come! (2, Insightful)

ADRA (37398) | more than 5 years ago | (#26523079)

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

Re:If happens: KDE here I come! (2, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#26523831)

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.

why even use gnome? (-1, Flamebait)

timmarhy (659436) | more than 5 years ago | (#26522945)

Qt far far FAR better tools for gui creation. why people bother with gnome i don't know.

Re:why even use gnome? (2, Informative)

monkeythug (875071) | more than 5 years ago | (#26523015)

More to the point - this sounds very similar to QTScript which has been available for more than 18 months (since QT 4.3)

Been doing this for a while (3, Interesting)

Anonymous Coward | more than 5 years ago | (#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).

I have a bad feeling about this (1, Informative)

erroneus (253617) | more than 5 years ago | (#26523051)

What part of "Active Desktop" was a good idea? Why are we attempting to recreate that?

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.

I can see where some things would be nice... and in fact, nicer because it was written in a scripting language rather than a compiled or interpreted binary. But there are some things I would rather not see "uncontrolled."

Re:I have a bad feeling about this (1)

natrius (642724) | more than 5 years ago | (#26523745)

This is not similar to Active Desktop at all. Building applications with the JavaScript language does not mean that the browser will suddenly have access to all sorts of system functions.

Usual Gnome/GTK wheel reinvention (1)

TopSpin (753) | more than 5 years ago | (#26523205)

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!

The problem is... GTK isn't portable ! (0)

Anonymous Coward | more than 5 years ago | (#26523417)

The problem with Javascript + GTK is that it isn't portable to other platforms, like Windows. At least that I am aware of. We shouldn't be writing applications that run on Linux alone. Its a multi platform world out there. I need to write a small application that runs on Linux, Windows and Mac. I was looking at Javascript and GTK just today. I also looked at Java + Swing and Java + SWT. I think I am going to end up using Python + Qt, although I think one can use Python with SWT or Swing via Jython. In any event while I applaud the use of Javascript, GTK is the last library I use, simply because of its portability.

You-know-what. (1)

john.picard (1440397) | more than 5 years ago | (#26523623)

Someone should write a JavaScript interpreter in Python and then port Bochs to JavaScript so we can emulate a virtual machine's instruction set in an interpreted environment running inside an interpreted environment. Then install Linux with GNOME on a 386, run Windows 3.1 in this environment, and note how much faster it is than you-know-what, when you-know-what is running on the biggest, baddest, the shit, fastest box there is around.

Why the negative tags? (0)

Anonymous Coward | more than 5 years ago | (#26523697)

I don't understand the "deargodno" and "deargodwhy" tags; forgive me if I'm having an epic sense of humour fail though! I use JavaScript to prototype stuff all the time; you can even use it for animation in the browser (I prototype games and simulations with it, mostly, but see Doug Crockford for more useful programs - the example that readily springs to mind is his symbol table based top down parser which appears in Beautful Code).

At the end of the day it's just another language, albeit one with a familiar (C-descendant) syntax, object orientation, first class functions and (as of 1.7) generators and iterators.

Note that Python (and I do love a bit of Python) supports lambdas but not closures, thus limiting the flexibility of anonymous functions in the language. Javascript in the browser does not support (currently in all implementations AFAIK) tail recursion optimization, although this does not preclude non-browser-sandbox based interpreters from supporting this feature.

Due to the prototype-based nature of its object orientation mechanism (as has already been mentioned) it also allows some interesting opportunities for experimenting with purely behavioural inheritance, something that is occasionally required but not really possible to achieve in any sane fashion in Java (for example; I'm a Java programmer for a living). I'm thinking along the lines of:

var self = this;
this.prototype.behaviour = function(){
BehaviouralObject.prototype.behaviour.call(self);
}

sort of thing. I appreciate this code may be unnecessarily verbose, but I think would illustrate my point at least. There's a lot more that I like about the language, but I feel I've probably gone on far too long by this point.

(Apologies for the AC; it was late, I was tired, and I can't remember whether I have a Slashdot account.)

Security risks (0)

bradbury (33372) | more than 5 years ago | (#26523741)

Any individual who enables the untrusted execution of javascript on their computer is crazy (IMO). If the direction of development (Gnome, etc.) is in this direction it is similarly crazy. Unless Javascript is executing in a completely secure virtual machine (read a completely different VM, e.g. enabled by Xen, VMWare, etc.), anyone who uses it is vulnerable.

You have to make a critical distinction between programs that run on your machine (which is what Javascript is) and programs which draw on your display (which was what HTML was designed to do (back in the "early days")). Any program which runs on your machine is vulnerable to the security flaws of said program. In contrast a program which only directs your program to draw on the display can only mess up ones display.

There is a critical lack of distinction between these two circumstances. And if I would make a recommendation to the incoming presidential staff it would be that Javascript should be shut down on all governmental computers!

Palm WebOS (1)

ChrisXS (816616) | more than 5 years ago | (#26523813)

Isn't this the sort of thing Palm encouraging on their new Web OS SDK? Sadly, I do not believe there is a current option to write binary compiled code on that platform even if you wanted to. I'm happy with Maemo for now.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...