Still Active
As datasets and user bases grew, eager initialization caused unacceptable startup times and memory consumption. Lazy loading ensures applications only fetch what they need, when they need it.
Martin Fowler formalized lazy loading as a pattern in Patterns of Enterprise Application Architecture (2002). The core principle: don't load data until it's accessed. Hibernate's proxy objects, Rails' Active Record associations, and JavaScript's dynamic import() all implement variants of this pattern.
Why it replaced eager initialization: When applications served thousands of concurrent users and datasets grew to millions of rows, loading everything at startup was no longer viable. Lazy loading reduced memory footprint, improved startup time, and distributed database load across the application's lifetime instead of concentrating it at initialization.
The tradeoff: Lazy loading introduces latency at the moment of access and creates the N+1 query problem — iterating over a collection triggers one query per item instead of one query for all items. The mitigation (eager loading specific associations) is, ironically, a return to the pattern lazy loading replaced.
Where it persists: Modern applications use a hybrid approach — eager loading for data that is always needed, lazy loading for data that might be needed. The challenge is correctly classifying which data falls into which category, especially as usage patterns change over time.