Hacker News Reader

Comment by tmpz22 | Hacker News Reader

MomentJS may be an exception but any JavaScript project with a large number of node_modules or testing/distribution pipelines pinned to build systems like gulp or webpack are highly likely to break from year to year as they become incompatible with a version of node or one of the dependencies is taken over by a potentially malicious actor. For this reason any JavaScript ecosystem based project must receive increased scrutiny for this type of stuff.

Now give me a golang library that hasn’t been touched in four years and it would be a completely different situation (knock on wood go2 doesn’t ruin this).

View on HN

A significant issue though is that timezones change. For example the EU is ditching daylight savings time in 2021[1].

So actually there are many libraries and tools that could be done and just work forever, timezone stuff is much more dynamic than I'd ever realised.

FWIW I loved moment and made the move this year to date-fns[2] as I trusted browser availablity of the prerequisites enough to finally switch, and I do like working with it, but its focus on lightweight makes it less "magic" than Moment.

- [1] https://www.insider.com/europe-to-get-rid-of-daylight-saving...

- [2] https://date-fns.org/

(edit formatting)

The article specifically states that they're going to keep Moment-Timezone up to date. Which is important, because the timezone database has changed approximately 4 times a year for the last 5 years (https://mm.icann.org/pipermail/tz-announce/).

Let's just hope no random country decides to use 100 minutes an hour or something one day.

Like France and China did, once upon a time.

https://en.wikipedia.org/wiki/French_Republican_calendar#Dec...

https://en.wikipedia.org/wiki/Traditional_Chinese_timekeepin...

> So actually there are many libraries and tools that could be done and just work forever, timezone stuff is much more dynamic than I'd ever realised.

I think the parent’s point was that things like security updates still need to happen. So there may be scrutiny if you come across a package and there hasn’t been a change for a couple of years, in the JS ecosystem it would raise red flags for many. Maybe not so much in the Go ecosystem.

Yeah, active development is always a good sign. These days at least NPM shows popularity, quality and maintenance data in search, and flags up known vulnerabilities so you can at least see if a project is rotten, or just no longer maintained (which may be ok in some circumstances).

Well, they do say: "We will release data updates for Moment-Timezone following IANA time zone database releases."

EU ditching daylight savings time is unlikely to happen next year, as the legislation is only at draft stage and hasn't been finalised yet. The original proposal in 2018 called for it to end in 2019, but various industries pushed back saying that a transition would need more time. Because of Brexit (Ireland wants to use the same timezone as Northern Ireland, i.e. keep daylight savings time) and COVID-19 it's been delayed.

Precisely! Working with Erlang, I come across libraries that haven't been touched in years. Sometimes that means they're experimental projects that have been abandoned, but more often than not it means the're done. Complete. All bug fixed, all functionality implemented, stable, safe to use and unlikely to change. I'll take that any day over the twitchy, look-away-for-a-second-and-your-build-chain-is-broken JS way of things.

I think the only reason for a Go 2 would be to introduce breaking changes.

Reply on news.ycombinator.com