[SonOfLilit]

PHP and Javascript both improved significantly, but both still have horrible legacy baggage that can't be rid of, namely weak typing (not dynamic, where a variable can hold any type, but weak, where "1"+2=3). For me, that makes programming in either language like running in a minefield. And still, I write Javascript daily, because myeusers don't care about weak typing :-)

[chrisweekly]

If you really care so much, why not simply embrace TypeScript?

[SonOfLilit]

Perhaps one day I will. When I last started a big JS project it wasn't mature enough to build a company around. This does seem to be changing.

[Kinrany]

TypeScript is awesome compared to JavaScript and even to other popular C-like languages. But it inherits all of the problems of the JS ecosystem without providing all of the benefits.

To make a JS package consumable by a reasonably strict TS project, someone has to basically rewrite the package. It's less effort than writing one from scratch, but it's not free.

[jt2190]

> To make a JS package consumable by a reasonably strict TS project...

I’m not sure what you mean by “strict” here... Certainly one can use JavaScript from TypeScript, and even provide type information for the JS with declaration files. [1] Does a “strict” project require something beyond this?

[1] “Declaration Files”, TypeScript Handbook https://www.typescriptlang.org/docs/handbook/declaration-fil...

[Kinrany]

Type information is easy to half-ass: list all the exports, mark them as 'string', 'Object', 'Function', done.

Adding the actually correct and reliable types is the hard part. (But easier than writing the code in the first place.)

[derangedHorse]

The typescript compiler can be a bit slow at times as well which dramatically lowers the developer experience when using typescript

[kmill]

Javascript is a lot saner than that. The result is "12". (I'm ok with automatic casting so long as it's an embedding. Every number has a reasonable string representation, but not vice versa. Wanting explicit casts like in Python is defensible, though.)

[SonOfLilit]

Huh, what do you know.

Still, this is unforgivable in my book:

  [] + {} == "[object Object]"
  {} + [] == 0

[kmill]

For the first, I frequently (for my own projects) change the Array prototype to have

   Array.prototype.toString = function () {
      return '[' + this.join(', ') + ']';
   };

It would be convenient if Object.prototype.toString by default threw an exception, since the default breaks the embedding rule I described.

The second example is misleading, and it has nothing to do with the rules for addition: the {} at the beginning of the expression is parsed as a code block, played off the rules for what the value of a Javascript statement is. More realistically, we have

   ({}) + [] == "[object Object]"

but the original is, effectively,

   {
   }
   console.log(+[]);

[SonOfLilit]

I didn't realise about the second one. Thanks!

[skykooler]

Thanks, I never realized that the second one was parsed as a code block rather than an object!

[z3t4]

Strong/weak and dynamic/static. JS is dynamic, but variables will always have a type, which is memory safe - which makes types strong.

[jt2190]

I’ve heard another definition of strong, which is that the compiler will make more guarantees, and in those cases the terminology was:

    * safe/unsafe
    * strong/weak
    * static/dynamic

Note that while safe/unsafe is basically all-or-nothing, strong/weak and static/dynamic are more of a spectrum, so JavaScript would be safe, weaker, and more dynamic than other languages. Typescript makes JS stronger when authoring code.

[z3t4]

Also sound/unsound

[Ndymium]

I thought weak/strong typing is more about how explicit/implicit type conversion is. In PHP and JS it's almost always implicit and they don't warn you for mixing most types, whereas e.g. Python will complain. That's one thing I don't enjoy with PHP/JS. A lot of certainty goes out of the window with it.

[wolco]

Everyone likes different things.

'1'+1=2 prevents a lot of errors. The languages tries to help you along compared to an harsh error. Maybe you want a harsh error.. halting everything until you declare a new variable with the same type and have to go through a manual conversion. For me let the language handle that. If you are tdding anything unexpected will be caught anyhow if you are worried how things convert.

It's like rust in terms of memory management vs c. It handles it for you..

[SonOfLilit]

Implicit string to number conversion is more like C in terms of memory management, in the sense that it's a huge footgun that you will definitely shoot yourself with. I have never seen it prevent errors, only make them worse by hiding them from QA so they can reach production and ruin your weekend.

[z3t4]

It's unfortunately in JS that + is used for both string concatenation and number addition. There are however defined rules that anything concatenated with a string becomes a string. And anything used with -/* > < becomes a number. As a beginner in JS I always used -- instead of plus when doing addition. But as I got more experienced I learned what was strings and what was numbers. And if I'm not sure I add an assertion - so that there will be an early error. I also parse all input (user input etc) not even a static strong type system will help you there, you always have to check/parse the input at runtime! JavaScript is strongly typed as in whatever the user inputs it will be converted to a type. JS don't have that many types and usually it becomes a string.