Really nice to see this... would also be nice to see a shim library that isn't too big that takes care of the abstraction for you... this way if you're on a desktop browser without the sharing API, you can present the common social media sharing buttons if the API isn't available.
Nice to see Preact catching up on some features in React proper... I stopped even trying to target Preact a little over a year ago for a couple reasons. First is missing features in React that are very useful, this is a large bridge. The second is that React has *REALLY* helpful tooling in terms of diagnostic messages in the console as well as browser extensions themselves.
Beyond this, the extra 60k or so that React has in payload over Preact + compat isn't that much in relation to an application's payload, and the performance difference is negligible in most real world cases (in my experience), so I've favored the better tooling and diagnostics.
That said, I do love to see smaller frameworks as they are an incredible option for bandwidth and resource limited devices or when using a progressive enhancement.
Please, don't use HMAC via shared secrets for JWT if you can avoid it at all... prefer RSA signed keys, this way only the public key is shared and the private key only needs to be secured in one place.
Here's a more relevant article with actual code examples.
https://link.medium.com/0W35cJtseZ
Though I would go with a 4092 bit key and use RSA 384 for the signing. The article mentions generating keys in Chrome... unless you have a real use case for this, then go for the stronger options on the server.
Nice writeup... not a fan of using Classes outside of contextual needs, and even then often not needed.
One bit of warning, do *NOT* use deep inheritance chains if you are dealing with large arrays of objects and inherited properties, the lookup against the prototype chain is relatively expensive. Often, you are better off with composition if you need more than 1 layers of inheritance.
I do agree... and the number 100 devs is probably a bit over the top. It's only that a lot of people will try approaches like this on a very small scale and will run into serious problems of orchestration at a small scale that tends to outweigh the advantages. I've worked on similar approaches in the past and see both sides.
My advice is simply caution and YAGNI to an extent. Much like most Enterprisey patterns in general, many lead to more friction than they're worth.
For a front end... *ONLY* do this if you *REALLY* need it... Some really large corporations need this kind of thing (think hundreds of developers writing interconnected applications). If you're on a relatively small team and unlikely to have over 20 developers, this will create more friction than it solves imho.
Doesn't really bring much new to the conversation, no mention of interactive tooling such as storybook[1] or bit[2] (despite my personal opinions of the value of bit). While not directly related to the narrow topic I feel they do fit into this space.
* [1] https://github.com/storybookjs/storybook
* [2] https://bit.dev/