Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: comparison with webdriver package #19

Open
thomasjm opened this issue Jan 31, 2020 · 3 comments
Open

Question: comparison with webdriver package #19

thomasjm opened this issue Jan 31, 2020 · 3 comments

Comments

@thomasjm
Copy link

This looks like a great package! I was wondering if you could clarify how this compares with the older webdriver package. It looks like this package is more directly aimed at complying with the W3C spec, and has a different API design (monad transformer vs. typeclass). I see there's a brief mention of webdriver in the README but it would be super helpful if you could say more about this package's motivation/differences/when to choose one versus the other. Thanks!

@thomasjm thomasjm changed the title Question: comparison with webdriver package / spec compliance? Question: comparison with webdriver package Jan 31, 2020
@georgefst
Copy link

georgefst commented Apr 15, 2022

I've just ported a (small-ish) project to this library, to avoid some of webdriver's limitations, so I may as well weigh in. In general, it's improved my code (apart from having to litter it with T.pack and T.unpack, see below about Text). And I can use Firefox! Which is crucial in my case, due to Chromium being broken on aarch64-linux in Nixpkgs.

Pros

  • Works from GHCI.
  • Better logging, making things easier to debug.
  • Supports Firefox. In fact, encourages it in examples.
  • Cleaner API (somewhat subjective).
  • More actively maintained (slightly).

Cons

I have more faith in these being solvable than I do in webdriver's limitations being overcome any time soon.

@hughjfchen
Copy link

Cons

For cross-build, I've done a fully static build with musl based on Haskell.nix without any problem except need to fix Aeson 2 dependency. What specific issues have you met?

@georgefst
Copy link

For cross-build, I've done a fully static build with musl based on Haskell.nix without any problem except need to fix Aeson 2 dependency. What specific issues have you met?

Yeah, okay, I'm being a bit fussier here and talking specifically about cross-compilation without Nix, which does have some workarounds for custom setups and TH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants