Yeah, diagnostics would be really beneficial... possibly something that can generate a bundle from the polyfills that get added. Of course, would need to run across several browsers and aggregate the results.
Only including what you actually need, vs say the babel-env fills, that include everything missing for your target, even if you aren't using it.
Blocking requests can be seriously nasty in practice though... I had to use them for SCORM implementations at one point. And if you have a spotty connection as a user (think mobile) it can/will get particularly bad.
I think the biggest issue I have with this, are the in-between devices, like smaller screen laptops and tablets. People still use these things and this type of split makes no sense for them as you will likely have a combination of both for these tween devices.
Also, the bulk of your overhead is more likely your library packages, and even the component libraries themselves, not your application component modules. While you *can* break these down, I don't know that it's worth the consideration in many/most cases.
You can wrap most of your components in async load and your bundler can break these out... you will lose some benefits, but http2+ can offset some of the disadvantages in practice.
Cool... that said, relies on Firebase and Algolia, both are commercial SaaS, and Algolia in particular will be *VERY* expensive in practice. While I don't mind paid services, be careful of these kinds of locking.
Another issue is the potential extra thought that needs to go into security models in Firebase itself.
If you're doing something similar, should definitely explore Elastic Search (self-hosted or Elastic Cloud) or other search specific databases as alternatives. For example, at the 100k/month search point a base level 3 node Elastic Cloud cluster is going to be competitive, and offer more room for growth without blowing up pricing. For that matter, you can self-host with some relatively modest pricing structures on the likes of Linode or Digital Ocean.
I will often remove articles that are very obviously thinly veiled advertisements for a specific cloud service., or simple knock-off clones. I don't think that is the case here.
I'm less than convinced. Especially because now, there are models where the new FLoC style associations will now leak interests and allow for certain leaching activity and weird models of competition against niche markets.
I'd rather see television-like models where advertising is targeted/related to the content itself, or general to a given audience over individual targeting at all.
It's sometimes easy to fall into a singular mindset with how Databases should work.
In some environments, the transaction/consistency are king... for others, you relax certain guarantees for potentially expired data, or slower consistency models for performance and scale.
It really will depend on the environment and target audience(s) for your applications. Not to mention how unbalanced reads vs. writes are at scale and this will really shape decisions.
This *could* be useful if you're creating a leaner application where responsiveness on mobile or otherwise very limited devices as a priority.
Outside of the above context, I'm not sure it offers that much above current bundlers, especially if you are limiting support to modern (self-updating) browsers.
Currently, the killer feature for React is the component libraries. While Hyper and related alternatives offer some competitive advantages in some limited ways. When it comes to developing applications, being able to find readily available component libraries and even one-off components is invaluable. Material-UI is a personal favorite, and some of the Bootstrap based libraries are very nice as well. Yes, you can ad-hoc many of these things.
Another advantage, by nature of JSX being a JS abstraction instead of a DSL is that you get intelligent interactions with your IDE, more so with TypeScript. hyperlit won't autocomplete your available component properties for example.
Yes, Hyperapp has a lot to offer, and if you're able to do ground up development, or enhancing existing, or mostly-static/server rendered applications, it can be great. That said, it won't replace with React (or even Angular and Vue) offer for application development with teams of developers.