Seems easy, right? How about the below code, what will it print? new Promise((_, reject) => reject(new Error('woops'))). catch(error => { console.log('caught', err.message); }); It'll print out an unhandled rejection warning. Notice that err is not defined!

Good catch, @Hokascha. The project claims support for cross-domain iframes, but reading the docs reveals that it does still require server access to the embedded domain.

Notice the use of Enter key after backslash in the sed command.

we also wrap them in Failure to solve the second problem: spotting potential exceptions is hard

Almost everything in python can fail with different types of exceptions: division, function calls, int, str, generators, iterables in for loops, attribute access, key access, even raise something() itself may fail. I am not even covering IO operations here. And checked exceptions won’t be supported in the nearest future.

You still need to have a solid experience to spot these potential problems in a perfectly readable and typed code.

print will never be actually executed. Because 1 / 0 is an impossible operation and ZeroDivisionError will be raised.

If you teach your users to trust that URL bar is supposed to not change when they click links (e.g. your site uses a big iframe with all the actual content), then the users will not notice anything in the future either in case of actual security vulnerability.

Can we just forward/bubble all events emitted by the underlying input element?

Good risk management is inherently simple; adding too many complexities increases the likelihood of overlooking the obvious.

The problem I have with this approach to state and prop variables is that the difference between them is very blurry. In React you can clearly see that a prop is an input to component (because of clear function notation), and that state is something internal. In Svelte they are both just variables, with the exception that props use export keyword.

Just throwing in <div class="{$$props.class || ''} otherChildClass"></div> seems the easiest, and it'll avoid undefined classes. I feel like many aren't noticing the undefined values getting inserted in their classes.

I reckon that it was: less a communication failure more a failure to pay attention – no disrespect intended. Given the unfortunate coincidence, it's almost entirely understandable that everyone concerned lost sight of Mozilla's forewarning.