Yeah I bet once you get the stack up and running, as well as smooth out the inevitable early adopter bugs of lit-html, you'll have a great experience. The subtext of this was my friend constantly telling me easy and simple it'd be versus React. When in fact each stack has its tradeoffs and incidental complexity.
lit-html has been used in production for over 2 years now, on sites with billions of page views a day. At this point no one new to it would be an early adopter :)
The issue with module loading is a pretty fundamental one, though pretty unrelated to web components.
Once you understand it, there are a large number of tools that make them work. The core problem is that most modules available on npm are written with import specifiers that assume the environment supports Node's module name result. Browsers don't, so it won't load something like `import * as redux from 'redux';`
The solution is a tool that transforms package names into URLs. Webpack, Rollup, Parcel, es-dev-server, Snowpack, Vite, unpkg.com, Polymer CLI, and many more do this for you.
More and more of the ecosystem is moving to native modules and we're all going to have to understand this issue.
ReasonReact has been used in production for 3 years now, with billions of page views a day. I'd still call it immature in many^[1] regards :D
The particular point of this project was to prove that each successive simplification that my friend proposed, i.e. avoiding Webpack for native ES6 modules, using lit-html instead of React, etc. introduced its own complexity. I'm not saying that these were all bad ideas, but just that they're fundamentally tradeoffs. I'm quite sure lit-html is a great stack. But it's not "better" than React any more than React is "better" than Angular.
[1]: Lack of async/await, or its equivalent, let+ in OCaml 4.08, is a big one. Mediocre typings for browser APIs is another.
