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

Yes it does...

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 argue that the goal is to have this "simple DSL that looks like english" so that normal people can use it.

This argument has existed since DSL exist, and the result is always the same:

- the simplicity of the language will, in the end, limits its usefulness. Not every domain is like SQL/HTML/CSS, where descriptive is enough. Complex domains need branches, loop, namespaces, etc. Eventually you will be forced to add features in a twisted way to something that was not designed for it and replace its simplicity with ugliness, or restrain yourself and be limited forever. See Ansible DSL for a good, or rather, horrible, example of that.

- end users that can't use a normal programming language won't suddenly become tech saavy because your DSL is simple, but their use case will never stop at simple. So they will start building complex systems as soon as they use it for real, with a limited DSL and their limited ability. The system will become a monstrosity, and you'll have no tooling to help.

- successful dsl are usually not simple. Css is not. Sql is not. Html is an exception because it has no logic. This has logic.

- it looks so cool. It's like candy for tech lovers. Even to me: I find it so sexy. And so people will adopt it, ignoring the arguments above. Ignoring the decades of such attempts that ended up in pain behind so many corporate firewalls. There will be many tweets at adoption to talk about how nice it is, but no blog post 2 years later to admit it was a bad idea. And then it will happen again with $new_shiny_dsl_based_tool.

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 env.

2 is probably not solvable: automatic testing it hard, you need to be tech saavy to do it.

But let's say you still want to solve 2, a better approach would be to solve 1, then solve 2 by creating a GUI that let users record their actions and generate code from 1.

Such API and GUI exist, as you said, but they could be improved by tenfold.

It's boring work though, and working on a DSL is much more cool.

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/