101–110 of 266 posts
I see that immutability is major concern for backward incompatibility, however over years I've become so much used to moment js that I wish I can still use their API's. Can someone explain why is it so hard to release a completely new version that isn't backward compatible? We could as well use different naming so that it doesn't conflict with last versions. moment3().now()
Good for them. Open Source seems to have an irrational fear of done . Done is good. Done should be the goal. But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned , dead . To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” I wish the was a way to fix this attitude. So that project maintainers didn’t need to write tw…
Older open source was more okay with this, but it's a huge issue with the modern JS/github model, where quality is measured by recent updates, "stars" within the last month etc.
A big "Thank you!" to the developers of Moment.js. For the last 8 years or so it has always been the first library I included in any new JS-project. I didn't even bother looking for alternatives, so I didn't know about Intl, Luxon & day.js until today. The size of the library has always been one of these things where I thought that the benefits outweigh the costs, and I knew that it wouldn't be like this forever. To…
While the browser won't convert it automatically, this is what the HTML ⁰ tag is for. The publisher can use 2020-09-15 10:26:48 and include a script which will read the datetime attribute and convert it to the browser's local time zone.
⁰ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
Good for them. Open Source seems to have an irrational fear of done . Done is good. Done should be the goal. But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned , dead . To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” I wish the was a way to fix this attitude. So that project maintainers didn’t need to write tw…
Is this really what a "done" software is? "Should not be used for new projects" is not "done" imo, it's more like "unfixable" and "obsolete". No prejudice at all against Moment.js or its devs, but this is essentially what they're saying. And the purpose and tone of the article does not seem to be an apology at all, but rather simply setting the expectations for future work so that the maintainers don't have to answer…
I think it is. It basically solved all the problems that were there at its inception and the world moved on. It continues to offer a solution for the original problems (which legacy software most likely still has) and can still be used with minimal engineering effort.
I would call that done.
A big "Thank you!" to the developers of Moment.js. For the last 8 years or so it has always been the first library I included in any new JS-project. I didn't even bother looking for alternatives, so I didn't know about Intl, Luxon & day.js until today. The size of the library has always been one of these things where I thought that the benefits outweigh the costs, and I knew that it wouldn't be like this forever. To…
Earlier quoted context omitted.
> One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does…
You might benefit from flipping this around and asking yourself why you're not able to ship software that remains shipped without intervention. And why you can't even imagine a world where that would be possible. If you spend some time and effort removing whatever obstacles you have in place that are keeping you from being able to do that, you'll have a lot more free time to spend building new things. For what it's w…
Every project that I do; even experimental and “unending” projects are done as “ship-quality.” This is because I often revisit previous work, looking for snippets. If they are already at “ship” quality, then that’s one less problem.
I’m also a grizzled veteran of “the prototype becomes the product.” That’s something that many of us have experienced. It sucks, but it’s real. If the prototype is already “ship-quality,” then that’s one less problem.
I tend to tag ongoing projects, so the head may be dynamic, but cloning a tag will generate a stable release, or branch point. That’s a fairly typical Git workflow. I’m not a fan of too many branches. I used the Mainline Model (a Perforce pattern) for years, but I like no more than two branches, these days (dev and master, and sometimes, dev can be in a private repo, squashing to master). Often, I only have one branch. If I create a branch (like a retrospective fix to a release tag), I merge that branch back into master, or apply the same fix to master (not my preferred pattern). I will, occasionally, create experimental or exploratory branches, which are short-lived, and designed to be reintegrated with master. Again, not a unique workflow. This will be familiar to many folks.
So, lots of “done,” as mileposts on a continuum. In some cases (like when I am preparing course materials), I may do a lot of work in a dev branch, and squash over to master, in order to reduce the “noise” in master, but the “done bits” are always tags in master. I always reintegrate back to dev, so the branches remain in sync, and the tags propagate to dev.
One exception to the “continuum model,” is that fix tags may be in small, short-lived branches. If possible, I try to add the tag to master, at the reintegration point, but that isn’t always practical or safe, especially if I can’t actually reintegrate, but have to introduce the fix as new code, down the road.
Since I have started using the Swift Package Manager, this has been a good fit. I believe that many package managers rely on that pattern, so I don’t think the way that I work is especially creative or standout. Pretty much garden-variety configuration management.
Speaking of package managers, I often extract subprojects from my work in the master branch, as I progress, spinning them off as standalone package projects, with their own project lifecycle, and reintroduce them as dependencies. This gives me little pockets of “done,” that have encapsulated state and identity (and their own repo), along with focused testing. Each project I spin off, is one less thing to worry about, and another tool on the pegboard, for future projects.
So, in my case, “done” is really just a signpost along the road, but there can be many signposts.
TIL: Intl.DateTimeFormat [1] has good browser support [2] and allows for nifty tricks like > new Intl.DateTimeFormat('zh', { hour: 'numeric' }).format(new Date) [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... "MDN: Intl.DateTimeFormat" [2]: https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... "Can I Use: Intl.DateTimeFormat"
The whole Intl namespace is a godsend.
Only Chrome seems to have actually implemented the spec this strictly, they don't want to change it: https://bugs.chromium.org/p/chromium/issues/detail?id=104579...
Earlier quoted context omitted.
This isn’t me disagreeing with the design decision, this was their own explanation for why you shouldn’t use Moment.js in the future. My point was that the reason we’re transitioning away from it is because of technical reason, not because it’s not being updated.
I'd been complaining about these issues for years. I kinda hate being vindicated years later, the time in between as an outsider kinda frustrates me. I wish we had a more thoughtful, less packrat culture in programming. Fighting off the pushback is exhausting. It's not even worth bringing things up most of the time. And as a disclaimer to those feeling tempted, I've got zero interest in debating this reality, water i…
The important thing to keep in mind that we don't know which of today's counter-culture takes will end up winning (I don't say "being right" because cultural evolution is, like biological evolution, not teleological).
In other words, you had a belief, and in hindsight you were "vindicated". But there were many others who had equally strong beliefs that were not.