3 ms·

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

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.
      - guido_vongraum 7y ago
        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.
        jcelerier 7y ago
- ahartmetz 7y ago
  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
- c-smile 7y ago
  Sciter's author here... "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-HTML-XML-Scanner-Tokenizer 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.
  - BubRoss 7y ago
    I don't think I've missed much. > 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.
    - c-smile 7y ago
      > a text language with lots of different overlapping rules and syntax. Could you elaborate more on this? What are those overlapping rules? > unnecessary complexity just to get a layout heirarchy and dependencies. I have no idea why you think it is so complex... DOM element is this: class Element { weak_ptr<Element> parent; vector<ptr<Element>> children; map<...> attributes; } And you will see EXACTLY the same structure in any GUI framework/system.

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.
    - guido_vongraum 7y ago
      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.
      - jcelerier 7y ago
ahartmetz 7y ago
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
c-smile 7y ago
Sciter's author here... "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-HTML-XML-Scanner-Tokenizer 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.
- BubRoss 7y ago
  I don't think I've missed much. > 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.
  - c-smile 7y ago
    > a text language with lots of different overlapping rules and syntax. Could you elaborate more on this? What are those overlapping rules? > unnecessary complexity just to get a layout heirarchy and dependencies. I have no idea why you think it is so complex... DOM element is this: class Element { weak_ptr<Element> parent; vector<ptr<Element>> children; map<...> attributes; } And you will see EXACTLY the same structure in any GUI framework/system.