After you selected a few, you can review your selection in the Share page.

For example, https://fonts.google.com/share?selection.family=Akaya%20Teli...

Wow, thank you! Why in the hell would they hide such a useful feature?

> That's React in 8 lines of jQuery

No sir, that doesn't include server side rendering or diff rendering either (meaning changing a bit on the top component would re render all markup, not just what has changed)

Stop trying to over-simplify. The problem being discussed here is not React vs jQuery. It's what we do and the decisions we make as engineers to provide a good experience based on performance which is OUR side of UX.

I mean, you can use either the of the morphdom or setdom libraries to do the diffing if you don't want to replace all the HTML, but the concept remains the same.

I'm not convinced by arguments such as "when you're a large team it's necessary". Scaling teams has more to do with project structure than what rendering library you use.

Likewise, it's much easier to tweak performance when you aren't depending on a monolith like React or Angular.

I'm sorry bigmanwalter but you're working on a team of 3 people, not 100+ engineers working in the same codebase.

And you've created your own abstraction beyond "jquery bits for each component".

This is proper vanillaJS engineering, I do the same, it's just not what you're selling here.

Well of course I've created my own abstraction... that's what programming is.

I prefer to keep my abstractions simple and light, and preferably built using lower level libraries. If I can build a powerful component system in 150 lines of jQuery (and it would be barely more in vanilla js), I much rather do that than than import a 30kb + library.

There are plenty of 4kb react alternatives to choose from. Most with vastly simpler APIs. Choo.js or Mithril come to mind :)