5 ms·

JavaScript is NOT the first language to provide cross-platform GUI. Such toolkits are very old. Gtk, Qt, wxWidgets, and many others serve this functionality and

JavaScript is NOT the first language to provide cross-platform GUI. Such toolkits are very old. Gtk, Qt, wxWidgets, and many others serve this functionality and have bindings across dozens of languages. There is no reason to use JavaScript just so you can get a "cross platform GUI".

rspeer 10y ago
Gtk is not very cross-platform. It looks non-native on Windows, and it's so non-native on macOS that you have to run an X server just to see it. wxWidgets seems to be abandoned (their bindings don't even have a Python 3 release, which would happen right away if anyone cared). Most of these provide dated UI elements that people don't want to work with. Qt perhaps is holding up the best, but I can see why people prefer Javascript's event model to Qt's. Pointing out that old toolkits still exist doesn't necessarily help when people expect more from their toolkit now.
- blub 10y ago
  What do people expect nowadays from their toolkit? It can't be performance, because Electron is slow. It's not conservative power usage, because browsers are power hungry. It's not disk space or memory usage either. Nor is it a native-looking UI. Nor security. Nor privacy. Nor accessibility. The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new.
  - bpizzi 10y ago
    You missed the ecosystem ;) NPM, even if it has plenty of do-not-use-that-packages crap, is still far more furnished that Qt will ever be, for example. > The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new. One could say the same for the typical Qt developer that refuse to get serious in learning the web platform.
    - kitsunesoba 10y ago
      It's all anecdotes, but in my experience native devs are by far more willing to step outside of their area of expertise and use the right tool for the job when building for the web. Yeah they'll groan, but at the end of the day they realize that HTML+CSS+JS is how web front end works and so they write that. Very few bother compiling their favored language to JS or asm.js or whatever because it adds an unnecessary step/level of indirection and feels like trying to use a hammer as a handsaw. By comparison web front end devs tend to cling much more tightly to their favored language+toolchain, taking it with them to every platform they decide to develop for.
    - blub 10y ago
      I think the front-end world has a big culture problem, and your answers are an example of that. Ignoring arguments, aggressive advocacy, "you too"s, asserting that web technologies are great in the face of so much evidence to the contrary and most of all, insisting to use the same inadequate tools for everything from desktop to mobile to embedded. I've been having the same discussion for six years with different characters now. One thing has never changed - web apps consistently show poorer quality than their native counterparts, especially in performance, resource usage and usability. The software this community so focused on PR and advocacy is building is not good in spite of the bragging. And regarding your arguments: * Java, C++, .NET, Python, etc can claim having ecosystems. JS has a continuously churning collection of libraries. Nothing has been forgotten. * a lot of Qt developers use it where it makes sense by bulding hybrid apps or together with QML.
      - bpizzi 10y ago
        > Ignoring arguments, aggressive advocacy, "you too"s, asserting that web technologies are great in the face of so much evidence to the contrary and most of all, insisting to use the same inadequate tools for everything from desktop to mobile to embedded. Don't get me wrong, I'm actually a nice guys who has nothing against Qt/C++. I'm glad it exists because I can use it when what matters is power usage, native looking UI, security, privacy and all. It's just that I don't, personnaly, need those requirements. > The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new I'm sorry but this is simply wrong. And I think you don't need to show disregard to "typical web developers" when you're trying to make a point. What do you choose when you need to quickly throw an MVP in front of a customer? Surely not C++/Qt (well, maybe yes if that's the only platform you master). When you need a web-looking UI ? Not C++/Qt. When you need to easily deploy on hundred's of windows workstations at a plant where IT is blocking you from installing anything on said workstations? A web app, not a C++/Qt client. So, you see, maybe the web platform also has it advantages when you start looking outside of what you do everyday for a living.
- jhasse 10y ago
  > and it's so non-native on macOS that you have to run an X server just to see it. Gtk has been ported to macOS in 2007. You don't need an X server anymore :)
  - rspeer 10y ago
    Oh! Sorry. I suppose this is what Inkscape for Mac is using; that makes sense. Does it support hi-DPI yet?
    - jhasse 10y ago
      Gtk 3 should (GIMP is still using 2 unfortunately ...), not sure how the support is on Mac.
- __david__ 10y ago
  > Gtk is not very cross-platform. It looks non-native on Windows, and it's so non-native on macOS that you have to run an X server just to see it. This has not been true for years now. There is a native port of Gtk that does not require an X server. Gimp is available natively, as are other Gtk apps (Gnucash, Deluge, etc).
mamcx 10y ago
Is not about the first (and this is more about html/css than JavaScript). Is about the easier to work out, specially for custom styling and do custom widgets. Not get me wrong, I don't like much JS/html apart as be hostage as everyone else to use it in the web, but is clear that as far to build the GUI is way more enjoyable than most GUI toolkit.
- blub 10y ago
  I think you need to prove that a (custom) UI is easier to build with HTML/CSS compared to QML. Or even plain old QWidget. It can't be that web developers have been bitterly complaining about how poor HTML and CSS are at building UIs for years and years and suddenly it's become easy and enjoyable.
  - bpizzi 10y ago
    > suddenly it's become easy and enjoyable. Actually it has become easy and enjoyable ;) Even for complex UIs. Just think seriously about what a stack like es6/React/Redux brings on the table against plain old ES5, and you'll be struck by how well things have become.
    - cookiecaper 10y ago
      Last time I implemented a complex web frontend was about 2 years ago. I can assure you that the process was anything but "easy and enjoyable". I will, of course, grant that things have improved greatly since the bad old days of IE6. But that's not a good anchor point to use for "easy and enjoyable".
      - bpizzi 10y ago
        > I will, of course, grant that things have improved greatly since the bad old days of IE6. But that's not a good anchor point to use for "easy and enjoyable". Totally granted, the web platform suffer from a very bad reputation. And what does not help at all is that one need to carefully choose his tooling among a zillion of short-lived, hyped github repos. But there is future-proof gems for those who invest the time in trying and learning. In a jumble: React, Redux, Reagent, Re-frame, Typescript, Clojurescript, Om, Immutable.js, Om.next, and so on.
bpizzi 10y ago
> JavaScript is NOT the first language to provide cross-platform GUI. Of course it's not. > There is no reason to use JavaScript just so you can get a "cross platform GUI". The main reason (imho) is that "JavaScript" (as you call it, but you should say "the web platform") is more future proof than "old toolkits". Qt would be the best candidate for a "cross platform GUI", but you are relying on the [Qt company/nokia/whatever] for its continuation. When you choose html/js you choose a standard used by virtually every single person with a computer nowadays. There is far less chance that html/js will be killed someday, like Microsoft killed WPF or like IBM made SWT an abandonware, because nobody is in that position and this whole World Wide Web thing rely on it.
- blub 10y ago
  Your message left me scratching my head. How can JS be more future-proof than old UI toolkits when JS libraries and frameworks are constantly changing? Sure, nobody will kill HTML and JS, but that's not the point. Nobody knows how UIs will be built with web technologies in two years! Edit: based on your reply below, it looks like I have to spell it out. GUIs are built with UI frameworks, not just with programming languages and markup languages. JS frameworks are so short-lived that one can't be sure if their code will still work in one year. That is the opposite of future-proof.
  - bpizzi 10y ago
    > Sure, nobody will kill HTML and JS, but that's not the point. Yes, it is the point. Nothing more, nothing less. > Nobody knows how UIs will be built with web technologies in two years! You can't say that things like es6/react/typescript/clojurescript will be plain gone in two years, there's too much real momentum behind these things.
    - cookiecaper 10y ago
      There's real momentum behind a lot of things, including C and FORTRAN. That doesn't mean your next project is necessarily going to be written in either C or FORTRAN. The crop of JavaScript derivatives are probably not going to disappear, but riddle me this: while there are many variations on JavaScript's syntax, why do other languages that are arguably JavaScript competitors, like Ruby and Python, not have the same wide selection of alternate syntaxes and sugar packets? Could it have something to do with the usability of the default dialect? I personally think it's a bad sign when so many people feel they need to write a transpiler to add some syntactic and behavioral enhancements. The language should provide a functional, livable set by default, at least good enough that writing a transpiler doesn't sound like the time-effective solution. I don't understand ASM.js very well but it sounds like it's a new type of bytecode that allows programs written in many different languages to be executed in the browsers' JavaScript VM. If this truly bring us first-class support for non-JavaScripts (which won't be real until browser vendors either ship or make it transparent and automatic to install additional DOM bindings), I will be so happy. I will also be curious to see if it has any impact on the popular use of JavaScript itself -- the node buzz already kind of seems to be fizzling out and moving onto things like Go, so maybe we won't have to wait too long.

rspeer 10y ago

Gtk is not very cross-platform. It looks non-native on Windows, and it's so non-native on macOS that you have to run an X server just to see it. wxWidgets seems to be abandoned (their bindings don't even have a Python 3 release, which would happen right away if anyone cared). Most of these provide dated UI elements that people don't want to work with. Qt perhaps is holding up the best, but I can see why people prefer Javascript's event model to Qt's. Pointing out that old toolkits still exist doesn't necessarily help when people expect more from their toolkit now.

blub 10y ago
What do people expect nowadays from their toolkit? It can't be performance, because Electron is slow. It's not conservative power usage, because browsers are power hungry. It's not disk space or memory usage either. Nor is it a native-looking UI. Nor security. Nor privacy. Nor accessibility. The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new.
- bpizzi 10y ago
  You missed the ecosystem ;) NPM, even if it has plenty of do-not-use-that-packages crap, is still far more furnished that Qt will ever be, for example. > The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new. One could say the same for the typical Qt developer that refuse to get serious in learning the web platform.
  - kitsunesoba 10y ago
    It's all anecdotes, but in my experience native devs are by far more willing to step outside of their area of expertise and use the right tool for the job when building for the web. Yeah they'll groan, but at the end of the day they realize that HTML+CSS+JS is how web front end works and so they write that. Very few bother compiling their favored language to JS or asm.js or whatever because it adds an unnecessary step/level of indirection and feels like trying to use a hammer as a handsaw. By comparison web front end devs tend to cling much more tightly to their favored language+toolchain, taking it with them to every platform they decide to develop for.
  - blub 10y ago
    I think the front-end world has a big culture problem, and your answers are an example of that. Ignoring arguments, aggressive advocacy, "you too"s, asserting that web technologies are great in the face of so much evidence to the contrary and most of all, insisting to use the same inadequate tools for everything from desktop to mobile to embedded. I've been having the same discussion for six years with different characters now. One thing has never changed - web apps consistently show poorer quality than their native counterparts, especially in performance, resource usage and usability. The software this community so focused on PR and advocacy is building is not good in spite of the bragging. And regarding your arguments: * Java, C++, .NET, Python, etc can claim having ecosystems. JS has a continuously churning collection of libraries. Nothing has been forgotten. * a lot of Qt developers use it where it makes sense by bulding hybrid apps or together with QML.
    - bpizzi 10y ago
      > Ignoring arguments, aggressive advocacy, "you too"s, asserting that web technologies are great in the face of so much evidence to the contrary and most of all, insisting to use the same inadequate tools for everything from desktop to mobile to embedded. Don't get me wrong, I'm actually a nice guys who has nothing against Qt/C++. I'm glad it exists because I can use it when what matters is power usage, native looking UI, security, privacy and all. It's just that I don't, personnaly, need those requirements. > The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new I'm sorry but this is simply wrong. And I think you don't need to show disregard to "typical web developers" when you're trying to make a point. What do you choose when you need to quickly throw an MVP in front of a customer? Surely not C++/Qt (well, maybe yes if that's the only platform you master). When you need a web-looking UI ? Not C++/Qt. When you need to easily deploy on hundred's of windows workstations at a plant where IT is blocking you from installing anything on said workstations? A web app, not a C++/Qt client. So, you see, maybe the web platform also has it advantages when you start looking outside of what you do everyday for a living.
jhasse 10y ago
> and it's so non-native on macOS that you have to run an X server just to see it. Gtk has been ported to macOS in 2007. You don't need an X server anymore :)
- rspeer 10y ago
  Oh! Sorry. I suppose this is what Inkscape for Mac is using; that makes sense. Does it support hi-DPI yet?
  - jhasse 10y ago
    Gtk 3 should (GIMP is still using 2 unfortunately ...), not sure how the support is on Mac.
__david__ 10y ago
> Gtk is not very cross-platform. It looks non-native on Windows, and it's so non-native on macOS that you have to run an X server just to see it. This has not been true for years now. There is a native port of Gtk that does not require an X server. Gimp is available natively, as are other Gtk apps (Gnucash, Deluge, etc).

mamcx 10y ago

Is not about the first (and this is more about html/css than JavaScript). Is about the easier to work out, specially for custom styling and do custom widgets. Not get me wrong, I don't like much JS/html apart as be hostage as everyone else to use it in the web, but is clear that as far to build the GUI is way more enjoyable than most GUI toolkit.

blub 10y ago
I think you need to prove that a (custom) UI is easier to build with HTML/CSS compared to QML. Or even plain old QWidget. It can't be that web developers have been bitterly complaining about how poor HTML and CSS are at building UIs for years and years and suddenly it's become easy and enjoyable.
- bpizzi 10y ago
  > suddenly it's become easy and enjoyable. Actually it has become easy and enjoyable ;) Even for complex UIs. Just think seriously about what a stack like es6/React/Redux brings on the table against plain old ES5, and you'll be struck by how well things have become.
  - cookiecaper 10y ago
    Last time I implemented a complex web frontend was about 2 years ago. I can assure you that the process was anything but "easy and enjoyable". I will, of course, grant that things have improved greatly since the bad old days of IE6. But that's not a good anchor point to use for "easy and enjoyable".
    - bpizzi 10y ago
      > I will, of course, grant that things have improved greatly since the bad old days of IE6. But that's not a good anchor point to use for "easy and enjoyable". Totally granted, the web platform suffer from a very bad reputation. And what does not help at all is that one need to carefully choose his tooling among a zillion of short-lived, hyped github repos. But there is future-proof gems for those who invest the time in trying and learning. In a jumble: React, Redux, Reagent, Re-frame, Typescript, Clojurescript, Om, Immutable.js, Om.next, and so on.

bpizzi 10y ago

> JavaScript is NOT the first language to provide cross-platform GUI. Of course it's not. > There is no reason to use JavaScript just so you can get a "cross platform GUI". The main reason (imho) is that "JavaScript" (as you call it, but you should say "the web platform") is more future proof than "old toolkits". Qt would be the best candidate for a "cross platform GUI", but you are relying on the [Qt company/nokia/whatever] for its continuation. When you choose html/js you choose a standard used by virtually every single person with a computer nowadays. There is far less chance that html/js will be killed someday, like Microsoft killed WPF or like IBM made SWT an abandonware, because nobody is in that position and this whole World Wide Web thing rely on it.

blub 10y ago
Your message left me scratching my head. How can JS be more future-proof than old UI toolkits when JS libraries and frameworks are constantly changing? Sure, nobody will kill HTML and JS, but that's not the point. Nobody knows how UIs will be built with web technologies in two years! Edit: based on your reply below, it looks like I have to spell it out. GUIs are built with UI frameworks, not just with programming languages and markup languages. JS frameworks are so short-lived that one can't be sure if their code will still work in one year. That is the opposite of future-proof.
- bpizzi 10y ago
  > Sure, nobody will kill HTML and JS, but that's not the point. Yes, it is the point. Nothing more, nothing less. > Nobody knows how UIs will be built with web technologies in two years! You can't say that things like es6/react/typescript/clojurescript will be plain gone in two years, there's too much real momentum behind these things.
  - cookiecaper 10y ago
    There's real momentum behind a lot of things, including C and FORTRAN. That doesn't mean your next project is necessarily going to be written in either C or FORTRAN. The crop of JavaScript derivatives are probably not going to disappear, but riddle me this: while there are many variations on JavaScript's syntax, why do other languages that are arguably JavaScript competitors, like Ruby and Python, not have the same wide selection of alternate syntaxes and sugar packets? Could it have something to do with the usability of the default dialect? I personally think it's a bad sign when so many people feel they need to write a transpiler to add some syntactic and behavioral enhancements. The language should provide a functional, livable set by default, at least good enough that writing a transpiler doesn't sound like the time-effective solution. I don't understand ASM.js very well but it sounds like it's a new type of bytecode that allows programs written in many different languages to be executed in the browsers' JavaScript VM. If this truly bring us first-class support for non-JavaScripts (which won't be real until browser vendors either ship or make it transparent and automatic to install additional DOM bindings), I will be so happy. I will also be curious to see if it has any impact on the popular use of JavaScript itself -- the node buzz already kind of seems to be fizzling out and moving onto things like Go, so maybe we won't have to wait too long.