181–190 of 333 posts
When ever i see "never implement your own...", i know i want to implement it myself. People say that about hard things, and I only want to do hard things. Nobody wants people who can do easy things, people want people who can do hard things. The only way to learn how to do hard things, is to do hard things, so do the hardest things. So go ahead, write your own date library, your own Unicode font rendering, compiler,…
The bundle size reductions are impressive (230kB client-side savings!), and your RFC 9557 alignment is a smart forward-looking move. Two questions:
Edge cases: How does your parser handle leap seconds or pre-1582 Julian dates? (e.g., astronomical data) Temporal readiness: Will @11ty/parse-date-strings become a temporary polyfill until Temporal API stabilizes, or a long-term solution? Minor observation: Your comparison table shows Luxon supports YYYY-MM-DD HH (space separator) while RFC 9557 doesn’t – this might break existing Eleventy setups using space-delimited dates. Maybe worth an explicit migration note?
Regardless, fantastic work balancing pragmatism and standards. The web needs more focused libraries like this!
Earlier quoted context omitted.
I think that advice makes sense in the context of cryptography, where the consequences for getting it wrong can be quite serious indeed. I don't think it holds true for something as unimportant as a date parsing library.
Correct date handling (including parsing) can be monumentally important. Imagine an app that reminds people when to take their medications, for example
Earlier quoted context omitted.
In order to have these mature libraries, someone hat to start building them. They all had to to be incomplete, immature and horribly buggy early in their lifetime, too.
Why would I mature yours and deal with those issues when I can just use the already-mature one?
Earlier quoted context omitted.
Correct date handling (including parsing) can be monumentally important. Imagine an app that reminds people when to take their medications, for example
You typically take medication at a set time every day. You don’t need to parse dates for that.
2) Many people (especially the elderly) take enough medications on different schedules that managing them all would be a significant cognitive load for anyone
It’s just an illustrative example, though. My point is getting dates right (including parsing their string representations) often matters quite a bit. If you disagree, let’s argue about that rather than quibble about the minutiae of the example
I like such subtle branding. I will try 11ty when I need a static site generator.
All engineers please follow this example when you want to promote your product, even when you don't want to promote your product.
Earlier quoted context omitted.
I don't think tables are the hard thing. If you wanted to grow your wood, plane and dry it yourself, etc... then you'd be "hard way" building a table. I assume you use tools?
I mean, a table is as hard as you make it. I work with rough construction lumber, and make nice finished goods, my point was that people still do stuff that isn’t worth their time financially.
We aren't talking about the same thing: I stated "I don't think tables are the hard thing."
Note the word "the" in front of "hard thing" -- I'm referencing the article we're discussing, which mentions "the hard thing"
When ever i see "never implement your own...", i know i want to implement it myself. People say that about hard things, and I only want to do hard things. Nobody wants people who can do easy things, people want people who can do hard things. The only way to learn how to do hard things, is to do hard things, so do the hardest things. So go ahead, write your own date library, your own Unicode font rendering, compiler,…
The only way you understand X is by making your own X and trying to support it for a few decades, and our industry needs more people who understand X; fewer who just ask chatgpt/stackoverflow/google for "the answer".
Earlier quoted context omitted.
By all means, write it. Just don't use it. These warnings are almost always in the context of code you're going to release, not exercises in learning on your own.
I think that advice makes sense in the context of cryptography, where the consequences for getting it wrong can be quite serious indeed. I don't think it holds true for something as unimportant as a date parsing library.