OSNews

The shell extension mechanism is not meant to be an application platform.

It is now.

No, it isn't.

Why can't they just use QML? After all it's a language, and not something bound to Qt only.

Edited 2013-02-04 20:02 UTC

I didn't know that QML was invented before Javascript, oh and QML is also based in other set of technologies, is not the firsth onr of its class.

Edited 2013-02-04 20:23 UTC

By reinventing QML I mean creating the toolkit bindings and API's for their javascript engine. QML is more than just javascript.

You are misinformed, GNOME started using javascript binding even before QML, the news is that it is now the official language, nothing else. And to dare to say that implementing javscript bindings is reinventing QML is an ignorant comment IMHO.

Edited 2013-02-04 20:30 UTC

Back in the day, Gnome started using Clutter bindings to implement Gnome 3. I'm not aware of them switching from Gtk to Clutter for app development, that would be even bigger news.

Clutter is a library, and is common that libraries have bindings in python, ruby or javascript, now what do you mean with "clutter bindings"? there is no such thing, now if you mean javascript bindind to clutter libraries may be.

Of course I mean javascript binding to Clutter library, because that's what they did with Gnome shell.

See https://live.gnome.org/GnomeShell

Clutter, GTK+, GIO, GStreamer are all GObject libraries and can be used together in the same application, they are all bound to JS via the same mechanism (GObjectIntrospection).

I don't see how is that related to QML, bacause QML is a meta languaje to create UI's (that uses javascript for some tasks), GNOME's javascript bindinds are for creating also bussiness logic, now tha fact that KDE developers are using it to put also bussiness logic in QML, witch I think is the wrong way is another story.

Edited 2013-02-04 22:48 UTC

Clutter is already used in Gnome/GTK applications, it's not news. Clutter and GTK can be used together in the same application, they are complementary, just like QtGui and QtSceneGraph.

Edited 2013-02-04 21:04 UTC

Clutter has nothing to do with it. Gnome has supported application coding in JS for quite a few years now, via the 'seed' (WebKit) or 'gjs' (Mozilla) engines. Several of the games in the later Gnome 2.x releases were written in JS, with gtk widgets, and (I think) some embedded clutter stuff for the game itself.

That would be stupid, they do different things.
Clutter is a paint engine while GTK is a GUI library.
Clutter knows how to draw pixels (and lines, circles...) on a surface (like your screen).
GTK could use clutter to draw it's widgets (buttons & stuff), but it also handles mouse and keyboard input, has events...

There's no difference anymore. Gnome got rid of libgnome* with 3.0 and consolidated the useful parts into GTK.

HTML/CSS is not superior to Clutter/CSS. Maybe one day with a good WebGL scene graph library, but not yet.

Edited 2013-02-04 20:05 UTC

It is less powerful if you are talking big features and only if you exclude WebGL, and why would you do that?

For little details, polish, maturity, tools, and existing developer base, HTML/CSS crushes Clutter/CSS.

In any case, there is no reason you can't have your cake and eat it to. I'm not suggesting that they build gnome out of standards compliant web widgets. You can go nuts extending things and including custom, gnome-only widgets.

But the fundamental language for expressing things should HTML/CSS + DOM for traversal, manipulation and introspection. Drop jQuery into the mix and you have a powerful app development combo that no existing gnome (or Qt) tech can touch. And when I say powerful I don't mean in terms of some specific feature, I just mean 95% of all potential apps can be built 50% faster, 2X more robustly by 10X more people.

Edited 2013-02-05 03:21 UTC

Sure, I just wish they hand't standardised on the most awkward and badly designed language next to PHP.
(although admittedly JS has nifty object model)

JS is a pretty language with warts, not a fundamentally ugly language. Warts are easily cover up with a little makeup or just ignored. If you use JS a lot you'll find it is actually an extremely expressive language, much more so than other prettier languages and certainly many times more expressive than C/C++ (or PHP) for application development. You never end up spending any thought or energy on these nasty details once you learn to avoid them.

It also is as powerful a language as more popular dynamic peers like Ruby or Python and as you mention is't object model is very interesting and powerful, more akin to Lisp than Ruby.

Anyway, nowadays you can always use Coffeescript if you really can't stomach JS in the buff. I personally find JS to be quite tasty.

As someone with little experience in other languages, I'm genuinely curious ... what are the warts?

There are quite a few, probably two many to mention.

Most would quote the semi-colon insertion mechanism, how the "this" keyword works, and how equivalence works.

I would read JavaScript Patterns.

http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp/059680...

Edited 2013-02-05 08:25 UTC

I'm a huge Vala fan and I'm not disappointed. It's not like anyone is meant to be discouraged from writing an application in his favourite language, JS is just what will be recommended to noobs.

Edited 2013-02-04 20:15 UTC

Non-programmer question here: So where does it end? I mean, can the entire DE be rewritten in JS (I'm thinking not) or will there still have to be a ton of low-level C based stuff to hold it all together?

And if the latter is the case, why even bother moving to such a high level, browser engine dependent language for app development? Granted I'm far from an expert on these matters, but from what I've read over the years, moving JS outside the realm of browser executed web scripts is more of a hack than anything.

Don't get me wrong, I'm all for using an easy to learn, simple but powerful language for future desktop apps, but I think the Gnome team is making a mistake here. They are building walls that they won't be able to tear down in the future, limiting themselves to a very narrow path for future app development.

Then again, they've been doing that since Gnome 3 was first conceived.

The vision of Gnome has been from day one "C for low-level stuff + scripting language for high-level stuff":

From https://mail.gnome.org/archives/gtk-list/1997-August/msg00123.html

Originally it was meant to be Scheme, now it's JavaScript. Scheme is more beautiful, but JavaScript is more pragmatic.

Thank you! That puts things into perspective.

I guess Scheme excels in the area of '(beauty inner) and simplicity more than actual aesthetic side ;-)

IT simply Atwood's law in affect.

http://www.codinghorror.com/blog/2007/07/the-principle-of-least-pow...

Today's JavaScript engines are way faster than the standard Python implementation, see: http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fast...

I'm writing a Vala application. It's quite nice in many ways... but its string manipulation functions are often pathetic. For example, I could find no way (short of coding the function myself) to concatenate an array of strings short of iterating through and doing it bit by bit.

Python: result = ''.join(strings)
Perl: my $result = join('', @strings);
PHP: $result = implode('', $strings);

...and, as with any language, the selection of readily-available libraries has its strengths and weaknesses.

For example, I don't remember seeing an equivalent to Python's highly-lenient, highly-unit-tested feedparser library in Vala, but Vala has access to an interesting SQLite ORM named SQLHeavy which Python only gained access to when it added GObject introspection support.

Edited 2013-02-05 00:23 UTC

When you do a default install of Ubuntu, you get lightdm, which is written in Vala and it is slow as hell on a lot of less powerful systems.

So my guess is Vala might not be all that great either.

JS VMs are almost as fast as compiled code these days. I wish people would fact check this stuff.

Yes, I do wish they would. Because JavaScript is such a poorly defined language engines like V8 have to use heuristics on it over time. JavaScript didn't suddenly become a world beating language environment because of V8. Those who do code shit like node.js.

Depends of what version of are you targering to, if you talk about an old version of javascript then yes, if it is a newer specification like Harmony then no.

Edited 2013-02-05 00:16 UTC

It not poorly defined. JavaScript is a proper programming language with a proper language specification.

JavaScript is simply dynamically typed.

There are some oddities that come up thanks to the JavaScript Semi-colon insertion mechanism and the function scope (i.e. Hoisting).

There are some evil things that the programming language allows you to do (some of the more evil things can be effectively disabled with "Use Strict").

JavaScript has a pretty strong community and if you really get your head around it you can do some very neat things that you can't do in other languages easily.

As another has said the newer specifications are pretty good.

As for the viability of things like node.js, Trello and other quite robust web apps that were developed in reckon time pretty much disproves the notion that it is rubbish.

Edited 2013-02-05 00:35 UTC

Well, it depends how you look at it.

It was created in 10 days and the specification came much later.

Actually, having Javascript being defined in a specification didn't really improve the language.

It made it worse: http://www.livestream.com/etsy/video?clipId=pla_1463e546-47ed-4a93-...

It isn't 1996 anymore.

The new spec is pretty decent, judging JavaScript by it back almost 2 decades ago now ... is like judging C++ on the 1998 standard.

Well Javascript "the bad parts" is still in the spec.

And everyone worth their salt knows not to go near them.

The "almost" is the key word here.

As the original poster suggests, why should I (an end user) have to have poor performance (and a lot of resources uselessly being used) because the programmer of my applications did not know how to implement them in some native language?

Edited 2013-02-05 00:24 UTC

Why not, javascript is widely use for server side, mobile and desktop applications, and it is faster than Python BTW.

Edited 2013-02-05 00:29 UTC

That's why I said: "native"

Edited 2013-02-05 00:30 UTC

Speed is not the only metric when writing applications.

Performance and programmer productivity are the two most important metrics when writing apps.

IMHO Qt provides a good trade-off between both of them: You can write cool and easy-to-write apps in a native language.

That's your subjetive opinion, not mine.

Edited 2013-02-05 00:37 UTC

ERRR NO! While both are important I would argue quite strongly that performance isn't as important as it was.

When we have more processor power and RAM than most of us can possibly use. The main bottleneck these days in Desktop applications is I/O (bar a few specialist applications).

I'd rather have something run slower that ran accurately and had a maintainable code base than something that ran fast.

Or have languages that are easy to understand like python (as opposed to JavaScript which I think is much more difficult to understand) and have the same sort of effort that has gone into JavaScript execution optimization in recent years.

Edited 2013-02-05 00:48 UTC

Firstly we must have a different definition of "almost".

Secondly these days the main cost of any project is not the hardware, but rather the development costs. Most cheap mobile phones have more memory and processing power than we had a decade ago. I doubt you will even notice it.

Thirdly I expect there is more client side processing on a lot of webpages and applications that you probably aren't aware of.

I been writing a Samsung TV applications. Everything is done via client side processing ... it works fine on a TV's which is running some flavour of Linux and probably has either MIPS or an ARM processor.

"JS VMs are almost as fast as compiled code these days. I wish people would fact check this stuff."

That is a fantasy:
http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fast...

Also you will find most small JS applications spend a lot of time executing library functions written in C and as the application has more and more actual Javascript, performance really degrades. This degradation is both execution speed and memory usage.

What is really surprising is in that link it shows how the Go programing languaje that is suposed to be native is slower than javascript.

If you are talking about a large codebase with significant portions of execution time are in the application itself rather than the libraries used (which in nodes case are C), this is definitely not the case. I have ported node.js applications to Go and it was well worth it.

Also, keep in mind this is a single threaded test, Go scales much better on multiprocessor machines than V8 javascript.

(Also the version of Go used is 1.0.3 rather than tip. I switched to tip for a project yesterday and it had a surprising but appreciated 50% speed-up.)

Edited 2013-02-05 05:13 UTC

Hey, I'm just interpreting the table in the link, that's all, you mean that table is flawed?

Well- yes every benchmark is flawed to some degree.
So that is always worth talking about; however, that does not make all benchmarking meaningless.

I was pointing out that:
1. Testing small JS programs that make a lot of library calls ends up being a benchmark of C with a little JS glue and the performance profile changes as a codebase grows and JS comes to represent where a larger percent of where the execution time is spent.

2. The benchmark linked is single threaded (that side has both, but JS data is only bailable to compare single threaded). This is esp. relevant since Go makes writing multithreaded applications easy (so most Go application are multithreaded from the start).

3. I was pointing out that the link is using Go used is 1.0.3 rather than tip. In the Go community tip is highly recommended for performance critical projects. I have seen tip be much faster than 1.0.3.

Include Python in that chart - as the high level dynamic glue language JavaScript is meant to replace in Gnome application development - and JS will indeed look in the same ballpark as C.
C to JS a factor 3.5, JS to Python a factor> 15
Plus, I expect the tooling and engines for JS to grow faster than those for Python

Depends what the code is compiled to doesn't it?

There is native and there is byte code. I meant the latter. V8 performance doesn't stack up bad against Mono and Java for something that is JIT compiled.

Edited 2013-02-05 09:33 UTC

Would like to see how it measures against native compilers for .NET/Java.

So would I

Actually, it is easy.
I'm one, and I know quite a lot of such programmers.