Random JS rant

utcenter

Everyday I have to work with QML the concept of a ridiculous JS is reinforced. I wish more core Qt classes are exposed to QML so that the transition from C++ Qt to QML Qt is more fluid and less frustrating and irritating. Just today I got:

You cannot remove a segment from a JS string, ridiculous I know... If you want to get a string with a portion of it removed, you have to do the opposite - construct a string using substring() with everything in it except for the segment you want out. Utterly tedious. Or alternatively, replace the segment with "", a tad better but still, as discussed below, replace has awkwardness of its own.

You can't reverse a string, you have to split to a character array, reverse, then join back as a string... Ingenious... Or write a loop, which seems like the first thing to do, but takes more typing. std::reverse anyone?

Replacing a substring with another string doesn't change the original string, replace doesn't modify the string but returns a new string, how genius is that? Surely, you can just set the new string to string.replace(), but it is just not intuitive IMHO. When you replace something, you expect to get that thing replaced, not get a new thing while the target remains unchanged.

And besides, when is QML going to support the new (curiously fully unsupported anywhere) JS spec which finally introduced a sane OOP paradigm, I mean ecmascript 6?

And I cannot help but think, considering the evolution of QML to eventually reach V4 - a bytecode interpreter, wouldn't it have been much, much better if QML utilized a C++ bytecode interpreter instead of JS to begin with? The effort to implement that would be tremendously less than what QML has gone through so far, just to make the boundary between C++ and QML abrupt and awkward. Surely, I understand that was done in order to attract existing JS developer user base, which is quite big, but I think the Qt APIs are actually better, and something better than JS would have actually attracted more developers. Surely, JS had enjoyed a tremendous industry endorsement, boosting a mere scripting language to application development, but pushing JS to a place it doesn't belong doesn't really make it good at it. In contrast, implementing a simple C++ bytecode interpreter would have made the boundary between C++ and QML Qt seamless and would have brought tremendously more power and flexibility to QML. Seems like software architects in charge of Qt are more of the conformist type rather than innovators...

JKSH

Every system has its pros and cons.

Using JavaScript in QML reduced the cleanliness of string manipulations in QML, but enabled "rapid prototyping of a complex game":http://google.github.io/VoltAir/doc/main/html/index.html#16 and "easy integration of a rich JS server library":http://achipa.blogspot.com.au/2014/12/meteor-and-qt-match-made-in-heaven.html, to name a few.

Whether that's considered a good tradeoff depends on what you're trying to do, I suppose ;)

utcenter

Any reason rapid prototyping won't work with a C++ bytecode compiler and interpreter?

And I wish it was just the awkward string API, JS is full of similar annoyances and limitations.

A C++ bytecode interpreter would have allowed easy integration with C++ server libraries, which trounce JS in terms of performance, gaining you either higher throughput or lower power consumption, both of which good things.

And the tradeoff is not just expressed by the current state of awkwardness, consider all the missteps and changes QtQuick went through since its introduction, which is essentially wasted developer efforts. All to force a clumsy language in a niche it doesn't belong in. And the gain of rapid prototyping could have been achieved from the get go in a much better way, giving you all the benefits at no cost, literally eliminating the tradeoff.

hipersayan_x

Same here, after some experiments with the JS engine, I think that using JavaScript as scripting language was a bad choice. JS lacks many features like operator overload.
I think a best approach would have been something similar on how "ChaiScript":http://chaiscript.com/ works.

bq. A C++ bytecode interpreter would have allowed easy integration with C++ server libraries

There are some experiments with "Cling":https://root.cern.ch/drupal/content/cling and "Qt":https://github.com/cptG/qling but it is unmaintained.