WebReflection / hyperHTML

A Fast & Light Virtual DOM Alternative
ISC License
3.06k stars 112 forks source link

Why so many projects? #402

Closed danny-andrews closed 3 years ago

danny-andrews commented 3 years ago

hyperHTML looks cool! I'm excited to try it out.

Why are there so many projects, though? µhtml, lighterHTML, hypersimple, hyperHTML, it never ends!

As someone interested in this project, I have to admit this turned me off to exploring further. It's all a bit overwhelming, and I can't help but wondering: how many of these is he actually going to maintain? Which one does he believe in, etc.

I also realize you're not trying to be a framework, and I totally respect that point of view. I also understand this project is relatively new and these projects may be a bit of R-and-D.

danny-andrews commented 3 years ago

Nvm, this helps a lot: https://gist.github.com/WebReflection/761052d6dae7c8207d2fcba7cdede295.

WebReflection commented 3 years ago

these projects may be a bit of R-and-D

There's no R-and-D here, especially in here, as we've shipped HyperHTMLELement in production to nearliy 100 million users for the last 2+ years, and while the concept behind is very mature, the API has been criticized for not being instantly clear (bind instead of render and wire instead of html or svg), which is why the lighterhtml alternative was born, allowing me to fix that not-super-clear part and improve the logic behind (stack based, soft keyed out of the box, etc) and get rid of the extra stuff I've put in here that might be not useful at all, hence bloat unnecessarily the final size (we're talking about a couple of K anyway).

Which one does he believe in

I believe if I came out with uhtml in 2017, instead of hyperHTML, it would've been game over for everything else that came after, but that's the beauty of maturing a concept and make it minimal: only after years of successful applications of any kind, written with template literals, I could make uhtml happen, and since the concept and bricks to put it together are rock-solid, I believe myself anything else might be superfluous, 'cause there's not a single use case I can't solve with uhtml other frameworks, or libraries, can. That's the same with lighterhtml and hyperHTML too, but these are heavier than uhtml (for few valid reasons) so that whoever needs extra features can swap core libraries around.

core is the key to understand the fact there are 3 variants of the same approach:

All libraries built on top are simply an offer for developers that come from, or used, other libraries approach:

how many of these is he actually going to maintain?

Most of these libraries share, behind the scene, the same modules, but on top of that, these libraries are 100% code covered and, as you can verify yourself, the bugs counting is close to zero.

As a matter of fact, the stack is so mature that actually I never worry there is some new bug, it's just some new feature, or some new example, that people want, so time it takes to maintain all this is virtually zero, but when it comes to actual bugs, hyperHTML has been solved within the same day the bug has been discovered (because we use it in production), but if that bug affects lighterhtml and uhtml, also used both internally and in production, but more recent than hyperHTML, things get fixed pretty instantly too.

I have also automated updates per dependencies so that as soon as some module I use is part of another module, everything gets bumped automatically: it's literally a ../find && ../update command away for me.

Why are there so many projects, though?

Because I like to offer every possible known development pattern style through libraries that would never weight more than 10K, so that any junior to senior developer, with some kind of pattern preference, can give these libraries a try, and tell me what is it that they are really missing, coming from this or that "famous alternative".

I understand this could be overwhelming, specially landing in a chaotic README page like the one I have in here, but I can assure you all these libraries are pretty identical to each other, it's only the surface/exposed API that changes, and it's on you to pick the one you prefer the most.

I believe these days uce-template is revolutionary, but many people from big companies or other frameworks won't tell you that, 'cause they have to "sell" their stuff and pretend nothing I do here is actually pretty cool.

(I know latest statement is not super humble, although I find it funny famous Web perf/size advocates rarely mention my tiny libraries)

I hope I've answered your questions, but if you have more, feel free to ask 👋

WebReflection commented 3 years ago

P.S. in case you'd like to also compare/know uce with lit-element, here the gist I've written yesterday: https://gist.github.com/WebReflection/ae3451c17c5e882bbc7f0714c14eefcd

danny-andrews commented 3 years ago

Wow, thanks for the detailed explanation. I totally vibe with your philosophy of providing small-but-powerful primitives rather than a bloated framework. Frustration with React is what led me here in the first place.

I believe these days uce-template is revolutionary, but many people from big companies or other frameworks won't tell you that, 'cause they have to "sell" their stuff and pretend nothing I do here is actually pretty cool.

Don't even get me started, man. There is certainly an "in-crowd" in the web development world. If you don't work for one of the big companies, your ideas don't get noticed, no matter how good. It's tiring to see ego and hype take precedence over good engineering, but what can you do?

Cheers!