[dgb23]

You are optimizing for entirely different use cases.

There are a whole bunch of devs who work alone or in (very) small teams. For this type of work it’s really more of a hindrance to have an imposed structure and tooling.

We want to get to your goals as efficiently as possible. Minimal abstractions, guidelines, tooling, indirection, magic, surprises and general overhead are in order. We don’t want to struggle with questions like “how to do this in X”. We already know how to do it, so we just do it.

As time goes on and LOC get merged we find ways to add sensible structure and compress our code.

[mrweasel]

There's another comment that talks about medium to large project, and it's the same thing, it's a different use case. I don't care about medium or large projects, I need to add a quick semi-dynamic element to an incredible basic web app.

In my case, setting up a React or Angular project is going to be more work than just writing the whole thing in vanilla JavaScript. This has the added benefit that I actually understand what's going on.

The modern JavaScript frameworks are great for large projects, but it feels like learning Django in order to make an API that goes "pong" when you do a get request. I get why this happens. Vue looked great 8 years ago, small, simple and easy to get started with. Then it grew to support more and more use cases, and larger projects and now we need a new tiny framework. Or we can accept that JavaScript has come a long way and that many of us might not need a framework.

[oefrha]

No, proper structure and tooling (especially for HMR) are important productivity boosters for solo developers as well. Single file scales to about 1k LoC, it’s only viable for toys and tiny projects; beyond 2k-3k LoC you’ll hate yourself every time you need to change something (been there). And ad hoc shell script in place of npm/yarn/whatever proper package manager, which is way easier than said script? I hope that’s show business and not actually used.

Btw, this direct module import approach means you’ll be shipping a lot of unused code to users.

Edit: If you only need a tiny amount of progressive enhancement on top of static HTML: forget about this import map and ad hoc npm script business, use petite-vue (single script, 6KB, add a script tag like good old jQuery).

[selfmodruntime]

> There are a whole bunch of devs who work alone or in (very) small teams.

And you still need to reimplement a bunch of stuff if you don't use oss packages. And the next maintainer will curse your family for generations because of your own custom framework.

[mmcnl]

Imo being "smart" like this is reinventing the wheel and doesn't give you any productivity gains.

[dgb23]

It's not reinventing anything. It's just avoiding complexity until necessary.

[mmcnl]

Writing custom shell scripts to avoid complexity usually achieves the opposite result. I can Google npm errors, but not why a custom shell script fails.

Second, anyone reading the repo is now expected to understand not 1 but 2 languages.

Finally, the shell script performs basic tasks that npm does out of the box.

Because of above reasons I think this solution is needlessly complex.