Very cool stuff! I might check this out for my extension (https://github.com/herrherrmann/omnivore-list-popup). So far, I’ve been creating my own scripts to manage the extension builds, dev mode etc. – but I’ve been eyeing web-ext already to make my life easier. However, my main browser is Firefox, which doesn’t seem fully supported yet by Extension, right?
You can run your Mozilla Add-On on Chrome or Edge by adding a --polyfill flag, but for now you need to manually add the extension to Firefox. I do plan to support Firefox in the near future, but no browser runner available at the moment.
In particular, navigating the conflicting requirements for `manifest.json` would be useful, e.g. the difference between event pages and background service workers, or permissions that are inconsistently required/forbidden.
I don't know exactly what the the person you're replying to had in mind, but support for different parts of the manifest varies (especially in Manifest V3). While it's possible to write a single manifest that works in all browsers (with warnings), doing so requires more than a little specialized knowledge.
For example, Firefox does not currently support the `optional_host_permissions` top level manifest key. To work around this, developers can declare their optional host permissions in both the `optional_host_permissions` array for Chrome compatibility and in the `optional_permissions` array for Firefox/Safari compatibility.
Another example is that currently only Chrome supports `background.service_worker` in stable releases. To work around this, developers can write their MV3 background scripts in a way that's compatible with both service workers and event pages, then declare both in the manifest like so:
Yep, that's it! I settled for generating the manifest.json through a script, since at some point adding something only supported by one browser would cause an error in the other, though I think that may have been remedied now.
I'm confused. I've written an extension, already (just for Chrome, all Javascript). Getting started was simply a matter of copying a few files from the Chrome extension documentation site. I haven't done anything to configure an IDE, but I don't know what I should want to do.
I'm trying to understand what your tool does, above and beyond copying a few files. Is it cross-browser support? multi-language support?
In your case, Extension.js can help by managing the configuration details that are usually overlooked in general web development.
After copying a few files from the Chrome extension documentation site, you'll need to manually enable "developer mode" in your browser and add these files. If you make changes to your code, seeing the updates live requires manually reloading the various contexts that a browser extension can influence. Additionally, if you want to test your extensions on multiple browsers, you must do this manually for each one.
If you plan to use package dependencies like TypeScript or a JavaScript framework, you'll either have to rely on an existing abstraction framework for extensions and learn new techniques, or create your own configuration using tools like webpack, Parcel, esbuild, or another code compiler. At this point, developing browser extensions can become complex and frustrating.
Extension.js simplifies this by automating the process of bundling an extension in a browser ready for development. It comes with auto-reload support for every context, including parts of the browser that are not HTML/CSS/JavaScript. It also has built-in support for code dependencies such as TypeScript and React, where a simple installation enables your extension to have support without any setup wizardry. And it runs on multiple browsers at once.
Hope that clarifies things, and I'm happy to answer more questions :)
The biggest difference, in my opinion, is that Plasmo is a framework, which means you have to learn its abstractions and rely on specific samples tailored for these abstractions to create new extensions. There are config files and specific rules to follow that are not necessarily related to browser extensions.
On the other hand, Extension.js allows developers to create extensions using the standard extension APIs and abstracts only the configuration files, without the need to learn the tooling specifics. This way, a sample from Chrome or MDN that works with a manifest file as the source of truth requires no refactoring to work with Extension.js, making it easier to get started and prototype new projects.
Okay I love it, I feel like you should also sprinkle your magic on extension<>tab communication. Whenever I make an extension, it's always such a pain to read from the DOM or send a message from the extension to the active tab.
Looks good! I'll give this a swing on my own extension Vim for Docs. Firefox not being supported is a bummer, but it's not like there is a build tool for extensions that does support both Firefox and chromium based browsers.
Absolutely amazing! When I was developing a chrome extension all I could think of was a severe lack of dev-tools. I'll try it when I get the opportunity.
Please read these quotes from these links to better understand why it’s not wrong.
“Extension is a plug-and-play, zero-config, cross-browser extension development tool for browser extensions with built-in support for TypeScript, WebAssembly, React, and modern JavaScript.”
“WebExtensions are a way to write browser extensions: that is, programs installed inside a web browser that modify the behavior of the browser or web pages loaded by the browser. WebExtensions are built on a set of cross-browser APIs, so WebExtensions written for Google Chrome, Opera, or Edge will, in most cases, run in Firefox too.”
well... you just gave me a reason to rebuild my Bluesky extension from scratch, without a dependency from the original extension I used to get my base opengraph running. Bluesky OGraph Poster
Not to take away from the simplicity of use, of course, totally giving it a go. I think this is an awesome foot in the door for people who never considered developing extensions.
Agreed. It would be more fair to call it chromium only. I don’t consider that cross browser as any chrome extensions defacto works on any chromium browser
It has often been called "WebExtensions" or "WebExt" for a long time [1].
I wasn't even aware that it's just referred as "browser extensions" on MDN [2] now (..and the URL still uses "WebExtensions" and it's all over the actual article content. So I don't know.)
To me, 'WebExt' represents a specific specification within the broader category of browser extensions. However, since all major browsers now support this specification (and this only), it has become the de facto standard.
I hope someone more familiar with this topic can provide a more precise explanation
"WebExtensions API" is the genericized term coined by (IIRC) Mozilla, for the (subset of the) originally-proprietary browser extension API surface exposed by Chrome, that non-Chromium browsers (Firefox, Safari) have since added support for in order to be able to support easy porting of originally-Chrome-targeted extensions.
Basically, until ~8 years ago, there were only three browsers of note with browser extension APIs (Chrome, Firefox, and Safari); and they were all proprietary and all different, so developers had to code each extension from scratch for each browser. And developers of major extensions mostly did.
But then Chromium-based browsers like Brave and Opera and Edge became a thing, and they all inherited de-facto support for what they at the time called "Chromium-style extensions." With this, the Chrome extension API effectively "won" the browser-extension-API developer-mindshare war without really meaning to. Developers became less and less interested in porting their extensions, instead opting to just focus on Chromium-based browsers, since not only was Chrome the majority of the market, but Chromium-based browsers comprised a large fraction of the remainder.
Rather than Mozilla and Apple "solving" this by coming up with some artificial new eleventh-hour browser-extension API standard to foist on Google through the WHATWG (that would have required every dev rewriting all their code), Mozilla and Apple both did the pragmatic thing, and "embraced and extended" Chrome's own extensions API, locking in "whatever Chrome was doing at the time" as now being a conventional cross-browser API. That API, going forward, was referred to in the Firefox and Safari docs — and eventually the Chrome docs as well — as the "WebExtensions API" (mostly so that Mozilla and Apple didn't have to say the words "Chrome" or "Chromium" anywhere in their docs.)
A browser saying that it supports the "WebExtensions API", means that it exposes certain browser-extension APIs in JS under the chrome.* namespace, with Chromium-compatible semantics. Yes, Firefox and Safari both present themselves as Chrome to browser extensions, up to and including answering to the name "chrome" rather than "browser" in JS. Wild, isn't it?
Note, however, that these browsers do still also expose their original, incompatible extension APIs under the browser.* namespace. And if you write your JS carefully, you can attempt to make use of these per-browser features in your extension, while gracefully degrading to a WebExtensions baseline.
I’ve been pretty happy with web-ext, I’m curious what abstractions and configurations Extensions.js avoids comparatively. I’m assuming you’ll still need a manifest.json, and it looks like both use npm/package.json for dependencies.
Yes, the manifest.json is a required file for all extensions, and the package.json file provides necessary package metadata.
web-ext is excellent, but it seems there are no plans for the project to support more browsers than it currently does. On the other hand, Extension.js plans to support all major vendors.
Except for Firefox support, which is in progress, I believe Extension.js offers parity with all core functionalities of web-ext, but it goes further by providing built-in support for React and TypeScript. All you need to do is add the correct dependencies to get up and running.
Additionally, Extension.js provides comprehensive extension reload support, including changes to the manifest.json file and the service_worker background. This feature sets it apart from similar tools, including web-ext, which do not offer this capability.
I've made a couple of (admittedly trivial) Chrome extensions to tweak things on sites I use. I didn't really spend any time configuring the compilation config (not sure what that is) or frameworks. I'm guessing the reason for needing something like this is for handling complicated dependencies and cross-platform stuff?
The main issue I've run into is that I have no idea how to hook into and modify the behavior of fancy modern web sites with all of their React and Angular and Snorfleflox. I was kind of hoping this was for that. Is there some sort of framework that makes that stuff easier, or failing that, a really good tutorial for an experienced but a little out of date web developer to get up to speed?
IMO MutationObserver's API is a bit difficult to grasp. For simpler cases for getting a callback when an element is created, I use spect[1] or sentinel[2].
You can wimp out and just use MutationObserver as a way to get a callback whenever anything changes, ignoring all of the mutation records. Then in the callback, look up all of the elements you care about. The API is pretty simple then. It may be less efficient, but usually when you're mucking about with existing web pages, you're not all that performance sensitive. (And MO batches up updates reasonably well, so it's not like you're running the callback once per change.)
Occasionally it might even be faster, since you're not iterating through the mutation
records and testing for stuff you care about.
> The main issue I've run into is that I have no idea how to hook into and modify the behavior of fancy modern web sites with all of their React and Angular and Snorfleflox. I was kind of hoping this was for that. Is there some sort of framework that makes that stuff easier, or failing that, a really good tutorial for an experienced but a little out of date web developer to get up to speed?
I've written extensions (L I N K S I N B I O) which significantly modify Twitter.com (which uses React Native for Web) and YouTube (which uses web components), which are both SPAs - the main tips I'd give are:
1. Which page am I on?
In an MPA extension or userscript, you just check the current URL and go. In an SPA, you could go as far as patching the pushState() method on History (although you can't do this from an extension's content script - you would need to inject a page script) and watching for popstate events to detect URL changes, but I've found using a MutationObserver [1] to observe the contents of <title> to be a simpler proxy for the current page changing.
When the <title> changes, check the current URL to see if it's one you've already handled, and if not, start making your modifications. This also gives you a natural place to put any teardown logic, such as disconnecting active observers and cancelling any async actions which may be in progress for the previous page, such as waiting for elements to appear.
The target app may even have custom events you can hook into. YouTube has these, for example, but I found they were being fired at the same time the <title> was being changed whenever the user was navigating to a different page, so I stuck with the implementation-independent approach.
2. When are the main elements I care about available?
You'll need some utility functions which allow you to wait for specific elements to be available in the current page, either as an indicator the page is ready to modify, or because you need to do something with their contents.
This could be as un-smart as writing a function which returns a Promise wrapping document.querySelector() calls at regular intervals, or uses a MutationObserver to wait for a specific element to appear, then resolves with it, but there should be lots of existing open source utilities like these available out there (some have already been linked to in this thread).
I ended up writing my own version of these so I could specifically control stopping waiting for an element based on a timeout and/or other conditions, e.g. immediately resolving the Promise with `null` if the current URL has changed at the next available interval.
3. When do the elements I care about change?
Use the MutationObserver API [1] to watch for child elements being added/removed, or for specific attributes being changed.
It's kind of clunky, so you may want to write your own convenience wrapper - this is also a natural place to facilitate storing active observers for a later teardown. I've found I usually end up with at least a pageObservers collection, which makes it easy to disconnect everything which is currently being observed when the page changes.
e.g. I use a MutationObserver on the element which contains Twitter timeline contents to watch for the current window of visible tweets being changed so I can do things like hide quotes of specific tweets or hide Retweets from the Following timeline.
4. Hiding things in an SPA-friendly way
Removing elements which UI libraries such as React expect to be under their control when some state changes at a later time can lead to errors, so I've found it best to use CSS where possible to hide things, and even adding your own class names to use as styling hooks. It can also just be more convenient than writing code to manually remove things from the DOM.
e.g. Twitter uses React Native for Web's styling system, which takes CSS-like style objects and generates utility-like style rules from them (it's like Tailwind in reverse) - this means there aren't any developer-friendly class names to use as styling hooks, so on some pages I add my own. If I open my own user profile, <body> will have 'Profile' and 'OwnProfile' classes on it, which I can use to hide the "Articles" and "Highlights" tabs, which are there purely as Premium upsells.
I haven't done a lot of userscript dev, but based on my experience so far, all of this advice is spot-on.
I found it useful to create a `waitForElement(query)` helper function that takes a CSS selector path and returns a Promise that resolves when the query starts finding a match in the DOM. (Internally, it's just populating a table that is iterated over in the MutationObserver callback.)
As for SPA "navigation", I had trouble with popstate events. I hadn't considered your <title> trick; I'll bet that would have worked for me! Right now, I'm polling window.location.href every half second, which sucks.
Minor feedback: please consider an option to exclude emojis from the cli output. I can appreciate wanting to add some character here and there, but the output of ``npx extension create my-extension`` seems very noisy.
fwiw, in my experience, Safari is a much bigger annoyance to release extensions on than all the other platforms, and has the more differences is release process. So I'd expect this browser to be supported last.
What is it with "I made a _______" posts? Those seem new to me and very braggy. I see them on youtube as well. I feel like if I could check all the posts to HN I'd find a trend of instead of just "Show HN: A tool/app/site to do X" there's a tread of adding "I made" in front. Is that a result of social media conditioning, that you must brag that "I" made?
I can't speak for youtube given that I don't really actively browse it, but I'm not sure how it's "braggy" when the entire purpose of "Show HN" is to demo things that were made by the person posting it (https://news.ycombinator.com/showhn.html):
> Show HN is for something you've made that other people can play with.
At most, it's redundant, but not in a way that hurts anyone.
https://news.ycombinator.com/item?id=1381172 is the oldest one I could find via the algolia search at the bottom of the page, from 2010, so it's not that recent a phenomenon. A different reading is less that the emphasis is on I made a thing, and more about being a complete sentence with an explicit subject vs implicit.
I don't have a problem with people bragging about a thing they made. I think if someone spent a bunch of time on a thing, I'll give them time to be proud of the work they did and give them space to show off.
if it's something I'm interested in. The difference between "ShowHN: I built a thing", and "ShowHN: thing" seems inconsequential to me.
But you know that one about how naming things is an unsolved problem in computer science? Looking at random search results, I think it's more about it being a more natural way to describe something. "Show HN: I built a thing that does blah", rather than "Show HN: Foobar, a thing that does blah".
If I do "Show hn: George", what's George? vs "Show HN: I made a thing that does foo called George"
Interestingly enough, there are only 805 results for "Show HN: We" vs 5,060 results for "Show HN: I", What a bunch of loners we are.
I see "I made X that does Y" as self promotion. You're not prmmoting X, your prmoting the fact that "I" made it. You're smart. People should take you seriously. They should offer you jobs and/or praise. Of course you're secondarily promoting X but only in the cause of promoting yourself
I see "X, an app that does Y" as promoting X and sayuhg "reader, you might find X useful if you want to do Y"
The purpose of the posts are entirely different.
Your observation on "We" is interesting though I suspect that teams are more likely to write "X, and app that does Y" because "We made X" doesn't achieve the self promotion goals in the same way as "I made X"
Another question is, why do you have such a problem with people promoting themselves? On the Internet, no one knows who your sockpuppet is. So if you come across a post that says look at this cool thing I found on the Internet, and you feel one way about it, vs someone says look at this cool thing I made, vs I'm cool, look at this thing I made, and then you feel a third way about the exact same thing.
You can run your Mozilla Add-On on Chrome or Edge by adding a --polyfill flag, but for now you need to manually add the extension to Firefox. I do plan to support Firefox in the near future, but no browser runner available at the moment.
Firefox Support Issue: https://github.com/cezaraugusto/extension.js/issues/5
For example, Firefox does not currently support the `optional_host_permissions` top level manifest key. To work around this, developers can declare their optional host permissions in both the `optional_host_permissions` array for Chrome compatibility and in the `optional_permissions` array for Firefox/Safari compatibility.
Another example is that currently only Chrome supports `background.service_worker` in stable releases. To work around this, developers can write their MV3 background scripts in a way that's compatible with both service workers and event pages, then declare both in the manifest like so:
```json { "background": { "scripts": ["background.js"], "service_worker: "background.js" } } ```
I'm trying to understand what your tool does, above and beyond copying a few files. Is it cross-browser support? multi-language support?
After copying a few files from the Chrome extension documentation site, you'll need to manually enable "developer mode" in your browser and add these files. If you make changes to your code, seeing the updates live requires manually reloading the various contexts that a browser extension can influence. Additionally, if you want to test your extensions on multiple browsers, you must do this manually for each one.
If you plan to use package dependencies like TypeScript or a JavaScript framework, you'll either have to rely on an existing abstraction framework for extensions and learn new techniques, or create your own configuration using tools like webpack, Parcel, esbuild, or another code compiler. At this point, developing browser extensions can become complex and frustrating.
Extension.js simplifies this by automating the process of bundling an extension in a browser ready for development. It comes with auto-reload support for every context, including parts of the browser that are not HTML/CSS/JavaScript. It also has built-in support for code dependencies such as TypeScript and React, where a simple installation enables your extension to have support without any setup wizardry. And it runs on multiple browsers at once.
Hope that clarifies things, and I'm happy to answer more questions :)
This could also be because this is my first browser extension development. https://chromewebstore.google.com/detail/bettermenu-for-door...
There is still lot more work to do, so I will checkout your project. Thanks for sharing!
I'm going to give this a try. I've been holding off on adding an extension to my app because of the absolute cluster that is Google Play.
https://www.plasmo.com/
The biggest difference, in my opinion, is that Plasmo is a framework, which means you have to learn its abstractions and rely on specific samples tailored for these abstractions to create new extensions. There are config files and specific rules to follow that are not necessarily related to browser extensions.
On the other hand, Extension.js allows developers to create extensions using the standard extension APIs and abstracts only the configuration files, without the need to learn the tooling specifics. This way, a sample from Chrome or MDN that works with a manifest file as the source of truth requires no refactoring to work with Extension.js, making it easier to get started and prototype new projects.
But it’s never a bad thing to have two projects solving a painful problem
I don't really use the framework stuff but HMR that works really well is just chefs kiss.
so I was wondering the same thing as GP, could this be a self-hosted plasmo of sorts
Every time i make a chrome extension i get massive imposter syndrome. It is so hard to create a new project for some reason. This would be awesome.
https://docs.plasmo.com/framework/messaging
“Extension is a plug-and-play, zero-config, cross-browser extension development tool for browser extensions with built-in support for TypeScript, WebAssembly, React, and modern JavaScript.”
“WebExtensions are a way to write browser extensions: that is, programs installed inside a web browser that modify the behavior of the browser or web pages loaded by the browser. WebExtensions are built on a set of cross-browser APIs, so WebExtensions written for Google Chrome, Opera, or Edge will, in most cases, run in Firefox too.”
> WebExtensions are a way to write browser extensions
Even if “technically correct”, the tool still specifically creates WebExtensions, it does not create “non-WebExtension browser extensions”
https://github.com/cezaraugusto/extension.js/issues/5
Firefox would be a MASSIVE win!
- Safari https://github.com/cezaraugusto/extension.js/issues/46 - Firefox https://github.com/cezaraugusto/extension.js/issues/5
To me, 'WebExt' represents a specific specification within the broader category of browser extensions. However, since all major browsers now support this specification (and this only), it has become the de facto standard.
I hope someone more familiar with this topic can provide a more precise explanation
[1] https://developer.mozilla.org/en-US/docs/Glossary/WebExtensi...
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[1] https://www.w3.org/community/webextensions/
Basically, until ~8 years ago, there were only three browsers of note with browser extension APIs (Chrome, Firefox, and Safari); and they were all proprietary and all different, so developers had to code each extension from scratch for each browser. And developers of major extensions mostly did.
But then Chromium-based browsers like Brave and Opera and Edge became a thing, and they all inherited de-facto support for what they at the time called "Chromium-style extensions." With this, the Chrome extension API effectively "won" the browser-extension-API developer-mindshare war without really meaning to. Developers became less and less interested in porting their extensions, instead opting to just focus on Chromium-based browsers, since not only was Chrome the majority of the market, but Chromium-based browsers comprised a large fraction of the remainder.
Rather than Mozilla and Apple "solving" this by coming up with some artificial new eleventh-hour browser-extension API standard to foist on Google through the WHATWG (that would have required every dev rewriting all their code), Mozilla and Apple both did the pragmatic thing, and "embraced and extended" Chrome's own extensions API, locking in "whatever Chrome was doing at the time" as now being a conventional cross-browser API. That API, going forward, was referred to in the Firefox and Safari docs — and eventually the Chrome docs as well — as the "WebExtensions API" (mostly so that Mozilla and Apple didn't have to say the words "Chrome" or "Chromium" anywhere in their docs.)
A browser saying that it supports the "WebExtensions API", means that it exposes certain browser-extension APIs in JS under the chrome.* namespace, with Chromium-compatible semantics. Yes, Firefox and Safari both present themselves as Chrome to browser extensions, up to and including answering to the name "chrome" rather than "browser" in JS. Wild, isn't it?
Note, however, that these browsers do still also expose their original, incompatible extension APIs under the browser.* namespace. And if you write your JS carefully, you can attempt to make use of these per-browser features in your extension, while gracefully degrading to a WebExtensions baseline.
https://github.com/mozilla/web-ext
web-ext is excellent, but it seems there are no plans for the project to support more browsers than it currently does. On the other hand, Extension.js plans to support all major vendors.
Except for Firefox support, which is in progress, I believe Extension.js offers parity with all core functionalities of web-ext, but it goes further by providing built-in support for React and TypeScript. All you need to do is add the correct dependencies to get up and running.
Additionally, Extension.js provides comprehensive extension reload support, including changes to the manifest.json file and the service_worker background. This feature sets it apart from similar tools, including web-ext, which do not offer this capability.
The main issue I've run into is that I have no idea how to hook into and modify the behavior of fancy modern web sites with all of their React and Angular and Snorfleflox. I was kind of hoping this was for that. Is there some sort of framework that makes that stuff easier, or failing that, a really good tutorial for an experienced but a little out of date web developer to get up to speed?
https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
You can hack on the behavior via userscripts, my preferred way to alter websites, though I write extensions too (greasemoney is good tho)
1: https://github.com/dy/spect 2: https://github.com/kubetail-org/sentineljs
Occasionally it might even be faster, since you're not iterating through the mutation records and testing for stuff you care about.
npx extension create my-react-extension --template=react
But I guess it doesn't make it any easier to modify the behavior of fancy modern web sites :_(
I've written extensions (L I N K S I N B I O) which significantly modify Twitter.com (which uses React Native for Web) and YouTube (which uses web components), which are both SPAs - the main tips I'd give are:
1. Which page am I on?
In an MPA extension or userscript, you just check the current URL and go. In an SPA, you could go as far as patching the pushState() method on History (although you can't do this from an extension's content script - you would need to inject a page script) and watching for popstate events to detect URL changes, but I've found using a MutationObserver [1] to observe the contents of <title> to be a simpler proxy for the current page changing.
When the <title> changes, check the current URL to see if it's one you've already handled, and if not, start making your modifications. This also gives you a natural place to put any teardown logic, such as disconnecting active observers and cancelling any async actions which may be in progress for the previous page, such as waiting for elements to appear.
The target app may even have custom events you can hook into. YouTube has these, for example, but I found they were being fired at the same time the <title> was being changed whenever the user was navigating to a different page, so I stuck with the implementation-independent approach.
2. When are the main elements I care about available?
You'll need some utility functions which allow you to wait for specific elements to be available in the current page, either as an indicator the page is ready to modify, or because you need to do something with their contents.
This could be as un-smart as writing a function which returns a Promise wrapping document.querySelector() calls at regular intervals, or uses a MutationObserver to wait for a specific element to appear, then resolves with it, but there should be lots of existing open source utilities like these available out there (some have already been linked to in this thread).
I ended up writing my own version of these so I could specifically control stopping waiting for an element based on a timeout and/or other conditions, e.g. immediately resolving the Promise with `null` if the current URL has changed at the next available interval.
3. When do the elements I care about change?
Use the MutationObserver API [1] to watch for child elements being added/removed, or for specific attributes being changed.
It's kind of clunky, so you may want to write your own convenience wrapper - this is also a natural place to facilitate storing active observers for a later teardown. I've found I usually end up with at least a pageObservers collection, which makes it easy to disconnect everything which is currently being observed when the page changes.
e.g. I use a MutationObserver on the element which contains Twitter timeline contents to watch for the current window of visible tweets being changed so I can do things like hide quotes of specific tweets or hide Retweets from the Following timeline.
4. Hiding things in an SPA-friendly way
Removing elements which UI libraries such as React expect to be under their control when some state changes at a later time can lead to errors, so I've found it best to use CSS where possible to hide things, and even adding your own class names to use as styling hooks. It can also just be more convenient than writing code to manually remove things from the DOM.
e.g. Twitter uses React Native for Web's styling system, which takes CSS-like style objects and generates utility-like style rules from them (it's like Tailwind in reverse) - this means there aren't any developer-friendly class names to use as styling hooks, so on some pages I add my own. If I open my own user profile, <body> will have 'Profile' and 'OwnProfile' classes on it, which I can use to hide the "Articles" and "Highlights" tabs, which are there purely as Premium upsells.
[1] https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
I found it useful to create a `waitForElement(query)` helper function that takes a CSS selector path and returns a Promise that resolves when the query starts finding a match in the DOM. (Internally, it's just populating a table that is iterated over in the MutationObserver callback.)
As for SPA "navigation", I had trouble with popstate events. I hadn't considered your <title> trick; I'll bet that would have worked for me! Right now, I'm polling window.location.href every half second, which sucks.
What is it with "I made a _______" posts? Those seem new to me and very braggy. I see them on youtube as well. I feel like if I could check all the posts to HN I'd find a trend of instead of just "Show HN: A tool/app/site to do X" there's a tread of adding "I made" in front. Is that a result of social media conditioning, that you must brag that "I" made?
> Show HN is for something you've made that other people can play with.
At most, it's redundant, but not in a way that hurts anyone.
if it's something I'm interested in. The difference between "ShowHN: I built a thing", and "ShowHN: thing" seems inconsequential to me.
But you know that one about how naming things is an unsolved problem in computer science? Looking at random search results, I think it's more about it being a more natural way to describe something. "Show HN: I built a thing that does blah", rather than "Show HN: Foobar, a thing that does blah".
If I do "Show hn: George", what's George? vs "Show HN: I made a thing that does foo called George"
Interestingly enough, there are only 805 results for "Show HN: We" vs 5,060 results for "Show HN: I", What a bunch of loners we are.
I see "X, an app that does Y" as promoting X and sayuhg "reader, you might find X useful if you want to do Y"
The purpose of the posts are entirely different.
Your observation on "We" is interesting though I suspect that teams are more likely to write "X, and app that does Y" because "We made X" doesn't achieve the self promotion goals in the same way as "I made X"
Human psychology is fascinating.