[megadal]

This sounds a lot like gatekeeping to me.

It's not that you can't build a website without a framework, its that at the end of the day, no one cares what tools you use (in front end), it's how fast you get the job done, does it look like the mock up, and does it function.

No one cares if the site is written in vanilla JS vs. a framework except a certain segment of HN web purists.

[austin-cheney]

80% agree. That is immediately true when only talking about code, but then absolutely everyone bitches about how shitty the result is (big, slow, brittle, and so on). People do care enough to complain, even non technical people.

Worse than that people who do that work also bitch about how shitty the results are too, but then continue writing garbage because that’s the best they can do.

[megadal]

> Worse than that people who do that work also bitch about how shitty the results are too, but then continue writing garbage because that’s the best they can do.

True, but the only solution to this is "get good". Because using vanilla JS isn't going to make them any less likely to make a foot gun.

In my experience, the most brittle projects I've worked with tend not to be component-based SPAs. Maybe not necessarily because they're SPAs, but because they're component based, which in JS world, pretty much always requires the use of ES modules.

Even if someone makes some horseshit you can iterate away from it easily because (at least in the case of Vue), it's incredibly difficult to leverage global state (and discouraged, in programming in general, but also specifically bt Vue) and everything you do is encapsulated in components.

The JS projects that give me nightmares are the ones that use globals that are defined/populated/hydrated across different JS files, so the JS files have to be loaded in a certain order, or you get undefined reference errors and the like everywhere.

All of this is sorted out for you by bundlers and frameworks. And if you're not using a framework, you almost have to be good enough to make a framework to avoid all those pitfalls yourself.

At least that's been my experience with vanilla JS vs. framework JS in enterprises.

I really think the web purist rage about it comes from the fact that these individuals have dedicated years to perfecting exactly this craft (building little frameworks for themselves) and now complete noobs can make websites that look equally as sophisticated in 5 minutes. I don't think it really has to do with practicality as they claim. (E.g. gatekeeping)

Many webpages can and should exist with as little JS as possible, but the moment UX matters more than whatever bespoke concern is causing that restriction, you start having to think about the JS as a full fledged app vs. just some scripts bringing life to HTML (or you just delegate a bunch of UI code to the server).

I think if the website is primarily for reading static content, it makes sense not to use a framework. But once you are managing forms, reactivity, and rapidly changing demands from user feedback, it stops being easy to balance between creativity/flexibility in design and robustness.

And the reality is, most web developers are just working on some version or component of an ERP, which is a reactive data driven app that changes constantly to keep up with the business it's built for.

Frameworks usually facilitate rapid iteration in such products.

But I agree, installing 40 npm packages to build a blog is silly.

[austin-cheney]

> True, but the only solution to this is "get good". Because using vanilla JS isn't going to make them any less likely to make a foot gun.

That is a common misconception that only occurs in software and is exceptionally common to JS. If you want to avoid foot guns set validation criteria: lint, test automation, strong types, and so forth. Contrary to what many JS developers suggest vanity is not a solution here and even that can be automated.

I had a personal project that was this peer-to-peer file sharing utility. I wanted test automation but was not aware of a test-automation utility for the browser in a peer-to-peer environment. So, I wrote one. When I changed the project from HTTP to WS I was about to execute up to 300 tests in about 8 seconds. That was very helpful. I found that since it was fast enough I could run this test automation all the time even before manually testing in the browser.

When I was at this consultancy last year that used Vue 2.0 tiny refactors were full of risks and could take up to 2 weeks. They had no automation of any kind and it scared the shit out of me. Making heavy use of strong types due to TypeScript I was able to execute refactors several dozen times larger in about 2 hours at almost no risk in a much larger personal project.

None of that means I am awesome. It just means that by putting the proper processes in place I was allowed to be really bad and could still release hundreds of times faster at low risk. At work I had to be astonishingly stellar when tip toeing around eggshells very slowly to release anything at all. I have been doing this long enough to see the same faulty patterns repeated.

The ideal path forward has to come from somebody that understands risk analysis, can measure things, and understands compound interest. That person could be an MBA who has never programmed before. Software almost always gets this wrong and does the opposite because it likes to repeat its failures. My repeated failure is not getting out of JS sooner.

[megadal]

> That is a common misconception that only occurs in software and is exceptionally common to JS. If you want to avoid foot guns set validation criteria: lint, test automation, strong types, and so forth.

The thing is, a developer can do all these things and make ugly UXes. They could also do none of them and make brilliant ones.

> My repeated failure is not getting out of JS sooner.

Have to agree. You sound like a strong backend engineer who was trapped in a frontend engineers body for years.