Same. I haven't done frontend work for a job for about a decade, but kept up to date with things like Angular/Vue/React. I was recently vountold by my wife to create a reunion site for her class. I looked up "barebones front end frameworks." Anything that began the "Getting Started" page with "npm install" I noped out of there.

I ended up with Skeleton/jQuery for the front end and PHP Slim for the backend. This is a 5 page, 2 forms, site targeted at 100 people. There's no need to SPA this, npm that.

You seem to be refuting a straw-man argument here. Why would a hobby site provide a counter example for people talking about work they do for their employers?

No rational person would advocate using Svelte or React for a static, one-off, informational site to be maintained by a single person.

In fact, you didn't even need jQuery at all. Vanilla JS works across browsers in a way that it didn't when you learned web coding 10 years ago.

Where frameworks become useful is for large projects that many people work on over a long period of time. Turnover is an issue for non-standardized code, as is poorly organized code.

And none of that even touches on security, which absolutely requires libraries, packages, and many of the other benefits of reusing the ecosystem that you seem to eschew.

> No rational person would advocate using Svelte or React for a static, one-off, informational site to be maintained by a single person.

This is where we disagree, and I think that's the problem. In my use case, I just wanted an HTML template file with at most a few CSS files. There's a dearth of those frameworks/templates compared to bigger packages.

Someone on HN recommended it to me before, so I’ll just pass this along: look at intercooler JS for making individual “live widgets” on a well-designed graceful degradation site like you describe.

Also Alpine.js, which has got quite a community behind it (somehow promoted by Laravel, IIRC). It is less than intercooler, but provides timesavers for simple sites like described. A compromise between a framework and none.

No, that’s not along the lines of what I’m suggesting at all.

Haven't heard of that one. Thanks!

Also unpoly, which I prefer to Intercooler and it’s my favourite unknown library since jQuery was first released. It’s an incredible time saver.

Thanks for pointing me towards that. Looks like a very nice “graceful ajaxification” library.

> Anything that began the "Getting Started" page with "npm install" I noped out of there.

> I ended up with Skeleton/jQuery for the front end

So rather than install a dependency via a package manager you installed it manually. Okay.

Calling Skelton a dependency is ludicrous. It's just an HTML file with a CSS file. Look at every other "lightweight CSS framework" - Specture, Mustard UI, etc. They all have dozens and dozens of files where you need a package manager.

The whole point was that it's simple enough that I don't have to deal with a package manager, and a lot of projects don't need to.

The whole point is that you choose an arbitrary thing to treat as a dealbreaker that doesn't really make a whole lot of sense. "npm install jquery" would have given you the exact same result you have, except it would have violated your dealbreaker. It just doesn't seem particularly logical to me.

To be honest, if you're going for "as simple as possible" there's no reason to use jQuery at all these days, it's a waste. Modern browsers have perfectly capable APIs!

Svelte can do server-rendered and static page generation with the near-zero overhead of string concatenation, and with it you gain the component model. Part of the magic of compilers is that you can get most of the best of both worlds. Sapper provides both of these use cases.

I worked as a fronted dev, so I know this problem very well. Server rendered pages, I don't mean Sapper. But the ol' rails erb, or flask jinja templates type of rendering.

Yeah if you're building a relatively simple webpage, a frontend framework really isn't needed.