16 ms·

This is a very solid foundation to work with, for anyone who might have struggled with the contexts and how arrow functions, local variables, thises (hah) and p

This is a very solid foundation to work with, for anyone who might have struggled with the contexts and how arrow functions, local variables, thises (hah) and prototypes fit into the bigger picture. It also clearly shows that Javascript is not the mess that it looks like from a beginner's perspective. Yes, anyone can create a 15-20 min video about how == and === can mess up stuff, how you cant just pass around a function with a this in it without being careful, how NaN is wtf, and all that jazz. But at the end of the day, stick to this language long enough and it works for you.

skocznymroczny 9y ago
I just wish Javascript had a standarized working module system that doesn't require external dependencies (webpack/rollup etc.)...
- fiala__ 9y ago
  It does now (ES2015 modules) but it was standardized too late, so people created their own solutions, and now it's super hard to implement the standard over them. That's why nodejs isn't transitioning to ES2015 modules anytime soon (although they're working on it).
sametmax 9y ago
Sure this car get dust on the ventilation, and you can mess up if you use the 3rd gear and you can't really use the blinkers without being careful and the seat warmers are wtf. But in the end of the day, stick to this car long enough and it works for you. Plus the most popular road of the world only accept this car so take it or leave.
- at-fates-hands 9y ago
  Not everybody can afford a Tesla or a BMW. For some of us, A Toyota Corolla or a Honda Accord is more than capable of getting the job done.
  - jjawssd 9y ago
    It is so tempting to poke holes in this analogy but in general I like it!
  - Scarbutt 9y ago
    Hey, Toyota and Honda are good quality cars, did you mean chevrolet, ford or renault?
    - Rapzid 9y ago
      Hey, I own a Fiesta SE and ST and they are great. Ford quality is way up.. Actually, maybe that's a perfect analogy for javascript :)
      - madhadron 9y ago
        That's because they're designed in Germany now.
    - codazoda 9y ago
      I've owned two generations of the Chevy Malibu. I'm pretty sure that's what he meant.
- sh87 9y ago
  I fail to get the flak that javascript faces ! Coming from java it was a breath of fresh air. This was the car that let me drive without a seatbelt when i wanted, let the doors be open if i wanted, stepping on the gas accelerated without fail and the brakes functioned fine, i could change the gearbox orientation, choose which side the steering wheel i wanted to be in general let me do what i wanted to without getting in my way. Sure it was not foolproof and i dont want it to be. I like JS just the way it is and I am grateful to it.
  - deleted 9y ago
    [deleted]
  - FLUX-YOU 9y ago
    >I fail to get the flak that javascript faces ! I personally don't like that Javascript has had to have a ton of work done on it to get it to the point of other languages that were better at their first release. It was just a ton of time spent on something that was weak to begin with. If Javascript were better at the beginning, and this same effort was spent on it, it probably would be ruling the world, front and back-end, and be a really good language with great tooling around it. There was a great amount of debate about nulls being a billion dollar mistake, but Javascript probably beats it in monetary damages by far.
    - sh87 9y ago
      Something wasn’t done right, right off the bat, thats grounds for not liking it, sure. But to dismiss it as immature despite it overcoming most (not all) of those flaws seems unfair. I like it, some dont. I get it. All I ask is to not dismiss it. Folks new to programming find these edge cases as a reason to not learn it. That irks me.
      - nightski 9y ago
        It has not overcome any of the flaws, we have just learned to work around them. They are still there and can bite you. Some of us value our time and would like to improve our discipline. In other fields it's called being professional. It's a shame we care so little about it.
macspoofing 9y ago
>It also clearly shows that Javascript is not the mess that it looks like from a beginner's perspective. Let's agree to disagree. I suspect your bar is too low. You could have made that argument for early versions of PHP (i.e. before 5)
- sli 9y ago
  Full disclosure: I've been writing JS for pretty much as long as I can remember and currently do it professionally, and I'm speaking mostly to my personal experience with having used both of them personally and professionally. The question is how often you get bitten in the ass by it, specifically as a professional rather than a beginner, and in my experience it's been very little with Javascript but quite often with PHP. Once you know a few things like the difference between == and ===, that undefined and null are different, etc., it's pretty easy to avoid the warts because the warts become obvious. I'm not going to argue that Javascript is well designed, it's really not, just that I rarely if ever run into the typical laundry list of gripes in such a way that it has a profound effect on my job. And having ESLint backing me up doesn't hurt, either. But that's not technically relevant. PHP, especially the older versions, contained many subtle traps you could easily fall into. For all of its flaws, I've never really felt the same about Javascript. More to the point, beginners are always going to stumble. It comes with the territory. I tend to focus my criticisms more on problems that knowledgeable programmers can stumble into accidentally rather than ones that are commonly met by new programmers, if that makes sense. The former seems like a far worse problem, because the former starts to touch (bear with me) "real" code. Just as an aside, the biggest single pain point for me when I still used PHP (a lifetime ago, now) was the way PHP used to report missing quotes extremely inaccurately. Egads that was an awful bug. I hope they fixed that. What it boils down to in my mind is, when I'm writing JS, I'm comfortable not having a linter available. I don't always feel the same way with PHP, because I don't feel like the traps are as easily avoided. I certainly don't think I'm some sort of Javascript guru, it's just that I don't have many problems with it in a purely practical sense when compared to PHP.
  - eropple 9y ago
    I think this is a fair way to read it. I have made my bones on ripping PHP and JS up and down, left and right; I didn't trust them as far as I can throw them. SPAs sucked because JavaScript sucked, and PHP sucks because its existence has put more frustrating work on my plate than anything else. I still feel that way about PHP. ES6 and ES2017 changed my mind about JS, though, along with the eventual maturity of the stack: babel, eslint, good testing in Jest. Everything I always hated about JS totally does still exist in its bowels, that's never going to change. But the guard rails have gotten very good and more modern flavors of JavaScript have added a lot of stuff that makes life easier (strongly opaque modules, async/await, and arrow functions are probably my top three). The build ecosystem is still bonkers, yeah--but there's a baseline level of sanity that I can work with. I know there are still land mines in there, but they're flagged and mostly out of the way. On the other hand, any time I'm stuck back in PHP, it is fundamentally the same stuff that has been sticking needles in me since I was in high school. Yeah, the language has advanced--but I'm not sure the general practice has advanced all that much, and the parts of the language that are problematic are right up in your face.
chubot 9y ago
I wonder why nobody has created a version of JavaScript that just throws exceptions for all the WTF cases? That is, it would basically be a mode like 'use strict-at-runtime'; . This would be incompatible, but it would be a useful development aid. Surely most frameworks like React and Angular avoid these corners of the language, and they could be trivially modified to run on such an interpreter? It would improve their code quality. I know this would be a large amount of work, but it doesn't seem that huge compared to all the other JavaScript infrastructure out there (parsers, transpilers, etc.). There are more independent JavaScript interpreters written than interpreters of any other language, AFAICT. At least before ES6, writing a JS interpreter was a one-talented-person project, not a huge team project like a JIT. I guess one reason is that the DOM and node.js bindings aren't easy to reproduce. But I would think people still run their unit tests in a limited environment and it would be useful for some code. It could even be based on narcissus -- JavaScript in JavaScript?
- baddox 9y ago
  I think the most common way to accomplish that idea is to run a linter. Linters should be able to statically catch most of the unsafe operations you're probably describing.
  - chubot 9y ago
    Yeah, that's probably true -- linters do an OK job at attacking this problem. But then there are still people complaining about JS semantics... I think there is a gulf between what tools professional JS programmers use, and what tools X programmers use when they write JavaScript, where X != JavaScript.
    - baddox 9y ago
      I think most JS fans these days recognize the inherent problems with JS, and work around them with best practices (on the lenient side) or linters and more advanced preprocessors like type checkers (on the strict side). At the end of the day, by far the main advantage of JS is the fact that there are mature and reliably-updated implementations with a relatively easy and open distribution platform on virtually every modern computing device (browsers and the World Wide Web). Some of the other fundamentals of the language are nice (particularly first-class functions), while the bad fundamentals (particularly the hopelessly messy type coercion) are now well-recognized and hopefully avoided through various techniques.
mvaliente2001 9y ago
I agree, this post is super-b, but it also shows why JS is the mess everybody knows it is. When you use a function as a constructor, the function creates an object and assigns as its __proto__ the value of the function's 'prototype', which is an object with the class' methods and that has an attribute 'constructor' that points back to the constructor function... and all that... for what? What purpose has this over-complex dance of references? Before trying to justify the current status quo, let's ask ourselves "could it be done easily?" The answer is a resounding yes. Javascript is a prototype oriented language (nothing wrong with that) who is ashamed of being prototype oriented and wanted to look object (class) oriented, and that's a shame. And of course, we have ECMA, a committee whose motto is "let's not change any past error no matter how flagrant it is, let's add just another layer of painting over it". That's why we have to live with hoisting and var/let, and crazy type conversions that are an affront to every living neuron in the universe, and typeof which return useless values, and yes, two comparison operators because the first one was worse than wrong.

skocznymroczny 9y ago

I just wish Javascript had a standarized working module system that doesn't require external dependencies (webpack/rollup etc.)...

fiala__ 9y ago
It does now (ES2015 modules) but it was standardized too late, so people created their own solutions, and now it's super hard to implement the standard over them. That's why nodejs isn't transitioning to ES2015 modules anytime soon (although they're working on it).

sametmax 9y ago

Sure this car get dust on the ventilation, and you can mess up if you use the 3rd gear and you can't really use the blinkers without being careful and the seat warmers are wtf. But in the end of the day, stick to this car long enough and it works for you. Plus the most popular road of the world only accept this car so take it or leave.

at-fates-hands 9y ago
Not everybody can afford a Tesla or a BMW. For some of us, A Toyota Corolla or a Honda Accord is more than capable of getting the job done.
- jjawssd 9y ago
  It is so tempting to poke holes in this analogy but in general I like it!
- Scarbutt 9y ago
  Hey, Toyota and Honda are good quality cars, did you mean chevrolet, ford or renault?
  - Rapzid 9y ago
    Hey, I own a Fiesta SE and ST and they are great. Ford quality is way up.. Actually, maybe that's a perfect analogy for javascript :)
    - madhadron 9y ago
      That's because they're designed in Germany now.
  - codazoda 9y ago
    I've owned two generations of the Chevy Malibu. I'm pretty sure that's what he meant.
sh87 9y ago
I fail to get the flak that javascript faces ! Coming from java it was a breath of fresh air. This was the car that let me drive without a seatbelt when i wanted, let the doors be open if i wanted, stepping on the gas accelerated without fail and the brakes functioned fine, i could change the gearbox orientation, choose which side the steering wheel i wanted to be in general let me do what i wanted to without getting in my way. Sure it was not foolproof and i dont want it to be. I like JS just the way it is and I am grateful to it.
- deleted 9y ago
  [deleted]
- FLUX-YOU 9y ago
  >I fail to get the flak that javascript faces ! I personally don't like that Javascript has had to have a ton of work done on it to get it to the point of other languages that were better at their first release. It was just a ton of time spent on something that was weak to begin with. If Javascript were better at the beginning, and this same effort was spent on it, it probably would be ruling the world, front and back-end, and be a really good language with great tooling around it. There was a great amount of debate about nulls being a billion dollar mistake, but Javascript probably beats it in monetary damages by far.
  - sh87 9y ago
    Something wasn’t done right, right off the bat, thats grounds for not liking it, sure. But to dismiss it as immature despite it overcoming most (not all) of those flaws seems unfair. I like it, some dont. I get it. All I ask is to not dismiss it. Folks new to programming find these edge cases as a reason to not learn it. That irks me.
    - nightski 9y ago
      It has not overcome any of the flaws, we have just learned to work around them. They are still there and can bite you. Some of us value our time and would like to improve our discipline. In other fields it's called being professional. It's a shame we care so little about it.

macspoofing 9y ago

>It also clearly shows that Javascript is not the mess that it looks like from a beginner's perspective. Let's agree to disagree. I suspect your bar is too low. You could have made that argument for early versions of PHP (i.e. before 5)

sli 9y ago
Full disclosure: I've been writing JS for pretty much as long as I can remember and currently do it professionally, and I'm speaking mostly to my personal experience with having used both of them personally and professionally. The question is how often you get bitten in the ass by it, specifically as a professional rather than a beginner, and in my experience it's been very little with Javascript but quite often with PHP. Once you know a few things like the difference between == and ===, that undefined and null are different, etc., it's pretty easy to avoid the warts because the warts become obvious. I'm not going to argue that Javascript is well designed, it's really not, just that I rarely if ever run into the typical laundry list of gripes in such a way that it has a profound effect on my job. And having ESLint backing me up doesn't hurt, either. But that's not technically relevant. PHP, especially the older versions, contained many subtle traps you could easily fall into. For all of its flaws, I've never really felt the same about Javascript. More to the point, beginners are always going to stumble. It comes with the territory. I tend to focus my criticisms more on problems that knowledgeable programmers can stumble into accidentally rather than ones that are commonly met by new programmers, if that makes sense. The former seems like a far worse problem, because the former starts to touch (bear with me) "real" code. Just as an aside, the biggest single pain point for me when I still used PHP (a lifetime ago, now) was the way PHP used to report missing quotes extremely inaccurately. Egads that was an awful bug. I hope they fixed that. What it boils down to in my mind is, when I'm writing JS, I'm comfortable not having a linter available. I don't always feel the same way with PHP, because I don't feel like the traps are as easily avoided. I certainly don't think I'm some sort of Javascript guru, it's just that I don't have many problems with it in a purely practical sense when compared to PHP.
- eropple 9y ago
  I think this is a fair way to read it. I have made my bones on ripping PHP and JS up and down, left and right; I didn't trust them as far as I can throw them. SPAs sucked because JavaScript sucked, and PHP sucks because its existence has put more frustrating work on my plate than anything else. I still feel that way about PHP. ES6 and ES2017 changed my mind about JS, though, along with the eventual maturity of the stack: babel, eslint, good testing in Jest. Everything I always hated about JS totally does still exist in its bowels, that's never going to change. But the guard rails have gotten very good and more modern flavors of JavaScript have added a lot of stuff that makes life easier (strongly opaque modules, async/await, and arrow functions are probably my top three). The build ecosystem is still bonkers, yeah--but there's a baseline level of sanity that I can work with. I know there are still land mines in there, but they're flagged and mostly out of the way. On the other hand, any time I'm stuck back in PHP, it is fundamentally the same stuff that has been sticking needles in me since I was in high school. Yeah, the language has advanced--but I'm not sure the general practice has advanced all that much, and the parts of the language that are problematic are right up in your face.

chubot 9y ago

I wonder why nobody has created a version of JavaScript that just throws exceptions for all the WTF cases? That is, it would basically be a mode like 'use strict-at-runtime'; . This would be incompatible, but it would be a useful development aid. Surely most frameworks like React and Angular avoid these corners of the language, and they could be trivially modified to run on such an interpreter? It would improve their code quality. I know this would be a large amount of work, but it doesn't seem that huge compared to all the other JavaScript infrastructure out there (parsers, transpilers, etc.). There are more independent JavaScript interpreters written than interpreters of any other language, AFAICT. At least before ES6, writing a JS interpreter was a one-talented-person project, not a huge team project like a JIT. I guess one reason is that the DOM and node.js bindings aren't easy to reproduce. But I would think people still run their unit tests in a limited environment and it would be useful for some code. It could even be based on narcissus -- JavaScript in JavaScript?

baddox 9y ago
I think the most common way to accomplish that idea is to run a linter. Linters should be able to statically catch most of the unsafe operations you're probably describing.
- chubot 9y ago
  Yeah, that's probably true -- linters do an OK job at attacking this problem. But then there are still people complaining about JS semantics... I think there is a gulf between what tools professional JS programmers use, and what tools X programmers use when they write JavaScript, where X != JavaScript.
  - baddox 9y ago
    I think most JS fans these days recognize the inherent problems with JS, and work around them with best practices (on the lenient side) or linters and more advanced preprocessors like type checkers (on the strict side). At the end of the day, by far the main advantage of JS is the fact that there are mature and reliably-updated implementations with a relatively easy and open distribution platform on virtually every modern computing device (browsers and the World Wide Web). Some of the other fundamentals of the language are nice (particularly first-class functions), while the bad fundamentals (particularly the hopelessly messy type coercion) are now well-recognized and hopefully avoided through various techniques.

mvaliente2001 9y ago

I agree, this post is super-b, but it also shows why JS is the mess everybody knows it is. When you use a function as a constructor, the function creates an object and assigns as its __proto__ the value of the function's 'prototype', which is an object with the class' methods and that has an attribute 'constructor' that points back to the constructor function... and all that... for what? What purpose has this over-complex dance of references? Before trying to justify the current status quo, let's ask ourselves "could it be done easily?" The answer is a resounding yes. Javascript is a prototype oriented language (nothing wrong with that) who is ashamed of being prototype oriented and wanted to look object (class) oriented, and that's a shame. And of course, we have ECMA, a committee whose motto is "let's not change any past error no matter how flagrant it is, let's add just another layer of painting over it". That's why we have to live with hoisting and var/let, and crazy type conversions that are an affront to every living neuron in the universe, and typeof which return useless values, and yes, two comparison operators because the first one was worse than wrong.