Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 109 posts

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

#51

Post by zabil »

Normal_gaussian wrote: post #48
zabil wrote: 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?

You can open tabs, incognito windows and switch back and forth

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

#52

Post by exdsq »

SlowRobotAhead wrote: post #42
BiteCode_dev wrote: post #28

Earlier quoted context omitted.

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.

Depends if the goal was to make a scripting language and at the same time tackle a problem (or not). Some people like building stuff for the hell of it. A language by itself is an interesting non-trivial project.

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

#53

Post by [deleted] »

zabil wrote: post #45
DailyHN wrote: 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();

[deleted]

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

#54

Post by mherrmann »

zabil wrote: 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…

Helium author here. Thank you for mentioning us as an inspiration!

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

#55

Post by zabil »

maple3142 wrote: post #46
hliyan wrote: post #40

Earlier quoted context omitted.

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

Taiko was initially based on puppeteer, but it was hard to keep up with puppeteer's api changes.

Plus, the abstraction leaked. Taiko is now built on the excellent https://github.com/cyrus-and/chrome-remote-interface

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

#56

Post by threatofrain »

debaserab2 wrote: post #49
BiteCode_dev wrote: post #24

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…

Using Ansible is what made me lose faith in DSL's in all the ways mentioned (eventually wanted loops, conditions, variables and namespaces...). Ansible is an API over a domain and if it were originally just represented through a Python language library I don't see why it would be less accessible or productive. Even something as simple as YAML can be screwed up and turned complicated.

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

#57

Post by zabil »

mherrmann wrote: post #54
zabil wrote: 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…

Helium author here. Thank you for mentioning us as an inspiration!

Big fans. Thanks for creating Helium!

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

#58

Post by yachtman »

debaserab2 wrote: post #49
BiteCode_dev wrote: post #24

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…

All these kinds of HN comments share the same flaw, in failing to recognize that the primary obsession of hacker news is in discussing the flaws of things posted on hacker news.

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

#59

Post by someone7x »

languagehacker wrote: post #11

Would be great if this "transpiled" into a more robust and popularly supported formalism so that the functionality could be refined over time. I could see implementing this script as being a requirement for a new feature delivered by engineering, and then having test engineering use that functionality as a foundation for more thorough qualification. I worry that this approach by itself will fall into the same issues…

I think Selenium IDE is still around.

Its a drag-n-drop browser plugin that does everything Kasaya can do (both selenium under the hood) and can export to js/python/etc.

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

#60

Post by Normal_gaussian »

zabil wrote: post #51
Normal_gaussian wrote: post #48

Earlier quoted context omitted.

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

You can open tabs, incognito windows and switch back and forth

Is the tab switching synchronous? If not then I couldn't do it in parallel without inadvertently hitting the wrong tab.

If it is then its no better than using a page handle (as a handle would be required)

Post reply on HN