Superseded — superseded by lazy loading (2005)
In the desktop era, applications ran on a single machine with dedicated resources. Loading everything at startup ensured responsive UI once the splash screen closed. Network calls during operation were expensive and unreliable.
In the early desktop era (1990s), eager initialization was not just common — it was recommended. Visual Basic applications loaded lookup tables into combo boxes during Form_Load. Delphi applications populated in-memory datasets from the database before showing the main form. PowerBuilder datawindows retrieved their data in the application's Open event.
Why it made sense: Desktop applications owned the machine. Memory was growing. The splash screen was the social contract — users expected to wait at startup in exchange for responsive operation afterward. Network connections were unreliable and expensive, so pre-loading reduced runtime failures.
How it was superseded: As applications grew, datasets grew, and client-server gave way to web applications, eager initialization became untenable. Loading everything at startup meant startup times grew linearly (or worse) with data volume. Lazy loading — fetching data only when needed — became the replacement pattern.
Why it persists: Even after lazy loading became standard, eager initialization survives in configuration loading, dependency injection containers, ORM session factories, and any context where "ready" is conflated with "loaded everything." GTA Online's six-minute load time was, at its core, a 2013 application still using a 1992 initialization pattern.