Hacker News Reader

Comment by hliyan | Hacker News Reader

The web seems to be becoming paradoxically less and less machine/automation friendly. I recently had to modify 150+ accounts in a Google Workspace. Twenty years ago, I would be doing this in a Unix environment with a very simple shell script. Instead, I had to click-copy-paste-click, 20 times per page, like a monkey. I'm sure there must be some sort of API, but it would have taken 100 times the time it would have taken to write a simple command line script. In the quest for more and more human eyeballs, the web is becoming less and less machine friendly.

View on HN

> The web seems to be becoming paradoxically less and less machine/automation friendly

Less distributed/democratized machine/automation friendly... But definitely automation friendly for giant search scrapers, with lots of compute, cash, IP blocks and AI.

I'd like to change that. I originally created BrowserBox^0 as a platform to serve "web scraping authoring tools". These tools are normally served as extensions, or even downloadable electron apps. But what about something easier to distribute, more powerful, more lightweight, and less beholden to walled-garden gatekeeping? BrowserBox changes all that, as it's clientless and runs in a regular web browser even on mobile. Anyone can build a scraping script on top of it, even from your mobile device while riding the bus. That's the vision anyway. But I got side-tracked by how the "embeddable browser" is a useful product in its own right. I still intend to return to fulfilling its original purpose however.

The key is to build a good "extensions-like"-but better-API atop the Chrome DevTools protocol and our BrowserBox functionality. We're open source so come visit if you'd liked to get involved or check it out! :)

0: https://github.com/BrowserBox/BrowserBox

https://github.com/GAM-team/GAM

> GAM is a command line tool for Google Workspace admins to manage domain and user settings quickly and easily.

I need this about once per year, but every time it's invaluable.

Your general point definitely stands - there is a pretty nice third party solution for google workspace though: https://github.com/GAM-team/GAM

I doubt how many admins are comfortable with (or allowed to) using a non-approved third-party tool to manage their organization, despite open source and all that

The third party tool is based on the official google-api-python-client. It’s about as non-approved as ad hoc shell scripts.

> It’s about as non-approved as ad hoc shell scripts.

That's not a fair comparison. There's a big difference between your own ad hoc shell script (or command line or whatever) that you fully understand, and downloading and running third party code without any kind of audit.

Meanwhile, the industry keeps talking about "software supply chain".

`src/gam/__init__.py` alone is over 3 MB of code that's not from `google-api-python-client`. Combine all the ad hoc shell scripts I've ever written and it probably wouldn't be that much.

> I'm sure there must be some sort of API

There is, but somehow, rather than being a workspace API, it's a GCP api ; and so if you want to use it, there is a big step to climb.

You can automate a lot of that stuff in the DevTools command-line, using basic DOM APIs. It's not ideal, but it allows you do to most of the things you'd do manually (click things, read text, write to textboxes) and it's easy to learn.

User experience has long been superseded by developer experience. You can see it in how both camps operate, dev tools are snappy command line apps but end users get electron slop.

Reply on news.ycombinator.com