Project ideas from Hacker News discussions.

Temporal: The 9-year journey to fix time in JavaScript

📝 Discussion Summary (Click to expand)

Key take‑aways from the discussion

Theme What people said Representative quote
1. Adoption & ecosystem support Developers are excited that Temporal is finally shipping in major runtimes (Node, Deno, browsers) and that polyfills already exist. “I’ve been using it server‑side via the js‑temporal polyfill for some time, no issues.” – CharlesW
The rollout is still uneven, especially in Safari, but the trend is clear. “Deno has had it behind the --untable-temporal flag… removed the requirement for the flag and it is out of the box.” – WorldMaker
2. API design – explicit, immutable, type‑safe Temporal’s separation of Plain, Zoned, Instant types and immutability is praised as a major improvement over Date and Moment. “The main advantage of json is that it’s human readable… Temporal is typed; its serialization helpers aren’t, because there’s no single way to talk about types across serialization.” – jayflux
The verbosity is accepted as a trade‑off for correctness. “It’s a bit more verbose, but I’ll take writing a handful of extra characters over being called at 3 AM to fix a DST bug any day of the week.” – wesselbindt
3. Serialization & inter‑op concerns The fact that Temporal objects lose their prototype when stringified is a pain point for people who share data between client and server. “JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1})))… won’t work, because it misses the prototype.” – VanCoding
Solutions involve revivers or thin transform layers, and the debate touches on OOP vs functional style. “All Temporal objects are easily (de)serializable, though. .toString and Temporal.from work great.” – qcoret
4. Historical lineage & influence Many note that Temporal was inspired by Java’s JSR‑310 / Joda‑Time and that the design borrows from languages like C#’s NodaTime. “It’s a copy of Java’s JSR310, which in turn took many years to get right.” – andrewl‑hn
The discussion also touches on how other ecosystems (Java, C#, Python) shaped the spec. “The Temporal team made the right call… the API makes clear distinctions between the different types.” – rmunn

These four themes capture the bulk of the conversation: the excitement around real‑world adoption, the appreciation for a cleaner, immutable API, the practical challenges of serializing Temporal objects, and the historical context that explains why the design looks the way it does.


🚀 Project Ideas

Generating project ideas…

TemporalBridge

Summary

  • Provides seamless Temporal support across Node, Deno, and browsers by automatically polyfilling missing features.
  • Simplifies adoption by handling environment detection, optional native fallback, and version compatibility.

Details

Key Value
Target Audience Node/Deno backend teams, full‑stack JS developers
Core Feature Automatic polyfill injection, environment detection, optional native fallback
Tech Stack TypeScript, Node.js, Deno, V8, existing Temporal polyfill
Difficulty Medium
Monetization Hobby

Notes

  • Users like bnb and CharlesW mention “can't wait for it to land in the server‑side runtimes”.
  • “What a journey!” and “Only a matter of time…” show eagerness to adopt.
  • A single npm package that works everywhere would remove the current friction.

TemporalJSON

Summary

  • Offers automatic JSON.stringify and JSON.parse with a reviver for Temporal objects, preserving prototypes and enabling round‑trip without manual conversion.
  • Works out of the box with tRPC, GraphQL, and any JSON‑based API.

Details

Key Value
Target Audience Full‑stack JS developers, API teams
Core Feature Custom replacer/reviver, schema‑less roundtrip, integration helpers
Tech Stack TypeScript, Node.js, browser
Difficulty Low
Monetization Hobby

Notes

  • VanCoding, tshaddox, and others lament “JSON.parse(JSON.stringify(...))” losing prototypes.
  • The library would eliminate the need for manual Temporal.from() calls on every boundary.
  • A small, well‑tested package would quickly become a standard in Temporal‑heavy projects.

TemporalEase

Summary

  • Provides a fluent, concise API for Temporal, e.g., Temporal.now() returning a ZonedDateTime, chainable methods, and shorthand constructors.
  • Reduces verbosity and improves developer ergonomics while retaining type safety.

Details

Key Value
Target Audience Front‑end and back‑end JS developers
Core Feature Wrapper functions, shorthand constructors, chainable API
Tech Stack TypeScript, Node.js, browser
Difficulty Medium
Monetization Hobby

Notes

  • Commenters like hungryhobbit and tshaddox criticize the verbosity of the current API.
  • A small wrapper that keeps the full Temporal semantics but offers a cleaner syntax would be widely appreciated.
  • Auto‑completion and IDE support would make the transition painless.

TemporalScheduler

Summary

  • High‑level library for defining recurring events, time‑zone aware scheduling, DST handling, and conflict detection using Temporal.
  • Provides recurrence rules, next‑occurrence calculation, and calendar integration.

Details

Key Value
Target Audience SaaS, calendar apps, scheduling services
Core Feature Recurrence engine, timezone support, Temporal integration
Tech Stack TypeScript, Node.js, optional WebAssembly for performance
Difficulty High
Monetization Revenue‑ready: subscription per user or per API call

Notes

  • Discussions about “Report KPIs for each shift” and DST complexities highlight the need for robust scheduling.
  • Existing solutions often rely on Date or custom logic; this library would provide a standards‑based, Temporal‑native foundation.
  • A SaaS offering could expose the engine via a REST/GraphQL API, monetizing the recurring‑event logic.

Read Later