tschiller

Yep! We're also experimenting with small models to filter out sections that are irrelevant for the agent given its current goal/task

PixieBrix | REMOTE | https://www.pixiebrix.com

What if you could customize any web app to provide the perfect user experience?

Open positions (learn more at https://careers.pixiebrix.com/positions):

  - Lead Browser Extension Engineer (must ♥ reverse engineering)
  - Senior Front-end Engineer (Typescript/React)

Email [email protected]. We're Series A startup backed by NEA. Fully remote within ±3 hours of Eastern Time

PixieBrix | REMOTE | https://www.pixiebrix.com

What if you could customize any web app to provide the perfect user experience?

Make an impact on a small, growing, team that's open-source, post-revenue, and VC-backed by NEA

Open positions (learn more at https://careers.pixiebrix.com/positions):

  - Head of UX/Product Design
  - Senior Front-end Engineer
  - Lead Browser Extension Engineer (must ♥ reverse engineering)

Stack: Typescript, React/Redux, Python, Django/DRF, PostgreSQL

Email [email protected]. We're fully remote within ±3 hours of ET

PixieBrix | REMOTE | https://www.pixiebrix.com

Our mission is to give everyone the power to customize their technology to have the perfect UX. Our first product is a low-code browser extension builder (open-source under AGPLv3)

We recently raised a 3.5M seed from New Enterprise Associates (NEA)

Open positions (learn more at https://careers.pixiebrix.com/positions):

  - Product UI/UX lead
  - Developer Advocate 
  - Lead Web Engineer (must like reverse engineering)
  - Lead Backend Engineer

Stack: Typescript, React, Redux, Python, Django, PostgreSQL, DRF, Heroku, GitHub

Email [email protected]. We're remote within ±3 hours of ET

PixieBrix | REMOTE | https://www.pixiebrix.com

Our mission is to give everyone the power to customize their technology to have the perfect UX. Our first product is a low-code browser extension builder (open-source under AGPLv3)

We recently raised a 3.5M seed from New Enterprise Associates (NEA) and some incredible angel investors including Tableau co-founder Chris Stolte and DataRobot CEO Dan Wright

Open positions:

  - Product UI/UX lead (UI/UX designer who can code)
  - Community/education lead
  - Senior Backend Engineer - API/platform lead 
  - Senior Front-end Engineer

Stack: Typescript, React, Redux, Python, Django, PostgreSQL, DRF, Heroku, GitHub

Email [email protected]. We're remote within ±3 hours of ET

PixieBrix | REMOTE | https://www.pixiebrix.com

Our mission is to make it possible for everyone to customize the web to fit the way they work. (Think browser extensions and userscripts, but using sharable lego blocks)

Come be a founding engineer at a company backed by a leading VC and execs of major AI, business intelligence, and edutech companies

Open positions:

  - Senior Front-end Engineer
  - Senior Backend Engineer - Platform Lead 
  - Mid-Level Web Designer/Developer

Stack: Typescript, React, Redux, Python, Django, PostgreSQL, DRF, Heroku, GitHub

More information at https://careers.pixiebrix.com. We're remote within ±3 hours of ET

Author of the blog post here! If you comment with corrections/milestones I missed, I'll try to incorporate them

I'll also be attempting to update the augmented browsing/browser extension Wikipedia page in the coming weeks

That's a very cool bit of history! Adding it to my list of references/updates to make to the blog post

Thanks for the link! Adding this to the list of corrections I need to make to the Medium post

According to the spec, Bookmarklets should actually be exempt from a site's CSP. The reason is that the user's preferences should take precedence over a site's preferences

There's an open bug in Firefox about this (because it doesn't follow the spec): https://bugzilla.mozilla.org/show_bug.cgi?id=866522

Yep, the first style manager extension was released in 2005 (Stylish). Style manager extensions are a much more frictionless way to manage and share styles

The WebExtensions API has APIs for injecting styles: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Not an expert on this part, but I'd imagine that problem isn't having an API, it's more that running native executables is the problem if you can't sandbox them or limit their resource consumption. Also, relative to running Javascript, their base resource utilization per tab is significantly worse (especially for Java or .NET-based ones that have a base resource utilization from the VM)

Java falls under plug-ins. The Java plug-in was released in 1998. Flash was released in 1996

The safety/stability issue comes from the fact that plug-ins (e.g., NPAPI) are native executables

Browsers started dropping support for plug-ins around 2015. However, plug-ins actually held on longer than you might think. Firefox didn't completely drop support for Flash until the beginning of this year

The timeline of browser extensibility is quite fascinating. There's really not a single place that covers all of it, so I decided to research my own timeline/history:

  - Consumer web browsers (1993-)
  - Plug-ins (1995-2015ish)
  - User Style Sheets (1998-2019)
  - Bookmarklets (1998–)
  - Browser Extensions (1999–)
  - Mozilla XUL (1997–2017)
  - Alternative Browser Distributions (2004–)
  - Userscripts (2005–)
  - Converging on the WebExtensions API (2017–)
  - Manifest V3 (2021–)
  - No/Low-Code Browser Extension Builders (2021–)

Here's a link to the blog post with my research: https://medium.com/brick-by-brick/a-brief-history-of-browser...

Also, if you care about browser extensibility, join the w3 group (it's free) and watch the GitHub repo!

PixieBrix | REMOTE | https://www.pixiebrix.com

Our mission is to give everyone the ability to customize the websites they use to have the perfect UX. (Think browser extensions / userscripts, but using sharable lego blocks)

Come be a founding engineer at a company backed by a leading VC and execs of major AI, business intelligence, and edutech companies

Open positions:

  - Senior Front-end Engineer - Authoring Tools Lead
  - Senior Web Engineer - Browser Extension Lead
  - Senior Backend Engineer - Platform Lead 
  - Mid-Level Web Designer/Developer
  - Mid-Level Full Stack Engineer

Stack: Typescript, React, Redux, Python, Django, PostgreSQL, DRF, Heroku, GitHub

More information at https://careers.pixiebrix.com. We're remote within ±3 hours of ET

Their site has a lot of great content and research, but it's spread out across PDFs, many of which are single-page handouts for practitioners.

For example, here's their in-depth framing memo on STEM education: https://www.frameworksinstitute.org/wp-content/uploads/2020/...

It's available a couple links in from the corresponding "Toolkits" page: https://www.frameworksinstitute.org/toolkit/wiring-up/

Rhetoric is traced back to Mesopotamia: https://en.wikipedia.org/wiki/Rhetoric#History

The FrameWorks Institute is just a non-profit that's modernizing the study of rhetoric for modern political and social discourse

Great question. Our general approach is to look up the devtools browser extension for the framework, and use that as a reference point for determining how to interface with the framework

The most popular framework we haven't implemented support for yet is Angular. (AngularJS, the old version, is straightforward.) Any of the compiled frameworks, e.g., Google Closure Compiler are difficult because they mangle identifiers. I suspect Svelte might also be tricky, but we haven't tried that yet

At the end of the day though, every framework has to write to the DOM and be accessible. So you can use selectors, or in the worst case OCR/computer vision. (IIRC, FB actively inserts dummy elements to try to prevent structural scraping).

That's definitely the easiest when it's there. In some cases the microdata will instead be embedded in the HTML tags in the body: https://schema.org/docs/gs.html

For React and similar frameworks, the component names get minimized. In practice, JS compilers/bundlers can't mangle property names because 1) alias analysis is hard, and 2) property name string logic is ubiquitous in JS 3) the data often flows from APIs, and mangling would make API maintenance hard. Google's closure compiler and other static compilers are an issue.

As I mentioned in the post, dynamic CSS classnames are also tricky depending on how much gets mangled. We have some techniques in the pipeline for better handling those

Thanks for the links! Will check them out

As far as selectors go, we're currently working through how to support more specific selection when there's multiple HTML element alternatives for a single visual element (e.g., nested tags with no padding/margin).

This isn't too big of an issue for scraping text, but comes into play when pulling attributes, or when using the selectors to modify the page structure. (Our tool lets you place buttons, panels, etc., copying the style/structure from existing elements)

Author here, happy to answer any questions

For our product (PixieBrix) we actually generally grab the data directly from the front-end framework (e.g., React props). It's a bit less stable since it's effectively an internal API, but it means you can grab a lot of data with a single selector and can generally avoid parsing values out of text

As a browser extension, this is very possible to do securely (we support it for our extension pixiebrix.com):

1. APIs accessed authenticated via OAuth2, or via locally-managed credentials. (Browser extensions support this via https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...)

2. For data extraction and form fill, the data never leaves the user's browser