I really like the idea of a framework designed from first principles around the idea of islands and progressive enhancement. That said, this feels like a lot of potential misleading marketing.

Firstly, I don't think the comparisons with React/Vue are hugely helpful for Nue. React and Vue do a lot. You're right that most people probably don't need all of that stuff, but it is in the frameworks for a reason - those who need it really do need the complexity.

Some better points of comparison in terms of compile-to-JS frameworks might be Svelte and SolidJS, both of which have some similar goals to this, and specifically focus on producing small, fast code. Alternatively, if you want the "it's just Javascript" approach, Mithril is another great framework oriented around minimising complexity, albeit with a reactivity model more like React's.

I also think the specific code comparisons scattered around the site are similarly unhelpful. For example, you typically use Typescript-based examples for other frameworks, and JS-based examples for your own. This is obviously going to make Nue look smaller, but typically people use Typescript for good reason, and understand the trade-off around code size. More egregiously, many of the comparisons seem very much apples-to-oranges comparisons. For example, the React listbox on the homepage is a part of Headless UI - it meant to be as unopinionated as possible and allow the user of the component to bring their own components, styles, etc. This makes it more complex but more powerful - a trade-off that isn't always worth making, but can be very useful for these sorts of components where 90% of the complexity is getting the UI interactions right. Your example is not headless, I don't think it's even styleable, and while it includes keyboard navigation, the lack of aria tags makes me doubt its accessibility. That doesn't mean it's bad - it looks like the sort of component I'd write as a custom component for a particular project - but it makes the comparison somewhat meaningless. I would imagine any component I wrote in most frameworks I use would be a similar order of magnitude in size.

(In fairness, I've just seen you call both of these points out in your compare FAQ. I disagree with your answers though - a framework's choice to use Typescript internally does not affect the choices of users to write components in Typescript, so "embracing dynamic typing" feels meaningless in this context. Moreover, it's not apples-to-apples if the components themselves are designed with different purposes - a quick React listbox could look a lot simpler if it needed to.)

More practically, I think it would be really helpful if you talked about rendering model more clearly. As a frontend developer, this is one of the first questions I have when looking at a new framework. Is reactivity sound, or am I going to have to spend a week trying to figure out why some variable isn't updating when I think it should be? It looks like the Svelte-style compile-to-DOM-mutations approach, is that right?

I have some other more philosophical quibbles with some of the claims in the documentation and FAQ, but I don't think those are so important. But I do think they you could improve the sales pitch a lot by making the underlying technologies clearer, and by having more useful points of comparison.

As an aside, do you have an entry on the Krausest framework benchmark yet? It may be worth submitting a PR there. Obviously pure framework speed isn't everything, but it's a useful point of comparison to see how one might approach the same problem in different frameworks, particularly a fairly intensive problem.