4 ms·

I'm not surprised that the architecture isn't new, I'm surprised that web apps were already being talked about this way using JS specifically. JS's early design

I'm not surprised that the architecture isn't new, I'm surprised that web apps were already being talked about this way using JS specifically. JS's early design flaws are often written off as, "well it was never intended to be a real programming language like it is today". But from reading this, that doesn't sound to be the case.

ChrisSD 6y ago
I think JS' early design flaws were a result of being written in a day more than anything to do with a specific purpose (I exaggerate but not by much). Though it is true that most people at the time used JS (if they used it) for much simpler tasks than described in the article.
- jrumbut 6y ago
  I think in some ways the problems people have experienced come back to a language design that is fairly ambitious. Specifically the inclusion of a prototype OO system is confusing if you aren't aware what that is and have only been exposed to Java-like OO programming. But in fact it's very powerful and not so hard to learn once you realize you have to. As with other web technologies, it's simple at first glance but the learning curve gets steeper at some point.
- blululu 6y ago
  It was written in 9 days, which is astounding. I suspect that the project was given a week to complete and it came 2 days late. In any case it seems unlikely that it’s problems would go away if given another 5 days. A lot of the wired things in a scripting language only become obvious at scale.
tracker1 6y ago
I don't so much think of them as flaws... the first use case was form validation, and most of the fuzzy type coercion makes a ton of sense through that lens, where ''. 0, etc. coercion to falsy is easy for dealing with user input. It's also why it's one of my favorite options for ETL workloads. It's just a matter of understanding the langauge. That said, it's been my favorite language since well before the "good parts" book.
- brundolf 6y ago
  I use JS every day; I would say I like it. I would even say that in 2020, if you know what you're doing, it's a pretty good language on the whole. But I don't think it's controversial to say that the following were objectively bad decisions (in hindsight, of course, but still): - Automatic casting behavior between the core types (you're the only person I've ever heard suggest that this might be a good thing) - Automatic semicolon insertion - A core Date object that lacks basic control over time-zones and reasoning about time-zones - Assigning to an undeclared variable silently creates a global - Allowing duplicate function parameter names where later ones just hide the earlier ones - Distinction between undefined and null (this one might have a few defenders) Some of these are now prevented by "strict mode". Others have been patched-over, for example by the addition of === which prevents casting behavior for comparisons at least. Others can be bridged by libraries (Moment.js) or by best-practices (use foo == null to smooth over the null/undefined distinction, never use a value's implicit falsiness in a conditional, etc). But the point is that JavaScript has this giant asterisk that will never go away, of things you need to do/avoid/utilize in order to get the most basic behaviors right.
  - dragonwriter 6y ago
    > Automatic casting behavior between the core types This is (mostly) awesome for quick/light glue scripting and a (almost entirely) a horrible pain for most other programming. As the scale of JS apps has gone up, this has gone from probably being a net win from the way JS was used early on on the web to being a net harm. > Distinction between undefined and null This existence of this distinction is, IMO, a very good thing, but there's some big ergonomic issues with the implementation. (The rest of your list I agree with.)
    - sergeykish 6y ago
      Netscape 2.0: "foo" - 1 //raises "is not a numeric literal" "" == false //raises "is not a numeric literal" "foo" + new Object() //"foonull" "foo" + new Array() //"foonull" 0 + true //1 0 + false //0 1 + new Array() //raises "null is not a number" new Object + new Object //raises "null is not a number" true.foo //raises "true has no properties" 1..foo //raises "1 has no properties" Ten days language was not that silent.

ChrisSD 6y ago

I think JS' early design flaws were a result of being written in a day more than anything to do with a specific purpose (I exaggerate but not by much). Though it is true that most people at the time used JS (if they used it) for much simpler tasks than described in the article.

jrumbut 6y ago
I think in some ways the problems people have experienced come back to a language design that is fairly ambitious. Specifically the inclusion of a prototype OO system is confusing if you aren't aware what that is and have only been exposed to Java-like OO programming. But in fact it's very powerful and not so hard to learn once you realize you have to. As with other web technologies, it's simple at first glance but the learning curve gets steeper at some point.
blululu 6y ago
It was written in 9 days, which is astounding. I suspect that the project was given a week to complete and it came 2 days late. In any case it seems unlikely that it’s problems would go away if given another 5 days. A lot of the wired things in a scripting language only become obvious at scale.

tracker1 6y ago

I don't so much think of them as flaws... the first use case was form validation, and most of the fuzzy type coercion makes a ton of sense through that lens, where ''. 0, etc. coercion to falsy is easy for dealing with user input. It's also why it's one of my favorite options for ETL workloads. It's just a matter of understanding the langauge. That said, it's been my favorite language since well before the "good parts" book.

brundolf 6y ago
I use JS every day; I would say I like it. I would even say that in 2020, if you know what you're doing, it's a pretty good language on the whole. But I don't think it's controversial to say that the following were objectively bad decisions (in hindsight, of course, but still): - Automatic casting behavior between the core types (you're the only person I've ever heard suggest that this might be a good thing) - Automatic semicolon insertion - A core Date object that lacks basic control over time-zones and reasoning about time-zones - Assigning to an undeclared variable silently creates a global - Allowing duplicate function parameter names where later ones just hide the earlier ones - Distinction between undefined and null (this one might have a few defenders) Some of these are now prevented by "strict mode". Others have been patched-over, for example by the addition of === which prevents casting behavior for comparisons at least. Others can be bridged by libraries (Moment.js) or by best-practices (use foo == null to smooth over the null/undefined distinction, never use a value's implicit falsiness in a conditional, etc). But the point is that JavaScript has this giant asterisk that will never go away, of things you need to do/avoid/utilize in order to get the most basic behaviors right.
- dragonwriter 6y ago
  > Automatic casting behavior between the core types This is (mostly) awesome for quick/light glue scripting and a (almost entirely) a horrible pain for most other programming. As the scale of JS apps has gone up, this has gone from probably being a net win from the way JS was used early on on the web to being a net harm. > Distinction between undefined and null This existence of this distinction is, IMO, a very good thing, but there's some big ergonomic issues with the implementation. (The rest of your list I agree with.)
  - sergeykish 6y ago
    Netscape 2.0: "foo" - 1 //raises "is not a numeric literal" "" == false //raises "is not a numeric literal" "foo" + new Object() //"foonull" "foo" + new Array() //"foonull" 0 + true //1 0 + false //0 1 + new Array() //raises "null is not a number" new Object + new Object //raises "null is not a number" true.foo //raises "true has no properties" 1..foo //raises "1 has no properties" Ten days language was not that silent.