Echo JS 0.11.0

Both of these components don't seem to have anything actually wired for click events, feels like half the example is missing and not in a way that makes things really understandable.

Would be nice if you used github pages to host an active version of this.

Why the hell did you just turn around and post this again literally 2 days after you already posted it?

TBH, it's just massive information overload to the point where it really loses value.  There's some inline bits as well as external links.

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.