Weather.gov 2.0

Original Article ↗ Hacker News Discussion ↗

Weather.gov is being rebuilt as “Weather.gov 2.0,” with a new Drupal-based site and design led in partnership with U.S. digital service teams, aiming to make NWS forecasts and hazard information easier to find, understand, and act on. Commenters praise the current service and its detailed graphical forecasts and radar loops, but worry the new version could sacrifice simplicity, performance, and direct data access in favor of heavier JavaScript interfaces and analytics. The project also highlights broader issues around governance of public weather data, fragmentation across agencies, and political pressure not to outcompete commercial weather providers.

Technology stack: Drupal in 2024

  • Several commenters are surprised Drupal is still the choice in 2024, calling it an “interesting” or dated pick.
  • One thread argues Drupal’s plugin/theme architecture is “insecure by design”; others push back that any CMS running arbitrary third‑party code shares similar supply‑chain risk.
  • Some note Drupal’s Symfony base and modern similarities to Laravel, and emphasize that many government sites already use Drupal because of staffing and ecosystem support.

Government open-source coordination

  • Multiple people wish there were a unified “usa-gov” style GitHub org listing all federal OSS.
  • Existing partial solutions are cited: code.gov, government.github.com, and various agency/org-specific repos.
  • There’s mention that code.gov’s original unified indexing via code.json has atrophied due to funding and policy changes.
  • Some suggest GitLab and self-hosted options with hierarchical orgs, but others argue a single code host for all government is unrealistic; a cross-host catalog is preferable.

Weather.gov usage, APIs, and third-party tools

  • Many rely on weather.gov as a no-frills, ad‑free, stable source, especially after Dark Sky’s shutdown.
  • Several homegrown dashboards and clones using api.weather.gov or other open APIs (like Pirate Weather) are shared.
  • Commenters strongly value the Area Forecast Discussion and graphical forecast products as uniquely honest and detailed.
  • Some wish 2.0 emphasized APIs and last‑mile tooling more, especially for emergency management and specialized use cases; api.weather.gov is said to be out of scope for this project.

Radar, UX, and accessibility

  • The previous “big radar update” is widely criticized as slow, complex, JS-heavy, and worse than the old GIF loops.
  • Others defend radar.weather.gov as fast, ad-free, and effective on many devices.
  • There’s appreciation that legacy GIF loops (national and local) still exist, though discovery is non-obvious.
  • Concerns are raised about poor progressive enhancement and no-JS accessibility.

Governance, transparency, and politics

  • The README’s candid admission about organizational silos and Conway’s Law is praised as rare transparency.
  • Some fear “feedback/monitoring” will justify analytics scripts and cookie banners; others note the government’s existing analytics.usa.gov approach.
  • Several comments reference historical political pressure to keep NWS products from competing too strongly with commercial weather firms, and concern about attempts to privatize forecasting.

Status and future of Weather.gov 2.0

  • The project is moving from prototyping to MVP; roadmap targets around May.
  • Staging and beta endpoints are discovered, but the authoritative site remains the existing weather.gov.
  • Some are excited and see it as a model for modern federal digital services; others fear a “bloated JS” redesign that degrades today’s highly valued, data-dense pages.