25

It seems to me that, despite being one of the world's most used languages, even some of the leading experts of JavaScript like Doug Crockford think JavaScript suffers from some pretty big design flaws (JavaScript: The World's Most Misunderstood Programming Language) that make development confusing and ambigious.

Programming languages and development tools are always getting better and make it much easier for developers to make things. There's a new version of .NET every few years, new version of HTML5 with new tags, new versions of CSS, etc.

Why hasn't there been a better version of JavaScript or another dynamic loosely typed language, but without all the design flaws, come out to supercede JavaScript?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
RoboShop
  • 2,770
  • 6
  • 29
  • 38
  • 7
    It's a bit unfair to use Doug Crockford as an argument here, because he's a very vocal *fan* of JavaScript, at least of the good parts :) And getting rid if the bad parts is, after, all, his job in the ECMA committee. – balpha Jul 06 '11 at 14:08
  • 1
    No new version of Javascript? Isn't the Ecmascript 5 spec just two years old? – user16764 Jul 06 '11 at 17:24
  • 4
    Inertia I guess. I sure wouldn't choose javascript if there was any other reasonable choice. After working with other languages desktop side, going into javascript is like having to go back to FORTRAN or COBOL. Certainly doable, but seems more painful than it should be. – Brian Knoblauch Jul 06 '11 at 19:29
  • Because all the choices that the stodgy types like Brian are more comfortable with couldn't handle the problem. And the problem was big. Don't write to a JVM but instead write to like 6-20 browsers several of which refuse to agree on what your code actually means. JS is powerful and Crockford either understands a lot less about JavaScript than he knows about JavaScript or he's just doing his part to get the old guard to pay for seats at his speaking engagements. – Erik Reppen Dec 20 '12 at 06:44
  • Isn't Wasm (https://webassembly.org/) aiming to open up the browser to other languages? – Thomas Junk Sep 19 '22 at 13:04
  • Apple and Google and therefore the majority of browsers have highly optimised versions of JavaScript. I don't know what Google does, but Apple has one interpreter and three compilers that are used one after the other to create JavaScript that is not much away from compiled C# or Swift code. (The last pass uses the full Clang compiler with highest optimisation). Can you imagine how happy they will be if you ask them to do the same work again? – gnasher729 Sep 20 '22 at 15:54

6 Answers6

22

Two words: "Browser Support". Javascript is interpreted by the web browser, so if we were to use a different client-side scripting language, every browser would have to implement support for it. Obviously some browsers would lag behind others and developers would avoid using the language because only a fraction of their potential users would be able to use their application. So, as you can see, there are considerable economic impediments to using anything other than Javascript (or even a newer version of JavaScript). Actually, at this time, there have been newer "official" versions of JavaScript released. However, the only browser that supports then is Mozilla Firefox.

Zhehao Mao
  • 883
  • 4
  • 6
  • 4
    Actually IE tried to start down a path of fixing JS the result was IE 6... – SoylentGray Jul 06 '11 at 14:38
  • Okay, yeah, I've removed that statement. – Zhehao Mao Jul 06 '11 at 16:26
  • You forgot to mention that there are newer versions of _ECMAScript_ mainly EcmaScript5 and that's a significant improvement on EcmaScript3 as a language. All modern browsers support it (Apart from Opera :() – Raynos Jul 09 '11 at 02:39
14

All languages suffer from design flaws. The flaws in Javascript aren't all that serious. Messy type handling (can be circumvented), False/Null/undef/zero/NaN silliness (can be still grasped), "+" for concatenation (perfectly manageable), semicolon insertion (just be cautious) - nothing critical overall.

On the other hand, the language is incredibly extendable. Unlike in other OO languages where you are stifled by class-based inheritance/extensiblity, in JS you are free to extend/modify an instance of an object on the fly. It has a very friendly learning curve - the entry level is very easy, and there's lots and lots to be explored and learned over time. It's the entry level javascript (and the stupid name) that makes people believe it's a toy language. It is not. The advanced features allow you to modify the syntax, the essence of the language so much, that you adapt it to your needs and then achieve desired results in several simple, straightforward lines of (perfectly clear) new syntax. It works very well both for sequential programming and for event-driven interfaces. It integrates with web environment very well.

...also, what other client-side language would you suggest for WWW? Visual Basic? As long as Javascript is the only widely supported browser-side language, any questions "why people still use it" are quite misplaced.

SF.
  • 5,078
  • 2
  • 24
  • 36
  • 6
    There's nothing wrong with + for concatenation, at least not by itself. It only becomes problematic when you add type coercion into the picture. – Mason Wheeler Jul 06 '11 at 16:37
  • 1
    I have never been a huge fan of Crockford's assertion that the language is flawed. Sure, type coercion can be problematic if you don't understand that it will occur, but is that a design flaw of the language or simply ignorance on the part of the developer struggling with the difficulties that it can sometimes cause? Again, if you know what you are doing, these "issues" are not really issues. JavaScript is a great language, it's too bad it's taken this long for people to start appreciating it for what it is, instead of what people assume it to me. :) – Jason Bunting Jul 06 '11 at 17:35
  • By the way, I wish I could up-vote your answer 10 times - you are spot-on. – Jason Bunting Jul 06 '11 at 17:36
  • 14
    @Jason: When the majority of new developers have the same "difficulties" with the same "issues" over and over again, IMO that's when it's safe to call it a language flaw. – Mason Wheeler Jul 06 '11 at 20:40
  • 1
    @JasonBunting: There's nothing wrong with type coercion *in cases where it's clearly and unambiguously going to occur*. If a language used `$` as a string concatenation operator which was defined as coercing operands to strings, then I would have no problem with it allowing `"count=" $ it.count` without requiring `it.count` to be explicitly converted to a string. On the other hand, the fact that one cannot tell whether x+y will coerce either operand to string without knowing the operand types is, IMHO, a sign of dubious design. – supercat Jul 20 '14 at 16:10
  • @MasonWheeler - we'll just have to disagree. Millions think Britney Spears is a great musician/artist... does that make it so for everyone? No. – Jason Bunting Nov 10 '15 at 20:51
  • @supercat - if the code one has written or is reading is so complex and opaque that one doesn't know the types of a given pair of operands, that's not the problem of the language, that's the problem of the one who wrote the crappy code, IMO – Jason Bunting Nov 10 '15 at 20:52
  • @JasonBunting: How is the author of a function supposed to know the types of the arguments that will be passed to it? In JS, a lot of code will--almost by default--work in many cases where numbers are passed where strings are expected, or where strings which contain representations of numbers are passed where numbers are expected, but fail with certain combinations of numbers and strings. Such semantics are generally far more trouble-prone than semantics where different types are independently accepted or rejected. I'm reminded of MS text-to-speech... – supercat Nov 10 '15 at 21:08
  • ...which would if I recall pronounce "12/10/15" as "December 10, 2015" but "13/10/15" as "October 13, 2015". I would suggest that it would be more helpful to have the latter read in a manner that would distinguish it from "10/13/15". – supercat Nov 10 '15 at 21:13
  • @supercat - in the 10 years since I first began writing non-trivial JavaScript applications, I've rarely had an issue. By the way, they are called opinions for a reason, because they are not the same as "facts." I'm not going to say your points are invalid, per se, I just don't have the same problem with them that you do, that's all. It's okay, we're not in a competition. I just don't see the problems so many people do. I write my code semantically, which means I rarely don't know the type expected. `firstName` would be a string. `dateOfCreation` would be a date. etc. – Jason Bunting Nov 17 '15 at 21:42
  • @JasonBunting: It doesn't cause problems terribly often, but one may end up with situations where code which takes a value from an input field without converting it to a number will mostly work but sometimes fail in bizarre fashion if the first operation most functions do with a passed-in number happens to be something other than addition. – supercat Nov 17 '15 at 23:52
  • @Jason All language flaws can be overcome by adopting coding habits that nullify their impact. It doesn't mean there are no flaws or they are not flaws. It just means efficient workarounds have been found. – SF. Nov 18 '15 at 11:30
8

It works, and it's widely supported. The language itself is quite powerful and supports a wide variety of paradigms (functional, OOP, etc.). It also has an built in API to the DOM, making it very easy to manipulate a page - after all, that's what it was designed to do!

Also, libraries like jQuery are making it much easier to code JavaScript without worrying about browser compatibility. Since, until HTML5 becomes mainstream, JavaScript is the only way to dynamically manipulate web pages on the browser side, people are still focused on making it better and easier. And even after HTML5 is broadly accepted, many people will still be using browsers that don't support it. So many companies won't switch because they would lose a large number of customers.

Despite its supposed deficiencies, JavaScript is the only client-side browser language we have, and will have for a while. It's going to be around for a long time.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Michael K
  • 15,539
  • 9
  • 61
  • 93
  • 1
    Saying that JavaScript "is also tightly coupled with the DOM" is a stretch - the language itself, in its pure form, couldn't care less about the DOM. That's why it can be used for so many other things than merely DHTML. Too often programmers confuse an API for built-in functionality of a language; that confusion is, in fact, one of the reasons _why_ JavaScript has such a bad reputation. – Jason Bunting Jul 06 '11 at 17:32
  • 1
    @Jason That's true, it's not really a tight coupling - JS doesn't require DOM any more than the DOM requires JS. I've edited my answer. – Michael K Jul 06 '11 at 17:37
4

I think there's a few reasons.

Backwards compatibility is probably key. When IE had 90%+ market share, it would make sense for alternative browsers (Firefox, Opera) to continue to use JavaScript. It would have been a tougher uphill battle if Firefox came out with something totally different.

It's a standard. There's an overlord out there (ECMA) that says what JavaScript actually is. The web happens to like this kind of thing, especially in revolt to IE being "the bully".

Of course, this doesn't get into the the IE vs. Netscape war that put JavaScript in such a mess.

Jeremy
  • 4,791
  • 1
  • 25
  • 40
  • Technically, ECMA only defines what ECMAscript actually is. JavasSript itself was defined by Netscape, and now by the Mozilla foundation. Addmittedly in common useage nobody but Mozilla actually claims comformance to specific versions of JavaScript, but instead talk about conformance to specific versions of ECMAScript which is continueing to absorb most of the extentions to the core language. (DOM extentions being out of scope of course). – Kevin Cathcart Jul 06 '11 at 18:30
4

Increasingly, we don't. The popularity of all-inclusive libraries (such as jQuery), as well as languages that compile to JavaScript (such as CoffeeScript) has been steadily growing. Yes, JavaScript is still the language that gets interpreted, but I consider it analogous to writing in C, and compiling to machine code.

That said, there are many people out there who wish to understand JavaScript itself, either for the purpose of improving the previously mentioned libraries and languages (and the use thereof), or because they don't want the overhead of libraries like jQuery.

Ryan Kinal
  • 1,481
  • 10
  • 14
  • 5
    Although you really need to know Javascript to write good JQuery, IMO. – Michael K Jul 06 '11 at 14:19
  • 4
    -1 jQuery is a Javascript library. It simply wraps several handy methods into its libraries. With out JS we have no jQuery – SoylentGray Jul 06 '11 at 14:41
  • 2
    +1 for recognizing that libraries are creating an interpreted language on top of JS. Yes, JS is still the 'assembler' of the web, but how much assembler do you actually write these days? – Alex Feinman Jul 06 '11 at 15:18
  • Indeed, jQuery is a JavaScript library, and if you know JavaScript, then you will write better jQuery. However, jQuery encourages structures and design patterns that JavaScript doesn't, and so (at the very least) can be considered a "dialect" of JavaScript. Pure JavaScript can also be considered a "dialect" (as can "The Good Parts", or prototype.js, or any number of other subsets or libraries. – Ryan Kinal Jul 06 '11 at 15:45
  • 1
    I can't imagine writing anything more than basic jQuery without a good knowledge of JavaScript. To be clear, jQuery covers two areas, and two areas alone: the DOM and AJAX. Sure, there are utility functions. But if you write anything that's even moderately complex, you quickly find out that the DOM and AJAX are not sufficient for many situations. They were never designed to be. – Reid Jul 06 '11 at 16:00
  • @Alex no JS is not the assembler of the web. JS is interpreted by the browser. Assembler is machine language it works directly with the machine. It doesnt care what your OS is it just executes instructions. And the language you use to call the jQuery is javascript. It calls javascript and returns back to javascript. It never goes outside of javascript. It is not a dialect, they are prepackaged methods of javascript. But they are all intepreted not compiled. – SoylentGray Jul 06 '11 at 16:38
  • 3
    @Chad: I think you are taking the comments about JavaScript being "the 'assembler' of the web" too literally; it was merely an analogy. Maybe a bad analogy, but an analogy nonetheless. :) – Jason Bunting Jul 06 '11 at 17:39
  • 1
    JS is interpreted by the browser. It doesn't care which browser (given modern architectures, and forgiving a few bugs), it just executes instructions. Writing in jQuery (or prototype.js or MooTools or CoffeeScript) simplifies a lot of the lower-level interaction necessary when writing JavaScript. Lastly, there are several languages that *are* compiled into JavaScript - like the aforementioned CoffeeScript and the Google Web Toolkit (Java to JavaScript). – Ryan Kinal Jul 06 '11 at 17:40
  • 3
    I like jQuery & I use jQuery. However, this idea that jQuery isn't, somehow, JavaScript, drives me nuts. It's a library built-on and for use-in JavaScript. If you don't know JavaScript, you're not going to be able to exploit the power of the language sufficiently to make jQuery as awesome as it can truly be. Those using jQuery that don't understand how jQuery & JavaScript actually work, and don't know how to extend either of them, are like children playing with letter blocks of the alphabet, not realizing the power those letters have, when combined, to create words which can change our world. – Jason Bunting Jul 06 '11 at 17:46
  • I definitely agree. But it is *fully possible* to write an application using jQuery (and its plugins) without knowing a scrap of JavaScript. It may be bloated and inefficient, but it's possible. jQuery is JavaScript, but you write code using jQuery differently than you would write code without jQuery. – Ryan Kinal Jul 06 '11 at 17:50
  • 1
    @Jason Exactly. But saying that javascript is assembler and that using jQuery is not using javascript are the fallacies that I was trying to correct. @Ryan I guess you can say compiled though I dont really like that word. The javascript is built but not really compiled as compiling indicates something that is at least somewhat optimized for execution. Javascript is not. It is interpreted at runtime. Some of us old farts that have coded in assembler get picky about these distinctions. – SoylentGray Jul 06 '11 at 17:57
  • @ryan no it is not possible to write an applcation using jQuery with out knowing any javascript. Because calling the method is javascript. All jQuery does is wrap some commands the way it is written is telling javascript to use the jQuery library for the method. But that is javascript notation but the definition for the ($ or jQ or whatever) identifier you use is all javascript. jQuery instructions are just javascript method calls. They do not just look kinda like them that is what they are. I dont not know what I can say to get this point through. jQuery is great. but it is javascript. – SoylentGray Jul 06 '11 at 18:04
  • 3
    Yes. jQuery is JavaScript. Woo. *bored now* – Ryan Kinal Jul 06 '11 at 18:57
2

While its absolute ubiquity within web browsers and web applications is the root cause of JavaScript sticking around in spite of its not-good parts, that same ubiquity has led to it receiving the attention of some of the best software engineers. The end result is that we get ultra-fast JIT compilers and runtime engines, making JavaScript one of the not the best-performing dynamic languages available.

Also, it's not such a bad language. EVERY language has flaws, and to use any of them well, you need to know their strengths, weaknesses and foibles.

Adam Crossland
  • 9,688
  • 2
  • 35
  • 46