Sciter is fantastic, and honestly I don't get it why being closed source is a con.
In fact, both 'commercial license / closed source' statements are not quite true - one may link against the precompiled dll for free, even in commercial apps (as cheap as that could be), while commercial licenses, starting from fair $310 (a lifetime license!), are there for those who need static linking, dedicated support and, mind you, access to the sources.
But even free users can expect a welcoming and timely response from the author (Sciter is a one-man affair). I, for one, never had a condescending or impolite reply to the dumbest of my questions.
Also, the article doesn't mention the fact that Sciter is more widespread than it might seem - for example, many Windows AV solutions, including Eset, Norton, Avast, Bitdefender and Comodo, use it as GUI engine.
> honestly I don't get it why being closed source is a con
Transparency is a dependency of trust. If it ain't transparent, then it's not possible to trust it, end of story. This means that I'm going to be significantly disinclined to use a library if I can't see its source code (i.e. it's a binary blob with a header file). Sure, I could pay $310 for access to the source code so I can audit it myself (or hire someone to audit it for me)... or I could not spend that money and use something I can actually audit freely.
Same goes for static linking. I could spend $310 for the ability to statically link Sciter with my project... or I could not spend that money and use something I can include in any of my projects regardless of the license for that project.
What sort of incentive would an indie developer who makes his living from sales of his software has to make his library malware and thus not only kill any current and potential future commercial endeavor, but also open himself to lawsuits from his own customers (among others)?
Maybe he wants to make a quick buck off users who don't pay for the source code?
Maybe he's a Latvian sleeper agent looking to infiltrate government software systems to boost the global potato market?
Maybe his machine was in turn infected by malware that's now able to spread via his compilers to any software he in turn compiles, Ken-Thompson-Trusting-Trust-style?
Maybe he sold it to someone else and the new owner is in one or more of the above categories?
These sorts of things happen all the time. Why should I expect this library to be an exception?
I mean, if you want to take that chance, go for it. Personally, given there are numerous other options out there, I'd rather stick to something with a FOSS license and source code that the general public (including myself) can audit (and potentially even maintain, for reasons that I outlined in response to the sibling comment).
No, I don't think I want, now that you've sown a seed of doubt in my mind..
It's just occurred to me that he well might be a covert princess who'll jump out of my laptop, disguised as a frog, and demand me to kiss him in order to dispel the evil spell!
Instead of paying $350 to a security analyst, I'd better pay them to an independent closed-source developer who makes a living from his software. Why would I trust some analyst more than the guy who works on his project with great care and dedication for over 10 years now?
> the guy who works on his project with great care and dedication for over 10 years now?
You're assuming he'll always work on his project with great care and dedication. Humans are, last I checked, mortal; even assuming he doesn't eventually tire of maintaining it and/or decide to sell it to someone else to maintain it (that someone else being by no means guaranteed to be neither negligent nor outright malicious), he'll almost certainly fall victim to the Great Garbage Collection Algorithm In The Sky at some point, and now all of a sudden you're tied to a library that now literally nobody can legally maintain (because the one person who had the rights to publish new versions is dead).
Even if he had the foresight to create an LLC or other business entity to abstract ownership away from his own person, that's still dependent on that LLC continuing to meaningfully exist. Ain't like companies are really immortal, either.
Why deal with that hassle when there are plenty of libraries that don't have that problem (because they're released under licenses that permit the users of those libraries to fork and continue their development should it be necessary to do so)?
If you're willing to pay an independent developer for a closed-source library, why not instead pay an independent developer for a not-closed-source library and get the best of both worlds?
> Instead of paying $350 to a security analyst, I'd better pay them to an independent closed-source developer who makes a living from his software.
If I'm paranoid enough to feel the need to pay someone else to audit my dependencies, FOSS would save me money; I'd only have to pay the $350 v. having to pay $350 + the source code price.
And no, just paying the original programmer is insufficient; the point of an audit is to establish trust in a system, and the original programmer has a pretty obvious conflict-of-interest if he's trying to, you know, sell me the software.
He could, of course, seek out a well-known third-party auditor to independently audit each build, thus being able to say "no need to take my word for it; this totally trustworthy other person checked it out and confirmed it's totally safe". While that's not quite as reassuring as a customer-initiated audit, it's certainly better than "just trust me, mmmkay?".
> he'll almost certainly fall victim to the Great Garbage Collection Algorithm In The Sky at some point, and now all of a sudden you're tied to a library that now literally nobody can legally maintain
Don't worry, you too are literally not going to be tied to such a library forever, you know :)
And I'm sorry to burst your bubble, but no software project, however open sourced and redundantly-maintained it is, is immortal either.
Indeed, no software project is immortal, but a software project with a license that lets literally any user pick up where the upstream developer left off and maintain a fork to continue development is significantly less mortal than one without.
That separate language can be learned in a few days and leave you wondering how one guy managed to make things more logical than a crowd of people around JS.
If 5MB is a con, what do you say about 30MB for Qt and ~100MB for Electron?
Also, could you please elaborate on the first statement?
Markup languages for a GUI where isn't needed is a pain because you have a source of indirection when you could just pass the data that the UI library wants directly. Why have a separate text representation and if it must be there, why HTML and CSS? Json would allow you to give the information directly instead of using the convoluted rules of a system that has evolved over decades?
A text language that isn't just values being passed creates new rules and an opaque layer when it is completely unnecessary.
I don't know why Qt takes 50MBs or more for hello world or why anyone would use electron at all. At least Qt will run fast and not have lag and latency. Electron is just the worst of all worlds unless all someone knows is JavaScript.
"Markup languages for a GUI where isn't needed..."
You've missed big picture.
Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes.
ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language. Either binary one (e.g. Windows dialog resources) or text based ones (XAML,HTML,QML, etc). And HTML parsing is not significantly slower (https://www.codeproject.com/Articles/14076/Fast-and-Compact-...) then deciphering of binary formats. Yet the Accessibility ... that thing alone mandates DOM tree to be present.
Of course you can have UI where components are nailed down to pixel grids and colors but think about HighRes monitors, RTL languages, support of night/day theming, branding, etc.
Considering all that you will quickly understand that you need all three components: DOM, style system for the DOM and code that changes state of that DOM. Just to have all this modular an manageable on the long run.
> Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes.
You've argued that UIs require a DOM. Ok, so UIs require a DOM.
That still fails to make a case for needing a separate proprietary markup language to define a DOM, let alone a XML-based one.
Even the Qt folks learned that lesson nearly a decade ago with the introduction of QML.
> ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language.
You are conflating DOM and markup language with heirarchy/dependencies. It isn't necessary to have a text language with lots of different overlapping rules and syntax.
> And HTML parsing is not significantly slower
It's not about speed, it's about unnecessary complexity just to get a layout heirarchy and dependencies.
> UI where components are nailed down to pixel grids and colors
That's a false dichotomy. UIs have been laying out their components without parsing text for almost half a century.
I'm talking about unnecessary complexity when laying out the gui, not implementation. There is no reason to introduce HTML with the various rules in various places, verbosity and indirection. It's a scenario that seems like when all you have is a hammer, everything looks like a nail.
> And you will see EXACTLY the same structure in any GUI framework/system.
I'm sure it works fine, but I wouldn't get stuck on thinking there is no other way.
You need to focus, no one is talking about electron. It's in its own world of nonsense.
> There is a way, named "Dear ImGUI"
I'm not talking about immediate GUIs (and they use a heirarchy for layout too of course). You put some example c++ and said every GUI has that same structure, which isn't necessarily true. A heirarchy doesn't have to be implemented with a tree of pointers.
I'm not saying these things can't work, but saying 'this is how it must be done' is just not true.
But it is though. If you need to have accessibility support in your GUI, all the native accessibility APIs are based on trees so you're going to have to create that tree one way or another.
You showed a few lines of C++. Even for heirarchy,this doesn't need to be a tree of pointers. It's not so bad if it is, but data can be represented as tables or arrays of attributes. Really in a ui the layout is about dependencies and doesn't strictly have to be hierarchy. It's not all that important, just saying that everything must be done in a certain way is ridiculous.
You can do inside whatever you want but you shall provide an API similar to these two functions: HWND GetParent(HWND child) and EnumChildWindows(HWND parent, callback).
Once again: IAccessibility mandates tree organization of your UI. You can do whatever you want but your UI framework MUST expose UI structure as a tree.
This is just moving the goal posts. First you said every GUI needs a markup language, then a specific pointer tree internal structure, now accessibility and specific exposed API.
You only need to ship what you use. QtCore + QtWidgets is more like 15 MB. QtNetwork is another couple MB. The biggest part is QtWebEngine which contains Blink, the core of Chrome.
Edit: QtCore + QtQuick + QtQml should also be roughly 15 MB
I have an application written for Qt and the Qt DLLs for Windows 16-bit are about 16 MB. (Core, Gui, Widgets, WinExtras, style and imageformats.) But, frankly, even if it were true, the disk size of the framework should be extremely low on a list of criteria. As others have noted, the pros and cons listed are not convincing.
I believe 50MB is an exaggeration, but not too far-fetched one. More of a problem is the proliferation and duplication of these DLLs all over the storage when many Qt-based apps are installed. A quick Everything query shows that right now I've got 290MB of Qt*.dlls on my drive.
Seems more like an issue with Windows and its ecosystem of nonfree software.
On most of the Unix-like distros, the maintainers fetch & compile the applications that they make available in the repositories. They can provide a few packages for the various Qt libs, and add these as dependencies to the hundreds/thousands of programs that use Qt. The Qt libs are only downloaded once regardless of whether you have 1 or 20 end-user Qt applications.
Dynamic loading and library updates aren't an issue since the distro maintainers recompile all the Qt-dependent applications whenever Qt has a major update. Older versions can be kept around for programs that haven't been updated in a long time (e.g. I have Qt4 installed on my system as a dependency even though Qt5 has been out for a long time), so there's little extra burden on developers. And with the exception of a few nonfree programs, the entire system works with one system-wide copy of any library.
Of course that doesn't fix the issue for Windows/macOS users, but there's an obvious and proven solution which works, and if main reason it doesn't work for Windows/macOS is because most developers for those platforms restrict the users of their software using nonfree licensing, it only seems fair to blame those ecosystems and OSs instead of blaming Qt.
Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception.
> Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception.
uh... you were right in 2005. Nowadays the standard is for every app to ship its JRE - having to have to install a system wide JRE is part of the stuff that gave Java such a bad and bloaty reputation.
In the light of 290MB of scattered DLLs mentioned above, I believe that this is more than elegant way to advocate the guy who made this false claim - if you read carefully enough, you'll notice that it wasn't me. Care to check?
> I don't know why Qt takes 50MBs or more for hello world or why anyone would use electron at all
You have all my sympathy here :) Well, it should also be noted that 5MB is the size of Sciter's dynamic library. Compiled statically, there will be less contributing to the app's size.
As to markup languages, well, maybe, but I think they are a lot more expressive for things that are styled, positioned via constraints, dynamic and animated. That's completely different approach compared to predefined component libs like WinForms etc.
In fact, both 'commercial license / closed source' statements are not quite true - one may link against the precompiled dll for free, even in commercial apps (as cheap as that could be), while commercial licenses, starting from fair $310 (a lifetime license!), are there for those who need static linking, dedicated support and, mind you, access to the sources.
But even free users can expect a welcoming and timely response from the author (Sciter is a one-man affair). I, for one, never had a condescending or impolite reply to the dumbest of my questions.
Also, the article doesn't mention the fact that Sciter is more widespread than it might seem - for example, many Windows AV solutions, including Eset, Norton, Avast, Bitdefender and Comodo, use it as GUI engine.