A framework like React or Next.js exists to solve a specific problem: state reconciliation and UI syncing across heavy, dynamic applications where data changes constantly at runtime.
So why are we using it to ship single-page, static portfolio sites?
If your portfolio page does not have complex, multi-user real-time state mutations, pulling in a virtual DOM, a node_modules folder, and a massive runtime bundle is bad engineering. You are optimization-killing your load times before a user even renders the first paint.
I built my entire layout using raw HTML, custom stylesheets, and vanilla JavaScript for tracking and UI transitions. The layout does not change dynamically based on a complex backend state, so it does not need a framework.
Stop choosing your tech stack based on community hype. Use the baseline tool required for the job. If vanilla JS can handle the DOM manipulation natively, let it do its job.
Portfolio: ahmershah.dev
GitHub: ahmershahdev
When you use a massive framework for a simple project, you aren't solving a problem—you're trading a minor development inconvenience for a massive performance tax on the end user. We need to evaluate our stack based on user needs, not resume building.
Frameworks were invented to stop developers from losing their minds trying to manually keep the DOM in sync with complex, multi-layered application states. If your site has no real interactive state, the framework isn't solving a problem for the user—it's just a developer comfort tool.
A beautiful 3D landing page is useless if it causes a user's laptop fans to sound like a jet engine taking off. WebGL is powerful, but developers forget that asset optimization, texture compression, and mesh simplification are where the real work happens.
Sagar Kumar
The "framework-first" mentality means beginners learn the abstractions of React before they understand how the browser actually processes a click event or renders a style change. We're fixing problems we haven't allowed developers to experience naturally.