userscript.zone: search for userscripts by URL, domain or search term | Hacker News Reader

userscript.zone: search for userscripts by URL, domain or search term

userscript.zone

56 pointspizza16 comments

Here's a free project idea for someone. I really want to implement but probably don't have the time to, so I'd like someone else to make it:

    userscripts + pyscript => script any web page using python

this is a bit of a convoluted example but e.g. imagine you want to be able to grep web pages visually, boom just write a userscript that uses CLIP to find the DOM element you are looking for, whether that's visually or with just text.

or if you want semantic text search, or even something simpler like find all the text matching

   x.isnumeric() and 10000 > int(x) > 5000

or imagine reading a blog post and you want to annotate interactively/play a bit with the ideas presented. imagine you could insert some jupyter cells inlined between the article paragraphs, with full matplotlib plots and everything, then save and export the annotated article to be shared with others

Does JS really have a higher entry barrier than Python?

It's less so about lowering the barrier of entry and more about

- vastly multiplying the number of available libraries at one's disposal to tweak the browsing experience

- less wheel reinvention and writing less code

Uh… you know there are rather a lot of libraries for JavaScript too? For general-purpose computing, and even more so for web stuff?

It sounds to me like the body of what you’re wanting is the ability to execute code outside the browser. That would, of course, be rather hazardous for security, and there’s a reason why user script managers don’t expose such a thing. But it’s not actually all that hard to do, especially if you’re willing to take the form of running an HTTP server on localhost and treat that as an FFI boundary.

In case you thought otherwise: PyScript will not run anything like CLIP, which makes liberal use of non-Python code. You could conceivably compile something like CLIP to WebAssembly, but it would certainly be slower, probably vastly slower; or perhaps JavaScript + WebGPU would be a better target.

Uh... Is it so hard to accept that people like using different languages for different things?

I understand there are challenges that may make this idea infeasible or just not worth the maintenance effort. But if it existed, I would definitely try it. I like python. I don't like JavaScript as much. I have hundreds of small python projects from which I can draw experience and code samples. If I could use those directly in a browser, I could do some neat stuff. Or, I could re-implement them in the JavaScript ecosystem. But I have never done that. Because it's not fun for me.

My point is that, generally speaking, what pizza is asking for doesn’t practically increase the libraries available (I would expect that JavaScript already has equivalents for the vast majority of the applicable pure Python libraries—and libraries that aren’t pure Python won’t work), and doesn’t solve as much as you’d hope in the way of wheel reinvention and writing less code (in fact, I’d categorise the entire effort as wheel reinvention and writing more code, though I acknowledge the library versus end user distinction in this regard). Your second paragraph reinforces my very point; pizza was saying it’s not so much about lowering a barrier of entry, yet that’s the majority of what you’re wanting it for.

If you need libraries or packaging, yes. Gulp, browserify, babel, etc. There are a lot of pre-processors, any number of which may end up being necessary to use certain libraries. That can be pretty complicated.

Such an initiative would involve reimplementing/proxying the entire set of browser APIs to Python: not only would that be a huge undertaking maintenance-wise for the developer of that project, but also, for any Python dev wanting to write userscripts, the learning curve for the new Python API wrappers would be much much higher than just learning JS.

If you like CLIP, just writing CLIP.js would be much much easier (and have more applications).

> x.isnumeric() and 10000 > int(x) > 5000

   isFinite(x) && 10000 > x && x > 5000

Learning another C-like scripting language when you already know one is really not very difficult (certainly hella easier than learning a new set of platform APIs).

I think that is pretty much the goal of pyscript: https://github.com/pyscript/pyscript/blob/main/docs/tutorial...

Bidirectional python<->javascript communication, + the entirety of the python ecosystem

reimplementing/proxying the entire set of browser APIs would mean such things as DOM, the CSSOM, the browser specific JavaScript APIs, the SVGOM, the accessibility tree and probably a few other things I'm not thinking of at the moment, so a lot more than just JavaScript being understandable by Python.

However I suppose it could be done with Ghost.py or similar library?

That project looks very cool - definitely a good starting point if you want to achieve this as a proof-of-concept at least, as that project looks very advanced & mature.

I didn't say it wasn't possible. It's just going to be inefficient, high-maintenance and have a steep learning curve.

> + the entirety of the python ecosystem

Worth noting: you would only be able to use "self-contained" or "pure" libraries from the python ecosystem; any Python-only APIs in use for IO won't translate to a browser environment (or will need explicit re-implementation to map them to something different).

It's essentially about learning the difference between IO API surface (DOM/W3C web APIs -vs- Python File IO/networking/etc.) and language syntax (PEP vs ECMA). Syntax translation is the (relatively) easy part - API mapping is a massive moving target, as well as an added learning curve for programmers using your system.

Being able to use user scripts in a browser is amazing - got some that improve my youtube experience for example.

Does this differ from GreasyFork[1] at all? They have been around for a long time and also have a search by site feature.

[1]: https://greasyfork.org/en

https://www.userscript.zone/search?source=index&q=news.ycomb... was the one that popped in my mind, obviously.

The <title> of the front page is Home. I now have a bookmark called Home.

The irony is that you could use a userscript to fix this userscript search engine's title. With something like: document.title = "not home";

Reply on news.ycombinator.com