Oh I think it is very much "just fine", but people have requirements which make things too complicated. I find it way harder to work in a React app than a few .html and .js files. TypeScript's cool though.

Most people working professionally as web developers have limited ability to reduce the requirements and have to implement what their company ask for. At that point having something to manage the complexity is much better than not.

Yeah. I'd argue you should quit if you as dev have no say in the development, but what do I know

What do you consider "not fine" about websites written in "just" html, CSS, and js?

1) Rats nest of non-declarative JavaScript.

2) Rats nest of JavaScript callbacks.

3) Overlapping stylesheets with !important everywhere.

4) Elements used for style not their semantic purpose (<b>, <strong>)

5) Subtle and not-so-subtle browser compatibility issues.

5) is the only valid reason, the rest has comparable alternative shitty things when using whatever framework

No amount of discipline was going to make medium-large websites maintainable back then. Today it's actually possible if the creators know what they're doing. Tooling isn't going to prevent people from doing stupid things.

I agree with HTML+CSS+JS websites being not fine. But to be honest, js callbacks are more of a language thing than a framework thing. You don't need to use frameworks to write promises.

Also: using JS for things where HTML and CSS would have been sufficient, creating some of the issues above.

this ^ - and if js at all, then only using a subset which passes jslint.com without any errors or warnings. that the score of any site should be

100 100 100 100 1.1s max paint (mobile) 0ms block 0.0xx max shift A+ headers 0 errors and 0 contrast errors webaim goes without saying of course

You can't reuse pieces of UI functionality (a bundle of specific html, css and js) unless did copypasta which is obviously awful. Sharing business logic across different areas of an application becomes much harder and you can't non-trivially write and run tests across areas of your application because you are just using html,css and js. And the big monster: state. Sharing state safely across different areas of an application becomes much harder. You end up writing your own micro framework trying to make all the above work. At that point you might as well use as existing battle-tested one

So, instead of "Building websites...", would it be fairer to say "Building some types of web app..."?

Sure you can, Web Components exist now, and SSR components exist for 25 years across all main languages.

Using them was fine. but developing them, no. It's way more work just managing event handlers for a start.

mainly the CSS

This. A not so great analogy is you can always drop a single php file into your /var/www/ (or even do cgi) and get your "dynamic" website running like decades ago, but people don't do that any more for any website that is not a tiny one with just a few pages (barring famous exceptions like WordPress). People realize there are good reasons to use frameworks, and often, use other languages for website backend.

The reason being CV driven development in most cases.

For the large part of projects I work on, plain old server side rendering with sprinkles of vanila.js work just fine.

At least folks now rediscovered SSG, but they seem to build rewriting bundlers in Rust as well.

> sprinkles of vanila.js work just fine.

Bullshit. jQuery as a library didn't inherently cause spaghetti code, it was predominantly just used as a cross-browser selector function and some standard library augmentation/fixes before JS itself caught up. Sprinkles of progressive enhancement jQuery were exactly the problem that caused frameworks to be created. Sprinkles of vanilla JS lead to the exact same outcome, minus a jQuery library load.

Whatever dude, we're doing ASP.NET MVC and Spring/Jakarta with vanilla.js just fine, go improve that CV.

How long have you guys been around? How large/old is the codebase? How many members are on your team?

We have been around since decades, being hired guns for Fortune 500 consulting.

Codebases are as old, or as new, as customers require for their business cases.

> it was predominantly just used as a cross-browser selector function and some standard library augmentation/fixes before JS itself caught up.

Do not forget jQuery.ajax, making cross-browser JS HTTP interactions possible in the first place.

it absolutely was fine. it was easy and many children were able to do it with minimal experience. the reason frameworks were invented was because the web devs at big tech companies decided to use dumb and sluggish hacks to simulate features that websites never did and still don't need.