Live data from Hacker News

Show HN: Kasaya – A scripting language and runtime for browser automation

github.com

41–50 of 109 posts

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#42

Earlier quoted context omitted.

The whole point of this is the scripting language, there are already lots of other browser automation tools out there.

A scripting language is not a goal in itself (although in the case of a DSL, it often is unfortunately because of the coolness factor), solving a problem is. Here the problems it tries to solve are: 1 - to have a nicer API to do automation 2 - for non tech saavy users to be able to create tests My take on this is that DSL are a wrong answer to this. 1 can be solved with a better lib, with a better API, or a dedicated…

> A scripting language is not a goal in itself

Agreed, I think this is a case where people forget “what is the problem I’m trying to solve” and instead get lost in a means not an ends.

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#44
post #21

I am confused by the use of "WYSIWYG". It seems to be more a control console/REPL with Natural Language syntax. Edit: A killer feature would be autocomplete for things found on the page.

> Edit: A killer feature would be autocomplete for things found on the page. Challenge accepted!

IMHO it would also benefit from a "raw typing" mode. It's a bit silly to have to explicitly write 'type "cat"' and 'press "enter"', when you're already typing 'cat' and 'enter'.

You could simply start this raw mode with a keyboard shortcut, and everything you type is automatically transformed into this "type" and "press" commands, until you exit the mode with either the same shortcut or Esc.

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#45
post #32
post #14

This looks great. I also want to shamelessly plug something similar I am working on, Taiko, it uses javascript and comes with a REPL that generates scripts like. await openBrowser(); await goto("http://todomvc.com/examples/react/#/"); await write("automate with taiko"); await press("Enter"); await click(checkBox(near("automate with taiko"))); The reason we use a javascript is familiarity, IDE support and use of exist…

Your sample code looks like a puppeteer script.

Close, but Taiko has a flat API. For reference here's a script in puppeteer

  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});

  await browser.close();
and the same thing in Taiko

  await openBrowser()
  await goto('https://example.com');
  await screenshot({path: 'example.png'});
  await closeBrowser();

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#46
post #40

Earlier quoted context omitted.

Note that some sites block Selenium, since browsers report the use of WebDriver, and Selenium injects known predictable Javascript. Does Kasaya do anything to mitigate this?

Not yet, but someone suggested Chrome DevTools protocol. This is still in the very early stages, so we're looking into these things.

I wonder why don't use Puppeteer[1], which is a established project for automating Chromium using Chrome DevTools protocol.

[1]: https://github.com/puppeteer/puppeteer

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#47

Looks cool for really simple things but wouldn't use it for anything serious. I have been using Cypress[0] the past few months and so far I've been quite pleased with it. [0] cypress.io/

Is it suitable to do automation? They seem to be mentioning testing only.

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#48
post #45
post #32

Earlier quoted context omitted.

Your sample code looks like a puppeteer script.

Close, but Taiko has a flat API. For reference here's a script in puppeteer const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://example.com'); await page.screenshot({path: 'example.png'}); await browser.close(); and the same thing in Taiko await openBrowser() await goto('https://example.com'); await screenshot({path: 'example.png'}); await closeBrowser();

so I can't work on multiple pages in parallel?

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#49

All those kind of projects share the same flaw: it uses a DSL instead of an existing language, so tooling/documentation/testing/support/modules are going to be very weak, and 100% depending of the creator for the first years, in a domain that is already a niche. It could be a library with good API instead. Or even a special env setup for an existing language with injected built-in and automatic imports. Now you could…

All these kinds of HN comments share the same flaw: they unnecessarily detract from the work the OP has done by attacking use cases that the project never claimed to solve.

DSL's, for all their problems, do simplify complex programming logic, and people use them every day to do great things. DSL's like Ansible and Chef save people an order of magnitude of time for server provisioning hence why they are wildly popular.

It seems reasonable to me that someone would build a DSL with the same goals for web browser automation. The screen recording example gif they have looks so intuitive even a non-programmer could do it.

I don't look at this project and expect that it solved every problem with web scraping and reading the README it doesn't look like they are claiming it does either.

Re: Show HN: Kasaya – A scripting language and runtime for browser automation

#50
post #45

Earlier quoted context omitted.

Close, but Taiko has a flat API. For reference here's a script in puppeteer const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://example.com'); await page.screenshot({path: 'example.png'}); await browser.close(); and the same thing in Taiko await openBrowser() await goto('https://example.com'); await screenshot({path: 'example.png'}); await closeBrowser();

so I can't work on multiple pages in parallel?

It seems that way.
Post reply on HN