> you also have your build code, oddly dictating the organization of your source code It... really doesn't? You generally have an entry point file - which can

> you also have your build code, oddly dictating the organization of your source code It... really doesn't? You generally have an entry point file - which can be any file, you just have to specify it to your build system - and import statements are followed from there on. If anything you could argue the JS build ecosystem is too flexible (which is one of the things esbuild is pushing back against). I've never heard someone criticize it for being too opinionated. > For extra fun, some libraries don't build with build system a, others require build system b I've literally never encountered this problem. Library authors virtually always ship least-common-denominator JS that will work without using a build system at all, and then build systems know how to handle lots of different variations of JS and converge them into a single representation. Compatibility is not an issue that exists in my experience. > The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all. Now you're just airing your own personal beef which doesn't actually have anything to do with the original topic.