6 ms·

In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots,

In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots, and open source libraries. Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always. It's their way to stand out. So why is this more prevalent in JavaScript? Front end inherently has more new comers. Long time hackers or cs grads feel less of a need to prove themselves making free software? I think it's natural that the web programmers would understand web self promotion better than other languages. Guess who's better at Twitter? The js people! Why? They were writing the web to begin with! I wish it would stop. Our qa engineer is writing web driver tests in JavaScript and I don't understand why! There's nothing about testing that NEEDS to be async! The python API would likely be no slower and much easier to write and debug. Sane defaults are an important part of tech, and default async is a terrible setting. Python sync is easier, and Go routine concurrency is easier. Always on async just seems like a terrible default. For speed I'd do Go, and for all else Python.

Shanea93 10y ago
Just a minor off topic correction, since you made the mistake twice: "squeue" is actually "skew".
- nickstefan12 10y ago
  Thanks! I forgot to require the spellcheck module ;).
deleted 10y ago
[deleted]
jacquesm 10y ago
> The python API would likely be no slower and much easier to write and debug. But probably not for your qa engineer who most likely already (and possibly only) knows javascript.
- tscs37 10y ago
  Who needs more than one language? One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT? SINGLE STACK!! /s
  - smonff 10y ago
    Diversity for a richer ecosystem.
    - Roboprog 10y ago
      "/s" [End] Sarcasm :-)
  - greenshackle2 10y ago
    They (kind of) have a point though. I agree you should aim to be polyglot, but a particular project may not afford the learning curve if the dev doesn't already know the best stack. For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to learn it, but I'm uncertain I could pull it off in time. EDIT: Then again, it looks like I could realistically learn enough Go for this project in a weekend. Only problem is there could be data analysis, I know good libs in Python, don't know how hard that would be in Go.
    - tscs37 10y ago
      Well, it's certainly not something that needs to be avoided at all costs but in the long term it can be less efficient and more costly. It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.
      - greenshackle2 10y ago
        All hail LISP. My main problem with LISP is that I stopped liking Python after learning it.
inimino 10y ago
That explains why lots of libraries get written, but not why they get used.
- nickstefan12 10y ago
  the lack of a good standard library might have something to do with it. I'll admit im not sure.
  - falcolas 10y ago
    The shaming of mature libraries doesn't help either. Try showing off something with jQuery these days.
    - jjnoakes 10y ago
      Do you have evidence that jQuery is shamed because it is mature? I've always seen jQuery not chosen (shamed doesn't seem like the right word) because it doesn't provide the level of abstraction that folks are looking for, and because it mainly papers over cross-browser differences which get smaller every year.
    - lloyd-christmas 10y ago
      I honestly can't say I've seen any true jQuery shaming exclusive of the cherry-picked click-bait blogs. The only "shaming" I hear is typically post-interview justifications as to why someone wasn't hired, as if it might not simply be the possibility that someone else was more qualified.
    - warbiscuit 10y ago
      Yeah. I've just taken to ignoring those responses. As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit. Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself. (Still hate jquery's inconsistent ajax callback signatures. sigh.)
mbrock 10y ago
I made a shell WebDriver tool that makes it really easy to script the browser from the comfort of your command line. It's not fully polished yet, especially error reporting is a bit ugly, but it works and supports most of the WebDriver API. https://github.com/mbrock/wd https://github.com/mbrock/wd I'm using it more for automation than testing but it could definitely be used for QA.
nnq 10y ago
Your QA engineer could use a framework like CodeceptJS (http://codecept.io/ http://codecept.io/) and get back the "sync behavior", mostly. If the app you're testing is messy, some of the test code will have to be injected into the browser by webdriver (so obligatory Javascript, and oblygatory async for getting the results back...) and some (hopefully most!) will run outside, in the test-runner, so JS ends to be the only sane option if you don't want to write "Python with strings of JS sprinkled around". Also, webdriver itself is a mess with a horrible API forcefully riding another bigger mess (the browser adapters and browser itself), riding a top another mess (your app, however non-messy you imagine it to be, it's still a soup of crap running though the bowels of the browser)... so no "clean" solution here even if you're using Python. Probably the way out of "webdriver testing hell" is to use a frontend framework with good testing support and write good front-end unit-tests: but they will obviously be Javascript :)
marcosdumay 10y ago
> default async is a terrible setting Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.
- spion 10y ago
  False. There is async/await, or generators. Its ES5 that is bad, not JavaScript.
spion 10y ago
On the other hand, Go's type system is so bad that it nullifies all the benefits it brings to the table. I'd rather have no type system than Go's type system, but why even ponder that if I can have everything? With JS I can start out with dynamic types, then switch to static types if the need arises (typescript, flow), fully or partially. Oh, and both of those have really good generics btw. And we have async/await too now, which means async code can also look almost the same as sync code. So I would still choose JS over both Python and Go (at least for that particular use case). mypy still has long ways to go before its anywhere near TS or Flow.
- smitherfield 10y ago
  Python has async/await now too (and it's considerably nicer than JS's version).
  - spion 10y ago
    mypy is immature compared to TypeScript and Flow. In theory, python is better (mypy, pypy, async/await). In practice most libs don't use asyncio (in node everything does and can be auto-promisified), can't run on pypy (in node everything runs with the fast JIT optimizing things) and the typechecker is not mature enough to express most things (unlike TS/Flow).
- nickstefan12 10y ago
  Ive never put the words together, but you've basically highlighted what I want: Python (and its type system) + Go routines Where can I find that!?
  - ricardobeat 10y ago
    TypeScript?

Shanea93 10y ago

Just a minor off topic correction, since you made the mistake twice: "squeue" is actually "skew".

nickstefan12 10y ago
Thanks! I forgot to require the spellcheck module ;).

deleted 10y ago

[deleted]

jacquesm 10y ago

> The python API would likely be no slower and much easier to write and debug. But probably not for your qa engineer who most likely already (and possibly only) knows javascript.

tscs37 10y ago
Who needs more than one language? One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT? SINGLE STACK!! /s
- smonff 10y ago
  Diversity for a richer ecosystem.
  - Roboprog 10y ago
    "/s" [End] Sarcasm :-)
- greenshackle2 10y ago
  They (kind of) have a point though. I agree you should aim to be polyglot, but a particular project may not afford the learning curve if the dev doesn't already know the best stack. For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to learn it, but I'm uncertain I could pull it off in time. EDIT: Then again, it looks like I could realistically learn enough Go for this project in a weekend. Only problem is there could be data analysis, I know good libs in Python, don't know how hard that would be in Go.
  - tscs37 10y ago
    Well, it's certainly not something that needs to be avoided at all costs but in the long term it can be less efficient and more costly. It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.
    - greenshackle2 10y ago
      All hail LISP. My main problem with LISP is that I stopped liking Python after learning it.

inimino 10y ago

That explains why lots of libraries get written, but not why they get used.

nickstefan12 10y ago
the lack of a good standard library might have something to do with it. I'll admit im not sure.
- falcolas 10y ago
  The shaming of mature libraries doesn't help either. Try showing off something with jQuery these days.
  - jjnoakes 10y ago
    Do you have evidence that jQuery is shamed because it is mature? I've always seen jQuery not chosen (shamed doesn't seem like the right word) because it doesn't provide the level of abstraction that folks are looking for, and because it mainly papers over cross-browser differences which get smaller every year.
  - lloyd-christmas 10y ago
    I honestly can't say I've seen any true jQuery shaming exclusive of the cherry-picked click-bait blogs. The only "shaming" I hear is typically post-interview justifications as to why someone wasn't hired, as if it might not simply be the possibility that someone else was more qualified.
  - warbiscuit 10y ago
    Yeah. I've just taken to ignoring those responses. As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit. Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself. (Still hate jquery's inconsistent ajax callback signatures. sigh.)

mbrock 10y ago

I made a shell WebDriver tool that makes it really easy to script the browser from the comfort of your command line. It's not fully polished yet, especially error reporting is a bit ugly, but it works and supports most of the WebDriver API. https://github.com/mbrock/wd https://github.com/mbrock/wd I'm using it more for automation than testing but it could definitely be used for QA.

nnq 10y ago

Your QA engineer could use a framework like CodeceptJS (http://codecept.io/ http://codecept.io/) and get back the "sync behavior", mostly. If the app you're testing is messy, some of the test code will have to be injected into the browser by webdriver (so obligatory Javascript, and oblygatory async for getting the results back...) and some (hopefully most!) will run outside, in the test-runner, so JS ends to be the only sane option if you don't want to write "Python with strings of JS sprinkled around". Also, webdriver itself is a mess with a horrible API forcefully riding another bigger mess (the browser adapters and browser itself), riding a top another mess (your app, however non-messy you imagine it to be, it's still a soup of crap running though the bowels of the browser)... so no "clean" solution here even if you're using Python. Probably the way out of "webdriver testing hell" is to use a frontend framework with good testing support and write good front-end unit-tests: but they will obviously be Javascript :)

marcosdumay 10y ago

> default async is a terrible setting Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.

spion 10y ago
False. There is async/await, or generators. Its ES5 that is bad, not JavaScript.

spion 10y ago

On the other hand, Go's type system is so bad that it nullifies all the benefits it brings to the table. I'd rather have no type system than Go's type system, but why even ponder that if I can have everything? With JS I can start out with dynamic types, then switch to static types if the need arises (typescript, flow), fully or partially. Oh, and both of those have really good generics btw. And we have async/await too now, which means async code can also look almost the same as sync code. So I would still choose JS over both Python and Go (at least for that particular use case). mypy still has long ways to go before its anywhere near TS or Flow.

smitherfield 10y ago
Python has async/await now too (and it's considerably nicer than JS's version).
- spion 10y ago
  mypy is immature compared to TypeScript and Flow. In theory, python is better (mypy, pypy, async/await). In practice most libs don't use asyncio (in node everything does and can be auto-promisified), can't run on pypy (in node everything runs with the fast JIT optimizing things) and the typechecker is not mature enough to express most things (unlike TS/Flow).
nickstefan12 10y ago
Ive never put the words together, but you've basically highlighted what I want: Python (and its type system) + Go routines Where can I find that!?
- ricardobeat 10y ago
  TypeScript?