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.
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?
But there are plenty of people who would recommend Python over JS as a first programming language for exactly this reason. Python gives better error messages and has fewer WTFs.
I think JS could be a good teaching language if it were not for the confusion over types, which is an important thing for a beginning programmer to understand.
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.
Google experimented with something they called "strong mode". Classes were read-only, accessing nonexistent properties was an error, and things like that.
I liked it. Unfortunately, the experiment didn't go anywhere and strong mode was removed from Chrome.
Dart is somewhat similar, though. It got more straightforward semantics than JS and most of those WTF things are an error.
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.
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.
They both more or less accidentally became popular. None of them were very well designed. They both lacked type safety.
Unlike php though javascript became not only popular but it actually ended up being the only alternative.
For some of us, A Toyota Corolla or a Honda Accord is more than capable of getting the job done.
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.
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)
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.
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.
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.
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.
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.
What text it does devote to Closures makes them sound like a "problem" to be worked around. Funny, I thought "this" was the problem (to be worked around, or avoided entirely whenever possible).
Class based languages such as Java do an excellent job of modeling how I thought about programming back in 1990. It's how we were taught in school, so as to be able to manage mutable data in a turing tar pit. (remembering a lecture about garbage collection, which essentially scoffed at the overhead...)
Having learned a good deal more about FP in the last 10 or 15 years (beyond the little bit of Lisp I did in an AI class back in the 80s), Javascript really starts to shine in many ways, whereas Java (and other [Simula67 subset] C++ derivatives) looks like the intellectual cripple in comparison.
I wish people would stop trying to turn Javascript into something more and more like C++/Java. Just stop, already. It was supposed to be like Scheme and/or Smalltalk, but The Management (marketing) got involved, and the rest is tragedy, er, history.
https://github.com/getify/You-Dont-Know-JS/blob/master/READM...
> ECMAScript is an object-oriented programming language, having concept of an object as its core abstraction.
This is technically correct but misses that Javascript is not OO in the way that many other languages are, but is instead prototypical in nature. That's an important distinction because creating long prototype chains in JS is a very bad and negative habit, where as the same behavior is absolutely fine in Java.
Anthony Alicea's Understanding Weird Parts of JS on Udemy was pretty good at introducing some of these concepts and I would have thought most people working with JS would be interested in finding out what's below the surface.
I'm curious as to whether or not this definition makes sense to other developers? ECMAScript does have a built-in "Object" data type, though I wouldn't say that this is it's "core abstraction". Further, firmly object-oriented languages, such as Java, seem to lack this abstraction. Perhaps I'm missing something in the definition?
(meanwhile, Scheming away in the background ...)
java isn't necessarily more object-oriented than other options. generally, i think when people say "oo", they're really just referring to nominal subtyping; probably due to the language's ubiquity (as well as c++ and c#).
this nominal subtyping gives rise to the hierarchical taxonomies of object-classes that are a quintessential characteristic of java, c# and friends.
There is also the big-"O" Object (sometimes called the "Object object," hah). This is a place to hang useful functions and also serves as the default prototype.
* IE11 isn't dead yet. MS still supports it.
* The "Nashorn" engine inside (Oracle) Java 8 only supports 5.1.
Scoff at them if you will, but some of us have to live with these things, and aren't using a transpiler.
Imagine being someone reading your post. What are they to think? "Oh, this person says X is worse than Y -- I'll go ahead and take their word for it, despite no justification"? That's them buying into an appeal to your authority.
Now imagine if you'd actually provided reasoning. "Oh, this person says X is worse than Y because Z -- Z is a good point, therefore this is useful!" How different.
Providing baseless opinions is not useful, which is why you got downvoted; and incidentally, it's the exact same reason why you should "care to elaborate".
Obviously not true. You just replied to the counterexample, where I did elaborate on my downvote.
