This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib...
I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skipped over AngularJS because it was meh, React beta finally came around and loved it for FP ideals, now wade thru piles of transpiling / hot-reload / Typescript and React fat-libs. Have also written a few projects with both Intercooler (and now HTMX).
HTMX is overall solid, but this ain't the first wagon to come through town.
To this comment’s replies: The dev of HTMX has said and is well aware that HTMX/hypermedia-based approaches don’t work well for every type of web app, but claims that it fits well with the vast majority of them, so the chance of it becoming bloated for want of fitting every single use case is pretty low. Greg says that a developer’s most valuable weapon against the complexity demon is limiting features by saying “no”, so I think the chance is pretty minimal.
So the cycle spoken of would be broken at this sentence. “SJSLib grows complex because it has to support all the web things.”
This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib...
I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skipped over AngularJS because it was meh, React beta finally came around and loved it for FP ideals, now wade thru piles of transpiling / hot-reload / Typescript and React fat-libs. Have also written a few projects with both Intercooler (and now HTMX).
HTMX is overall solid, but this ain't the first wagon to come through town.