Comment by nickstefan12 | Hacker News Reader

Comment by nickstefan12 | Hacker News Reader

Parent Full thread

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.

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.

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!?

TypeScript?

Python has async/await now too (and it's considerably nicer than JS's version).

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

Your QA engineer could use a framework like CodeceptJS (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 :)

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

I'm using it more for automation than testing but it could definitely be used for QA.

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

the lack of a good standard library might have something to do with it.

I'll admit im not sure.

The shaming of mature libraries doesn't help either. Try showing off something with jQuery these days.

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

I have been using Ramdajs, rather than lodash, but they both do about the same thing. One difference is that Ramda puts the functions before the data in its library calls, so that you can curry/apply the app logic function (e.g. - perhaps for a map or filter), save the resulting function and use it elsewhere.

Lodash looks nice, though, in that its partial function application mechanisms seem a bit more flexible than curry (only) - e.g. - I want to make a function with 0-arity, and bind it to an event handler, which Ramda won't do.

lodash has that ability from a sub-module "lodash/fp":

https://github.com/lodash/lodash/wiki/FP-Guide

Thanks. I wonder if somebody has a good comparison of the Lodash vs Ramda written up. Probably, but I haven't done the google and evaluation yet :-(

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.

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.

> default async is a terrible setting

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

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

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

Thanks! I forgot to require the spellcheck module ;).

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

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

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.

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.

All hail LISP.

My main problem with LISP is that I stopped liking Python after learning it.

Diversity for a richer ecosystem.

"/s"

[End] Sarcasm :-)

QA? Do it in Perl please!

Reply on news.ycombinator.com