4 ms·

> 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

by 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.
    - spion 10y ago
      > 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? Popularity, and the fact that things were very bare-bones before ES6. > 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 Interop with existing JS code/data(structures) will still be a problem. Shipping (or rather, not re-shipping every single time the user vists) your favorite language's runtime and standard library will become a problem (which can be solved). By that time JS will be good enough to make it even less worth it, especially for dynamic/GCed languages. > 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. This is true. There hasn't been anything new happening in node land for quite a while now, and the basic core platform is showing its age. With tools such as typescript, async/await and generators available, however, a revival is possible. TS tooling combined with a well designed and documented "core standard library" in the style of Dart's stdlib could make node a very nice platform again.
    - bpizzi 10y ago
      > 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. You focus too much on ES5. It's not about the language, it's the platform.
- sangnoir 10y ago
  > JS frameworks are so short-lived that one can't be sure if their code will still work in one year. Versioning your dependencies is good practice regardless of language and has been for decades. Javascript has enough cons, you don't have to resort to imaginary ones.
- bpizzi 10y ago
  > 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. Ok, so let me spell this out too (frameworks/librairies mixed): - jquery: 10 years - backbone: 6 years - angular v1: 6 years - ember: 5 years - react: 3 years Otoh, Qt5 with QML: 3 years. Quoting from wikipedia: > Qt 5 was officially released on 19 December 2012. This new version marked a major change in the platform, with hardware-accelerated graphics, QML and JavaScript playing a major role. The traditional C++-only QWidgets continued to be supported, but did not benefit from the performance improvements available through the new architecture.

by bpizzi 10y ago

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.
  - spion 10y ago
    > 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? Popularity, and the fact that things were very bare-bones before ES6. > 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 Interop with existing JS code/data(structures) will still be a problem. Shipping (or rather, not re-shipping every single time the user vists) your favorite language's runtime and standard library will become a problem (which can be solved). By that time JS will be good enough to make it even less worth it, especially for dynamic/GCed languages. > 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. This is true. There hasn't been anything new happening in node land for quite a while now, and the basic core platform is showing its age. With tools such as typescript, async/await and generators available, however, a revival is possible. TS tooling combined with a well designed and documented "core standard library" in the style of Dart's stdlib could make node a very nice platform again.
  - bpizzi 10y ago
    > 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. You focus too much on ES5. It's not about the language, it's the platform.
sangnoir 10y ago
> JS frameworks are so short-lived that one can't be sure if their code will still work in one year. Versioning your dependencies is good practice regardless of language and has been for decades. Javascript has enough cons, you don't have to resort to imaginary ones.
bpizzi 10y ago
> 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. Ok, so let me spell this out too (frameworks/librairies mixed): - jquery: 10 years - backbone: 6 years - angular v1: 6 years - ember: 5 years - react: 3 years Otoh, Qt5 with QML: 3 years. Quoting from wikipedia: > Qt 5 was officially released on 19 December 2012. This new version marked a major change in the platform, with hardware-accelerated graphics, QML and JavaScript playing a major role. The traditional C++-only QWidgets continued to be supported, but did not benefit from the performance improvements available through the new architecture.