stackoverflow.com and other Stack Exchange websites

[SemiKebab]

stackoverflow.com (and the other websites of Stack Exchange)

These actions don't work at all:

• Actions on the left of the question and the answers: "Upvote", "Bookmark question", "Mark as accepted answer"…
• Links at bottom of the answers: "Add a comment" and "Show N more comments"

Error:

Code: Select all

SyntaxError: expected expression, got '.'

I think you have guessed the cause already…

[moonbat]

Yep, this regex parser has been a PITA for a long time and more sites are starting to use it now

[vannilla]

Yep, this regex parser has been a PITA for a long time

It's probably ?., not the regex thing.

[moonbat]

Is that a separate issue, or a problem with the site's javascript?

[Moonchild]

Is that a separate issue, or a problem with the site's javascript?

Both. It is a JavaScript issue but a separate one from the regular expression parsing thing in JavaScript.

?. is "optional chaining". It is a shorthand form for checking if an object exists/isn't null before using a sub-object or property of it.
i.e. to check if an object is not null and get a property (already using shorthand here):

Code: Select all

let value = object && object.toCheck;

with optional chaining is written as

Code: Select all

let value = object?.toCheck;

Because this is difficult to implement in our parser that doesn't expect such ambiguity in tokens, because both "?" and "." already have very defined meanings in the parser, we don't support it at the moment and have focused on other important JS issues first. It would actually have been better to use a different operator altogether (instead of ".") to indicate not throwing and instead return null if the object is null than to make this weird combination of operators. It would have been just as easy for introduction to the programming community, but also completely unambiguous for implementers.

In a lot of sites that actually do have this employed, its primary goal (to save keystrokes) is actually irrelevant because the JavaScript code tends to be generated by some framework, and in that case it just becomes an arbitrary decision by whomever builds the "package" to not target ES6/ES2017 level browsers.

[moonbat]

n a lot of sites that actually do have this employed, its primary goal (to save keystrokes) is actually irrelevant because the JavaScript code tends to be generated by some framework, and in that case it just becomes an arbitrary decision by whomever builds the "package" to not target ES6/ES2017 level browsers.

Like I always say, Chrome is increasingly looking like a make work program for web developers. Break perfectly functional code just to implement the latest shiny.

[Deadgye]

Because this is difficult to implement in our parser that doesn't expect such ambiguity in tokens, because both "?" and "." already have very defined meanings in the parser, we don't support it at the moment and have focused on other important JS issues first.
It would actually have been better to use a different operator altogether (instead of ".") to indicate not throwing and instead return null if the object is null than to make this weird combination of operators. It would have been just as easy for introduction to the programming community, but also completely unambiguous for implementers.

I believe the "?." operator has been part of other programming languages for at least 6 years. Kotlin refers to it as a "safe call" rather than "optional chaining" and there the operator choice is decently implicit and feels appropriate. But that's because Kotlin defines nullable data types separately, "String" vs "String?". Or, perhaps more importantly, because Kotlin doesn't have a conditional ternary operator.
It might seem like a lazy unnecessary operator, but it can improve readability so much when dealing with long chains.

I went to glance at the repo so I could make more-informed comments and it appears a brave soul has almost tackled this issue. Looking forward to the affected websites working again.

[Moonchild]

I believe the "?." operator has been part of other programming languages for at least 6 years.

Unfortunately that is irrelevant with respect to how difficult it is to implement in SpiderMonkey.

Also, "because other languages have it" has been the problematic reasoning behind why more languages have become obscenely complex because they want to do everything in every possible way instead of doing one thing and doing it well. JavaScript was never designed to be used for what it has been used for in recent days, and with the latest proposals it gets much worse as it tries to be more and more like a C-derivative. And engine implementations are expected to be able to adjust their interpreters and (JIT) compilers to match this shift... it becomes exponentially more difficult for each changed fundamental because you're not merely extending a language at that point, you're redefining the programming paradigms (or creating new ones!) instead.

Or, perhaps more importantly, because Kotlin doesn't have a conditional ternary operator.

Which takes away the parser ambiguity I talked about.
JS does have a ternary operator. So "?" is already a defined symbol. That makes implementing "??" and "?." and any other 2-letter operator that begins with the same character more complex because now it has to start looking ahead to see if it is a ternary or a different operator altogether (since they aren't extensions to the ternary behaviour).