5 ms·

I still do not understand the fascination with JavaScript. SPAs, desktop apps like Electron, server-side stuff with Node, I just don't get it. JavaScript is the

I still do not understand the fascination with JavaScript. SPAs, desktop apps like Electron, server-side stuff with Node, I just don't get it. JavaScript is the worst tool for the vast majority of these things. It brings us enough pain as the only practical client-side language on the web. Who deals with that and says "I need to write my server (or worse, desktop app) in this, and you know what, I'm going to now bastardize the entire web model with all this Angular cruft just for good measure"? Every time I try to get someone to explain it to me I'm just met with a bunch of empty answers like "Yeah it just flows really well man". It seems like the JavaScript Everywhere fad came into being solely to fulfill the need of a lot of novices to feel smug and important against more reasonable people, who are just left with puzzled looks.

lj3 10y ago
Javascript gets used everywhere because it successfully commoditized programming. It requires very little knowledge to get it to work, so anybody can pick it up without much effort. For businesses, this means an endless supply of cheap labor. Most people here on HN and elsewhere believe this is a good thing. It furthers their dreams of programming becoming a basic literacy, like english and math. Keep in mind I don't agree with the above at all, but this is what a lot of people believe.
- StavrosK 10y ago
  > Javascript gets used everywhere because it successfully commoditized programming PHP would like a word.
  - deleted 10y ago
    [deleted]
- nottorp 10y ago
  Reading "ElectronJS" is when i decided not to try this app. I don't need websites masquerading as desktop apps thank you.
  - allover 10y ago
    That seems like a very irrational reason for not using an app.
- cookiecaper 10y ago
  I don't think that JavaScript did that. I think web development in general did that, and continues to do that. JavaScript is only contributing insofar as JavaScript-based backends are inexplicably now becoming more employable than some much better alternatives (which not too long ago I would've also been deriding, but they look beautiful compared to node). Until recently, and I know the "front-end devs" are going to have my head for this, but until recently, there was hardly any serious JavaScript coding going on even on the client-side. That means it wasn't something that a new developer would really stumble across and just start using to build full-fledged programs. JavaScript's main use was extending web widgets to do things slightly more conveniently. All the heavy lifting would be behind the scenes and JavaScript would watch you type so it could autotab for you. So I don't think the explanation that there was a vast knowledgebase eager to break into the backend is plausible. JavaScript was so disliked from horrifyingly frustrating exposure throughout the IE6 days that no one would go near the thing unless they were wrapped in the jQuery condom. John Resig was a hero of legendary bravery for biting the bullet and making JavaScript semi-usable. Someone had to write a book called "JavaScript: The Good Parts" that openly acknowledged JavaScript's inherent inferiority but tried to cheer us up by saying "Hey, I know we're stuck with this because browser vendors will never be able to agree on something else, but there are some hidden cool things about it! Don't cry!" Somehow in the last 5 years or so, JavaScript has gone from something that required a prophylactic device before anyone would approach it to something that real companies are writing production _DESKTOP_ applications in. What the heck happened? (I think The Good Parts is probably the real turning point here, where it became OK to treat JavaScript as a non-joke, and that V8 accelerated it. But people took Crockford's feel-good apologia and ran way past the finish line with it.)
  - blub 10y ago
    If a company's doing web (as a lot are) they have processes and tools in place for that, so they would like to reuse them. These companies have also discovered that they can still hold on to most customers if they deliver merely adequate solutions. They will then naturally choose the convenient-for-them known quantity and dismiss concerns regarding usability, performance, etc. I don't see a real trend toward building apps using web technologies, but there is a lot of noise, making the topic seem larger than it is.
mamcx 10y ago
In all fronts is the worst, except easy of build a cross-platform GUI (not necessarily native looking!). The thing is that is easy to get the basic widgets cross-platform but in the moment you need custom widgets or easy styling html/css just is easier. I wish exist a native renderer that could use a (saner, better) subset of html/css that fit the same use case, then let us use any better language for the logic. Probably OpenGL toolkits are the idea, but it way to operate and looks are weird.
- cookiecaper 10y ago
  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.
      - 10y ago
bpizzi 10y ago
> It brings us enough pain as the only practical client-side language on the web. That's plainly wrong. The list of praticals client-side language on the web is actually pretty vast: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu.... Of course you can't write a piece of, say, typescript, and just include it in your HTML and call it a day. You need to compile it first, and you need some tooling for that, but it's not different from using a C++ compiler for building a Qt application. > Every time I try to get someone to explain it to me I'm just met with a bunch of empty answers like "Yeah it just flows really well man". Well, actually it flows really well indeed :)
- cookiecaper 10y ago
  It's different from using a C++ compiler to build a Qt application because it's in the opposite direction. Qt is a toolkit that lays on top of C++, which your compiler translates to machine code. Qt is still C++. Everything is the same language and gets compiled directly into the code that the machine knows how to execute. With JavaScript transpilers, this happens in reverse; there is an entirely separate secondary language loosely bolted on here, which compiles to JavaScript, which compiles to some IR, which compiles to machine code. From the developer point of view, the code they wrote in the top-level language executes as JavaScript, not native code, and must be debugged at that level. I'm sure you're not actually naive enough to pretend this is the same as using a library like Qt. Language semantics are very different and can be difficult and bug-prone to cross-implement. Third-party libraries and modules have large, potentially interdependent module webs that have to be resolved and will often result in massive includes on such transpiled pages (talking 10M+). Bugs at runtime will have to be debugged as the transpiled language, not as the code you originally wrote. If you use Qt, everything is written in the same language, built by the same compiler, and that language's typical pipeline, including dependency resolution, is unaltered. Bindings in non-reference languages link out to shared objects that do not use transpilation, but long-established and well-understood OS-level linking conventions. This is a greatly reduced complexity surface (== fewer bugs). My experience with transpilers is that people avoid them whenever possible because they introduce very intricate and difficult-to-use bugs. Now that I think of it, the most well-known transpilers are specially-made to service a large project's needs, like the recently-announced Grumpy [0], which converts YouTube's Python codebase to Go. [0] https://github.com/google/grumpy https://github.com/google/grumpy
spion 10y ago
"JavaScript is the worst tool". Ah, no matter how many times I see it, it never fails to rub me the wrong way for some reason. Its faster than Ruby, Python and PHP by a mile. It now has async/await. The amount of work that goes into making it good for front-end apps is amazing. It has a fairly large ecosystem. Dynamic / unityped nature lets you prototype quickly. Tooling such as TypeScript lets you switch to static types when being dynamic just wont cut it any longer. Oh, and TypeScript has generics! (can't believe thats still a differentiator in 2017) TypeScript can typecheck JSX templates. It has PureScript for when you want even stronger type-checking and abstraction powers. It doesn't have: multicore green threads (probably not going to happen) and large ints (coming soon). Here, have a look at https://facebook.github.io/reason/ https://facebook.github.io/reason/ and https://facebook.github.io/reason/modules.html https://facebook.github.io/reason/modules.html and see how many equivalent features it provides using just lexical closures and free-form objects (the TypeScript overlay can also approximate some features of algebraic datatypes via tagged unions and control flow analysis) Really, the JS sucks meme is getting old, fast. Sure there are more powerful languages and higher quality ecosystems, but its quite far from being "the worst".
- cookiecaper 10y ago
  Thanks, this is the most convincing response so far. In particular, I didn't realize how much faster V8 is than the reference implementations of similar languages. That can be a real and significant usage consideration and makes me less hostile to things like desktop apps. I've been operating from the "JS is slow" pre-V8 perspective, and while I knew V8 was a massive speed-up from the web perspective, I didn't consider that it was actually now among the fastest dynamic languages for non-web uses. That's a great point that should probably get promoted more often. I still dislike a great deal about the methods and culture in the community and wish that such optimization would be directed at what, in my mind, is a more worthy target, but I know of a concrete rationale now. Thanks!
  - spion 10y ago
    Its not just the speed. Have you looked at ES6 code? You will see a modern language with all the bells and whistles, including classes, lambdas, coroutines, template strings, a few other sugary features and a python-like module system. All the fixable weirdness has been fixed. Even `this` has been mostly fixed by arrow functions. It still has implicit conversions, but hey, typescript and flow make that irrelevant because they'd check statically for those. What else is so bad about JavaScript? I really don't get it. The DOM... thats another story.
charrondev 10y ago
I completely understand why people are moving to electron apps. Recently, I began work on what was to be a crossplatform desktop app, with a goal of being nice looking, and easy to use. Most of my previous experience was in android development, a little bit of web development (no applications though, only document based sites) and design work. I do most of my development work on a Mac so I decided I was going to start with a native Mac app (learning swift along the way) and then deal with the windows side later. Swift itself was very easy for me to pick up, but the rest of the experience was a nightmare. The application involved a few components that were going to be quite complex and I wanted many of the basic components to have slight customizations. This turned out to be quite a bit more difficult than I thought. The numerous issues that I encountered in 3-4 weeks (part time) of native development for MacOS included * Xcode support for swift is garbage. Highlighting, code completion, and general responsiveness are far lower than even web based editors. Also no refactoring. * Lack of documentation in swift + cocoa + appkit * Lack of documentation for swift 3. Many examples were from either iOS (not everything is equivalent) or from older versions of swift (a lot has changed in 2 years apparently). Even basics of naming have changed a good bit. * There was a lot of magic going on in xcode with storyboards / interface builder. When something broke it was very difficult to figure out what went wrong in the storyboard. The generated code from the storyboards is useless to look through. The difference between code working or not could be me forgetting to option + click a part of interface builder to a certain line in my code, with little or no indication of whether it had been done correctly, or what needed to go where, particularly with certain appkit components. * Dependancies are a heck a of a lot harder to manage. I don’t know why but I ended up using Cocoapods and it was a total mess. * Many core UI components requiring me to extend them or recreate them for basic functionality that would be a single line of code/xml/css on other platforms. Components that are common in other desktop applications don’t seem to be included in AppKit (some are including in UIKit though) I ended up scrapping the idea of doing it natively and decided on Electron + React + Typescript. It was a lot easier to aquire and intergrate dependencies, the development enviroment is a lot faster, there’s no magic connecting my UI together, and it’s actually easier to recreate customizable, native looking components with css + js than it seems to be in AppKit. On top of that I won’t have to build a seperate windows app. Realistically my app currently looks and performs better than any competing app (many of which are legacy java+swing apps) and is a lot faster to iterate on.

lj3 10y ago

Javascript gets used everywhere because it successfully commoditized programming. It requires very little knowledge to get it to work, so anybody can pick it up without much effort. For businesses, this means an endless supply of cheap labor. Most people here on HN and elsewhere believe this is a good thing. It furthers their dreams of programming becoming a basic literacy, like english and math. Keep in mind I don't agree with the above at all, but this is what a lot of people believe.

StavrosK 10y ago
> Javascript gets used everywhere because it successfully commoditized programming PHP would like a word.
- deleted 10y ago
  [deleted]
nottorp 10y ago
Reading "ElectronJS" is when i decided not to try this app. I don't need websites masquerading as desktop apps thank you.
- allover 10y ago
  That seems like a very irrational reason for not using an app.
cookiecaper 10y ago
I don't think that JavaScript did that. I think web development in general did that, and continues to do that. JavaScript is only contributing insofar as JavaScript-based backends are inexplicably now becoming more employable than some much better alternatives (which not too long ago I would've also been deriding, but they look beautiful compared to node). Until recently, and I know the "front-end devs" are going to have my head for this, but until recently, there was hardly any serious JavaScript coding going on even on the client-side. That means it wasn't something that a new developer would really stumble across and just start using to build full-fledged programs. JavaScript's main use was extending web widgets to do things slightly more conveniently. All the heavy lifting would be behind the scenes and JavaScript would watch you type so it could autotab for you. So I don't think the explanation that there was a vast knowledgebase eager to break into the backend is plausible. JavaScript was so disliked from horrifyingly frustrating exposure throughout the IE6 days that no one would go near the thing unless they were wrapped in the jQuery condom. John Resig was a hero of legendary bravery for biting the bullet and making JavaScript semi-usable. Someone had to write a book called "JavaScript: The Good Parts" that openly acknowledged JavaScript's inherent inferiority but tried to cheer us up by saying "Hey, I know we're stuck with this because browser vendors will never be able to agree on something else, but there are some hidden cool things about it! Don't cry!" Somehow in the last 5 years or so, JavaScript has gone from something that required a prophylactic device before anyone would approach it to something that real companies are writing production _DESKTOP_ applications in. What the heck happened? (I think The Good Parts is probably the real turning point here, where it became OK to treat JavaScript as a non-joke, and that V8 accelerated it. But people took Crockford's feel-good apologia and ran way past the finish line with it.)
- blub 10y ago
  If a company's doing web (as a lot are) they have processes and tools in place for that, so they would like to reuse them. These companies have also discovered that they can still hold on to most customers if they deliver merely adequate solutions. They will then naturally choose the convenient-for-them known quantity and dismiss concerns regarding usability, performance, etc. I don't see a real trend toward building apps using web technologies, but there is a lot of noise, making the topic seem larger than it is.

mamcx 10y ago

In all fronts is the worst, except easy of build a cross-platform GUI (not necessarily native looking!). The thing is that is easy to get the basic widgets cross-platform but in the moment you need custom widgets or easy styling html/css just is easier. I wish exist a native renderer that could use a (saner, better) subset of html/css that fit the same use case, then let us use any better language for the logic. Probably OpenGL toolkits are the idea, but it way to operate and looks are weird.

cookiecaper 10y ago
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.
    - 10y ago

bpizzi 10y ago

> It brings us enough pain as the only practical client-side language on the web. That's plainly wrong. The list of praticals client-side language on the web is actually pretty vast: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu.... Of course you can't write a piece of, say, typescript, and just include it in your HTML and call it a day. You need to compile it first, and you need some tooling for that, but it's not different from using a C++ compiler for building a Qt application. > Every time I try to get someone to explain it to me I'm just met with a bunch of empty answers like "Yeah it just flows really well man". Well, actually it flows really well indeed :)

cookiecaper 10y ago
It's different from using a C++ compiler to build a Qt application because it's in the opposite direction. Qt is a toolkit that lays on top of C++, which your compiler translates to machine code. Qt is still C++. Everything is the same language and gets compiled directly into the code that the machine knows how to execute. With JavaScript transpilers, this happens in reverse; there is an entirely separate secondary language loosely bolted on here, which compiles to JavaScript, which compiles to some IR, which compiles to machine code. From the developer point of view, the code they wrote in the top-level language executes as JavaScript, not native code, and must be debugged at that level. I'm sure you're not actually naive enough to pretend this is the same as using a library like Qt. Language semantics are very different and can be difficult and bug-prone to cross-implement. Third-party libraries and modules have large, potentially interdependent module webs that have to be resolved and will often result in massive includes on such transpiled pages (talking 10M+). Bugs at runtime will have to be debugged as the transpiled language, not as the code you originally wrote. If you use Qt, everything is written in the same language, built by the same compiler, and that language's typical pipeline, including dependency resolution, is unaltered. Bindings in non-reference languages link out to shared objects that do not use transpilation, but long-established and well-understood OS-level linking conventions. This is a greatly reduced complexity surface (== fewer bugs). My experience with transpilers is that people avoid them whenever possible because they introduce very intricate and difficult-to-use bugs. Now that I think of it, the most well-known transpilers are specially-made to service a large project's needs, like the recently-announced Grumpy [0], which converts YouTube's Python codebase to Go. [0] https://github.com/google/grumpy https://github.com/google/grumpy

spion 10y ago

"JavaScript is the worst tool". Ah, no matter how many times I see it, it never fails to rub me the wrong way for some reason. Its faster than Ruby, Python and PHP by a mile. It now has async/await. The amount of work that goes into making it good for front-end apps is amazing. It has a fairly large ecosystem. Dynamic / unityped nature lets you prototype quickly. Tooling such as TypeScript lets you switch to static types when being dynamic just wont cut it any longer. Oh, and TypeScript has generics! (can't believe thats still a differentiator in 2017) TypeScript can typecheck JSX templates. It has PureScript for when you want even stronger type-checking and abstraction powers. It doesn't have: multicore green threads (probably not going to happen) and large ints (coming soon). Here, have a look at https://facebook.github.io/reason/ https://facebook.github.io/reason/ and https://facebook.github.io/reason/modules.html https://facebook.github.io/reason/modules.html and see how many equivalent features it provides using just lexical closures and free-form objects (the TypeScript overlay can also approximate some features of algebraic datatypes via tagged unions and control flow analysis) Really, the JS sucks meme is getting old, fast. Sure there are more powerful languages and higher quality ecosystems, but its quite far from being "the worst".

cookiecaper 10y ago
Thanks, this is the most convincing response so far. In particular, I didn't realize how much faster V8 is than the reference implementations of similar languages. That can be a real and significant usage consideration and makes me less hostile to things like desktop apps. I've been operating from the "JS is slow" pre-V8 perspective, and while I knew V8 was a massive speed-up from the web perspective, I didn't consider that it was actually now among the fastest dynamic languages for non-web uses. That's a great point that should probably get promoted more often. I still dislike a great deal about the methods and culture in the community and wish that such optimization would be directed at what, in my mind, is a more worthy target, but I know of a concrete rationale now. Thanks!
- spion 10y ago
  Its not just the speed. Have you looked at ES6 code? You will see a modern language with all the bells and whistles, including classes, lambdas, coroutines, template strings, a few other sugary features and a python-like module system. All the fixable weirdness has been fixed. Even `this` has been mostly fixed by arrow functions. It still has implicit conversions, but hey, typescript and flow make that irrelevant because they'd check statically for those. What else is so bad about JavaScript? I really don't get it. The DOM... thats another story.

charrondev 10y ago

I completely understand why people are moving to electron apps. Recently, I began work on what was to be a crossplatform desktop app, with a goal of being nice looking, and easy to use. Most of my previous experience was in android development, a little bit of web development (no applications though, only document based sites) and design work. I do most of my development work on a Mac so I decided I was going to start with a native Mac app (learning swift along the way) and then deal with the windows side later. Swift itself was very easy for me to pick up, but the rest of the experience was a nightmare. The application involved a few components that were going to be quite complex and I wanted many of the basic components to have slight customizations. This turned out to be quite a bit more difficult than I thought. The numerous issues that I encountered in 3-4 weeks (part time) of native development for MacOS included * Xcode support for swift is garbage. Highlighting, code completion, and general responsiveness are far lower than even web based editors. Also no refactoring. * Lack of documentation in swift + cocoa + appkit * Lack of documentation for swift 3. Many examples were from either iOS (not everything is equivalent) or from older versions of swift (a lot has changed in 2 years apparently). Even basics of naming have changed a good bit. * There was a lot of magic going on in xcode with storyboards / interface builder. When something broke it was very difficult to figure out what went wrong in the storyboard. The generated code from the storyboards is useless to look through. The difference between code working or not could be me forgetting to option + click a part of interface builder to a certain line in my code, with little or no indication of whether it had been done correctly, or what needed to go where, particularly with certain appkit components. * Dependancies are a heck a of a lot harder to manage. I don’t know why but I ended up using Cocoapods and it was a total mess. * Many core UI components requiring me to extend them or recreate them for basic functionality that would be a single line of code/xml/css on other platforms. Components that are common in other desktop applications don’t seem to be included in AppKit (some are including in UIKit though) I ended up scrapping the idea of doing it natively and decided on Electron + React + Typescript. It was a lot easier to aquire and intergrate dependencies, the development enviroment is a lot faster, there’s no magic connecting my UI together, and it’s actually easier to recreate customizable, native looking components with css + js than it seems to be in AppKit. On top of that I won’t have to build a seperate windows app. Realistically my app currently looks and performs better than any competing app (many of which are legacy java+swing apps) and is a lot faster to iterate on.