Yeah, remember the left-pad incident? It took until ECMAScript 2017 to make such a simple function part of the standard library. Things are slowly getting better, but JS is still rather lacking compared to "batteries included" languages like PHP and Python.
It is true that now, 22 years after JavaScript emerged as a toy language to allow people to do simple UI tricks like creating alert boxes, and 8 years after people started trying to shoehorn it into the backend for GCool Points, JS has finally started to adopt some useful features. ES6+ address most of the glaring omissions, and writing a script in JS/Node now doesn't feel too much different than writing a script in Python or Ruby (though much more build infrastructure is required; JavaScript is anything but native outside of the browser). Bolting on those features that have been available in other languages for much longer is a big accomplishment from the ECMAScript people, so props to them.
But there are still many instances of people "fighting the language" in the practical sense (the sense that matters). Two main exhibits: Node's "harmony" feature release model that requires the VM to be run with certain flags to enable certain syntax (much worse than Python's `from __future__` model) as well as Babel's entire existence and widespread usage.
I don't know how often you use other languages, but JavaScript is the only platform where I have to run my code through a chain of slow, third-party transformers just to use simple language features like constants with confidence.
Separately, the standard lib is bare and implementations remain inconsistent, requiring everything to be built on struts like lodash and jQuery (with tons of random dangling accouterments pulled from random GitHub repos, a la `left-pad`) that paper over JS's major pain points and general impracticality. Other scripting languages have convenience libraries and wrappers, even alternative implementations, but nothing else goes to the extremes we see in npm, where it's quite common to pull in single convenience functions as libraries.
While these things may not be quite fighting the "language" from the stringent academic perspective of the ECMAScript spec, they do represent practical constraints on virtually all real-world use. Just as you'd be crazy to try to use JavaScript without jQuery back in the day, you'd be crazy to use it now without the huge amalgam of crap people have developed (babel, lodash, webpack, yarn, etc.) because they are so inexplicably committed to shoving the square peg of JS through the round hole of server-side programming.
Agree. JS standard library has been very immature and was so slow to improve as it was primarily targeted for browser and people thought that wasn't the place to do complicated stuff, not even md5.
I still have some array helper methods just to shuffle array or randomly pick one.
Not any time soon, certainly. But it really should do. It's a language that was designed hastily and without a solid foundation. That was no big deal at the time, but it causes a horrible loss of quality and productivity now that it has become one of the most-used programming languages in the world.
JavaScript has a quirky and highly dynamic type system, with lots of edge cases that can cause surprises. See the famous "WAT?" presentation for some examples, though that was only a few minutes long and so could only scratch the surface.
JavaScript has awkward syntax, which makes it unnecessarily difficult to write tools and libraries to support it, as well as creating unusual complications like ASI.
Modern JavaScript is trying to be half-imperative, half-OO and half-functional programming, and there isn't enough sensible grammar to go around. This makes various idioms you'd often use in each style in other programming languages awkward in JS, while at the same time not providing some of the best features found in languages more specialised for each style.
JavaScript has a tiny standard library, and what it does have has plenty of inconsistencies and quirks. This, more than anything else, has led to a catastrophically complicated landscape of large JS programs importing on hundreds of relatively small libraries via transitive dependencies, in a tangled mess that probably no-one has ever even looked through on most projects. That's how you get the left-pad fiasco, but more generally, it's a staggering hit on productivity because everyone has to jump through hoops to do even quite simple tasks and often people choose to jump through slightly different sets of hoops that get a similar end result, so now you have multiple ways of doing the same things in your code and extra bloat in your build. It's also a legal and security nightmare just waiting to happen.
TypeScript inherits almost all of the above. It does improve on the type checking, obviously, but even there its type system is actually unsound because its developers made the choice to prefer JS compatibility rather than a completely foolproof type checker. I think that was a reasonable choice, but it doesn't change the fact that the one big feature TS brings to the table is actually flawed because of its JS legacy.
None of this should be surprising to anyone who programs JS/TS regularly, but since my previous comment got heavily downvoted I feel the need to defend it with more concrete and objective criticisms.
Given the importance of web development in the modern software landscape, I truly believe that adopting much better languages -- languages designed carefully, built on solid theoretical foundations, learning the lessons from decades with JS and other programming experience since JS was created, equipped with a good standard library and essential tools -- could bring a qualitative improvement in many important respects, particularly productivity and reliability, across what is now a vast part of the software industry.
I'm not crazy and have no illusions that this will just magically happen tomorrow, but with the advent of WASM, there is at least a chance that with a big backer or two behind it, something new might have a shot at becoming established and, in time, attracting enough support to take over.
If only we could scrap the whole ecmascript thing and force everyone to implement a language that wasn't fundamentally broken for anything more complicated than slapping event handlers on buttons.
Every language has it, but because JavaScript is evolving so rapidly the problem is amplified. We've seen more change in the last couple of years than some more mature languages have seen in the last decade - js isn't finished, and I don't think it ever should be.
On the plus side, it keeps us employed as long as we are prepared to keep learning the new stuff, or earn a spectacular exit.
I love where JS is heading, but perhaps its worth pointing out its a lot easier to rapidly advance a language that historically has been missing huge features.
I would love to see a nicer language replace JavaScript as much as the next guy, but it seems rather unlikely especially given the changes that ECMA has approved in the past.
I am really hoping that some day, we will be able to do front-end devwork that isn't just an abstraction of JS/HTML/CSS.
I think that's neither here nor there. JavaScript has a lot of strengths that few other languages can claim at this point, thanks to how universal it is. Many people understand it, it can be used to build everything from desktop apps to mobile apps to servers, and it has one of the largest package repositories out there.
I'm far from a JS fanboy but I think your point lends credence to the idea of using JS more than it strengthens the use of Emacs Lisp.
Yes, I've been developing websites since before JS existed, so it does in fact make me happy that JS has made some progress related to developer productivity in 20 years. Are they adding other baggage? It seems so, but the addition of a standard library is a things well past its time.
This. The tooling and development environment for JavaScript has improved by leaps and bounds. As an early adopted I found JS to be a pain in the ass. These days I dare say it's one of my favourite languages.
The reality of the situation is that JavaScript was designed at a time when there was NO CLUE that it would become the de-facto client-side language for decades.
So now the ECMAScript standard is pushing JavaScript towards a "proper" language, but we need additional tools (TS, Babel, etc) to write in an even more "proper" language/syntax that will give us something that the browser still needs to understand (JavaScript).
This isn't a fun process for those of us who have been developing a long time. Look, JavaScript has classes! And modules! Ok, that's good I guess, we're getting there. But that's not learning, that's just getting closer to something we are already familiar with as software engineers.
I agree that JavaScript got much better but I still feel like updating the DOM by hand is still too cumbersome to forego using a library or a framework.
Whenever I write an app with just regular JavaScript I find that I always end up creating an immature library for DOM manipulation.
In a year or two we are hopefully going to see a whole new Javascript (it's already happening now with ES6). For a language that was cobbled together in about a week, it's actually not the massive train-wreck people make it out to be. Sure it might not do things in a pure code way, but you could argue that about languages like PHP as well and at the end of the day it doesn't make them any less usable.
I think Javascript has reached a point where the good developers know of its weaknesses and limitations and thus, they hardly ever encounter them. I can't honestly remember the last time I ran into an issue that was a result of the way Javascript implemented something. In the right hands like anything, Javascript can be a decent language. Combined with something like ESLint and superset like TypeScript, you'll never write bad Javascript again (well it is very unlikely).
reply