4 ms·

>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

>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.
- mvaliente2001 9y ago
  In my case, my problem is that I like clean languages, languages whose mental model I can keep in my mind. I found "== is broken, use === instead" a terrible way of designing a language. It should have been "== is broken, let's fix it today so tomorrow will be better for everybody." I can program in JS, and sometimes I even enjoy it. I had a friend who liked snakes and had several as pets, even some poisonous. I prefer kittens.
always_good 9y ago
It's hard for me to take these comments seriously unless you feel this way consistently across most other dynamically-typed languages -- at least it'd be consistent. I've used most dynamically-typed langs at this point and I've run out of reasons to use something aside from modern Javascript if I would have originally used Clojure or Ruby in the past. Though it feels sheepish to reward your low-effort comment with a response.
- Scarbutt 9y ago
  Curious, for server side, why do you prefer JS over Clojure? (I assumed by your comment that you would still prefer modern JS already knowing Clojure. Maybe I misinterpret?)
  - always_good 9y ago
    Right, I would generally prefer JS over Clojure on the server side these days. Or, rather, I would default to JS and then possibly disqualify it based on my needs (like team composition). I spent over three years using Clojure and eventually learned how unimportant technical superiority is for most of my projects. For example, the first time I met a co-founder and they simply weren't interested in using Clojure. Well, that was easy. JS has major upsides like ubiquity and I'm-already-using-it-in-the-browser and its simple concurrency model that aren't so easy to paint over. I'm not saying everybody should default to JS like I do. But I think a lot of these avoid-JS-at-all-costs posts need to update their intel. For example, JS has pretty great static analysis compared to anything I've used in the other dynamically-typed languages. It's also one of the few where gradual typing actually caught on. For all its upsides, its warts aren't any worse than things like the overuse of metaprogramming in Ruby or the aversion to FP in Python or the tooling dependencies of Clojure.
- eropple 9y ago
  I still find a lot of reasons to use Ruby, though like you I spend a lot of time doing JavaScript in places I wouldn't have a couple years ago. (For a long time I've been anything-but-JavaScript, but I was also using JavaScript before it was cool--somewhere on a hard drive somewhere is a JavaScript implementation I wrote as a scripting layer for a game I was working on in like 2006...) My experience with API design in JavaScript is that it still kind of sucks. It's not the worst, that wonderful spot goes to PHP, but it's distinctly harder to get something usable and maintainable done than Grape/Ruby. Probably worse than Flask/Python, too. The Swagger tools out there for JavaScript aren't very good and none of the lesser-used alternatives seem any better; maybe it's the stateful/metaprogramming-friendly nature of Ruby, but `grape-swagger` is really nice and nothing comes close in JS, at least not that I've found. Data representation worries me, too. I have not yet found a decent `grape-entity`/`representative` library in JS (think a `grape-entity` or a `representative`). On top of that, SQL library support out there is pretty bad, Sequelize being the best I've found but much worse than Ruby's Sequel or even ROM. Sequelize is still frustrating and clunky. I'm also uncomfortable dealing with money and financials in JavaScript, in part because of the lack of a BigDecimal/fixed class that I feel like I can trust (as I'm not really qualified to judge the implementations of the billion gems out there). A standard library I feel like I can trust is still out there, somewhere. If all I have to do is plop out an endpoint, then JS (shouts, Express!) is as easy as it gets, and that's fine. But these days I need more, I want my tools to help me with it, and I don't really have time or inclination to build them, either. If I'm missing any that are worth checking out, though, by all means, I'm very interested.

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.
mvaliente2001 9y ago
In my case, my problem is that I like clean languages, languages whose mental model I can keep in my mind. I found "== is broken, use === instead" a terrible way of designing a language. It should have been "== is broken, let's fix it today so tomorrow will be better for everybody." I can program in JS, and sometimes I even enjoy it. I had a friend who liked snakes and had several as pets, even some poisonous. I prefer kittens.

always_good 9y ago

It's hard for me to take these comments seriously unless you feel this way consistently across most other dynamically-typed languages -- at least it'd be consistent. I've used most dynamically-typed langs at this point and I've run out of reasons to use something aside from modern Javascript if I would have originally used Clojure or Ruby in the past. Though it feels sheepish to reward your low-effort comment with a response.

Scarbutt 9y ago
Curious, for server side, why do you prefer JS over Clojure? (I assumed by your comment that you would still prefer modern JS already knowing Clojure. Maybe I misinterpret?)
- always_good 9y ago
  Right, I would generally prefer JS over Clojure on the server side these days. Or, rather, I would default to JS and then possibly disqualify it based on my needs (like team composition). I spent over three years using Clojure and eventually learned how unimportant technical superiority is for most of my projects. For example, the first time I met a co-founder and they simply weren't interested in using Clojure. Well, that was easy. JS has major upsides like ubiquity and I'm-already-using-it-in-the-browser and its simple concurrency model that aren't so easy to paint over. I'm not saying everybody should default to JS like I do. But I think a lot of these avoid-JS-at-all-costs posts need to update their intel. For example, JS has pretty great static analysis compared to anything I've used in the other dynamically-typed languages. It's also one of the few where gradual typing actually caught on. For all its upsides, its warts aren't any worse than things like the overuse of metaprogramming in Ruby or the aversion to FP in Python or the tooling dependencies of Clojure.
eropple 9y ago
I still find a lot of reasons to use Ruby, though like you I spend a lot of time doing JavaScript in places I wouldn't have a couple years ago. (For a long time I've been anything-but-JavaScript, but I was also using JavaScript before it was cool--somewhere on a hard drive somewhere is a JavaScript implementation I wrote as a scripting layer for a game I was working on in like 2006...) My experience with API design in JavaScript is that it still kind of sucks. It's not the worst, that wonderful spot goes to PHP, but it's distinctly harder to get something usable and maintainable done than Grape/Ruby. Probably worse than Flask/Python, too. The Swagger tools out there for JavaScript aren't very good and none of the lesser-used alternatives seem any better; maybe it's the stateful/metaprogramming-friendly nature of Ruby, but `grape-swagger` is really nice and nothing comes close in JS, at least not that I've found. Data representation worries me, too. I have not yet found a decent `grape-entity`/`representative` library in JS (think a `grape-entity` or a `representative`). On top of that, SQL library support out there is pretty bad, Sequelize being the best I've found but much worse than Ruby's Sequel or even ROM. Sequelize is still frustrating and clunky. I'm also uncomfortable dealing with money and financials in JavaScript, in part because of the lack of a BigDecimal/fixed class that I feel like I can trust (as I'm not really qualified to judge the implementations of the billion gems out there). A standard library I feel like I can trust is still out there, somewhere. If all I have to do is plop out an endpoint, then JS (shouts, Express!) is as easy as it gets, and that's fine. But these days I need more, I want my tools to help me with it, and I don't really have time or inclination to build them, either. If I'm missing any that are worth checking out, though, by all means, I'm very interested.