Linked by Thom Holwerda on Mon 4th Feb 2013 18:41 UTC
Gnome "At the GNOME Developer Experience Hackfest in Brussels, the GNOME developer community has tackled the problem of specifying a canonical development language for writing applications for the GNOME desktop. According to a blog post by Collabora engineer and GNOME developer Travis Reitter, members of the GNOME team are often asked what tools should be used when writing an application for the desktop environment and, up until now, there has been no definitive answer. The team has now apparently decided to standardise on JavaScript for user-facing applications while still recommending C as the language to write system libraries in." Discuss.
Order by: Score:
nothing new
by SeeM on Mon 4th Feb 2013 18:58 UTC
SeeM
Member since:
2011-09-10

Every single extension is JS, so it's standard already. Most of 3rd party useful apps are extensions:
https://extensions.gnome.org/extension/111/calculator/
https://extensions.gnome.org/extension/55/media-player-indicator/
https://extensions.gnome.org/extension/120/system-monitor/
etc...

I never get tired of getting more.

Reply Score: 4

RE: nothing new
by YEPHENAS on Mon 4th Feb 2013 19:58 UTC in reply to "nothing new"
YEPHENAS Member since:
2008-07-14

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

Reply Score: 4

RE[2]: nothing new
by SeeM on Tue 5th Feb 2013 07:12 UTC in reply to "RE: nothing new"
SeeM Member since:
2011-09-10

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


It is now.

Reply Score: 1

RE[3]: nothing new
by YEPHENAS on Tue 5th Feb 2013 14:08 UTC in reply to "RE[2]: nothing new"
YEPHENAS Member since:
2008-07-14

No, it isn't.

Reply Score: 2

QML
by vivainio on Mon 4th Feb 2013 19:00 UTC
vivainio
Member since:
2008-12-26

Stand by while Gnome slowly reinvents QML.

I'm currently a gnome 3 use (works great on new Ubuntu), but their "anything but Qt" adventure is starting to look old already.

Reply Score: 18

RE: QML
by shmerl on Mon 4th Feb 2013 20:01 UTC in reply to "QML"
shmerl Member since:
2010-06-08

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

Reply Score: 7

RE: QML
by Hiev on Mon 4th Feb 2013 20:22 UTC in reply to "QML"
Hiev Member since:
2005-09-27

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

Reply Score: 0

RE[2]: QML
by vivainio on Mon 4th Feb 2013 20:27 UTC in reply to "RE: QML"
vivainio Member since:
2008-12-26

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

Reply Score: 5

RE[3]: QML
by Hiev on Mon 4th Feb 2013 20:29 UTC in reply to "RE[2]: QML"
Hiev Member since:
2005-09-27

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

Reply Score: 0

RE[4]: QML
by vivainio on Mon 4th Feb 2013 20:36 UTC in reply to "RE[3]: QML"
vivainio Member since:
2008-12-26

You are misinformed, GNOME started using javascript binding even before QML, the news is that it is now the official language, nothing else.


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.

Reply Score: 3

RE[5]: QML
by Hiev on Mon 4th Feb 2013 20:39 UTC in reply to "RE[4]: QML"
Hiev Member since:
2005-09-27

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.

Reply Score: 2

RE[6]: QML
by vivainio on Mon 4th Feb 2013 21:01 UTC in reply to "RE[5]: QML"
vivainio Member since:
2008-12-26

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

Reply Score: 3

RE[7]: QML
by YEPHENAS on Mon 4th Feb 2013 21:07 UTC in reply to "RE[6]: QML"
YEPHENAS Member since:
2008-07-14

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

Reply Score: 2

RE[7]: QML
by Hiev on Mon 4th Feb 2013 22:40 UTC in reply to "RE[6]: QML"
Hiev Member since:
2005-09-27

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

Reply Score: 2

RE[5]: QML
by YEPHENAS on Mon 4th Feb 2013 21:04 UTC in reply to "RE[4]: QML"
YEPHENAS Member since:
2008-07-14

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

Reply Score: 1

RE[5]: QML
by Delgarde on Mon 4th Feb 2013 22:27 UTC in reply to "RE[4]: QML"
Delgarde Member since:
2008-08-19

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

Reply Score: 3

RE[5]: QML
by dragos.pop on Wed 6th Feb 2013 11:49 UTC in reply to "RE[4]: QML"
dragos.pop Member since:
2010-01-08


I'm not aware of them switching from Gtk to Clutter for app development, that would be even bigger news.


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

Reply Score: 1

What apps?
by reduz on Mon 4th Feb 2013 19:48 UTC
reduz
Member since:
2006-02-25

Does gnome still have apps? didn't all abandon Gnome and go GTK?

Reply Score: 2

RE: What apps?
by YEPHENAS on Mon 4th Feb 2013 20:12 UTC in reply to "What apps?"
YEPHENAS Member since:
2008-07-14

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

Reply Score: 4

Not far enough
by pooo on Mon 4th Feb 2013 19:48 UTC
pooo
Member since:
2006-04-22

This is good news! Standardizing around a dynamic language will yield great improvements and increase developer involvement (hopefully).

But you still need to go further and just adopt HTML/CSS as the markup for defining UI. The existing gnome stuff is just shite. Really bad and old. HTML/CSS kills it in every way. Someone mentioned QML but why use QML? HTML/CSS is superior, more people know it so more developers will get involved.

If you want desktop consistency, provide templates, default css, and drop in widgets (as now, but in HTML/CSS).

Developing in gnome currently sucks. I would never consider making a gnome desktop app. I would always make a standalone node app with a web interface because it is just so much easier, robust, and strangely, FASTER.

It blows my mind how slow so many simple gnome features are, like starting up the settings. WTF?

Edited 2013-02-04 19:49 UTC

Reply Score: 2

RE: Not far enough
by YEPHENAS on Mon 4th Feb 2013 20:02 UTC in reply to "Not far enough"
YEPHENAS Member since:
2008-07-14

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

Reply Score: 2

RE[2]: Not far enough
by pooo on Tue 5th Feb 2013 03:18 UTC in reply to "RE: Not far enough"
pooo Member since:
2006-04-22

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

Reply Score: 3

RE: Not far enough
by Soulbender on Tue 5th Feb 2013 01:41 UTC in reply to "Not far enough"
Soulbender Member since:
2005-08-18

Standardizing around a dynamic language will yield great improvements and increase developer involvement (hopefully).


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)

Reply Score: 5

RE[2]: Not far enough
by pooo on Tue 5th Feb 2013 03:16 UTC in reply to "RE: Not far enough"
pooo Member since:
2006-04-22

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.

Reply Score: 4

RE[3]: Not far enough
by pandronic on Tue 5th Feb 2013 07:03 UTC in reply to "RE[2]: Not far enough"
pandronic Member since:
2006-05-18

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

Reply Score: 2

RE[4]: Not far enough
by lucas_maximus on Tue 5th Feb 2013 08:21 UTC in reply to "RE[3]: Not far enough"
lucas_maximus Member since:
2009-08-18

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

Reply Score: 2

They are all mad, it's official
by dsmogor on Mon 4th Feb 2013 19:57 UTC
dsmogor
Member since:
2005-09-01

In a way, they fully exploit the joys of irrelevance.
Of course unless they perceive only the very desktop extentions as "Gnome applications", leaving the actuall stuff user is supposed to use on a computer unspecified. Given the fiasco linux desktop standarization that could be considered realistic approach.

Reply Score: 1

python
by stabbyjones on Mon 4th Feb 2013 20:05 UTC
stabbyjones
Member since:
2008-04-15

I do all my apps in python and gtk3. (Gtk2 if it's for Windows as well)

I'm glad they picked something, gobject was weird to start with but it shouldn't be hard to translate what I've learnt to js.

Anyone who learnt vala is going to be pissed.

Reply Score: 4

RE: python
by YEPHENAS on Mon 4th Feb 2013 20:08 UTC in reply to "python"
YEPHENAS Member since:
2008-07-14

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

Reply Score: 2

...
by Hiev on Mon 4th Feb 2013 20:21 UTC
Hiev
Member since:
2005-09-27

As someone who has been recently working less with desktop apps and more with internet client webapps, I welcome to this change.

Edited 2013-02-04 20:24 UTC

Reply Score: 3

RE: ...
by Morgan on Mon 4th Feb 2013 20:56 UTC in reply to "..."
Morgan Member since:
2005-06-29

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.

Reply Score: 5

RE[2]: ...
by YEPHENAS on Mon 4th Feb 2013 21:17 UTC in reply to "RE: ..."
YEPHENAS Member since:
2008-07-14

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

We plan to use GTK/Scheme bindings for coding small
utilities and applications. When these bindings are more
mature, it should be possible to write complete applications
in Scheme.

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

Reply Score: 3

RE[3]: ...
by Morgan on Mon 4th Feb 2013 21:20 UTC in reply to "RE[2]: ..."
Morgan Member since:
2005-06-29

Thank you! That puts things into perspective.

Reply Score: 2

RE[3]: ...
by vivainio on Mon 4th Feb 2013 21:28 UTC in reply to "RE[2]: ..."
vivainio Member since:
2008-12-26

Scheme is more beautiful, but JavaScript is more pragmatic.


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

Reply Score: 2

RE[2]: ...
by lucas_maximus on Mon 4th Feb 2013 22:14 UTC in reply to "RE: ..."
lucas_maximus Member since:
2009-08-18
Oh God NO!
by linux-lover on Mon 4th Feb 2013 20:47 UTC
linux-lover
Member since:
2011-04-25

First everyone was writing all their apps with pygtk. Now it's javascript.

Watch as apps become increasingly unresponsive and sluggish just like they did with python.

Why can't you just write apps using native, compiled languages? If C or C++ is too much hassle for a small GUI app, why not use Vala or D? Hell, Vala was created by gnome! (afaik)

https://live.gnome.org/Vala
http://dlang.org/

Reply Score: 3

RE: Oh God NO!
by YEPHENAS on Mon 4th Feb 2013 21:20 UTC in reply to "Oh God NO!"
YEPHENAS Member since:
2008-07-14

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

Reply Score: 2

RE: Oh God NO!
by ssokolow on Tue 5th Feb 2013 00:21 UTC in reply to "Oh God NO!"
ssokolow Member since:
2010-01-21

Why can't you just write apps using native, compiled languages? If C or C++ is too much hassle for a small GUI app, why not use Vala or D? Hell, Vala was created by gnome! (afaik)


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

Reply Score: 6

RE[2]: Oh God NO!
by Lennie on Tue 5th Feb 2013 15:06 UTC in reply to "RE: Oh God NO!"
Lennie Member since:
2007-09-22

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.

Reply Score: 2

That's terrible
by tuaris on Mon 4th Feb 2013 21:33 UTC
tuaris
Member since:
2007-08-05

Now I need 3GHz computer with 8GB of RAM and a quad core processor with a GPU just to run a calculator.

Reply Score: 6

RE: That's terrible
by lucas_maximus on Mon 4th Feb 2013 22:15 UTC in reply to "That's terrible"
lucas_maximus Member since:
2009-08-18

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

Reply Score: 4

RE[2]: That's terrible
by segedunum on Mon 4th Feb 2013 23:51 UTC in reply to "RE: That's terrible"
segedunum Member since:
2005-07-06

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.

Reply Score: 3

RE[3]: That's terrible
by Hiev on Tue 5th Feb 2013 00:13 UTC in reply to "RE[2]: That's terrible"
Hiev Member since:
2005-09-27

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

Reply Score: 2

RE[3]: That's terrible
by lucas_maximus on Tue 5th Feb 2013 00:18 UTC in reply to "RE[2]: That's terrible"
lucas_maximus Member since:
2009-08-18

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

Reply Score: 3

RE[4]: That's terrible
by Lennie on Tue 5th Feb 2013 15:10 UTC in reply to "RE[3]: That's terrible"
Lennie Member since:
2007-09-22

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


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

Reply Score: 2

RE[5]: That's terrible
by lucas_maximus on Tue 5th Feb 2013 18:09 UTC in reply to "RE[4]: That's terrible"
lucas_maximus Member since:
2009-08-18

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.

Reply Score: 3

RE[6]: That's terrible
by Lennie on Tue 5th Feb 2013 19:36 UTC in reply to "RE[5]: That's terrible"
Lennie Member since:
2007-09-22

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

Reply Score: 2

RE[7]: That's terrible
by lucas_maximus on Tue 5th Feb 2013 21:51 UTC in reply to "RE[6]: That's terrible"
lucas_maximus Member since:
2009-08-18

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

Reply Score: 2

RE[2]: That's terrible
by ebasconp on Tue 5th Feb 2013 00:21 UTC in reply to "RE: That's terrible"
ebasconp Member since:
2006-05-09

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


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

Reply Score: 3

RE[3]: That's terrible
by Hiev on Tue 5th Feb 2013 00:24 UTC in reply to "RE[2]: That's terrible"
Hiev Member since:
2005-09-27

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

Reply Score: 3

RE[4]: That's terrible
by ebasconp on Tue 5th Feb 2013 00:29 UTC in reply to "RE[3]: That's terrible"
ebasconp Member since:
2006-05-09

That's why I said: "native" ;)

Edited 2013-02-05 00:30 UTC

Reply Score: 3

RE[5]: That's terrible
by Hiev on Tue 5th Feb 2013 00:32 UTC in reply to "RE[4]: That's terrible"
Hiev Member since:
2005-09-27

Speed is not the only metric when writing applications.

Reply Score: 3

RE[6]: That's terrible
by ebasconp on Tue 5th Feb 2013 00:35 UTC in reply to "RE[5]: That's terrible"
ebasconp Member since:
2006-05-09

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.

Reply Score: 3

RE[7]: That's terrible
by Hiev on Tue 5th Feb 2013 00:36 UTC in reply to "RE[6]: That's terrible"
Hiev Member since:
2005-09-27

That's your subjetive opinion, not mine.

Edited 2013-02-05 00:37 UTC

Reply Score: 2

RE[7]: That's terrible
by lucas_maximus on Tue 5th Feb 2013 00:45 UTC in reply to "RE[6]: That's terrible"
lucas_maximus Member since:
2009-08-18

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


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

Reply Score: 2

RE[3]: That's terrible
by lucas_maximus on Tue 5th Feb 2013 00:33 UTC in reply to "RE[2]: That's terrible"
lucas_maximus Member since:
2009-08-18

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?


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.

Reply Score: 3

RE[2]: That's terrible
by voidlogic on Tue 5th Feb 2013 01:28 UTC in reply to "RE: That's terrible"
voidlogic Member since:
2005-09-03

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

Reply Score: 3

RE[3]: That's terrible
by Hiev on Tue 5th Feb 2013 02:07 UTC in reply to "RE[2]: That's terrible"
Hiev Member since:
2005-09-27

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.

Reply Score: 2

RE[4]: That's terrible
by voidlogic on Tue 5th Feb 2013 05:11 UTC in reply to "RE[3]: That's terrible"
voidlogic Member since:
2005-09-03

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

Reply Score: 5

RE[5]: That's terrible
by Hiev on Tue 5th Feb 2013 06:05 UTC in reply to "RE[4]: That's terrible"
Hiev Member since:
2005-09-27

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

Reply Score: 1

RE[6]: That's terrible
by voidlogic on Tue 5th Feb 2013 15:04 UTC in reply to "RE[5]: That's terrible"
voidlogic Member since:
2005-09-03

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.

Reply Score: 4

RE[3]: That's terrible
by Kitty on Tue 5th Feb 2013 06:33 UTC in reply to "RE[2]: That's terrible"
Kitty Member since:
2005-10-01

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

Reply Score: 3

RE[3]: That's terrible
by lucas_maximus on Tue 5th Feb 2013 09:26 UTC in reply to "RE[2]: That's terrible"
lucas_maximus Member since:
2009-08-18

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

Reply Score: 3

RE[4]: That's terrible
by moondevil on Tue 5th Feb 2013 10:06 UTC in reply to "RE[3]: That's terrible"
moondevil Member since:
2005-07-08

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

Reply Score: 2

RE[5]: That's terrible
by lucas_maximus on Tue 5th Feb 2013 13:26 UTC in reply to "RE[4]: That's terrible"
lucas_maximus Member since:
2009-08-18

So would I

Reply Score: 2

JavaScript is a bad choice
by kajaman on Tue 5th Feb 2013 07:51 UTC
kajaman
Member since:
2006-01-06

Obviously, it's popular and most of developers put it on their CV (not only web developers). It's hard to find a programmer who says "I don't know JavaScript".

However, JavaScript is difficult to program in *good*. It's got different paradigm of Object Orientation than most (prototype based vs. classes). It has also very little and chaotic standard library (but there are projects that fix that), and finally, the language itself is not that great in terms of design, syntax and consistency.

Don't get me wrong, if you use something like Coffeescript, and have deep knowledge on what is actualy going on, you can write good, complex apps in JavaScript. My feeling is that they chose it because it's easy for newcomers to start developing, which is a mistake, and will be a painful one. You can shoot yourself easily in the foot in JavaScript, and people will.

Reply Score: 3

RE: JavaScript is a bad choice
by pashar on Tue 5th Feb 2013 13:50 UTC in reply to "JavaScript is a bad choice"
pashar Member since:
2006-07-12

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

Reply Score: 1

Binding C Library to Javascript/GJS/Seed
by dindin on Tue 5th Feb 2013 17:37 UTC
dindin
Member since:
2006-03-29

Can one easily call C/C++ libraries from JavaScript? I have done quite a lot of Ruby coding and calling C libraries from Ruby Interpreter was pretty easy. Is this the case with GJS or Seed?

Reply Score: 2