Modern front-end development is heavily framework-driven.
React, Vue, Angular — they give us structure, state management patterns, and predictable rendering out of the box.
But I recently asked myself:
What happens if you remove all of that?
Not to avoid frameworks.
But to understand what they’re actually solving.
So I built a personal project:
An advanced personal finance tracker using pure Vanilla JavaScript — no frameworks, no UI libraries, no charting libraries.
The Real Goal Wasn't the UI
Yes, the app includes:
- Income and expense tracking
- Dynamic filtering
- Live search
- Monthly grouping
- CSV export
- Dark/Light mode
- Canvas-based chart visualization
- LocalStorage persistence
But the real challenge was architectural:
How do you prevent your application from becoming fragile as features grow?
Core Architectural Decisions
1. Centralized State Object
All application data lives in a single state object.
Instead of mutating the DOM everywhere, state changes trigger rendering functions.
This helped prevent:
- Inconsistent UI updates
- Scattered data mutations
- Hard-to-track side effects
2. State-Driven Rendering
Rather than updating isolated DOM fragments manually, rendering is driven by the current state.
When state changes → render cycle runs → UI reflects state.
This mirrors how modern frameworks operate internally.
3. Separation of Logic and Rendering
Business logic (adding transactions, filtering, exporting, formatting) is kept separate from UI rendering.
That separation made it easier to extend features without breaking existing functionality.
4. Canvas Without Chart Libraries
The income vs expense chart is built directly using the Canvas API.
No Chart.js.
No abstraction layer.
That forced me to think about scaling, layout, and rendering math manually.
What This Reinforced for Me
Frameworks are powerful.
But understanding:
- State flow
- Rendering cycles
- Data mutations
- UI synchronization
without relying on them builds real confidence.
It also makes you appreciate what frameworks abstract away — and when they’re truly needed.
Live Demo
Try the application here:
👉 https://amirhosseinln.github.io/advanced-finance-tracker/
Source code:
👉 https://github.com/AmirhosseinLN/advanced-finance-tracker
Connect
If you're interested in frontend architecture, state management, or UI engineering discussions, feel free to connect:
👉 https://www.linkedin.com/in/amirhossein-latifinavid-5923272a7/
Open Question
For developers building vanilla projects:
At what point do you introduce architectural patterns?
Do you design for scale early — or let complexity drive abstraction?
I'd genuinely appreciate feedback on the structure or UX decisions.
Top comments (3)
rebuilding the wheels 😂 good for training the mind, otherwise you can use your time to build actually something useful 😎 🍸
(preferably another wheel, that you can use when building other wheels)
Rebuilding a “wheel” once is how you learn about load distribution, friction, and failure modes.
Frameworks abstract those concerns but they don’t eliminate them.
Understanding what happens beneath the abstraction layer makes architectural decisions far more intentional.
I'm into programming for 40 years. 😂
so no more wheels, no time left for this