[austincheney]

https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc

Look at DOM performance. Chrome has a ceiling of about 45m ops/s where FF max speed is dependent upon your ram and bus speed reaching beyond 4-5b ops/s. In both though querySelectors perform at about the same speeds as slow as 25000 ops/s.

I have written an OS GUI that executes in the browser. It loads, including full state restoration in about 120ms. I was recently interviewing with a search engine company, one of the big ones, where I could demonstrate that JavaScript tool can execute file system search much faster than the OS and produce better results. They seemed really impressed.

Despite all of this my biggest learning about performance is that mentioning performance during job interviews shows that you are incompatible with other JavaScript developers and will not be hired.

[chockchocschoir]

> Despite all of this my biggest learning about performance is that mentioning performance during job interviews shows that you are incompatible with other JavaScript developers and will not be hired.

As someone who done plenty of JS, cares about performance and also has handled hiring for JS positions in the past, I can tell you that this is generally not true. Caring about performance is not a reason to not get hired.

But it is possible to be "technically superior" in every conceivable way, but still not be a good hire. Why? Because the candidate might be missing vital soft skills or even not be very good at describing their thoughts, something that can slow down an entire team.

"Learning the wrong lesson" when things go wrong would also be something I'd consider high up for reasons to reject a candidate.

[austincheney]

I have been doing web work for over 20 years. Everybody claims to care about performance, training, security, and so forth. The only thing that really matters in practice is comfort. Until developers are willing to abandon certain areas of comfort things like performance are only given lip service. In doesn’t matter what they want if they are actively working in opposition. This is performance is a massive incompatibility to hiring.

[chockchocschoir]

> In doesn’t matter what they want if they are actively working in opposition. This is performance is a massive incompatibility to hiring.

No one is working towards degrading performance on purpose, and caring about performance is not "a massive incompatibility to hiring". But the fact that you keep stating this makes it clear that there seems to be plenty of other reasons organizations are not hiring you.

[austincheney]

> No one is working towards degrading performance on purpose

You are not participating in the same interviews that I am then. Most developers know querySelectors, for example, are super slow. They will fight to death to retain them and anybody who suggests any alternative is not compatible for hiring. If they know its slow and deliberately choose to avoid faster alternatives how is that not degrading performance on purpose? How is that not common?

[gavinray]

  > "I was recently interviewing with a search engine company, one of the big ones, where I could demonstrate that JavaScript tool can execute file system search much faster than the OS and produce better results. They seemed really impressed."

How is this possible? OS should be using direct syscalls, any additional code you write should be pure overhead in theory, right?

[austincheney]

No, its a common misunderstanding of search and tree models. The OS is faster, by a tiny bit, at traversing the file system than my JavaScript application. It is only search that is slower, and dramatically so. I don't have visibility of the OS code so I cannot be certain why that is. I speculate its because the OS is doing too much.

With the DOM querySelectors are dramatically slower than using static methods with arbitrary strings as arguments. This is likely because a query string must be parsed against each child node to determine if the child node is a match to the supplied query. Likewise, modern OSs use ancient conventions to search the file system, such as wildcards, along with more modern advanced search syntax. These are rules that must be parsed against each child artifact from a tree segment. My application deliberately doesn't do that.

To compound matters Windows, don't know about OSX, caches search results so that subsequent searches are a little less slow, which incurs a greater performance penalty on first search. My application doesn't do that either. Each search triggers tree traversal, so its always as fast reading from the file system.

Mentioning any of this during a job interview makes for intriguing conversation with the interviewer. I do detect genuine interest and curiosity from the interviewer. At the same time they know their team will fight to the death at many mention of alternatives to querySelectors and/or JSX, so you have just effectively terminated the interview. Anything there after is purely for the interviewer's personal interests.

[greggman3]

No app I've ever written needs querySelector to be fast. I'm not saying I can't imagine such an app. But, I would never reach for some optimized but very uncommon solution unless the app really needed it.

[fluoridation]

>I could demonstrate that JavaScript tool can execute file system search much faster than the OS

What do you mean? How do you search the file system without calling into the OS?

[austincheney]

A micro service to a localhost node application. There is a file system API in the browser now but it isn’t mature and is highly restricted compared to the terminal.

[fluoridation]

??? So JIT code + IPC + more JIT code + native code + kernel code is faster than native code + kernel code? How does that work?

[IshKebab]

I suspect that isn't why you weren't hired.

[austincheney]

Why would you suspect that? Are you a JavaScript developer? If so have you seen the terrifying horror on people’s faces when you mention alternatives to querySelectors or that you can write/execute code faster by not using vDOM? Mentioning performance is the fastest way to exit a job interview.

[skinnymuch]

Isn’t this comment behaving in a sensitive way? Your bio says sensitive people make you sad. Unfortunately quoting an [out of touch] billionaire, though that’s not the point :p.