Live data from Hacker News

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

github.com

61–70 of 109 posts

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

#61

Earlier quoted context omitted.

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.

Even though I know how to program, I really like Ansible and probably wouldn’t have gotten into it if it had the same functionality but used Python instead of YAML.

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

#62

Earlier quoted context omitted.

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.

Building infrastructure is complicated. Have you found an easier way then Ansible to accomplish building infrastructure?

Ansible does make yaml more complicated, however, you don't need to use much of that complexity for simple projects. Compared to Terraform, Chef, Google Deployment Manager, and Windows Desired State Configuration, Ansible is by far the simplest to get up and running on to do real work with.

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

#63

Earlier quoted context omitted.

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.

Building infrastructure is complicated. Have you found an easier way then Ansible to accomplish building infrastructure? Ansible does make yaml more complicated, however, you don't need to use much of that complexity for simple projects. Compared to Terraform, Chef, Google Deployment Manager, and Windows Desired State Configuration, Ansible is by far the simplest to get up and running on to do real work with.

AWS CDK would be an example of using a programming language rather than a DSL to build infra.

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

#64

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…

Some of us legitimately believe DSLs are rarely the right choice. We don’t say this to shit on people’s work, we say it to kick off a conversation about API design.

I’ve written DSLs in the past. I was a Rubyist! I have come to some perspective on those choices in the intervening years. I’m a big fan of functions that take arguments, and I am skeptical of hidden shared state.

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

#65

Earlier quoted context omitted.

Building infrastructure is complicated. Have you found an easier way then Ansible to accomplish building infrastructure? Ansible does make yaml more complicated, however, you don't need to use much of that complexity for simple projects. Compared to Terraform, Chef, Google Deployment Manager, and Windows Desired State Configuration, Ansible is by far the simplest to get up and running on to do real work with.

AWS CDK would be an example of using a programming language rather than a DSL to build infra.

There's also Pulumi that covers a wider range of infrastructure than AWS only.

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

#66

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…

Absolutely the current version seems very limiting, but as they start adding more and more features towards Turing completeness, it will become just as complex as a normal Turing complete programming language. Which in many ways undermines the original promise.

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

#67
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…

FYI to avoid all those awaits and make it chainable you can wrap it in a Proxy. https://github.com/kozhevnikov/proxymise

Or ppipe, if you want more features (I'm the author):

https://github.com/egeozcan/ppipe

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

#68
post #43

> pronounced Kuh-SAA-yuh That's ambiguous and not helpful – particularly in English that has many varieties and also too many vowel phonemes to map onto letters. Use IPA instead.

I agree. Kuh-sha-ya in Sanskrit means a decoction made from any herb(s). And despite knowing that, I was a bit befuddled about how to pronounce the word, until I saw the logo.

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

#69
post #29

Earlier quoted context omitted.

I actually kind of really like this DSL, I think it is going to be easier for my QA team to use this, than asking them to use javascript.

Seriously, how is this DSL better? With JavaScript you get method completion and debugging. Are parentheses really so terrible? You can setup a DSL in scala.js and you can get the best of both worlds (though, parentheses are fine for me so I would just use one of the many fine existing JS libraries).

> With JavaScript you get method completion and debugging.

a) now your QA team needs to know JavaScript

b) method completion is crap when you don't know the language.

c) "You can setup a DSL in scala.js and you can get the best of both worlds" OMG You want to add Scala to the mix too? AND write your own DSL from scratch, and take on its maintenance to support your QA team's needs instead of leveraging an existing one?

your solution:

1. teach the QA team Javascript interaction with custom scala created dsl

2. have the dev team spend time creating a dsl

3. have the dev team devote some of its resources to maintaining the new DSL

their solution:

1. use english-like DSL much easier to learn than JS

2. that is already created

3. that someone else maintains

both solutions are going to have limitations in that what you want the DSL to do will be more than the DSL can _currently_ do.

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

#70

Earlier quoted context omitted.

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…

Some of us legitimately believe DSLs are rarely the right choice. We don’t say this to shit on people’s work, we say it to kick off a conversation about API design. I’ve written DSLs in the past. I was a Rubyist! I have come to some perspective on those choices in the intervening years. I’m a big fan of functions that take arguments, and I am skeptical of hidden shared state.

You can be skeptical of DSL's but still recognize that they provide a time/complexity trade-off. I agree that it's probably not the right decision to write your own DSL for something but to dogmatically crusade against all DSL's feels silly to me when there are so many popular projects using them.

Ansible is popular because it is accessible to devop type roles (previously known as sysadmin or IT services) that may know some programming but would fail to produce results nearly as fast if they were simply left with python libraries. It would not be as popular as it is today if it were simply a python library.

Criticizing this project for using a DSL as it's interface over some programmer purity test BS is completely missing the forest for the trees.

Post reply on HN