ui so you don't need to hand edit the URL
parsing variants of github urls so folks don't always have to get the raw url themselves
automatic conditional formatting (background colors) (also via query param)
I'd like to clarify: that my job was also to educate, modernize, and improve developer velocity through tooling and framework updates / changes (impacting every team in my department (UX / frontend engineering)).
Reviewing tests is part of PR review.
--- and before anyone asks, this is my statement on CrowdStrike calling everyone disgruntled:
"I'm not disgruntled.
But as a shareholder (and probably more primarily, someone who cares about coworkers), I am disappointed.
For the most part, I'm still mourning the loss of working with the UX/Platform team."
If we were to try implementing everything as reactive versions, there'd be be no end, and implementations couldn't keep up -- by pushing reactive Map/Set/etc to userland/library land, we can implement what we need when we need it incrementally, built on the solid foundation of the signal primitives.
> since non-deep is an optimization that can lead to accidental inconsistent state.
conversely, deep-all-the-time is a performance hit that we don't want to be default. Svelte and Ember take this approach of opt-in-deep reactivity.
Vue reactivity isn't compatible with Svelte, nor Angular.
As a counter example to your question, what if we all had competing implementations of the object primitive. Libraries would barely work with one another and would need an interop layer between them (just as reactivity layers do today!)
I'll admit I don't use JavaScript very often, but surely the state of polymorphism could be improved? For example, C++ recently added concepts, and most (modern) languages have some way to describe interfaces.
As to your counterexample, I agree with current JavaScript that would be a problem, but with good language support it would certainly be possible. For example, Rust (and C++?) have competing implementations of the global allocator, and must users will never notice.
The reactivity layers are all pretty tied into the hearts of the frameworks. There's no advantage to any framework to expose such a thing to end users to leverage a competing implementation.
As for polymorphism, even the current class syntax largely operates in the same way as the original prototypal inheritance mechanism, with a few exceptions in constructor behavior to support subclassing certain built-in objects.
You can pretty easily create run-time traits- like functions with prototpyes, the class construct is an expression whose resulting value can be passed around, mutated, etc.
For example, you can write a function that takes a class as an argument, and returns a new class that extends it.
Sorry there was hostility when you were around. We try hard to keep hostility out and keep everyone civil now a days