Well browser standards were pretty much gimped by microsoft during the IE5/IE6 era, so from 1998 until around 2010 there was no progress on standards and Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share.

From 2010 until about 2020 I would say the standard committee took hold and they have been quite busy with other things. Since JS is a language defined by committee it can take quite some time for people to agree on APIs which is a subjective topic. The last thing the standards body want is to introduce an API and then deprecate it in favor of another API slightly later.

> Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share.

Boy, it's a different company doing this now, but this is definitely still something that is happening, especially in mobile.

Not to the same level as back then, the closest thing would be Apple refusing to implement good PWA integration and Web Push Notifications (forcing people to use Apple Push Notifications which only works in Safari). PWAs are still (mostly) supported in Safari, they just don't integrate at the OS level in iOS.

Apple is still actively developing Safari and JSC and implementing standards, Microsoft basically COMPLETELY FROZE browser improvements for 10+ years. Worse even, they pushed proprietary Microsoft-only solutions to try to lock-in people.

Microsoft was MASSIVELY trying to make web applications a thing. They introduced HTML Applications[1] in 1999 (e.g. Electron). In 2001, they added the JavaScript features that let us have Gmail and Google Maps (XMLHttpRequest). They let you rebuild your Windows desktop or any folder as a HTML in Windows 2000/ME. They created a ton of APIs from web components[2] to CSS effects[3] in 1998.

However, when Netscape died, Microsoft did a 180 and went from the leader in promoting the web to the absolute worst obstruction. It seemed like they completely de-funded their IE development team.

[1] https://en.wikipedia.org/wiki/HTML_Application

[2] https://en.wikipedia.org/wiki/HTML_Components

[3] https://learn.microsoft.com/en-us/previous-versions/ms530752... (previously was just filter:)

Is Java not designed by committee?

> during the IE5/IE6 era

During that era was a peak of browser innovation. IE5 and IE6 contributed a lot of things to web standards. They contributed a bunch of things that web standards eventually rejected too, but that was the risk of innovation at the time.

It was the period between IE6's last feature update and IE7's first release where Microsoft declared the browser wars "finished" and disbanded the IE team entirely that was the Darkest Age. So about 2001-2006 were the darkest few years.

It certainly had repercussions until around 2010, but the worst "sabotages" were done and gone by then. "Legacy" problems.

I would say the darkest era was after IE7 was released: 2006-2010.

You could see all the new features, you could use them, you could design your site around them. But so many people refused to upgrade, so as a web developer you were forced to do stupid things to make IE6 work.

And it's not like IE7 was that much better. You needed to put effort into making that work too. At least Chrome and Firefox would usually both do the same thing.

> And it's not like IE7 was that much better.

The end of the dark ages was when IE9 was released in 2011 which massively improved the browser.

Javascript, for the longest time, was a _slow_ moving target - web browsers themselves had cross browser issues where API X might work on browser A but not on browser B.

There were so many bigger issues like that I think that made this not a high priority in the grand scheme of things.

I think a good example of this is jQuery - while jQuery is a good tool, a huge part of its usage was the quirks between browsers. Selectors and the class of problems jQuery solved had more immediate impact to web applications, so fixing and taking from it became a more immediate concern.

JS API -> moment/date-fn/luxon -> Temporal has the same kind of trajectory. Not that those libraries will now be immediately 'bad' mind you - just that the base API is more sane.

And for the longest time, nobody even considered javascript to be a serious tool; It was rare for anyone to write more than a hundred lines of javascript.

I remember when google introduced gmail in 2004. Suddenly google had done full single-page application in javascript, proving that not only was it possible, but that the resulting user-experience was awesome.

At the time, there were no javascript frameworks. Jquery (if you can even call it a framework) wasn't created until 2006. I don't think there were even helper libraries.

I mostly remember javascript from dynamicdrive.com, where you would go to find quick snippets of "Dynamic HTML" to copy/paste into your html. Sometimes there were useful things like roll-over menus, but I remember many of them being silly toys, like sparkles that would follow your mouse around the screen, or snow which would slowly cover the page.

excellent point. it took 6 years (!) for Backbone.js, arguably the first Javascript framework, to come out... and the same year AngularJS.

First rule of being a platform: Do Not Break Existing Code.

Well, Java did not break existing code, they added the new code alongside the old one. Just like JavaScript seems to be doing years later.

That's fair, but they didn't need to - just make a new Date library and deprecate the old one.

I've been a JavaScript developer since the nineties and I too have been puzzled about this very thing. Everyone has known Date has been broken for a very long time and a plethora of pollyfills and datetime libraries have sprung up to band-aid the situation but nothing ever got close to being resolved as major ECMAscript versions were released over the years. I guess if it takes 270 pages for MDN to explain it, it's a rocket science problem that's well over my head.

I think they thought they could get away with a hotfix like Intl.DateTimeFormat()

> Java replaced this implementation in 1997

If that date's correct, they replaced it with another flawed implementation. The 'good' one came much later: https://jcp.org/en/jsr/detail?id=310

> What are the forces at work here?

I feel like I'm always simultaneously engaged in about 5 HN threads at a time, advocating for some combination of immutability, type-safety, and/or no-nulls. It's basically all I do.

By and large, people simply aren't into it. "Because the world is shared and mutable" is a pretty common rebuttal:

4 hours ago: https://news.ycombinator.com/item?id=42876487

2 days ago: https://news.ycombinator.com/item?id=42850569

1997 would be JDK 1.1, which introduced the java.util.Calendar/GregorianCalendar classes. The Calendar API was an improvement in some use cases over Date, but it's biggest flaw was mutability. The current API is based on JodaTime and is very similar to Temporal.

and yet on threads about Elixir there seems a lot of people who care – rightly so, immutability it's great and Elixir makes the best out of it. Don't give up the good fight!

Going back even further in time, Java.util.Date was was heavily inspired by a C library.

That’s the origin of getMonth() in Java (and therefore in JS) returning a value from 0-11 and not 1-12 as many coders initially expect.

What was the origin for this peculiarity in C? That I don’t know, but I’m curious to find out if anyone knows.

Just spitballing, but in C it was always the convention to use zero-based indexing. Probably because you were often adding these indexes to pointers (literal memory addresses) to index into an array, so you needed a zero to index into the first slot of the array.

What I don't get is why the day of the month doesn't also start at 0?

C uses zero-based array indexing. A C array variable is a pointer to its first element, and an element index is just an offset from that. Element 0 is at start + 0, element 1 is at start + (1 * element size) etc.

Which why the fields of the 'tm' structure [1] (used to represent dates and times) are zero based§. Makes it easy to index into eg an array of day names using tm_wday. I guess at one time Java.util.Date was a leaky abstraction layer on-top of such an api.

§ Except for the tm_mday element, which curiously is 1-based. I've always assumed that this is because it is unlikely to be used as an array index. A long time ago I'm ashamed to admit that I used tm_mday == 0 as a quick check for an invalid tm value.

[1] https://en.cppreference.com/w/c/chrono/tm