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

81–90 of 109 posts

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

#81

Post by gitgud »

nubela wrote: post #9

Interesting but I'm not sure about the syntax. If I'm writing code, why do I want to write code in a language that is overly verbose and not that precise? Just make it code. And if it is not meant for programmers, then make it clickable+drag-and-drop. Having a compromise in this case, makes it not a solution for anyone.

> Having a compromise in this case, makes it not a solution for anyone.

Drag n drop is surprisingly slow and limiting to use, it's also hard to implement etc.

I think this DSL is approachable for non-programmers. I envision bosses/clients using this to write tests for parts of website to make sure it works.

If they need more functionality, they can move to more complex browser automation later... if they need it

A specific use case, but I can see demand for it...

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

#82

Post by ajoy »

yachtman wrote: post #58
debaserab2 wrote: post #49

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…

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.

I would argue that thats the benefit.

I want people more knowledgable than me to comment and point out the flaws in products/reports/theories. Thats what I love about HN.

How critical are those flaws? It's up to you. If you take the approach of "there is no right or wrong, only opinions" when you read comments, it's much better off.

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

#83

Post by webignition »

ou_ryperd wrote: post #77

Test automaton guy here. Why reinvent the wheel? Selenium/WebDriver is already a standard ( https://www.w3.org/TR/webdriver/ ). It has years of maturity. Maturity means that through use and development iterations it can now cater for a lot of corner cases. How to do domain authentication in IE. How to handle all the different types of modal dialogues. And so on. It can be used in several different REAL programming la…

I'm currently developing a test automation DSL as part of a full automation service.

My partner worked for some time running on-site test automation courses. This was for organisations where the devs were average 9-5 workers without any passion for software development. Not the sort of places that would ever feature on HN.

Manual testers transitioning to automation testers within such organisations are, in most cases, fully incapable of doing so effectively.

Such testers cannot learn to code. Many could barely type with much proficiency. All were great people and great at manual testing, but coding was generally not what they were wired for.

There is a market for something easier.

It took me some time developing a plain-English DSL to realise myself that the majority of browser automation coding isn't coding.

You can abstract away the hard parts. What you're left with is not coding but configuration.

Given the right automation system you don't need to write code to define your tests, you instead need to configure the system to test as needed.

A DSL to replace current automation coding as-is is indeed an odd task.

A DSL for a minimal-grammar configuration language within an automation system can definitely work.

Will it work for everyone? No, absolutely not. Not you and not many who read HN. We're the outliers.

Will it work for boring dusty companies that we've never heard of and which can't afford to employ people who read HN? Yes, definitely.

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

#84

Post by plufz »

ajoy wrote: post #82
yachtman wrote: post #58

Earlier quoted context omitted.

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.

I would argue that thats the benefit. I want people more knowledgable than me to comment and point out the flaws in products/reports/theories. Thats what I love about HN. How critical are those flaws? It's up to you. If you take the approach of "there is no right or wrong, only opinions" when you read comments, it's much better off.

I would argue that trying to find flaws is flawed (atleast in this context). Much better to use a neutral approach where you are equally open to strength and flaws.

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

#86

Post by enjo »

masukomi wrote: post #69
amitport wrote: post #38

Earlier quoted context omitted.

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…

The other choice is that your QA teams knows this DSL tho. Which is the point: eventually most DSLs converge on the complexity of programming languages and you’re left asking: why not just use a well known programming language in the first place?

We’ve beat the Ansible example to death but it’s a really good one. It started as something simple and then with every edge case came the need for increasingly complex logic until it resembled a programming language just with super funky syntax.

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

#87

Post by rickyc091 »

holtalanm wrote: post #71
masukomi wrote: post #69

Earlier quoted context omitted.

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

1) if you are on a qa team writing automation, there is a high chance you already know javascript. source: was qa automation engineer for a few years. I realize it is purely anecdotal, but nearly all of the QA people I worked with knew javascript, even the manual testers.

My experience here is different. The majority of manual QA I've worked with do not have experience with automation, nor do they know JavaScript.

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

#88

Post by brutuz »

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…

These are actually valid points for any DSL creation. I have been working on DSL for a few years. More precisely I'm working on a DSL tool that allows people to create "simple DSL that looks like english" so that normal people can use it. Here are my thoughts on those arguments.

Indeed complexity is there for most real domains. But DSL is meant to be another abstraction layer on top of the complexity. My lesson is constraint is the most important as this lays the foundation of its usefulness. I don't mean you should not have things like branch or loop. You certainly could add them, just in a domain friendly way that doesn't hurt the readability and writability of your DSL.

In order to tackle arbitrary complexity, the DSL itself should be designed with extensibility in mind so that technical people could easily add language constructs or vocabularies by using script or general purpose language. Further, those features should be able to be turned off for some scenarios. For those inherently complex stuff, they should be left to general purpose language anyway.

Tooling support is another big problem. In my opinion, DSL is never just the tiny language, it is about the language and tooling. However the tooling requirement is often not as standard as general purpose language. Domain users normally don't need an IDE(an editor should be generally required) or debugger. Rather, they want something that can be seamlessly integrated with the host application.

And more over, different people (even in the same domain) may have different requirements on DSL maintenance, eg, governance, versioning. This often leads to a case by case customization. I do not have a good answer for this other than the general advice: treat DSL and tooling as a whole and make the API as easy as possible for integration.

Edit: For anyone interested in my DSL(still work in progress), here is a glimpse:

http://www.typezoo.com/docs/workflowrules/editor-2.gif

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

#89

Post by cryptonector »

threatofrain wrote: post #56
debaserab2 wrote: post #49

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 something as simple as YAML can be screwed up and turned complicated.

Your problem is that you think YAML is simple.

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

#90

Post by losvedir »

This is neat. I was just looking for something like this the other day.

Does it support loops? I don't see any example like that. Basically I wanted to load a search results page and check something about each of the results on the page.

Post reply on HN