Who needs JS? Rapid prototyping and "LIVE" code with C++ and LLVM JIT :)
-
You might have seen "Bret Victor's real time feedback demo":http://vimeo.com/36579366, in which case you were probably left fairly impressed. Many people probably were, since "alternative implementations":http://www.kickstarter.com/projects/ibdknox/light-table started popping up too.
The fact that JavaScript, Python, Java, Clojure are VM based languages makes it fairly easy to get a "LIVE" IDE because "compilation" time is fairly short, and sometimes direct interpreter execution is also possible.
This has been pointed out as one of JS's main advantages and a justification for the fragmentation of Qt into C++ and QML parts.
With LLVM however, the C++ story seems to change a bit. "This video":http://www.youtube.com/watch?v=imkVkRg-geI was created just a few days ago, and it goes to show that a "LIVE" IDE is not outside of the reach for C++, thanks to LLVM and its JIT facilities, the user can get practically instantaneous feedback and indeed a live connection between the source code and the executable it produces. Nothing short of impressive.
Unfortunately, LLVM has not enjoyed a lot of attention when it comes to Qt, but judging from its merits, perhaps it is worth to consider extending QtCreator to take advantage of those features and enable rapid prototyping and live code for C++. Besides feedback and two way link between code and output, this can be extended to provide code generation for a visual GUI editor, which generates native C++ without the need of neither XML nor QML.
-
Wow! Very impressive!
This is really a feature I'm longing for. How sad, that Qt still cannot compile with LLVM on windows.
(Or am I wrong?) -
Here is something vaguely similar with Qt and Cling, which is a C++ interpreter. Not really live connection with the source but still fairly realtime:
http://www.youtube.com/watch?v=BrjV1ZgYbbA -
Interesting.
Does anyone have experience with Juce? How does it compare to Qt?
-
Well, the API is a little different in design which dictates a difference in the workflow, the framework itself is significantly smaller, yet offers some features that are completely absent in Qt.
As main advantages I'd point to support for stuff like ASIO, MIDI and VST audio technologies, creating self-sufficient statically linked executable with no external dependencies, full C++11 support and compiler agnostic, significantly cheaper to use commercially compared to Qt. Also Android and iOS are fairly well supported, under the initiative of the main developer of the framework. No scripting, no extra languages (QML, JS), no NEED of MOC/code generation behind the scenes (although optionally you can have C++ and meta code generated by the UI designer)
Disadvantages, compared to Qt - absence of LGPL, you either go commercial or open source, very basic (and I mean it) documentation, hardly any examples or educational materials, no books, no complimentary tool chain as with the Qt SDK, not as good modularity and absence of many auxiliary classes that make working with low level APIs and/or implementing new APIs easier. Much smaller community, harder for starters compared to Qt.
I should mention I have very basic experience with Juce, literally like a few hours, so my comparison may not be completely accurate. I am used to Qt APIs and naturally I find Juce odd where it differs.
All in all, even thou both frameworks are supposed to serve a similar purpose, they are very different in their specialization and application. I simply cannot recommend one or the other, I guess in a perfect world there would also be a perfect framework, a mix between Qt and Juce, both of which are hands down the best C++ frameworks currently in existence. The thing that impresses me the most with Juce is that it is virtually developed and maintained by a single person, which is in huge contrast to Qt and its scores of developers. The very idea a single person can implement and maintain so many features across all the supported platforms boggles the mind.d
-
Thanks for the comparison. It's really helpful.
I tried the demo from Juce and one thing immediately jumped on me is the non-native look on Mac. It feels more like a typical lack-of-personality Java app than a desktop C++ application. There are options to make it more native-looking but the controls like checkbox remains non-platform-native.
I am a firm believer in native platform look-n-feel. So that's a show stopper to me. But if I need to write a custom UI app, Juce will still be on my list to consider.
-
Well, in fact it is not lack of personality - platform native design is lack of personality - the design takes whatever form the platform implements, it does not have its own personality but takes the one of the platform, which is good in some cases and bad in others.
I am not a big fan of "native" look and feel, for me it is a compete nonsense. I've had HTML sites that use "native" components which totally break the design of the website, because they are different colors, different shapes, different sizes and sometimes not even supported on a given browser.
Juce aims to provide applications that look the same way irregardless of the operating system, the look and feel is OS agnostic. Lets face it, native look and feel is dull and boring, that is the whole reason QtQuick was "invented" - I myself never use native stock widgets with Qt or Juce, unless I am prototyping and not really concerned with the looks. So for me the styling of Juce is not a deal breaker, as I prefer my look and feel to be native to the application and my design intent, and agnostic of the platform instead of native to the platform and breaking the design. But that is because I have design background and do custom design for my apps instead of relying on the boring and stiff design of the native widgets.
For many people it doesn't work, the most frequent argument is that "users are familiar with the look and feel of their platform of choice" - but good custom designs do tend to be more intuitive and have more personality, and it makes the experience of using the same app on different platforms more consistent. After all I don't care about platforms, I care about MY application and the experience it provides.
On a side note, I am not convinced design intent is a matter of "believing" - it is a matter of functionality, efficiency and aesthetics, all of which are logical and factual, only brand cult obsessed blind fanatical fanboys take stuff for granted and "believe" that their favorite thing is "the best" - platform native look and feel is the same, it is boring, it completely deprives apps of personality and it is also not very feature rich and does not address the need of more advanced and specialized widgets and application scenarios - you got push buttons, radio boxes, dropdown menus, sliders, progress bars and thats pretty much it. It works well for certain apps but is totally unuseful for others, especially when your intent is to bring your app to desktop and mobile devices at the same time. Good luck using stock components, relying on platform native look and feel and trying to implement something more advanced than a box with some text fields and buttons on it.
Juce is intended for "apps that look like this":http://audiodeluxe.com/sites/default/files/presstudioone2instruments.jpg. What good are native widgets in this scenario? Trying to use native widgets for similar applications is something that can range anywhere from extremely stupid to completely impossible thing to do.
