> a "simple" stack of lit-html, vanilla JS and ES6 modules
This is precisely how I’ve been building tableofsending.com and it’s been a lovely experience.
You do need some babel/tsc/etc build step to reach a reasonable audience.
This is precisely how I’ve been building tableofsending.com and it’s been a lovely experience.
You do need some babel/tsc/etc build step to reach a reasonable audience.
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.
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.