Not a library per se, but HTML+CSS+JS. Bootstrap or some other mobile responsive framework. Works on just about every device&OS. Phone gap or similar if you really need native.
I think the question needs to be a lot more specific about the type of app and the platforms it needs to run on. Web-based applications give you the broadest reach for the lowest cost if you can assume internet connectivity and if the GUI that's possible from within the browser sandbox is sufficient for your needs. (Capabilities are growing all the time, but it's still not the same as native.) If your app needs to be offline, it's still possible with web tech but it's harder to justify, unless you're doing a hybrid of online and offline and the online part isn't just service calls.
Qt has a truly pleasant API and bindings in many languages. If you haven't used it before - and I know you haven't, otherwise you wouldn't be asking :) - give it a try. There's very little that's more cross-platform.
We have chosen Qt for our new cross-platform app (Android, Windows, MacOS) which we've developed for the past 1.5 years and have overall not regretted it. Doing UIs with QML and Qt Quick is so much faster than Android's XML based system and gives you a lot of flexibility.
However there's a bit of a UI rendering overhead, although I understand they made it faster with Qt 5.7. And OpenGL integration is more complicated than doing it natively since you have to understand Qt's UI scene graph system and the way Qt is threading things.
Same here. I ran into a few problems with Android. Controls 2 is not quite ready yet, I had to write some Java, but it worked. Hopefully more AndroidExtras will be added in time.
Qt's nice, but the thing I've always disliked about it is that it re-implements all these basic types, like QString, QVector, QList, QMap, etc. and you need to use them to interact with all their APIs. So, you either have to decide you're all-in on Qt and have these QThis and QThat types littered all over your code (making it more difficult to interact with other third party libraries like boost that know nothing about Qt, or you need to agree on a boundary between your non-Qt-specific code and your UI, and maintain a layer that converts to and from standard types.
This is common in older C++ projects that predate good quality STL and good compilers everywhere. They should factor it out, but that would break a ton of code.
I'm working on a Qt project, and our convention is to have a pure C++ back-end (i.e., STL), but use QObjects everywhere on the Models, Views and Controllers (as per Qt's MVC pattern). That way we can one day re-implement the UI if needed and keep the same "pure" C++ back-end. This has worked fine for us so far.
My impression with Qt is that it has less language bindings than the alternatives. For Qt5 you find lots of bindings for QtQuick stuff but if you want to use traditional QtWidgets then its basically C++ or Python.
JavaFX also has support to bundle a JRE with its native installer support, it can build a exe, msi, dmg etc. The bigger issue is Oracle not really giving it the proper attention.
Even if it were true, you can easily bundle a JRE with your app, which is what Oracle recommends actually. In the end, it still ends up being smaller in size than a Electron/NW.js app.
React (Native). You can build an iOS and android app with the same codebase. Even windows phone and ubuntu are starting to support it. Then when you want to use the web, your whole data layer can carry over to reactjs. It's a really nice way of doing things. There's even react native for Mac OS that someone has started.
I still haven't found a clear answer to that, but using the LGPL license could pose a problem, because you need to allow the user to recompile the application with his own version of Qt.
On iOS shared libraries are not allowed on the store, so you should distribute the files for static linking... it becomes quite messy and sort of unclear from the legal point of view.
Even if it's wasn't clear before now it's pretty clear - you must buy commercial license if you want to be on App Store. There was Qt license change[1] in January 2016 and there is no longer LGPLv2.1 licensed version since Qt 5.7.
Only option for commercial software currently is LGPLv3 and it's doesn't allow tivoization.
Hey thanks. I wasn't aware of the dylib appstore restriction. Is this still the case with iOS8 and if not, could a dynamic LGPL Qt app be put on the store. I hope they allow this going forward.
JUCE is a great framework, has a very commendable coding style and is easy to get into. One thing to note is that the "JUCE way" of doing things is to have a UI that looks exactly the same on every platform - this is good for predictability, but if you want a UI that looks native, you're better off using Qt or wxWidgets (as C++ UI toolkits go).
In many cases I'd say that's not an issue, and JUCE is underrated/underused as a general-purpose UI toolkit.
Well, commendable means "deserving praise", and when working with it, I generally appreciated the simplicity, consistency, and clarity I found throughout the JUCE codebase.
It also encourages you to adopt a coding style that's consistent with the rest of JUCE, particularly in terms of memory management. This is one of the things that makes it a lot more "framework" than "library", and again might not be for everyone. Take a look at the "Object lifetime and ownership" section in this page:
Licensing and cost is similar to Qt (free for open source, $$$ for commercial applications, though I think JUCE is cheaper). So, at least relatively to Qt, it doesn't particularly limit popularity.
And even in an absolute sense, you can't confidently say that dual-licensing limits popularity in the long term. If JUCE and Qt were free for everyone, perhaps they wouldn't be able to have the full-time developers they both currently have. So maybe they wouldn't be as good, thereby decreasing popularity against competing dual-licensed libraries. This is all wild speculation, of course, but it's an example to show how their model works.
There are plenty of options (all biased by personal opinion) for this task. Maybe one of these projects is a good fit for you (creating consistent uis should be easy with all of these).
It would help a lot to have the question elaborate on what you really need. What do you mean by "best", and do you actually need the best? Do you need easy to learn, or code that is easy to deliver, or most powerful features, or most number of platforms covered? Do you include mobile in cross platform, and do you have a performance or language requirement?
A web app is one of the most cross platform ways to go, is the easiest to deliver, and can be easy-ish to learn, but isn't the easiest. But, you are stuck with JavaScript. If a web app won't work for you, why not? Knowing that will allow people to help you more.
Qt is great, especially if you're using C++ or some other language. It's pleasant and very powerful, but a lot to learn, and deployment to users is harder than a web app.
It is a shame that OP does not want to go HTML/CSS engine, because over the years, I have found that to be the easiest to update, the most reliable across platforms, and (most importantly) the easiest to support for multiple users.
I have tried (and used in production) most of the UI tookits mentioned here.
WxWindows (later WxWidgets), Tk, and FLTK are getting long in the tooth and show it.
Java (SWT, etc), looks wonky across platforms and really do not stand up to the "write once, run anywhere" promise. Also, if you have to do anything even a little out of the lines, count on keeping multiple codebases for different platforms.
Although I had a brief love affair with other VM-type platforms (Adobe Air, Silverlight), mobile mostly pushed support for them out (Air just pivoted to mobile altogether, I believe). They offered single codebase, easy updates, and easy-ish support at a cost of have the user install additional software, but worth the tradeoff in my opinion.
All of the python UI libs are a pain in the ass to distribute, update, and support.
Ultimate++ and Borland Delphi are pretty polished, but you either have to buy into their ecosystems or accept their limitations.
At the end of the day, even though Javascript is a bullshit language for desktop development, HTML/CSS engines (phonegap, Electron, sciter, etc) are just pleasant for maintaining codebase, pushing out updates, doing anything you want with the UI, and support has been a breeze.
Tk and WxWidgets are not in the same league as QT.
Tk is limited, specifically, to being a gui toolkit, and even though the most recent versions look like native widgets, they are limited and the online support (from groups, etc) is limited. All the connecting libraries feel like you are back in the 90's programming again.
WxWidgets is to QT, as Linux is to Mac OS X -- one is cobbled together from amateurs with varying quality of components, and the other is built by professionals and held to professional rigor. The API (and output, in my opinion) is amateurish and dated in comparison. It lacks the polish and ecosystem that the professionally-supported QT has.
If you are making a full-fledged application (as opposed to a user tool or back-end interface) and are hell-bent on using a windowing toolkit (over say an HTML/CSS engine), then QT is currently the only correct answer. There are others around, but they all fall short of QT.
On a side note, Tcl (by the same original author as Tk) is a wildly under-appreciated scripting language.
That post is by the lead developer of a SQLite project competing with the one I'm involved in. The original version was developed in Tcl/Tk, and outgrew it.
Note - I'm not personally familiar with Tck/Tk, I just remembered reading this when you mentioned it. :)
I've recently been using Crank Storyboard and I've been off to a good start. You can run it on embedded devices like ARM Cortex-M series processors, or Linux, iOS, Android, Windows, with openGL support. It does require a license though.
Also someone else mentioned Phonegap and using HTML/JS. I think is a good option but it depends on what your app does and if you're doing mobile app design.
I have not used QT yet, but after doing some research, it's kind of a pick your poison type of choice, IMO.
Electron only works for desktop applications and probably needs a js-framework to work good. I think that React + Electron looks like a nice combo and then you can use React Native to create Android and iPhone apps also, probably sharing a lot of code between all versions.
+1 on this, I'm having a very pleasant time working on a couple Electron+React apps right now. I've been starting my apps based off https://github.com/chentsulin/electron-react-boilerplate but diverging greatly after getting it running.
Instead of react native you can also just reuse the UI-code directly for the mobile deployment. Just add meta tags like apple-mobile-web-app-capable=true and style with @media-rules.
To be fair "just" might be over simplifying things a bit. I've been doing this for an application and thinking that it actually would be a benefit to have a different code bases for the desktop and mobile editions. It can be a bit challenging to design for both targets at once.
At the moment the pairing seems to be Electron + Cordova for non-React JS frameworks; with those two you can share 100% HTML at least if you have a responsive CSS design.
Also, now that React Native is extending into the Desktop space more directly (with Linux, Mac, and Windows UWP variants), for React you may not need Electron at all.
Further aside, I'm also amused and unsurprised that engineering has been going into React Native for Web [1] so that with React Native you might not even target base DOM React again.
Electron is ok for certain applications, but I'm really wary of this whole trend. It's leading to extremely buggy, resource intensive desktop applications.
JUCE is all that and a bag of chips. It is a perfectly capable competitor to QT, yet also has fantastic multimedia APIs. Docs are excellent. Source is ultra clear.
What is the best depends on your exact requirements but three good options to get a GUI off the ground quickly are Tk [1], wxWidgets (and wxPython [2] and wxLua [3] in particular) and Lazarus (LCL) [4].
Tk widgets look native on Windows and macOS (if you use the right ones — see [5]), though their behavior is implemented by Tk itself. On Linux it draws its own widgets in several styles; GTK and Qt theme support is immature. Lazarus and wxWidgets use native widgets on Windows and macOS. Both can use GTK2 on Linux but Lazarus also supports GTK1 and Qt.
If I had to deliver a cross-platform desktop GUI application by midnight today, I would go with Tk, write the code in Tcl (which necessarily has the best Tk integration) and package it in a static binary Starpack [6].
Tk is antiquated (no antialiasing [1]) and has a poor look on Linux. It lacks functionality in widgets such as embedding a progressbar in a tree/list (don't remember) widget, which Qt supports. Also, poor font rendering support. (doesn't render Devanagari and probably CJK scripts). It feels like a 10 year old tech which it is.
(1) Maybe there is some option for it somewhere, but if so, having antialiasing disabled by default is weird.
Suitability of Tcl/Tk depends on what the goal is. For some applications, like utilities, GUI access to CLI tools, form-based data entry, etc., Tk is fine. It isn't a good option for a sophisticated drawing program, and I would try to use it for a full-bore word processor.
Within its domain, Tk is a very capable tool that easy to use, well-documented, versatile and relatively bug-free.
Future versions are planned to acquire antialiasing and other improvements, no doubt it will be a while before it's available.
I don't understand how anyone can assume that antialiasing is missing in Tk, it's simply wrong and has been there for many years for font drawing. On Linux, it must be compiled against fontconfig/xft (default, if the headers can be found). On OSX and Windows, it uses the native font renderer. The only point on OSX high dpi displays: you need to set a property that the application supports high dpi (in a .plist file), but this holds for any App-bundle on OSX. Antialiasing on a canvas (as opposed to text in labels, buttons etc.) is only enabled in OSX by default. tkpath replaces the default canvas with a more complete implementation (alpha blending, gradients, antialiasing...) on all 3 platforms.
Thanks so much for this! I know very little about Tk.
Besides antialiasing on a canvas, does antialiasing also work in text in labels, buttons, etc? Can I get in Tk all the fonts I can get in a Mac? Is Helvetica there?
But I did not say that. In the reply to the comment you've linked you
write that "this thread believes Tk is as good as QT". I am puzzled by
this conclusion because I do not see any comparison to Qt at all.
Certainly, I didn't want to suggest any with my comments.
If you want to know
my option on how Tk compares to Qt, I currently believe that, for the most part, they serve different use cases, with some overlap in the middle. Tk is better than Qt in one area (roughly: small-to-medium applications developed by a lone hacker ASAP) and Qt is better than Tk in another (roughly: medium-to-large applications developed by a team on some sort of a schedule).
Qt does a lot more than Tk. It comes with more features, e.g., networking abstractions.
Compared to it, Tk is limited. Qt looks better, too — much better on *nix.
I would not recommend Tk over Qt in the general, catch-all,
could-become-a-kitchen-sink-application case. (In
fact, working well in the general case seems to be a major selling
point for Qt.) If you develop one, chances are you will find yourself
wanting to do something that Tk can't. In other words, I would expect a
large application to outgrow Tk before it outgrows Qt.
I recommended Tk specifically for making a GUI quickly. It is good for
prototyping and rapid iteration and has neat widgets like canvas and the
text editor that help a lot with that. Tcl with Tk is expressive, so you can do a
lot in under 1000 lines of code (toy example: [1]). The
Tcl REPL helps more still, as does a great binary deployment story. After the prototype or MVP, once you understand what you want to do better,
you may stay with Tk if you decide it suits your needs or switch to
something else.
>Is there anything Tk can't do?
That is a very open-ended question. One thing that comes to mind is
integrating with the host platform's accessibility features. Most
cross-platform GUI toolkits suck at it. There is a wishlist wiki page
[2] that might offer some hints at what other things Tk
users find missing.
>Does Tk make it possible to use webfonts I see on websites?
Whoa, whoa, whao. QT is superior to Tk because of network abstractions? Hello, Tk is part of Tcl, which has a socket layer so sophisticated that its embedded into Cisco routers.
Let's keep the discussion between QT people who actually KNOW Tcl/Tk and Tcl/Tk people who actually KNOW QT
> I recommended Tk specifically for making a GUI quickly. It is good for prototyping and rapid iteration and has neat widgets like canvas and the text editor that help a lot with that. Tcl with Tk is expressive, so you can do a lot in under 1000 lines of code (toy example: [1]). The Tcl REPL helps more still, as does a great binary deployment story. After the prototype or MVP, once you understand what you want to do better, you may stay with Tk if you decide it suits your needs or switch to something else.
Actually, I would argue the opposite. I found it easy to create GUIs using Qt Designer and to use connect() to bind functionality together. (Albeit, this was with Python, it might be harder in C++).
> widgets like canvas and the text editor
Is there something particularly unique in Tk's canvas and text editor?
Tk is 25-year-old tech, not 10. ;-) It has also maintained backwards compatibility since 1997 or so, which is a nice feature to have in many cases but comes at a price. For example, you have to know to use a "ttk::button", not a plain "button", to get the native (Windows, macOS) or a least the somewhat better-looking (*nix) widget. The result is that old Tk software still runs unchanged instead of forcing its maintainers to upgrade, but it looks bad and outdated, contributing negatively to Tk's general image.
The poor look on Linux is definitely a big downside. You can ameliorate it somewhat with a custom theme [1] but your GUI will still look out of place in any major desktop environment. TileGTK and TileQt [2] aren't maintained.
I haven't used it myself, but Tk has at least some CJK support [3]. One thing to keep in mind from the start, though, is that Tcl/Tk suffers from a UTF-16 code unit limitation similar to Java's; it only handles the Basic Multilingual Plane [4] natively.
As for antialiasing, what do you mean when you say it is disabled by default? Is that in a particular Linux distribution? A recent Tk release (post-Tcl 8.5) should render antialiased text unless you compile it with "--disable-xft" or your font is raster.
> As for antialiasing, what do you mean when you say it is disabled by default? Is that in a particular Linux distribution? A recent Tk release (post-Tcl 8.5) should render antialiased text unless you compile it with "--disable-xft" or your font is raster.
Sorry, I was thinking about antialiased drawings (canvas). Text was antialiased if I remember correctly.
IIRC Tk only has linear gradients, no fancy gradients that is needed to make your GUI look good.
GTK may have a difficult API, but it is portable and it gives a better feel than Qt for Linux+Gnome users like me (I will always choose a GTK app over a Qt app).
GTK+'s Windows support is mixed. It mostly works, but bugs reports don't seem to get much attention and you're on your own if you want Windows binaries. macOS support is effectively an afterthought. The only teir 1, actively supported platform appears to be Linux which makes me wonder why the project advertises itself as "cross-platform."
If you're looking to do a desktop GUI type of application, then those two are decent choices.
If you have skill in C++ already, then Qt is a natural fit there. Also, Qt's docs are very good. None of the "oh, I was advised to use this class. Where are the docs? What do you mean... go read the source code?".
Gah... sorry... still haven't gotten my extremely bad experiences with Gtk out of my system (years later). ;)
If I were doing a desktop GUI type app again, I'd choose Qt for sure. Good docs, very large user base, actively helpful Community on IRC. (I'm not really a forums guy). Plus, bunches of Qt code (of various quality) on GitHub for getting ideas from.
wxWidgets has been used by some popular projects like Audacity, TortoiseCVS, RapidSVN, FileZilla, BitTorrent, etc.
Another wxWidgets advantage over Qt is the license, which gives you more freedom.
If you're looking for a faster start, take a look at wxFormBuilder which is a graphical WYSIWYG UI editor where you can drop controls in windows/dialogs and hook up event handlers.
You can find links to more related tools/IDEs on the Wikipedia page:
In my experience with it, wxwidgets has a very antiquated feeling to the API (I know, subjective) and it didn't ship high DPI support when I used it. Its Python bindings at the time felt rather unpythonic. Generally I wouldn't want to use this again.
"wxwidgets has a very antiquated feeling to the API"
This should not be relevant in any professional technical discussion. Last time I looked there was not an overflowing oversupply of cross platform UI frameworks.
"it didn't ship high DPI support "
This, on the otherhand, might be a critical deficit.
At least on Windows, there's a new UI API every 7 years. MFC, Winforms, WPF...
Maybe "wxwidgets has a very antiquated feeling to the API" really means that platform-neutral concepts do not encapsulate well when keeping the UI truly native?
Cross-platform with a single code base has always been a bit of a myth, if only because different platforms have different conventions for things like how to lay out dialog boxes or the writing style used for buttons. If you want something that feels like a native application on different platforms, it's always going to require some level of customisation.
It's still useful to have a single UI library in your code that you can tell to make a text box or open a menu or draw some graphics and have it translate into the correct API calls on each platform under the hood. For all the much-touted rearrangements of UIs, particularly in recent versions of Windows, the reality is that most of the familiar GUI controls haven't really changed that much in decades.
I think the biggest difficulty for any attempt at a cross-platform GUI framework today is probably making sure it does properly handle the widgets or behaviours that really are different or unique on each platform. More generally, if you're building for multiple platforms you also have to deal with all the installation and updating and sandboxing and so on that tends to be completely different from one OS to another, and often the GUI libraries and UI integration is a big part of that too.
Instead of giving me the tools to make a modal pop-up, but then leaving me to match that modal pop-up to the stylistic conventions of each OS GUI, why can't a UI framework give me a "YesNoModalPopup" that looks and acts however a "YesNoModalPopup" is supposed to act on the respective OS—even going so far as to actually be a modal sheet or a command-line prompt instead?
This, I think, is one of the bigger but oft-unstated reasons that people actually prefer to target the web rather than targeting native. Javascript's window.alert() is a function with a semantic behaviour-contract; it will alert the user. It doesn't specify how it'll alert the user, that's up to the browser to define. (And, therefore, up to the user to pick the browser whose definition they enjoy.)
Perhaps what I'm really craving, here, is a XAML-like or XUL-like constraint-based declarative view format, which has a very high-level and abstract set of controls available to be specified. Then, different GUIs could have renderer-clients for this system, that rendered those controls in all sorts of different ways. Maybe you could even mix-and-match your favourite concrete controls, like with browser extensions.
I want to agree with the spirit of what you're saying, but given the potential complexity and uniqueness of a GUI, I think it's an extremely hard problem in practice, if not impossible. You're asking for a toolkit that is both generic enough to provide the common functionality you're describing, yet also comprehensive and flexible enough to cope with the diverse needs of different applications and the diverse conventions and capabilities of different platforms.
How hard can it be to build a toolkit that supports a textbox on Mac OS X, Windows, and Linux? For a moment I thought you proposed a solution a thread up:
> have it translate into the correct API calls on each platform under the hood.
What if instead of writing controls for applications, the applications had low level access to create controls on their own?
Individual controls aren't the problem. Unique controls and idioms that cover multiple controls are.
For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing.
Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI.
Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.
I see that the deeper you go, the less you can keep common. I learned a lot from your answers.
I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI?
I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?
> why can't a UI framework give me a "YesNoModalPopup" that looks and acts however a "YesNoModalPopup" is supposed to act on the respective OS
As a simple counter-example, macOS rarely uses Yes/No/OK/Cancel buttons. Instead, dialog buttons have meaningful names based on the task at hand, e.g. "Overwrite File" and "Keep Old File".
That's exactly what I meant, though. "YesNoModalPopup" is the name of a semantic behavioural contract, not a concrete implementation class whose name describes what you'll see. In instantiating a YesNoModalPopup, there would be required fields for button labels—even though those field-values will only be used on OSX.
With an abstract+declarative toolkit, you would still have to do just as much customization toward your use-case as you would if you were writing one view class for each GUI. You just get to skip the marginal cost of everything that's not that customization. You can have a single code path to create, and show, and receive input from, the instance of the pop-up abstraction.
> This should not be relevant in any professional technical discussion. Last time I looked there was not an overflowing oversupply of cross platform UI frameworks.
That latter sentence kinda defeats the argument in your first sentence.
If there's a dearth of options, then there's room for a better API.
"If there's a dearth of options, then there's room for a better API."
A new UI framework is not something you can wish for Christmas. One can implement one (like Blender has done) but other than that, one is limited to the options which are available.
I don't think anyone claims there is no space for new UI libraries. It's not obvious one can simply implement a new one. This is not something someone does for fun over a weekend (at industrial scale) or just to try an epiphany of design over a few months. They are huge, laborious beasts. If one has resources to implement a huge UI framework, then generally, they probably have the resources to implement the UI natively on every platform they wish to deploy on.
"A better API" is kinda moot feature for a UI library since they are technically so demanding, all other factors are more critical.
I just started using it a few months ago, and perhaps the antiquated API you refer is the "old methods" described in wxWidgets books and such. There is a new modern-ish API with jQuery like function chaining, and an Advanced UI (AUI) subsystem enabling one complete control to the presentation layer. It is not perfect, but I'm liking it.
So far wxWidgets is the only library that anybody has mentioned that actually can be counted on to make somewhat accessible UIs. To see it dismissed because it's a little crufty for the developer to work with makes me incredibly sad, as it's just part of the slow decline that leaves me as a blind person with less and less accessible stuff to use.
One day I'll be stuck on an old emulated version of Windows running only apps which I have created for myself. What a bleak, shitty future.
Not against wx by any means, but I actually tried it recently on osx and it drew most controls manually on a canvas of its own. So "xplatform nativeness" is not a selling point for wx.
You've probably used wxUniversal. Try wxOSX/Cocoa, it wraps native controls such as NSButton. You can even get this object and use Cocoa API directly (inside appropriate #ifdef block obviously).
Because one platform supports more options and when using that control on a different platform there are exactly two choices: break cross compatibility or reimplement the control.
Add evolution of controls and idioms over time, and it's literally impossible to always unify: not all platforms evolve their non-trivial components in the same direction.
I'm glad I asked this because your answer suggests this is the main problem with cross-platform UIs.
What do you think is the right thing to do? To have a common denominator kind of approach where a control works on all platforms but with fewer features, or to reimplement the control?
Do you have an example handy of a control/idiom that caused this problem?
It sounds like reimplementing (emulation) is a good thing.
> Qt only emulates Windows controls, but wxWidgets uses the actual Windows controls via Microsoft Win32 API.
I don't think this is actually what you want on Windows. The standard common controls are pretty outdated. Anyone who has built a complex program with a lot of widgets using common controls (or a framework that wraps them) can probably tell you that they're really slow and they have problems with flicker. They also use outdated font rendering (GDI rather than DirectWrite) and they don't natively support alpha-blending. Even Microsoft avoid using common controls. Task dialogs, Aero wizards and most control panels are built with an internal toolkit called DirectUI. Office is built with similar technology, and obviously WPF and Windows Store apps don't use common controls.
This makes Qt pretty much what you want on Windows. It uses the native theming APIs so its controls look native, but they are rendered with a high performance raster engine that supports alpha-transparency and eliminates flicker. Also, I think the latest version of Qt uses DirectWrite for font rendering.
You can have your cake and eat it too. If you have to build a native desktop app, you can use Chromium Embedded Framework. Spotify is one of its biggest users. You can still build your UI in HTML but drive it with native code (C++, Objective-C, C#, etc). We used CEF when we realized how painful Win32 C++ WTL desktop UI was.
"...a cross-platform IDE for Rapid Application Development. It has variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces."
Why use Lazarus and Free Pascal? You can create native, cross-platform UI's all combined into a single, fast, low-memory executable that can easily be deployed and distributed on different platforms.
It depends on what you mean by, "cross-platform." In my world there is no such thing. You pick your target platforms and program to them. However it is common to imply "major platforms" (ie: iOS, Android, Windows 10, OSX). Different platforms have different requirements and will shape your solution.
Next... what is the application? Do you need to target native APIs? Do you have memory limitations?
If you don't mind taking up a lot of memory try one of the "cross platform" systems like Xamarin or some Java-based solution. If you need to be more constrained try writing to the native APIs and porting your project to each target platform you need to target. Lastly if you're highly constrained maybe you need to try an immediate-mode style library like Nuklear[0].
It really depends on your needs. There's no one-size-fits-all.
If a language run-time or virtual machine promises, "you can write code once and run it anywhere," then they're not telling you the whole story. There's no such thing as, "cross platform." It's just a vague term that is commonly interpreted as, "major OS platforms," or, "most popular mobile platforms," etc.
Requirements are both technical and non-technical. If we just focus on the technical requirements you have to look at the data you're working with, your user, and how the program interacts in this system between the human and the rest of the world. If you're writing safety-critical mobile applications for remote workers that spend a week or more in the field you're probably not going to waste your resources on a memory-hungry VM just so that life is more convenient for you. That's starkly different to prototyping an application in a lab where convenience is paramount compared to cheap resources. I have yet to see any kind of language or run-time that lets you have it both ways.
One may say, "Yes agentultra, but what about generating the code for the highly-constrained environment from the higher-level language?" I love this approach. It's possible to generate efficient code this way. This approach still requires you to understand your target platform well enough to spot bugs in the generated code. So while it may be an approach to gain some leverage as a single developer or small team; you're still quite constrained but this DSL... the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.
I haven't yet found a way to "escape" the reality that different combinations of hardware and OSs require different solutions for different applications. It may seem like "all you need is Java" or X, Y, or Z -- but the reality is more nuanced than that.
> I have yet to see any kind of language or run-time that lets you have it both ways.
If there were such a language I wouldn't be asking this question on HN. I have yet to see a clear answer why there is no such kind of language or run-time.
> the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.
> I have yet to see a clear answer why there is no such kind of language or run-time.
... I'm having trouble not being glib in my response. I want to say, because computers. But let's be a little hand-wavey for a moment.
As programmers we sometimes put too much faith in our poorly-thought-out abstractions. We think, "why is there not a library/runtime/VM that abstracts away all of these painful, tedious details? Surely someone must've invented a GUI library that runs on all platforms, perfectly." We look for ways to avoid the difficulty of thinking too hard about it. We just want to write an application and not think about operating systems, hardware architectures, memory allocation, etc, etc.
Well there are systems that do remove some of the effort in writing such applications. They will manage memory for you, abstract away the differences in various operating systems, and they might even provide a common library for writing a GUI that works across all of the platforms that the VM/runtime supports... this is a great tool to have.
However it has a cost. It has it's own memory model. It makes assumptions about what GUI interfaces are. It targets the common denominator between operating systems. It is, by necessity, quite complex on the inside... so as long as you can sit comfortably in the box and write programs that the system expects you to write you can safely ignore the hairy details of allocating memory, making system calls, managing resources, etc.
But if your application requirements pull you out of that comfort zone be prepared to have to deal with garbage collection algorithms and mapping your application's data to the runtime's model. That has a cost.
For some applications that cost isn't worth it or even feasible. How much battery power are you willing to consume? How many updates to the simulation can you make per second? How fast do you have to stream that data of the disk to this other component?
These languages and runtimes that claim to be "cross platform" are really just selling you a subset of functionality on a subset of platforms that you may or may not care about. It's never what you intuitively assume it to mean, "write once, run everywhere."
> Why? Can be you more specific with an example?
I wrote a 6502 assembler in Common Lisp many moons ago. With it I was able to write applications for that processor in a high-level language with all of the Common Lisp tools I was used to. However that DSL was restricted to that platform backend.
Had I a requirement to target another platform, say x86_64, I would have to write another backend for my high-level DSL and introduce plumbing to my build tools to produce the executable code for either platform. Great! Cross platform code!
Well... not really. I still had to write two different backends. And I can't really exploit the unique features of either. I can only really make use of the common denominator between both or else emulate features of one in the other at the expense of making one platform less performant/useful than another.
There's no such thing as "cross platform." It's just a marketing buzz-word. There are hardware platforms. There are operating systems. These are the things we program.
Abstractions are great but they're not free and they don't free you from thinking. It's an easy mistake to make because it comes so naturally to us humans -- we hate doing things that are difficult. But there's nothing natural about programming. It's hard.
There is Livecode (livecode.org). Does anyone have experience using it in production? It's cross-platform and has both commercial and open source (community) versions.
I like it for prototyping. I have done some real client projects with it and it does work well and fast. Especially for apps that either require a custom UI or not too polished at all.
229 comments
[ 4.2 ms ] story [ 284 ms ] threadQT refers to Apple's Quick Time.
Qt refers to the Qt project, pronounced 'cute'.
Electron or QT for cross-desktop apps, Angular & Ion framework for cross-mobile apps, React & React-native for cross-mobile apps
I think the question needs to be a lot more specific about the type of app and the platforms it needs to run on. Web-based applications give you the broadest reach for the lowest cost if you can assume internet connectivity and if the GUI that's possible from within the browser sandbox is sufficient for your needs. (Capabilities are growing all the time, but it's still not the same as native.) If your app needs to be offline, it's still possible with web tech but it's harder to justify, unless you're doing a hybrid of online and offline and the online part isn't just service calls.
However there's a bit of a UI rendering overhead, although I understand they made it faster with Qt 5.7. And OpenGL integration is more complicated than doing it natively since you have to understand Qt's UI scene graph system and the way Qt is threading things.
But overall it's been a good choice so far.
I used QT before. Please don't be presumptuous.
It's python based, and really easy to get going. It does have it's quirks, but overall I found it a joy to use.
But different, if you are selling source -- then you pay.
Only option for commercial software currently is LGPLv3 and it's doesn't allow tivoization.
[1] https://subsurface-divelog.org/2016/02/subsurface-mobile-for...
In many cases I'd say that's not an issue, and JUCE is underrated/underused as a general-purpose UI toolkit.
Please explain!
It also encourages you to adopt a coding style that's consistent with the rest of JUCE, particularly in terms of memory management. This is one of the things that makes it a lot more "framework" than "library", and again might not be for everyone. Take a look at the "Object lifetime and ownership" section in this page:
https://www.juce.com/learn/coding-standards
And even in an absolute sense, you can't confidently say that dual-licensing limits popularity in the long term. If JUCE and Qt were free for everyone, perhaps they wouldn't be able to have the full-time developers they both currently have. So maybe they wouldn't be as good, thereby decreasing popularity against competing dual-licensed libraries. This is all wild speculation, of course, but it's an example to show how their model works.
- https://crosswalk-project.org/
- https://cordova.apache.org/
- https://kivy.org/
- https://www.nativescript.org/
- https://www.xamarin.com/
- https://facebook.github.io/react-native/
#
- https://www.wxwidgets.org/
- http://nwjs.io/
- http://electron.atom.io/
A web app is one of the most cross platform ways to go, is the easiest to deliver, and can be easy-ish to learn, but isn't the easiest. But, you are stuck with JavaScript. If a web app won't work for you, why not? Knowing that will allow people to help you more.
Qt is great, especially if you're using C++ or some other language. It's pleasant and very powerful, but a lot to learn, and deployment to users is harder than a web app.
What are your constraints & requirements?
It is a shame that OP does not want to go HTML/CSS engine, because over the years, I have found that to be the easiest to update, the most reliable across platforms, and (most importantly) the easiest to support for multiple users.
I have tried (and used in production) most of the UI tookits mentioned here.
WxWindows (later WxWidgets), Tk, and FLTK are getting long in the tooth and show it.
Java (SWT, etc), looks wonky across platforms and really do not stand up to the "write once, run anywhere" promise. Also, if you have to do anything even a little out of the lines, count on keeping multiple codebases for different platforms.
Although I had a brief love affair with other VM-type platforms (Adobe Air, Silverlight), mobile mostly pushed support for them out (Air just pivoted to mobile altogether, I believe). They offered single codebase, easy updates, and easy-ish support at a cost of have the user install additional software, but worth the tradeoff in my opinion.
All of the python UI libs are a pain in the ass to distribute, update, and support.
Ultimate++ and Borland Delphi are pretty polished, but you either have to buy into their ecosystems or accept their limitations.
At the end of the day, even though Javascript is a bullshit language for desktop development, HTML/CSS engines (phonegap, Electron, sciter, etc) are just pleasant for maintaining codebase, pushing out updates, doing anything you want with the UI, and support has been a breeze.
Tk is limited, specifically, to being a gui toolkit, and even though the most recent versions look like native widgets, they are limited and the online support (from groups, etc) is limited. All the connecting libraries feel like you are back in the 90's programming again.
WxWidgets is to QT, as Linux is to Mac OS X -- one is cobbled together from amateurs with varying quality of components, and the other is built by professionals and held to professional rigor. The API (and output, in my opinion) is amateurish and dated in comparison. It lacks the polish and ecosystem that the professionally-supported QT has.
If you are making a full-fledged application (as opposed to a user tool or back-end interface) and are hell-bent on using a windowing toolkit (over say an HTML/CSS engine), then QT is currently the only correct answer. There are others around, but they all fall short of QT.
On a side note, Tcl (by the same original author as Tk) is a wildly under-appreciated scripting language.
What can Tk not do, specifically? This thread believes Tk is as good as QT https://news.ycombinator.com/item?id=12380456
http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=334
That post is by the lead developer of a SQLite project competing with the one I'm involved in. The original version was developed in Tcl/Tk, and outgrew it.
Note - I'm not personally familiar with Tck/Tk, I just remembered reading this when you mentioned it. :)
http://www.codenameone.com/blog/comparing-qt-and-codename-on...
http://cranksoftware.com/storyboard-suite
Also someone else mentioned Phonegap and using HTML/JS. I think is a good option but it depends on what your app does and if you're doing mobile app design.
I have not used QT yet, but after doing some research, it's kind of a pick your poison type of choice, IMO.
Electron - Build Cross-Platform Desktop Apps With HTML, JS, CSS
http://electron.atom.io/
To be fair "just" might be over simplifying things a bit. I've been doing this for an application and thinking that it actually would be a benefit to have a different code bases for the desktop and mobile editions. It can be a bit challenging to design for both targets at once.
Also, now that React Native is extending into the Desktop space more directly (with Linux, Mac, and Windows UWP variants), for React you may not need Electron at all.
[1] https://github.com/necolas/react-native-web
No more js app please! They're terrible! They're slow! They leak a LOT of memory! They don't work on virtual machines!
If you want a native one, probably Qt is the winner here.
Tk widgets look native on Windows and macOS (if you use the right ones — see [5]), though their behavior is implemented by Tk itself. On Linux it draws its own widgets in several styles; GTK and Qt theme support is immature. Lazarus and wxWidgets use native widgets on Windows and macOS. Both can use GTK2 on Linux but Lazarus also supports GTK1 and Qt.
If I had to deliver a cross-platform desktop GUI application by midnight today, I would go with Tk, write the code in Tcl (which necessarily has the best Tk integration) and package it in a static binary Starpack [6].
[1] http://www.tkdocs.com/
[2] https://wxpython.org/
[3] http://wxlua.sourceforge.net/
[4] http://www.lazarus-ide.org/, http://wiki.lazarus.freepascal.org/LCL
[5] http://www.tkdocs.com/tutorial/idle.html
[6] https://tcl.wiki/Starpack
(1) Maybe there is some option for it somewhere, but if so, having antialiasing disabled by default is weird.
Within its domain, Tk is a very capable tool that easy to use, well-documented, versatile and relatively bug-free.
Future versions are planned to acquire antialiasing and other improvements, no doubt it will be a while before it's available.
Besides antialiasing on a canvas, does antialiasing also work in text in labels, buttons, etc? Can I get in Tk all the fonts I can get in a Mac? Is Helvetica there?
Why can't I find on the web screenshots of Tk apps running on Mac OS X? Is the only way to get Tk to look good on a Mac using Tile http://tktable.sourceforge.net/tile/screenshots/macosx.html ?
From what I'm reading now there might be 4 options: Tk, wxWindows, QT, and a custom "thin layer".
Tile was integrated into Tk with version 8.5 (2007). The Tile button, label, etc. are now built in.
Is there anything Tk can't do?
Also a question on fonts. Does Tk make it possible to use webfonts I see on websites?
But I did not say that. In the reply to the comment you've linked you write that "this thread believes Tk is as good as QT". I am puzzled by this conclusion because I do not see any comparison to Qt at all. Certainly, I didn't want to suggest any with my comments.
If you want to know my option on how Tk compares to Qt, I currently believe that, for the most part, they serve different use cases, with some overlap in the middle. Tk is better than Qt in one area (roughly: small-to-medium applications developed by a lone hacker ASAP) and Qt is better than Tk in another (roughly: medium-to-large applications developed by a team on some sort of a schedule).
Qt does a lot more than Tk. It comes with more features, e.g., networking abstractions. Compared to it, Tk is limited. Qt looks better, too — much better on *nix. I would not recommend Tk over Qt in the general, catch-all, could-become-a-kitchen-sink-application case. (In fact, working well in the general case seems to be a major selling point for Qt.) If you develop one, chances are you will find yourself wanting to do something that Tk can't. In other words, I would expect a large application to outgrow Tk before it outgrows Qt.
I recommended Tk specifically for making a GUI quickly. It is good for prototyping and rapid iteration and has neat widgets like canvas and the text editor that help a lot with that. Tcl with Tk is expressive, so you can do a lot in under 1000 lines of code (toy example: [1]). The Tcl REPL helps more still, as does a great binary deployment story. After the prototype or MVP, once you understand what you want to do better, you may stay with Tk if you decide it suits your needs or switch to something else.
>Is there anything Tk can't do?
That is a very open-ended question. One thing that comes to mind is integrating with the host platform's accessibility features. Most cross-platform GUI toolkits suck at it. There is a wishlist wiki page [2] that might offer some hints at what other things Tk users find missing.
>Does Tk make it possible to use webfonts I see on websites?
Not easily. See [3].
[1] https://tcl.wiki/41294
[2] https://tcl.wiki/4055
[3] https://www.reddit.com/r/Tcl/comments/456ydh/is_there_a_way_...
Let's keep the discussion between QT people who actually KNOW Tcl/Tk and Tcl/Tk people who actually KNOW QT
Actually, I would argue the opposite. I found it easy to create GUIs using Qt Designer and to use connect() to bind functionality together. (Albeit, this was with Python, it might be harder in C++).
> widgets like canvas and the text editor
Is there something particularly unique in Tk's canvas and text editor?
The poor look on Linux is definitely a big downside. You can ameliorate it somewhat with a custom theme [1] but your GUI will still look out of place in any major desktop environment. TileGTK and TileQt [2] aren't maintained.
I haven't used it myself, but Tk has at least some CJK support [3]. One thing to keep in mind from the start, though, is that Tcl/Tk suffers from a UTF-16 code unit limitation similar to Java's; it only handles the Basic Multilingual Plane [4] natively.
As for antialiasing, what do you mean when you say it is disabled by default? Is that in a particular Linux distribution? A recent Tk release (post-Tcl 8.5) should render antialiased text unless you compile it with "--disable-xft" or your font is raster.
[1] E.g., http://chiselapp.com/user/skoro/repository/tclapps/artifact/....
[2] http://www.tclcommunityassociation.org/wub/proceedings/Proce...
[3] Per https://tcl.wiki/CJK.
[4] https://en.wikipedia.org/wiki/Basic_Multilingual_Plane
Sorry, I was thinking about antialiased drawings (canvas). Text was antialiased if I remember correctly.
IIRC Tk only has linear gradients, no fancy gradients that is needed to make your GUI look good.
Saying that from wrongly choosing it over Qt for a cross platform screenrecording/annotation project a few years ago.
There's literally no way in hell to recommend GTK for any new desktop project that likely has a Windows audience. GTK is a mess. :(
It sounds like GTK is eliminated too.
What's left now, QT and wxWidgets?
If you have skill in C++ already, then Qt is a natural fit there. Also, Qt's docs are very good. None of the "oh, I was advised to use this class. Where are the docs? What do you mean... go read the source code?".
Gah... sorry... still haven't gotten my extremely bad experiences with Gtk out of my system (years later). ;)
If I were doing a desktop GUI type app again, I'd choose Qt for sure. Good docs, very large user base, actively helpful Community on IRC. (I'm not really a forums guy). Plus, bunches of Qt code (of various quality) on GitHub for getting ideas from.
Hope that's useful. :)
I want to know the difference between the thin layer and the existing libraries. Not in vague terms but specifically with a code example.
But then again, it's not something I've personally tried (nor needed), so that might be an inaccurate assessment.
If you don't need a full/complete GUI stack (and other related bits) implementation for your application, then yeah, it might be the way to go.
http://wxwidgets.org
It provides API layer which compiles to Win32 API on Windows, Gtk2 on Linux and Carbon/Cocoa on Mac OSX.
Qt only emulates Windows controls, but wxWidgets uses the actual Windows controls via Microsoft Win32 API.
BTW, there's wxQt, a wxWidgets implementation that uses Qt instead of Gtk, but it's still experimental:
https://wiki.wxwidgets.org/WxQt
wxWidgets has been used by some popular projects like Audacity, TortoiseCVS, RapidSVN, FileZilla, BitTorrent, etc.
Another wxWidgets advantage over Qt is the license, which gives you more freedom.
If you're looking for a faster start, take a look at wxFormBuilder which is a graphical WYSIWYG UI editor where you can drop controls in windows/dialogs and hook up event handlers.
You can find links to more related tools/IDEs on the Wikipedia page:
https://en.wikipedia.org/wiki/WxWidgets
This should not be relevant in any professional technical discussion. Last time I looked there was not an overflowing oversupply of cross platform UI frameworks.
"it didn't ship high DPI support "
This, on the otherhand, might be a critical deficit.
Maybe "wxwidgets has a very antiquated feeling to the API" really means that platform-neutral concepts do not encapsulate well when keeping the UI truly native?
It's still useful to have a single UI library in your code that you can tell to make a text box or open a menu or draw some graphics and have it translate into the correct API calls on each platform under the hood. For all the much-touted rearrangements of UIs, particularly in recent versions of Windows, the reality is that most of the familiar GUI controls haven't really changed that much in decades.
I think the biggest difficulty for any attempt at a cross-platform GUI framework today is probably making sure it does properly handle the widgets or behaviours that really are different or unique on each platform. More generally, if you're building for multiple platforms you also have to deal with all the installation and updating and sandboxing and so on that tends to be completely different from one OS to another, and often the GUI libraries and UI integration is a big part of that too.
This, I think, is one of the bigger but oft-unstated reasons that people actually prefer to target the web rather than targeting native. Javascript's window.alert() is a function with a semantic behaviour-contract; it will alert the user. It doesn't specify how it'll alert the user, that's up to the browser to define. (And, therefore, up to the user to pick the browser whose definition they enjoy.)
Perhaps what I'm really craving, here, is a XAML-like or XUL-like constraint-based declarative view format, which has a very high-level and abstract set of controls available to be specified. Then, different GUIs could have renderer-clients for this system, that rendered those controls in all sorts of different ways. Maybe you could even mix-and-match your favourite concrete controls, like with browser extensions.
> have it translate into the correct API calls on each platform under the hood.
What if instead of writing controls for applications, the applications had low level access to create controls on their own?
For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing.
Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI.
Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.
I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI?
I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?
As a simple counter-example, macOS rarely uses Yes/No/OK/Cancel buttons. Instead, dialog buttons have meaningful names based on the task at hand, e.g. "Overwrite File" and "Keep Old File".
With an abstract+declarative toolkit, you would still have to do just as much customization toward your use-case as you would if you were writing one view class for each GUI. You just get to skip the marginal cost of everything that's not that customization. You can have a single code path to create, and show, and receive input from, the instance of the pop-up abstraction.
That latter sentence kinda defeats the argument in your first sentence.
If there's a dearth of options, then there's room for a better API.
A new UI framework is not something you can wish for Christmas. One can implement one (like Blender has done) but other than that, one is limited to the options which are available.
I don't think anyone claims there is no space for new UI libraries. It's not obvious one can simply implement a new one. This is not something someone does for fun over a weekend (at industrial scale) or just to try an epiphany of design over a few months. They are huge, laborious beasts. If one has resources to implement a huge UI framework, then generally, they probably have the resources to implement the UI natively on every platform they wish to deploy on.
"A better API" is kinda moot feature for a UI library since they are technically so demanding, all other factors are more critical.
This is not correct. Many controls use the native implementation of the underlying platform.
Emulating sounds like an extra layer one could do with out.
Add evolution of controls and idioms over time, and it's literally impossible to always unify: not all platforms evolve their non-trivial components in the same direction.
What do you think is the right thing to do? To have a common denominator kind of approach where a control works on all platforms but with fewer features, or to reimplement the control?
Do you have an example handy of a control/idiom that caused this problem?
It sounds like reimplementing (emulation) is a good thing.
I don't think this is actually what you want on Windows. The standard common controls are pretty outdated. Anyone who has built a complex program with a lot of widgets using common controls (or a framework that wraps them) can probably tell you that they're really slow and they have problems with flicker. They also use outdated font rendering (GDI rather than DirectWrite) and they don't natively support alpha-blending. Even Microsoft avoid using common controls. Task dialogs, Aero wizards and most control panels are built with an internal toolkit called DirectUI. Office is built with similar technology, and obviously WPF and Windows Store apps don't use common controls.
This makes Qt pretty much what you want on Windows. It uses the native theming APIs so its controls look native, but they are rendered with a high performance raster engine that supports alpha-transparency and eliminates flicker. Also, I think the latest version of Qt uses DirectWrite for font rendering.
What is a Lazarus? From their website:
"...a cross-platform IDE for Rapid Application Development. It has variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces."
Why use Lazarus and Free Pascal? You can create native, cross-platform UI's all combined into a single, fast, low-memory executable that can easily be deployed and distributed on different platforms.
http://www.lazarus-ide.org/
Next... what is the application? Do you need to target native APIs? Do you have memory limitations?
If you don't mind taking up a lot of memory try one of the "cross platform" systems like Xamarin or some Java-based solution. If you need to be more constrained try writing to the native APIs and porting your project to each target platform you need to target. Lastly if you're highly constrained maybe you need to try an immediate-mode style library like Nuklear[0].
It really depends on your needs. There's no one-size-fits-all.
[0] https://github.com/vurtun/nuklear
Why?
If a language run-time or virtual machine promises, "you can write code once and run it anywhere," then they're not telling you the whole story. There's no such thing as, "cross platform." It's just a vague term that is commonly interpreted as, "major OS platforms," or, "most popular mobile platforms," etc.
Requirements are both technical and non-technical. If we just focus on the technical requirements you have to look at the data you're working with, your user, and how the program interacts in this system between the human and the rest of the world. If you're writing safety-critical mobile applications for remote workers that spend a week or more in the field you're probably not going to waste your resources on a memory-hungry VM just so that life is more convenient for you. That's starkly different to prototyping an application in a lab where convenience is paramount compared to cheap resources. I have yet to see any kind of language or run-time that lets you have it both ways.
One may say, "Yes agentultra, but what about generating the code for the highly-constrained environment from the higher-level language?" I love this approach. It's possible to generate efficient code this way. This approach still requires you to understand your target platform well enough to spot bugs in the generated code. So while it may be an approach to gain some leverage as a single developer or small team; you're still quite constrained but this DSL... the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.
I haven't yet found a way to "escape" the reality that different combinations of hardware and OSs require different solutions for different applications. It may seem like "all you need is Java" or X, Y, or Z -- but the reality is more nuanced than that.
If there were such a language I wouldn't be asking this question on HN. I have yet to see a clear answer why there is no such kind of language or run-time.
> the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.
Why? Can be you more specific with an example?
... I'm having trouble not being glib in my response. I want to say, because computers. But let's be a little hand-wavey for a moment.
As programmers we sometimes put too much faith in our poorly-thought-out abstractions. We think, "why is there not a library/runtime/VM that abstracts away all of these painful, tedious details? Surely someone must've invented a GUI library that runs on all platforms, perfectly." We look for ways to avoid the difficulty of thinking too hard about it. We just want to write an application and not think about operating systems, hardware architectures, memory allocation, etc, etc.
Well there are systems that do remove some of the effort in writing such applications. They will manage memory for you, abstract away the differences in various operating systems, and they might even provide a common library for writing a GUI that works across all of the platforms that the VM/runtime supports... this is a great tool to have.
However it has a cost. It has it's own memory model. It makes assumptions about what GUI interfaces are. It targets the common denominator between operating systems. It is, by necessity, quite complex on the inside... so as long as you can sit comfortably in the box and write programs that the system expects you to write you can safely ignore the hairy details of allocating memory, making system calls, managing resources, etc.
But if your application requirements pull you out of that comfort zone be prepared to have to deal with garbage collection algorithms and mapping your application's data to the runtime's model. That has a cost.
For some applications that cost isn't worth it or even feasible. How much battery power are you willing to consume? How many updates to the simulation can you make per second? How fast do you have to stream that data of the disk to this other component?
These languages and runtimes that claim to be "cross platform" are really just selling you a subset of functionality on a subset of platforms that you may or may not care about. It's never what you intuitively assume it to mean, "write once, run everywhere."
> Why? Can be you more specific with an example?
I wrote a 6502 assembler in Common Lisp many moons ago. With it I was able to write applications for that processor in a high-level language with all of the Common Lisp tools I was used to. However that DSL was restricted to that platform backend.
Had I a requirement to target another platform, say x86_64, I would have to write another backend for my high-level DSL and introduce plumbing to my build tools to produce the executable code for either platform. Great! Cross platform code!
Well... not really. I still had to write two different backends. And I can't really exploit the unique features of either. I can only really make use of the common denominator between both or else emulate features of one in the other at the expense of making one platform less performant/useful than another.
There's no such thing as "cross platform." It's just a marketing buzz-word. There are hardware platforms. There are operating systems. These are the things we program.
Abstractions are great but they're not free and they don't free you from thinking. It's an easy mistake to make because it comes so naturally to us humans -- we hate doing things that are difficult. But there's nothing natural about programming. It's hard.