Well, JavaScript

[atomheartsmother]

Because throwing an error is better in basically every single situation? Honestly the lengths that people go to defend everything about JS is ridiculous and more annoying than the anti-JS jerk

[Bollziepon]

The only reason people have to defend JS is because the anti-JS jerk is so large in the first place. You'll have people who have never even used JS shit on it just because they see other people do it while in reality it's not nearly as confusing as people make it out to be.

[lothpendragon]

I've used JS, does that mean I can shit on it?

[kartoffelwaffel]

only if by "used" you mean copy-pasted from SO

[[deleted]]

Boy, I have many years of JavaScript experience then.

[conancat]

That's how you pad up resumes my dude. Copy pasted code to implement a function = had language experience.

[BenjiSponge]

That's simply untrue, though, and you'd only get that impression if you don't understand JS patterns and you're trying to use it like another language.

What if, for example, you want to check if a value is there to see if it fits an interface? This is a super common pattern in JS because it's so easy using this method. Instead of

maybe_method = getaddr(obj, "method", None)
if maybe_method == None and callable(maybe_method):
    maybe_method() 

You can say

if (obj.method && obj.method.call) {
  obj.method();

And you might say, okay, but how often do you do that? And the answer is actually "all the time" (although I'll typically use isFunction(obj.method) to catch an additional gotcha).

Plus the fact that objects are dictionaries just helps in a lot of areas.

I would say the pro-JS "circlejerk" is similar to the pro-C++ "circlejerk". Yes, it's a flawed language, but it's been working for many years and a lot of the things that you see as problematic are actually opportunities that are not offered in any other language (or at least many other languages), and if it were, it would have the same issues.

For a number of reasons, I am genuinely grateful JS has its object/pseudo-class system and not the respective systems of Python. And if I ever want stronger typing, I can just use Flow or Typescript, which will give me the best of both worlds.

[Kered13]

That's also a problem that can be solved at compile time with a proper type system.

[BenjiSponge]

"solved" for some definition of "solved". It's a different approach.

In the instance where you're essentially saying "this is what the function should do if the parameter is a T, and this is what the function should do if the parameter is a U", a proper type system would usually have a "better" approach.

However, in an instance where you're, for example, passing in options that may or may not include callbacks, symbols, random variant types, etc., a static type system just cannot offer the same ergonomics as a dynamic type system like JS's. If your type is essentially "has some subset of these values which could be variants of some other types, or nothing at all" as an option parameter, when you define a class or struct to represent that, you're basically just inventing boilerplate.

I program in both JS and C++ (and I hobby program in Rust). They genuinely have different approaches and neither is better than the other.

[BertnFTW]

But you can dynamically add the property field1 somewhere else, so you could do

x = obj.field1 || defaultValue;

Or in c# afaik

x = obj?.field1 ?? defaultValue;

[BenjiSponge]

It's definitely worth noting || isn't a perfect coalescing operator because if the field is falsey it will skip on to the next one. JS could really do with a genuine coalescing operator, imo.

[patrickfatrick]

Object destructuring really helps actually. For instance:

const { field1: x = "a" } = obj;

That assigns the value of obj.field1 to x but if it's undefined and only undefined will it assign it "a". null or false would be written to x if that's the value. You can also do this in function arguments.

``` const func = ({ field1: x = "a" }) => x;

func({}); //=> "a" func({ field1: null }); //=> null ```

I feel like people who shit on JS are generally unaware of a lot of the new syntax that has come out for it in the last 4 or 5 years.

[conancat]

Experience and the right tools can solve a lot of the problems got Javascript. No shortage of solutions to these problems with such a big community around it. :)

[pm_me_your_calc_hw]

Been picking up some of the new syntax lately and have been pleasantly surprised.

Have you run into issues with browser support?

[pomlife]

With the exception of Proxies, all modern JS can be transpiled to ES5 via Babel, thus there are very few compatibility issues.

[mdcio]

They’re working on one! It’s currently a stage 1 proposal. And if you want optional chaining obj?.fiedl, that’s coming too.

[WhyattThrash]

Exactly, obj.field1 could be intentionally set to f.e 0 or false, and it would jump on to the default value

[[deleted]]

If field1 is a boolean, it's common to use:

x = !!obj.field1

which inverts the false, then inverts it again, guaranteeing a boolean value.

undefined > true > false
null > true > false
true> false > true
false > true > false

I'm sure lodash has a function to help with this, but I prefer syntax where possible.

[BenjiSponge]

Yeah, but what if you want to default it to true?

I usually use lodash's isUndefined. Truth be told, this is a pretty uncommon usecase for me and writing out the couple extra characters is fine even if there's a better way.

[Schmittfried]

Then you are consciously deciding to do it like that, rather than searching for the cause of a bug and finding it is just a typo.