7 ms·

The people who hate javascript the most are the ones who wish it was something else. I used to be one of those people. Once I decided to accept it as it is an

The people who hate javascript the most are the ones who wish it was something else. I used to be one of those people. Once I decided to accept it as it is and read a few top books on the language to learn the "javascript way", my life got a lot better. It's really not that bad. I actually like it a lot, but there are still a lot of ignorant people who will look at you as if you're not l33t enough to know that foo language is better if you tell them you have a favorable view of js. Of the things on his list, the only ones that really resonate with me at all are verbose function syntax and silent coercion. Typing function () {} gets old fast, but then I set up snippets and it ceased being a problem. That really just leaves the type coercion problem, which you adapt to pretty quickly if you're using the language in earnest. What it boils down to is choosing to be a pragmatist who gets down to work with what's available instead of a naval gazer who swears everything will be awesome as soon as they have their preferred tool|language available. There are tons of compiles-to-js alternatives, but I don't see a huge difference in the productivity of people working in these not-JS alternatives. Where are the killer apps that were developed through a niche JS transpiler? If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate.

kenjackson 13y ago
If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a single language and seemingly little real effort to build a Multilanguage abstraction. If you told me 20 years ago about what the web would become, I'd be amazed. If you went on to say that all programming would be in a single language -- I'd think you were crazy, yet here we are. The web should have added 1st class support for plug-ins, rather than the direction we went to effectively abolish plugins from browsers.
- jmspring 13y ago
  Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.
  - kenjackson 13y ago
    JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.
    - _delirium 13y ago
      I probably wouldn't invent JS if I were tasked with coming up with a bytecode for the web. But how bad is it, on the overall scale of things? I mean, x86 is not a great ISA, and yet has prospered, despite some real nonsense corner cases and an anemic register set. Is JS bad as a bytecode the way that x86 is bad as an ISA, or bad at a different level?
      - AnthonyMouse 13y ago
        There is a degree to which you can make anything do anything. Using JavaScript as bytecode is actually really easy if you don't care about performance whatsoever. And if you get together a group of smart people who try very hard for a long time, I'm sure you could even get it to have reasonable performance. Especially if the people writing the interpreter are talking to the people writing the compiler. But why would you actually do that as a long-term solution? JavaScript isn't an ISA. It's not hard-coded into anything. You don't have to throw away all the existing JavaScript code to start supporting something else in addition to it. All you would have to do is write code to support whatever bytecode you actually want to use and contribute it to the major browsers.
        BugBrother 13y ago
Swizec 13y ago
Javascript's real problem is unfamiliar semantics hidden behind familiar syntax. It throws people off and they hate the language because they think it's weird. Really, they just haven't learned how to actually use it.
- gutnor 13y ago
  Javascript is a tiny language, but it pack a serious amount of gotcha. If you learn the javascript way, you just realise that the core language provide little to no tooling around it. Like if you really want to fully utilise the prototype based inheritance, or the functional aspect of the language, you will basically have to write a whole set of utilities and extension on your own. Of course, javascript run in the browser, is small and super simple, so it packs a lot of fun. To me it oddly reminds me toying with assembly in the old DOS 16 bit days and I like it despite its flaws ( and well those flaws are being addressed in latest iterations ) But the flaws are real, and if you need to use it on a big project with a regular team, and not complete freedom of choosing the browser you support, javascript will make you cry more often than smile.
  - flywheel 13y ago
    Considering the language was created in about a week, Javascript is nothing short of a computing miracle. It has enabled anyone with a web browser to write software that can run on billions of computers. And it is extremely easy to learn and use, with no boilerplate whatsoever. People who require the boilerplate to feel comfortable probably shouldn't use Javascript, and should have their heads examined.
  - nilliams 13y ago
    > Like if you really want to fully utilise the prototype based inheritance, or the functional aspect of the language, you will basically have to write a whole set of utilities and extension on your own. Hmm, this is definitely something of an exaggeration. With old-school cross-browser JS you just need something like Backbone's `extend` implementation (jashkenas posted a shorter example a while back [1]) for inheritance and underscore.js [2] for your functional aspects (assuming that's the sort of thing you mean). If your criticism is that those things had to be written, then this was solved with ES5 which gives you `Object.create` [3] for your inheritance needs and `map()`, `filter()` et al for your functional stuff. I certainly don't see why you'd ever need 'to write a whole set of utilities and extensions of your own', that reads like pretty hand-wavey and unfair criticism. > if you need to use it on a big project with a regular team, and not complete freedom of choosing the browser you support, javascript will make you cry more often than smile. I think you are depicting a pretty broadly-shit scenario that I don't think you can say any other language ecosystem deals with well. Trying to support many different clients is a nightmare across e.g. mobile and the desktop using any other language/ecosystem too, with same 'regular team'. And I don't agree there's anything particular about JS that will make you 'cry more often that smile' in that scenario, but that's obviously subjective. [1] https://news.ycombinator.com/item?id=7244023 [2] http://underscorejs.org/ [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create
teacup50 13y ago
> Where are the killer apps that were developed through a niche JS transpiler? If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. You're right about one thing: JavaScript is awful, but trying to avoid JavaScript while targeting a web browser is worse. I simply don't write software for the web. HTML/CSS/JS is too much of a train wreck of bad design for me to find any pleasure whatsoever in the task, and I'm content leaving the job anyone that can stomach it. However, if we followed your argument to its conclusion, we'd never escape the atrophied staleness of a browser technology core that somehow has never moved past 1995-era Netscape.
rdtsc 13y ago
I think it comes down to two things. * Acknowledging that it has many many warts. Weak types, modularity, every number is a double, etc. some of those warts are there. Explaining why they are there historically doesn't make them go away either. "Oh but it was only written in 1 month so.." -- "Yeah it is still broken". Many things can be chucked to "not broken but different". But, some are just broken, no sane language released after 1990's should not be this broken unless it was on purpose (brainfuck). * Realizing that in practice, currently, there are not too many alternatives and just learning to use it. Like you say just getting down to being pragmatic. One can talk about functional purity but that doesn't usually bring food to the table. A finished site does. But you see how the two are different. Many confuse them. For example, saying the language is fine and great just because they learned it and are using it. Yeah, at some level we want to feel good about the tools we use, so it is harder psychologically to say "this stupid thing I have to use every day". It goes the other way, just because the language is broken and there is some pure language, re-writing the site into might be very risky. I personally am looking at Dart with excitement but at the same time won't be urging anyone yet at work to switch to it yet. Kind of a chicken and egg problem, I understand, we just can't afford to take that risk yet. But with time who knows.
deleted 13y ago
[deleted]
Peaker 13y ago
IMO the biggest problem, even worse than type coercions, is the error silencing regarding wrong argument counts. This can easily hide so many bugs, it's amazing it is acceptable to anyone.
- Kiro 13y ago
  Do you have an example?
  - Peaker 13y ago
    Call a function "foo" that expects 3 arguments with 5 or 2 arguments, instead. Javascript will gladly accept that and not yield any error, not just at compile-time, but even at run-time! Unless the function explicitly checks that the argument list is correct, it will simply hide the bug. When changing function signatures in any language, it is the programmers' collective responsibility to fix all callers (some of which in the same working tree, some hidden in others' branches, etc). In a static-language, it is very easy, you get compile-time errors at some point. In dynamically typed languages, it is slightly harder -- you get an error (ideally under a test suite) and fix it there. In Javascript you get cryptic bugs. No compile-time error. No run-time error. Happy debugging!
    - LunaSea 13y ago
      How is that an issue ?
      - Peaker 13y ago
        How is a common change (updating a function signature) easily causing cryptic bugs rather than a visible compile-time or run-time error an issue? Bugs are bad?
  - implicit 13y ago
    Guess the result of this fragment: ["1", "2", "3"].map(parseInt)
camus2 13y ago
> The people who hate javascript the most are the ones who wish it was something else. Ask yourself,how can a single language can fit every use cases,for every developpers? We cant agree on what we should use on the server,but we are basically forced to use 1 language in the browser,of course some people are going to hate it. I shouldnt have to adapt javascript,javascript should adapt my coding style.But aint gona happen. Weak typing and Type coercion are imho the biggest flaw of javascript,I can live with the rest,but not that. Proxies will help a bit though.Devs will definetly abuse them.
Aardwolf 13y ago
> verbose function syntax I didn't agree with that one myself. I mean, ok, now we have C++11 and can just type [](){} for inline lambda functions, but before C++11 you needed a huge amount of boilerplate to pass a function to something. JavaScript's way to just type "function something" inline was so non-verbose and convenient compared to that. So what is it being compared to instead here? Functional programming languages?

kenjackson 13y ago

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a single language and seemingly little real effort to build a Multilanguage abstraction. If you told me 20 years ago about what the web would become, I'd be amazed. If you went on to say that all programming would be in a single language -- I'd think you were crazy, yet here we are. The web should have added 1st class support for plug-ins, rather than the direction we went to effectively abolish plugins from browsers.

jmspring 13y ago
Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.
- kenjackson 13y ago
  JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.
  - _delirium 13y ago
    I probably wouldn't invent JS if I were tasked with coming up with a bytecode for the web. But how bad is it, on the overall scale of things? I mean, x86 is not a great ISA, and yet has prospered, despite some real nonsense corner cases and an anemic register set. Is JS bad as a bytecode the way that x86 is bad as an ISA, or bad at a different level?
    - AnthonyMouse 13y ago
      There is a degree to which you can make anything do anything. Using JavaScript as bytecode is actually really easy if you don't care about performance whatsoever. And if you get together a group of smart people who try very hard for a long time, I'm sure you could even get it to have reasonable performance. Especially if the people writing the interpreter are talking to the people writing the compiler. But why would you actually do that as a long-term solution? JavaScript isn't an ISA. It's not hard-coded into anything. You don't have to throw away all the existing JavaScript code to start supporting something else in addition to it. All you would have to do is write code to support whatever bytecode you actually want to use and contribute it to the major browsers.
      - BugBrother 13y ago

Swizec 13y ago

Javascript's real problem is unfamiliar semantics hidden behind familiar syntax. It throws people off and they hate the language because they think it's weird. Really, they just haven't learned how to actually use it.

gutnor 13y ago
Javascript is a tiny language, but it pack a serious amount of gotcha. If you learn the javascript way, you just realise that the core language provide little to no tooling around it. Like if you really want to fully utilise the prototype based inheritance, or the functional aspect of the language, you will basically have to write a whole set of utilities and extension on your own. Of course, javascript run in the browser, is small and super simple, so it packs a lot of fun. To me it oddly reminds me toying with assembly in the old DOS 16 bit days and I like it despite its flaws ( and well those flaws are being addressed in latest iterations ) But the flaws are real, and if you need to use it on a big project with a regular team, and not complete freedom of choosing the browser you support, javascript will make you cry more often than smile.
- flywheel 13y ago
  Considering the language was created in about a week, Javascript is nothing short of a computing miracle. It has enabled anyone with a web browser to write software that can run on billions of computers. And it is extremely easy to learn and use, with no boilerplate whatsoever. People who require the boilerplate to feel comfortable probably shouldn't use Javascript, and should have their heads examined.
- nilliams 13y ago
  > Like if you really want to fully utilise the prototype based inheritance, or the functional aspect of the language, you will basically have to write a whole set of utilities and extension on your own. Hmm, this is definitely something of an exaggeration. With old-school cross-browser JS you just need something like Backbone's `extend` implementation (jashkenas posted a shorter example a while back [1]) for inheritance and underscore.js [2] for your functional aspects (assuming that's the sort of thing you mean). If your criticism is that those things had to be written, then this was solved with ES5 which gives you `Object.create` [3] for your inheritance needs and `map()`, `filter()` et al for your functional stuff. I certainly don't see why you'd ever need 'to write a whole set of utilities and extensions of your own', that reads like pretty hand-wavey and unfair criticism. > if you need to use it on a big project with a regular team, and not complete freedom of choosing the browser you support, javascript will make you cry more often than smile. I think you are depicting a pretty broadly-shit scenario that I don't think you can say any other language ecosystem deals with well. Trying to support many different clients is a nightmare across e.g. mobile and the desktop using any other language/ecosystem too, with same 'regular team'. And I don't agree there's anything particular about JS that will make you 'cry more often that smile' in that scenario, but that's obviously subjective. [1] https://news.ycombinator.com/item?id=7244023 [2] http://underscorejs.org/ [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create

teacup50 13y ago

> Where are the killer apps that were developed through a niche JS transpiler? If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. You're right about one thing: JavaScript is awful, but trying to avoid JavaScript while targeting a web browser is worse. I simply don't write software for the web. HTML/CSS/JS is too much of a train wreck of bad design for me to find any pleasure whatsoever in the task, and I'm content leaving the job anyone that can stomach it. However, if we followed your argument to its conclusion, we'd never escape the atrophied staleness of a browser technology core that somehow has never moved past 1995-era Netscape.

rdtsc 13y ago

I think it comes down to two things. * Acknowledging that it has many many warts. Weak types, modularity, every number is a double, etc. some of those warts are there. Explaining why they are there historically doesn't make them go away either. "Oh but it was only written in 1 month so.." -- "Yeah it is still broken". Many things can be chucked to "not broken but different". But, some are just broken, no sane language released after 1990's should not be this broken unless it was on purpose (brainfuck). * Realizing that in practice, currently, there are not too many alternatives and just learning to use it. Like you say just getting down to being pragmatic. One can talk about functional purity but that doesn't usually bring food to the table. A finished site does. But you see how the two are different. Many confuse them. For example, saying the language is fine and great just because they learned it and are using it. Yeah, at some level we want to feel good about the tools we use, so it is harder psychologically to say "this stupid thing I have to use every day". It goes the other way, just because the language is broken and there is some pure language, re-writing the site into might be very risky. I personally am looking at Dart with excitement but at the same time won't be urging anyone yet at work to switch to it yet. Kind of a chicken and egg problem, I understand, we just can't afford to take that risk yet. But with time who knows.

deleted 13y ago

[deleted]

Peaker 13y ago

IMO the biggest problem, even worse than type coercions, is the error silencing regarding wrong argument counts. This can easily hide so many bugs, it's amazing it is acceptable to anyone.

Kiro 13y ago
Do you have an example?
- Peaker 13y ago
  Call a function "foo" that expects 3 arguments with 5 or 2 arguments, instead. Javascript will gladly accept that and not yield any error, not just at compile-time, but even at run-time! Unless the function explicitly checks that the argument list is correct, it will simply hide the bug. When changing function signatures in any language, it is the programmers' collective responsibility to fix all callers (some of which in the same working tree, some hidden in others' branches, etc). In a static-language, it is very easy, you get compile-time errors at some point. In dynamically typed languages, it is slightly harder -- you get an error (ideally under a test suite) and fix it there. In Javascript you get cryptic bugs. No compile-time error. No run-time error. Happy debugging!
  - LunaSea 13y ago
    How is that an issue ?
    - Peaker 13y ago
      How is a common change (updating a function signature) easily causing cryptic bugs rather than a visible compile-time or run-time error an issue? Bugs are bad?
- implicit 13y ago
  Guess the result of this fragment: ["1", "2", "3"].map(parseInt)

camus2 13y ago

> The people who hate javascript the most are the ones who wish it was something else. Ask yourself,how can a single language can fit every use cases,for every developpers? We cant agree on what we should use on the server,but we are basically forced to use 1 language in the browser,of course some people are going to hate it. I shouldnt have to adapt javascript,javascript should adapt my coding style.But aint gona happen. Weak typing and Type coercion are imho the biggest flaw of javascript,I can live with the rest,but not that. Proxies will help a bit though.Devs will definetly abuse them.

Aardwolf 13y ago

> verbose function syntax I didn't agree with that one myself. I mean, ok, now we have C++11 and can just type [](){} for inline lambda functions, but before C++11 you needed a huge amount of boilerplate to pass a function to something. JavaScript's way to just type "function something" inline was so non-verbose and convenient compared to that. So what is it being compared to instead here? Functional programming languages?