7 ms·

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

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.

BubRoss 7y ago
Closed source is a con, separate markup language guis are a con, 5MB binaries are a con.
- guido_vongraum 7y ago
  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?
  - BubRoss 7y ago
    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.
    - guido_vongraum 7y ago
      > 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.
    - pierrebai 7y ago
      Why Qt takes 50 MBs for hello world? Simple: because that is not true. 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.
      - guido_vongraum 7y ago
        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.
        the_pwner224 7y ago
        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.
yellowapple 7y ago
> 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.
- guido_vongraum 7y ago
  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?
  - yellowapple 7y ago
    > 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?".

BubRoss 7y ago

Closed source is a con, separate markup language guis are a con, 5MB binaries are a con.

guido_vongraum 7y ago
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?
- BubRoss 7y ago
  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.
  - guido_vongraum 7y ago
    > 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.
  - pierrebai 7y ago
    Why Qt takes 50 MBs for hello world? Simple: because that is not true. 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.
    - guido_vongraum 7y ago
      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.
      - the_pwner224 7y ago
        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.

yellowapple 7y ago

> 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.

guido_vongraum 7y ago
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?
- yellowapple 7y ago
  > 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?".