How easy is it to detect that this is automation as opposed to a real user? I suppose probably pretty easy, so not sure if it is useful if I want to automate the web for things I do every day as I would really be running the risk of turning off access to those things if they determined I am automating them.
Helium: Lighter Web Automation with Python
41–50 of 53 posts
Re: Helium: Lighter Web Automation with Python
#42Earlier quoted context omitted.
That's how Playwright works too
Doesn't work for logging into HN: from playwright.sync_api import sync_playwright playwright = sync_playwright().start() browser = playwright.chromium.launch() page = browser.new_page() page.goto('https://news.ycombinator.com/login?goto=news') page.get_by_label('username').fill('mherrmann') # playwright._impl._errors.TimeoutError: Locator.fill: Timeout 30000ms exceeded. I suspect Playwright expects there to be a for…
I like what you're doing with Helium, and while you are technically correct that it's half as long - IMHO it's a bit disingenuous considering that in any meaningful web automation script, you'd only need to put in the initialization code a single time, e.g.:
from playwright.sync_api import sync_playwright
playwright = sync_playwright().start()
browser = playwright.chromium.launch()
page = browser.new_page()Re: Helium: Lighter Web Automation with Python
#43Thanks for posting. All this AI has been interested in scraping personal sites.
I have actually been wondering whether Helium's more high-level API lends itself well for use by AI.
This. Seems like you could wedge this and a model into a scrappy version of computer use for browsers.
Fwiw, thanks for contributing this. It seems apt for a number of repetitive things I probably do dozens of times a week and don't even notice as cruft anymore.
I'm not sure why there were such hot takes on what this is or isn't. Maybe Big Selenium crisis actors? You made something cool, you shared it w/ world -- that should be the system prompt for people posting about it in my kinder world of things.
Re: Helium: Lighter Web Automation with Python
#44Earlier quoted context omitted.
Just like what you've done with Selenium, such a wrapper could be written for Playwright (I think that's what most developers end up doing anyways, just in a more domain-specific manner)
This project was started long before Playwright existed. I's an OSS tool that had very good reason to be made the way it was at that time, and continues to be useful (in my opinion).
It is a useful tool, similar to others that accomplish the same task (WATIR and Capybara in Ruby, for example). My point was that the comparison of a wrapper to an underlying library is a bit apples to oranges, as a similar wrapper could be written for Playwright as well. I haven't looked at the code, but I assume Helium's API could be used to support Playwright (which itself was an evolution of Puppeteer).
Re: Helium: Lighter Web Automation with Python
#45for lightweight automation outside the browser: https://github.com/elyase/screenium
macOS only (uses Apple Vision framework)
I've used SikuliX[0] in the past for similar purposes. Unfortunately the author hasn't had much time to maintain it recently.
Re: Helium: Lighter Web Automation with Python
#46How easy is it to detect that this is automation as opposed to a real user? I suppose probably pretty easy, so not sure if it is useful if I want to automate the web for things I do every day as I would really be running the risk of turning off access to those things if they determined I am automating them.
This is a wrapper on top of Selenium, so unless the library implements additional techniques to improve stealth, it's on par with Selenium's detectability (which as you pointed out can be detected easily enough)
Re: Helium: Lighter Web Automation with Python
#47Selenium project founder here. (Hi!) Thanks for all your work on this project. Lots of negativity around here these days, but just wanted to say thanks. The functional style of Helium's API reminds me a lot of Selenium's original API when it was 100% JavaScript (aka Selenium 1 aka Selenium Core) back in 2004.
(Functional style: "method(thing)" vs object oriented style: "thing.method()")
We mostly abandoned the functional style when we merged with the WebDriver project (aka Selenium 2), but that functional style still lives on in the Selenium IDE record/playback tool.
That is all to say, there are fans of many different styles for automation APIs. No single API will please everyone. (But I personally like the simpler, functional style, fwiw!)
Side-note: This is also why I'm a fan of the Nim programming language. "method(thing)" and "thing.method" are supported syntax for literally the same thing. For others new to the idea, the fancy term for this is "Uniform Function Call Syntax".
Re: Helium: Lighter Web Automation with Python
#48Importing * is universally discouraged by most Python linters and best practice docs. You can always "import helium as h" if you're looking to type less. This looks largely like common workarounds that most people will write using Python-based browser automation. Most of the time, we accept that those capabilities aren't there by default because they are not explicit enough and can result in bugs and undefined behavi…
It would be much more useful if you tried out the tool before criticizing it
Or, if you have tried it, if you could explain why you don’t think the tool makes the right tradeoffs
Adages like “explicit is better than implicit” are incredibly context dependent, otherwise we’d all be writing assembly
Re: Helium: Lighter Web Automation with Python
#49How can a wrapper around selenium be lighter than it? A wrapper around an API is by definition heavier (more code, more functions) than using the lower level api. It’s not using less resources. It’s not faster (it has implicit waiting). It’s not less code; it’s literally a superset of selenium? Feels like a “selenium framework” is more accurate than light weight web automation? Anyway, there’s no fixing automation te…
> but, personally, as it stands all I can really see is “makes easy things easier with sensible defaults”. “Lighter” may be used as an alternative adjective to the word easy or easier. Your post, which comes off as very rude, misses the point of how the project is marketed. At least the OP did not call it Python automation for humans …
> “Lighter” may be used as an alternative adjective to the word easy or easier
That is, again, not common usage, there’s a word for easier to use; it’s “easier”. but whatever. It doesn’t matter; it’s just branding.
My point however, is that making easy to use frameworks for test automation is fundamentally misguided, and the responses like “try it, you’ll be amazed it makes all the problems go away” is the type of “drinking kool aid” that’s displays a deep lack of understanding of the problem space.
Doing easy things does not solve doing hard things; not here. Not in go. Not in rust. Not ever.
So, my point was (and is):
How does this address doing hard things because as someone who is familiar with this space and has tried it, I can’t see anything that helps with the hard things and no one who is heavily invested in automation realllly cares about doing easy things.
We can already do easy things
Another way of doing easy things is like using prettier or not; it’s a style preference.
So, is that what this is?
Selenium with a function calling style preference, or something that actual helps building automation?
There’s nothing wrong with making tools that make superficial cosmetic changes to the way you do things.
…but, that’s not how the project is marketed; as, at least, I’ve understood it.
Re: Helium: Lighter Web Automation with Python
#50That looks useful. How does it know which box is the user field? Just read label and assume the one below that or to the right of the label?