Yesterday afternoon at a friend's hackathon, I built a website where you can see an aggregated view of Hacker News. You can check out who the top posters are (both regular submissions and Show HN'ers), what interesting things they posted, and what the top posts in general are.Data gets updated from the Hacker News BigQuery database.If you have any requests for things to add let me know!
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.
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!
We've been having a hard time getting feedback on our docs. Some people post GitHub issues or send us pull requests, but we've heard that the friction is too great for little things like typos, etc.We thought Vercel's preview might be a decent solution to lower the friction for people with Vercel accounts.Vercel injects a code bundle into the site, similar to a browser extension, automatically...
When they use our CLI to watch the file system for changes for live-reload or to build their extension, etc., that's a Node.js program.
The build target is browser Javascript, though.
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]
[1]: https://docs.plasmo.com/#where-is-the-manifestjson-file
[2]: https://docs.plasmo.com/workflows/env
[3]: https://github.com/PlasmoHQ/examples/tree/57791e70549441e391...
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.
[1]: https://github.com/PlasmoHQ/plasmo/blob/main/packages/parcel...
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.
https://github.com/PlasmoHQ/plasmo
Hey HN, we're excited to have people try out our framework! When we built out a Chrome extension earlier this year, we noticed that the config was too imperative. You had to constantly tell Chrome via the manifest.json file where your files were, what your permissions should be, etc.So we thought it might be interesting to build a more declarative framework. When we built a proof of concept, we...
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.