GNOME To Use JavaScript For New User Programs

[kigurai]

http://highscalability.com/youtube-architecture
Youtube is also using Apache written in C and MySQL written in C/C++.
Youtube can add more servers if performance isn't sufficient.
Youtube web application is trivial compared to MySQL.

This does however not change the fact that Youtube use Python, which is a language with dynamic typing.
I am not going to argue whether a web application is more or less trivial than MySQL.
I just think we can all agree that Youtube does not really count as a "trivial" application.

[JS987]

I just think we can all agree that Youtube does not really count as a "trivial" application.

Python web applications don't include a lot of Python code as majority of code is client side (HTML, Javascript) and SQL commands.

[Awesomeness]

anyone suggesting that GNOME should give up all the work and expertise they already have in GTK and switch to Qt is either trolling, or out of touch with reality.

Gnome didn't give up GTK when they adopted Clutter. They simply added another official toolkit. Qt is perfectly usable for applications conforming to Gnome HIG.

I really don't see a big difference from KDE. I get the impression kde propagate for java script/QML int the gui more and more and javascript or c++ in the other layer. To me it's look like the full c++ apps is destined to disappear also on kde. Plasma2 is supposed to be mostly in qml and javascript and also kwin use qml or javascript for animation and behavioral scripting.
The underlying code in the libs is c++ just as its c on gnome.

The difference is that QML is a GUI building language and not a programming language. The primary language to implement application logic in Qt is still C++.
Maybe I overlooked something but this does not seem an attempt at replacing their UI format with something newer than gtkbuilder. Instead it seems it's gtkbuilder for UIs and JavaScript for back-end stuff, ie. the opposite of what KDE is doing.

[Akka]

Gnome didn't give up GTK when they adopted Clutter. They simply added another official toolkit. Qt is perfectly usable for applications conforming to Gnome HIG.




The difference is that QML is a GUI building language and not a programming language. The primary language to implement application logic in Qt is still C++.
Maybe I overlooked something but this does not seem an attempt at replacing their UI format with something newer than gtkbuilder. Instead it seems it's gtkbuilder for UIs and JavaScript for back-end stuff, ie. the opposite of what KDE is doing.

Some high profie kde software like plasma2 is supposed to be allmost c++ free soon as I understand it, the plasma applets do have logic. I don't get the impression kde try too steer the third part development to use busnisslogic in javascript but I'm sure a software like plasma affect the rest of the community. I'm sure we soon see small and light program without own heavy logic in qml and javascript. I'm sure Gnome don't plan the next office suit in javasript either.

[Teho]

Some high profie kde software like plasma2 is supposed to be allmost c++ free soon as I understand it, the plasma applets do have logic. I don't get the impression kde try too steer the third part development to use busnisslogic in javascript but I'm sure a software like plasma affect the rest of the community. I'm sure we soon see small and light program without own heavy logic in qml and javascript. I'm sure Gnome don't plan the next office suit in javasript either.

That's not happening at all. The plasma 2 libary is still (completely?) written in C++ and so are probably all of the default dataengines. Only the plasmoids and containers themselves are written in QML and most of the heavy lifting is done by the dataengines (which can be written in various scripting languages but are mostly done in C++ and will be so in the future too because of speed and efficiency).

[Akka]

That's not happening at all. The plasma 2 libary is still (completely?) written in C++ and so are probably all of the default dataengines. Only the plasmoids and containers themselves are written in QML and most of the heavy lifting is done by the dataengines (which can be written in various scripting languages but are mostly done in C++ and will be so in the future too because of speed and efficiency).

If you read the gnome guys blog, he says they don't plan to use javascript in libraries. Move your heavy code to the libraries or modules and do the pastering with a scripting language is not unique for plasma. Gnome do like that today in the python apps (I suppose at least). I'm sure they do the same with javascript.

[kigurai]

Python web applications don't include a lot of Python code as majority of code is client side (HTML, Javascript) and SQL commands.

That is not my experience of writing web applications with Python. Also, the framework itself (Django, to make an example) is hardly in the "trivial" category either.
Seriously though, you can have your opinion, but it is not one that you will be sharing with much of the software engineering community.

[kigurai]

Gnome didn't give up GTK when they adopted Clutter. They simply added another official toolkit. Qt is perfectly usable for applications conforming to Gnome HIG.

I think that is not really a good example. GTK and Qt have a large overlap in functionality while GTK and Clutter complement each other. I don't think you want to build a GNOME application in Clutter alone.
See project reference here: http://blogs.gnome.org/clutter/about/

I admit that I am neither a GTK or Clutter expert, so I'll let this post from stackoverflow give an overview instead: http://stackoverflow.com/questions/9...lutter-gtk-etc

And I am sure you could write a Qt-application that conforms to GNOME HIG. I am just a bit confused why I'd want to do that since GTK is a dependency of GNOME, while Qt isn't.
Just like I would not write a KDE application using GTK.

For a general Linux application? Then I suppose it becomes a matter of personal taste since most people will have both GTK and Qt installed.

[Nobu]

9. Use psyco, a dynamic python->C compiler that uses a JIT compiler approach to optimize inner loops.
10. For high CPU intensive activities like encryption, they use C extensions.
11. Some pre-generated cached HTML for expensive to render blocks.
12. Row level caching in the database.
13. Fully formed Python objects are cached.

So, optimized inner-loops and (or, at least) extensive caching play a big part.

That's not to say it wouldn't be fast without that, but you can't ignore it either.

[Ericg]

What would stop you from statically linking Qt to your program? It's licenced under LGPL 2.1 or later after all. You can also make modifications to it but you just have to release them like the licence requires.

The Qt Licensing deal stop you. Because Qt is under a dual-license they can create exceptions. One of the exceptions is if you use static-linking, you have to use a commercial license. Probably because they cant prove you arent modifying the static-libs since theyre just binary code. But when you're using dynamic/shared libraries there is a guarantee you aren't modifying them because you are stuck with whatever the user's computer provides.