[benoau]

Some good history of the JS ecosystem here but the underlying message is all the same, frameworks scale and provide structure but you don't need them. Very easy to agree up to this point.

Author then elaborates in the absence of using a common-knowledge framework you can create some tighter solution that achieves just the part you need. This is "fun" programming, and the author is suitably impressed with themselves for solving problems they created just by convincing themself not to use a framework. Sometimes that's fine, although I don't think there's much appetite for this anymore.

Article doesn't really elaborate on what "scaling" and "providing structure" means, I think it downplays the benefits because when you use <framework> you are really establishing ground rules for how all future developers are going to work on that software. You don't know exactly what they'll write, but you know they'll always gravitate towards the top 2 or 3 solutions for that framework at any given time.

When you bust out a bespoke solution that carves out that one thing you needed and does it oh so elegantly and perfectly, you're creating art but most of the canvas is left blank for future developers and they're effectively going to scribble on it with crayons.

[bluegatty]

You can say that without being demeaning. These are random people acting in good faith.

Also - sometimes it is actually useful to make a mini-thing instead of bringing in enterprise messes.

[chabska]

These people are perfectly fine with depicting React developers as corporate zombies that can't think for themselves. Good faith is bidirectional.

[bluegatty]

We can try to be a big magnanimous and rise above a tiny bit of 'English on the ball', let the small stuff slide.

[swatcoder]

We practice engineering. As engineers, we need to understand the realities of each project we take on. Those realities are not limited to the marketing bullet points we might apply to the imagined product someday, which is what early career folk might naively call "the requirements".

Among the most critical realities to consider exist outside the product definition entirely, and have to do with the environment in which it will exist during and after development. These are things like plausible scaling curves and limits, code lifetime, team size, deployment options and preferences, etc. Others are things like available runway, team fluency and talent, available tools and licenses, etc.

One of the big eyeroll moments of the last 15 years or so was when folks started blindly cargo culting global-scale 10,000-engineer enterprise practices on projects that would obviously only ever be touched by 1-2 technicians and deployed on a far far far more modest scale. Instead of actively considering any of those environmental requirements above, "engineers" would try to treat every project as though it would someday service 10,000,000 DAU under the hand of dozens or hundreds of churning technicians.

Akin to the joke about some Americans who see themselves as "temporarily embarassed millionares", making foolish choices at their own obvious expense, many engineers during this era would seem to see themselves as "temporarily embarassed Facebooks".

In countless cases, this was simply very dumb and very wasteful and at best amounted to inadvertent (or perhaps intentional) resume-padding for the people involved, while their projects bloated and sagged and lurched under unwarranted complexity.

Sometimes (in fact: often), just doing the thing well with simple, clear, stable tools -- and nothing more -- is the right choice.

[shimman]

It is truly insane that this still continues to happen today, I mean the entire cloud industry is built on overcharging clients for compute they will never ever realistically use.

Not too mention how damaging it all is to environment in exacerbating the climate catastrophe.

[groundzeros2015]

As computer hardware has become more capable we should have been able to build even more web applications on a single machine. But there are few people even pushing on that boundary.

Some engineers learned it works fine and are quietly maintaining a stable system well under capacity. Or building the most insane distributed systems ever conceived.

[RetroTechie]

> Sometimes (in fact: often), just doing the thing well with simple, clear, stable tools -- and nothing more -- is the right choice.

Stronger: that should be standard operating procedure. Unless there's a pressing need (if not absolute necessity) to do otherwise.

[FpUser]

>"frameworks scale and provide structure"

Web Components and vanilla JS scale just as well. Been doing this for ages.

[wett]

Asking in good faith: how is your experience working with vanilla JS on a team?

While I’m not the biggest fan of Nextjs for my own solo projects, I really enjoy using it at work. Leaning into the opinionation it provides/encourages keeps my team from bickering too much about how to structure things.

It’s really nice to say “this is the idiomatic way of doing it according to the docs” and for everyone to nod their head. Whereas pages in our legacy PHP codebase look completely different depending on who implemented them.

[FpUser]

Team or not makes no difference.

Front ends works like this - main app split into few smaller ones callable from a menu. Each sub-app is dynamically imported module (no need for building, code mutilation, direct dependency etc). Sub-apps in turn can consist from the other sub apps. Each can be worked on completely independently by different team member with virtually no interaction needed. Apps can share some approved libraries (like for graphics etc) and HTML components responsible for particular bits and pieces. Components and libs go into common pool. Once component is in a pool modifying behavior is punishable by death. Only internals. If change is breaking then simply new version is developed and deployed.

The whole thing is super scalable organization wise (nearly everything is decoupled) and resource wise as well since everything is loaded strictly on on need basis.

[pjmlp]

You impose static analysers on the CI/CD pipeline, or git pre-commit hooks for code style?

Folks learn about how to use modules and libraries?