While I agree those areas are much nicer, most people still need to commute to go work in, and spend considerable amount of time in soma, fidi, etc.
I used to live in one of those areas you talk about, yet still was attacked and threatened several times in the span of 6 months during my commute to our office on Market street.
Hi HN! Excited to showcase a fun browser extension we built over the weekend. Lenses is a browser extension for Twitter that transforms all the tweets in your feed to make them match your mood.
We have a lot of ideas on how to make this problem a lot easier. It's a big reason why extensions aren't as big as they could be. Browser extension devs having to tinker and even think about the DOM or any other website-specific quirk is a leaky abstraction.
If it's an issue, people's usual approach to solving that problem is to create some mapping of "twitter-sidebar : some XPath selector" on the backend and have their extension query whenever they want to interact with the web page.
They'll have e2e tests to check if their selectors or xpaths still work. If not, they'll figure out what changed and modify the xpath. Some automate this step.
It's tricky because A/B tests are a thing, websites might change based on geographical region, and a bunch of other stuff that leads to users seeing different things in the DOM compared to the e2e test). Logging errors to something like Sentry mitigates some of this, but the complexity is still quite large.
It stems from the fact that frontends only consider humans, not robots. You either need to make your robot super resilient to change (above approach), make your robot act more like a human, have the website consider the robot ("Connect to Wallet", etc), or use the web app's backend API if it exists.
We're experimenting with all four of these approaches this year and seeing which ones are the most valuable to people, so stay tuned for more exciting extension stuff!
In his most recent testimony, Mudge mentioned that he was in the leaked OPM database with his details and clearance level leaked which implies he had clearance.
We use Parcel under the hood and are huge fans! Our framework has opinionated abstractions on top of it that we think help improve the extension development experience considerably.
Features we've built so far:
- manifest.json is generated automatically. If you want to create a content script, you name a file content.ts, and it'll auto-gen the right manifest key-value pair for it. Same with backround.ts. [1]
- Mounting a React component to the popup or options page is similar. You create a popup.tsx or options.tsx file, export a default React component, and it'll automatically associate it in the manifest and mount the component automatically for you.
- We support environment variables with .env files [2]
- We just released support to automatically inject a shadow DOM into a webpage and mount a React component from a content script [3]
- We have remote code bundling that automatically fetches URL based imports (like Google Analytics) in build time to mitigate issues with MV3 not allowing remote code [4]
Thanks! We wrote a custom Parcel runtime [1] inspired by Parcel's HMR runtime (which was too bloated and buggy for us) that injects a web socket listener into the development build of the extension.
Whenever a bundle change happens, Parcel sends it the refresh message and it either does `chrome.runtime.reload()` or `location.reload()` depending on the context.
There's standardization work being done at the moment with the W3C WebExtensions Community Group [1] which is definitely a step in the right direction!
Mozilla has also done some great work building a web extension polyfill library that attempts to abstract away the differences between the browsers [2] but the translation will always be imperfect, and edge cases are abundant.
It's definitely something we want to consider in the future! Right now, we want to focus on a single view framework and make the developer experience as seamless as possible with it. The framework we've chosen is React because we're most familiar with it.
That's awesome - feel free to email me (should be on my website) if you want to talk more. Can share some tips and tricks or answer questions you might have.
Thanks! Yeah it was fairly slow but we did some work to try to make it faster.
Our process was
1. Remove all JS and CSS from the HTML file
2. Compress the file into a gzip stream
3. Base64 encode the file
4. Send it as a stream of text messages with some metadata on sequence numbers, etc
SMS uses the GSM 03.38 encoding which is a 7 bit encoding. I think we were working on building a custom encoding scheme for it rather than using Base64's 6-bit encoding, but never got around to it.
I think reddit.com (back in 2014 when it wasn't so fancy as it is now) took about 20 text messages to load, so you can imagine it would take less than a minute.
In 2014, I had a similar problem so I created Cosmos Browser, an Android based internet browser which allowed people to connect to the internet via SMS. It's pretty much dead now, but wouldn't take a lot of work to revive it if you really wanted to.
You can buy some cheap 3.5mm earphones, cut the wire right in the beginning, and plug it into your microphone slot, and assign that as your mic. If you're on mobile, it'll automatically do it. Basically piping from /dev/null
I used to live in one of those areas you talk about, yet still was attacked and threatened several times in the span of 6 months during my commute to our office on Market street.