Hacker News Reader

Comment by ranting-moth | Hacker News Reader

I was writing an extension a few weeks ago. I decided to go with MV3.

Most of the examples and documentation said something like "this has been copied from the MV2 documents or example. It might not work." It was awful.

I felt MV3 is really about limiting what the extensions can do.

I ended up having it Firefox only and MV2. Probably works in Chrome too, but I wasn't going to waste time on it since it was about to be removed.

View on HN

> I felt MV3 is really about limiting what the extensions can do.

You felt that way because that's exactly what it's about. It's about doing everything possible to increase ad revenue in the name of "increased security".

I developed an extension[1] after the Chrome Store stopped accepting MV2, but before Firefox support for MV3 in stable. I had to write some custom build scripts to build the extension with MV2 for Firefox and MV3 for Chrome. Pretty annoying.

[1]: https://github.com/b0o/aws-favicons-webextension

Yeah the state of Chrome's extension API documentation is awful. It needs to be totally reorganized and partially rewritten. I'm hopeful that MDN will become a better resource as Firefox becomes more compatible with the APIs. It's already more helpful in some places.

Funny, I've been using the MDN docs and took a look at the Chrome docs today. Some of the conceptual info was easier to track on the Chrome docs where the Mozilla side seemed to jump too low level too quickly.

Ideally, those docs should just be in one place so writing Chrome/Safari/Firefox extensions should just work.

> the Mozilla side seemed to jump too low level too quickly

This is literally my only complaint about MDN, and it’s only a complaint when I’m in a hurry. The sprawling body of standards MDN documents are almost all fairly low level and intended as such, and MDN mostly does a good job of balancing the low level details with good boilerplate examples. I can’t say how this is for extensions on any version, but if the MDN docs continue apace I’d be surprised if they don’t at least adequately answer this “should” as shortly behind a stable spec as anyone could wish for.

I wish XML-related tech was such a hot documentation commodity… guess I better contribute as I go :)

Hey! What things related to xml are you working on? I for one went through the signing and stuff and it was pretty rough going.

I maintain the Enketo[1] projects for ODK[2]. The latter is a little more flexible and stable on the XML front, but the former is currently in the position of using a lot of nonstandard XML tooling despite being well positioned to use existing browser tech, and at the same time may be better off migrating to many of the same abstractions ODK already uses.

1: https://github.com/enketo

2: https://github.com/getodk

All of Google's documentations are awful.

I spent a few days on a pet project using the Google Sheets API and the official docs use a mix of 3 different versions of libraries, none of which are really up to date, and you have to guess which is the right one.

They don't care about developers.

They put in quite some effort into writing the docs but then they often leave them to rot. Broken links and invalid code.

You'd have thought that a company the size of Google would have their public documentation problem totally solved by now.

It's more than just good stuff rotting. It's a fundamental lack of care, or maybe inability to ship anything that represents a big iteration. On the Google Analytics side, they are preparing to turn off data collection from the existing version of Analytics in 6 months and have been telling everyone to migrate to the new version for months now - but their "migration guides" are missing crucial technical detail, fall out of sync with the state of the new product a mere month or so after publishing, or contradict each other. It's like the whole effort of documentation has just been outsourced to the world of blogspam. Meanwhile, they started aggressively pushing for users to migrate their data collection when the new product itself didn't support some of the most basic use cases that needed to be migrated. Something is just off with Google's ability to ship these days.

MV3 has some changes that are genuinely good, even if those may feel inconvenient to develop for, mixed in with the genuinely bad. For FF you can get the best of both worlds though since their MV3 implementation isn’t removing the controversial deprecations/plans.

I'm in a similar boat, wrote a MV2 plugin for firefox, started looking at MV3 got confused about which bits are going to be usable and which are not and when. Ends up being too difficult.

From a extension creator perspective, it might be better to just pull all mention of MV3 on the MV2 pages until it's properly baked.

FYI Firefox is ditching MV2 too, they are keeping web request blocking but they will deprecate v2

Yeah, it's in the nightly and going to GA Jan 23 according to the latest blog post on it.

> MV2 will continue to work. We have not made decisions about MV2 deprecation yet. We want to see what the response and adoption of MV3 is from the community next year and will then make decisions about the future based on that.

https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-mi...

https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...

I guess they are following Chrome migration plan by delaying the inevitable

I don't think that says anything about concrete plans for ditching MV2 yet?

Reply on news.ycombinator.com