I got tired of test frameworks that require config files, plugins, and 50MB of dependencies just to run assert.equal. So I built QUnitX.

  The pitch is simple: one test file, three runtimes, no changes.

  import { module, test } from 'qunitx';

  module('Math', () => {
    test('addition', (assert) => {
      assert.equal(2 + 2, 4);
    });
  });

  node --test math-test.js
  deno test math-test.js
  qunitx math-test.js  # browser, headless

  Why QUnit?

  I know the reaction: "QUnit? That jQuery thing from 2008?" — yes, exactly. That's the point. It's been solving real edge cases for 16 years that Jest/Vitest are still catching up to. assert.deepEqual correctly handles circular references, typed arrays, Maps, Sets, prototype chains. assert.step / assert.verifySteps catches missing async callbacks that other frameworks silently swallow. assert.expect(n) fails if the wrong number of assertions ran — invaluable when async code paths are involved.

  What QUnitX actually does:

  - Wraps Node's built-in node:test runner with the QUnit lifecycle (no Jest, no Vitest, nothing extra)
  - Wraps Deno's native BDD runner the same way
  - Browser path is a thin re-export of QUnit itself — full browser UI with filterable, shareable test URLs

  TypeScript works out of the box (node --import=tsx/esm --test). Coverage via npx c8. Watch mode via --watch. Zero runtime dependencies.

  The browser demo is what I'm most proud of — the QUnit UI lets you filter to any test and share the URL, so your colleague sees the exact same filtered view. We've been using this in production for years and it never gets old.

Repo: https://github.com/izelnakri/qunitx

I can't tell if this comment is tongue in cheek or not.

The walkthrough on how to build a JS framework from scratch is "hypester" because in the short section that mentions existing frameworks, your pet frameworks weren't included?

> Yeah these type of articles always have hypester tone with less substance unfortunately.

Oh come on! The article mainly mentions the specific frameworks it does to qualify and contextualize the set of features it discusses, which it goes on to implement. The article is excellent, and this kind of reflexive dismissal is so tiresome.

> I refuse to work with people who has this thought

So you refuse to work with people who do not want to re-invent the wheel for a shiny new framework because it is "better"?

the problem is that every framework comes with only three of the wheels you need, but in each framework the missing wheel is different, so you will always end up "reinventing" a wheel that another framework already has, because if you switch to that other framework, you'll have to reinvent a different wheel instead.

if you don't want to reinvent a feature that another framework has a solution for, then i'll ask you to show that this other framework solves more problems than the current one, and it's worth the cost of switching (or switching back).

but, like you, i don't like to switch to a new framework just because it promises to be better.

i prefer to avoid switching frameworks as long as i can. i'll only switch in a project when i run into a problem that the current framework can't solve at all.

I think you’re 100% on point here.

I so far agree with all you said and strong think already based on limited info available to me that you are a well-versed Elixir dev. However nothing beats the short term dev speed of scripting up some JS with npm. Have you seen the latest test runner efforts on node.js and advancements in deno? I think this gap is slowly closing but node is still not near Elixir in terms of long-term productivity, in future it will take over though I think if types dont get into the Elixir language fast.

I have to transpile my scripts if I want to copy-paste which I often need to do.

And there's no repl if you're using transpiled code. I have tried using `ts-node` but that didn't work. In Elixir this stuff just works.

Maybe there's some tooling I am missing out on with Node.js. I am not familiar with Deno.

I strongly disagree that what he is asking is user hostile, just like asking microphone or camera permissions aren't user hostile. You also didn't need to lecture anyone like that on hacker news, thanks!

What they are asking would be used as an annoying tool against the user in the same way today sites ask for user location or push notification (on other OSs).

Websites are not randomly asking for mic or camera because that would be creepy and visitors would just run away.

I am not lecturing, I am giving my feedback on the matter, like everyone else here. If your product is good, users will save your site in their home, don’t worry about that.

I think these should actually be written in the job ads because I wouldn’t want to work for a colleague who has your mentality. I worked with many bunch of sit-on-your-chair claim your paycheck at the end of the month types, another colleague another competition types, and this one is the most complex: overly-invested/$feelingLikeOwnerYetOwnNoShares types but yet I have no way to screen them during the interview process and a single mention in the job ad description could help me save some time: Companies should immediately tell if they would reject job-hoppers, or particularly screen for loyalist in tech(ones with delusion given commercial activity in IT), that is a company I can respect!

> Companies should immediately tell if they would reject job-hoppers

Job-hopping isn't some arbitrary threshold that gets crossed. It's more of a pattern that gets identified while evaluating a person's resume.

When I say "job hopper" I don't mean someone who has 10 years of experience across 3 or 4 different jobs. The "job hopper" resumes I see are some times as extreme as 12 jobs in 10 years, or occasionally people who have never reached the 1 year mark at any company. If someone can't last a full year as an FTE at any company, it's hard to argue that there isn't a problem.

It's not a big deal for someone who is 1-2 years into their career. But when someone is 10 years into their career and they're not staying anywhere long enough to really make an impact, why would any hiring manager reasonably expect that to be different after hiring them again for job number 11 or whatever it ends up being? The most likely outcome is that the pattern continues.

I agree with you, with one caveat. Why is one year not enough time to make an impact? Isn't a key in agile development the iterated development? Wouldn't a year have plenty of iterations where a developer could build out tooling, ci/cd processes, ship many multiple long lasting features?

You can absolutely make an impact multiple times within a year, but the odds of those "impacts" being a net positive without ever having maintained the results is not good.

If I'm hiring for a senior or better role, I want you to be able to make meaningful, sustainable changes in large and complex systems. It can take the better part of a year to even fully understand many complex systems, so it's unlikely you ever experienced the full long term affects of your changes.

> You can absolutely make an impact multiple times within a year, but the odds of those "impacts" being a net positive without ever having maintained the results is not good.

Fully agree. I've seen a few FTEs come in, try to make a giant splash with changes, then leave right when their changes have any sort of major issue.

I'm still dealing with bad code from someone that came in and tried to do that.

This is one of the key "promises" of agile development, which to me shows why agile promises more than it can deliver often times.

> The "job hopper" resumes I see are some times as extreme as 12 jobs in 10 years, or occasionally people who have never reached the 1 year mark at any company.

Oh, man, I briefly worked adjacent to someone like that who went on to have principal and director level roles at pretty well-known start-ups, despite never sticking to any role for a year (according to their own LinkedIn!). Apparently they're now CTO of a small start-up, which seems like a recipe for disaster.

Never reaching a year at 10 jobs is something to ask I think however:

> why would any hiring manager reasonably expect that to be different after hiring them again for job 11

Thats is I think still the wrong approach, signals the wrong mentality in an IT company(a company thats greatest asset is its employees). Investing in employees can never be a saving center in a good IT business, considering all businesses are becoming IT businesses perhaps in every business in this context. If a candidate has the skills and took time to apply, if they are qualified you are responsible to hire them and keep them. If I was the manager of the hiring manager, I’d probably fire this hiring manager for keeping the organization dumber, and seeks his own interest/status-quo seeking behavior & protectionism with this behavior/approach/mentality. I do believe in moving mountains in 3-6 months, especially in badly managed projects or super fast growing companies.

If you haven't stayed at any single position for at least a year, then odds are you haven't developed some skills crucial for your job.

Sure, you can move a mountain in 3-6 months, I've seen such people. Most of them will move the mountain to a wrong place, and won't stay to help bring it back at the desired one. They will just go, leaving chaos back, totally unaware of the mess they created. Or they will move the mountain to the correct place, but will do it in such a way, that no-one is able to maintain, improve, or fix the mountain.

Leaving before a year or two, means you never owned your mistakes. You never tweaked your engineering intuition for teamwork, reliability, or maintainability.

Hey, you might be brilliant, but that's not what engineering is about.

There is no rare case at the opposite end of the spectrum.

Significant contributions aren’t a settled thing after six months. There always are loose ends to tie, things to reflect upon or unforeseen evolution forcing you to come back.

The issue with people leaving after six months is not that they might not have made a significant contribution in these six months. It’s that they never had to live through the consequences of what they did. It’s not a deal breaker but it’s career limiting because I very much want to hire people who know how to deal with things not going to plan and able to own their work. That’s why experienced people are paid more after all.

I’m equally suspicious of people with ten years of experience who can’t explain to me when something they were working on went wrong and what they did to fix it. It’s nearly impossible to work ten years on major projects and not having something blowing up on you at some point.

> That’s why experienced people are paid more after all.

They are paid to stick around? I thought good people would produce work that was well thought out enough to not require endless amounts of "maintenance".

They are paid better because they know what they are doing and they know what they are doing because they have been through it and experienced what should and should not be done.

How do you know how much maintenance your work actually needed if you never stuck out long enough to witness it?

Because its stable and there's no more serious feature requests. If the job description is no longer applicable then I think its fair to consider that a reasonable resignation moment. The employer can change the job requirements as much as they like, but no hard feelings if I'm no longer signed on for what you demand today.

Personally, I'd refrain from throwing around "If I was the manager of the hiring manager" rhetorics when responding to PragmaticPulp; that's someone w/ a lot of hiring experience in big tech.

I'll throw my own two cents as someone who interviewed a couple hundred senior/staff level eng candidates. When a candidate comes around w/ 10+ years of experience, a career filled with one year stints will not pass the bar for L6 level because some of the evaluated requirements (e.g "consistent cross-functional impact") simply cannot be achieved in <12 month stints (and this shows in the interviews)

Something to consider is that tenured big tech interviewers can have hundreds of interviews w/ 10+ YOE candidates under their belts; they've seen high performers and low performers and inflated titles and smooth talkers and everything in between. So when they say someone doesn't pass a bar, it's not just a quick dismissal of a resume (the interviewing process at these companies typically doesn't even allow that); instead there's a lot of interviewing experience behind that statement.

> Personally, I'd refrain from throwing around "If I was the manager of the hiring manager" rhetorics when responding to PragmaticPulp; that's someone w/ a lot of hiring experience in big tech.

Having seen a bunch of companies and hiring managers, I don't believe PP's approach is the correct one if he wants to maximize results, not minimize efforts.

There are reasons why at some point stellar candidates stop considering Big Tech, companies like FAANG etc. and also why good engineers deteriorate if staying there for too long (doesn't apply to certain departments, like RnD). Policies are simplifications, and hiring good candidates is a hard problem in modern industry; removing flexibility only makes the task that much harder.

I mean, I think "maximizing results" is a bit of a loaded term. The bar at FAANGs and adjacent companies is already very high to begin with; their systems are optimized to prevent bad hires and I'd argue they're quite successful at that. Also worth noting that when you hire at scale, optimizing for finding mythical 10x'ers doesn't scale, almost by definition.

The other thing is that you're assuming a hypothetical candidate w/ only short tenures is someone who is necessarily an ace, vs the original claim that this person is likely a dud. The point I'm making is that in a real concrete scenario w/ lots of numbers to look at, people w/ that sort of resume don't perform well when benchmarked against known high performers. Which then begs the question of whether it is even reasonable to assume that there's any overlap between the extreme job hopper archetype and the "ace" archetype statistically speaking, when comparing to the stats for the cohort of people with "normal" tenures.

I can point to a vast pool of people jumping from one 6 month contract to the next that tend to do abysmally bad in interviews, and I can tell you none of the staff+ or director-type people I know are extreme job hoppers, as anecdotes to support the argument that the overly short tenure strategy doesn't perform as well as average tenures. You'd need to provide a very strong argument for the idea that "short tenures = good heuristic for finding golden needle in a haystack" is a superior strategy for either job seekers or employers, because I just don't see it.

Huh? If someone never stays for more than a year at a job, unless they are consulting gigs, that’s a red flag. The person is either dumb, unable to complete tasks, a risk due to behavior/etc, or otherwise problematic.

Sometimes you see people who hop around while transitioning between roles. It’s fairly typical to see veterans hit 2-3 places after leaving the service. Likewise, if someone leaves a unique vertical (ie healthcare, government, some finance), some hopping around makes sense. But like all things outliers are usually outliers for a reason.

> Huh? If someone never stays for more than a year at a job, unless they are consulting gigs, that’s a red flag. The person is either dumb, unable to complete tasks, a risk due to behavior/etc, or otherwise problematic.

Really, that's the only conclusion here? Can't a person, who's much better engineer than an interview-goer - I mean, to modern interviews in the industry - have to get at some point a position which he isn't so sure about, get his concerns realized, and made to leave? It's tough market for good engineers, despite some media would tell otherwise; search for a position could take months, more than half a year sometimes, and engineers typically have to make some money, not only working software. So if a good engineer loses a good position, it's a situation against him to find another one - and job hopping bias only makes it worse for everybody, except maybe those bad companies who still hire him, but which can't sustain him.

That's reasonable, and rational, but at the same time I don't want to disrupt my team by bringing in someone who might decide they don't like the job after six months and who isn't able to ask the questions they need answers to during the hiring process to find that out. Consequently I might miss out on some good engineers by rejecting people with a series of short jobs on their resume and I accept that's a downside for me. The upside is better though.

I don't care if the candidate is having a hard time finding their ideal job. I care about my team.

> Really, that's the only conclusion here?

Well, yes, because any other conclusion really misunderstands what problem the hiring process is solving. It is not optimizing for hiring the best engineer possible, it's aiming to minimize a range of possible headaches for the employer. There's a hundred ways that best engineer could have work or personality traits that are absolutely terrible for your organization.

How do you assess, or even self-assess engineer goodness if they’re never around? Most people take a few months to get productive at a given job and become less productive when they get ready to leave.

So the strawman engineer who has never been at a job for more than a year probably only had 4-6 months of productive work at these jobs, and never had any meaningful responsibilities or career growth.

In my experience, most folks stay around for 2-3 years at a job or >5.

Thanks for all your comments on this thread. Made me think more about this issue than I ever had before. Props for standing up to the hive mind. I think for me the crux is that searching/interviewing/etc. all that stuff to find a job _fucking sucks_ and anyone not managing to either pick the right jobs or stay at their current one is a big red flag. I have trouble imagining someone not hating the process of finding a job and so why can't they avoid having to go through it every year?

> If a candidate has the skills and took time to apply, if they are qualified you are responsible to hire them and keep them.

The problem with this mentality is that the hiring process isn’t a 1-on-1 process between candidate and employer. When a job opening is posted, you get multiple applications from different people.

It doesn’t make sense to suggest that hiring managers are obligated to hire the first candidate who applies. They collect a number of candidates and try to give the role to the person most qualified for the job.

And that is the core problem for job hopping applicants: Inevitably, you’re going to go up against other candidates with resumes suggestive of longer tenures and, in turn, bigger accomplishments at companies.

> And that is the core problem for job hopping applicants: Inevitably, you’re going to go up against other candidates with resumes suggestive of longer tenures and, in turn, bigger accomplishments at companies.

Can you consider job hopping as an advantage of the candidate, the same way you seem to consider it as a disadvantage?

I've seen this bias for various people many times, and I also have examples among my fellow engineers, way more competent than average level in tech companies, who can't find a new position, not without many months of search and being dismissed for imagined shortcomings from the fragile interviewing process. Job hopping bias is one of traits lately which skews the field against them even more.

You keep mentioning “very competent engineers” which somehow experience repeated short tenures. Might I suggest that competency is not just about technical skills, and that soft skills are also part of the expected “brilliant engineer” package?

> Might I suggest that competency is not just about technical skills, and that soft skills are also part of the expected “brilliant engineer” package?

Basically, no. Soft skills are sufficiently different, so that mismatch their should be considered differently. Just like hiring is a hard problem, retaining hard-skillers is something industry has no good solution at the moment.

If they don't have enough soft-skills the hard skills aren't worth retaining in a typical corporation.

> way more competent than average level in tech companies

How does one evaluate the competency an engineer who has never had to consider and be responsible for the implications of their decisions two or three years down the road?

I think one perspective for companies looking to hire FTEs is that at some point, those "job hopper" advantages are best captured by hiring consultants and other non-full-time people for fixed term gigs. (It's another question to ask the job hopper, too, why don't they go into consulting or fixed contract work?) Sometimes that will involve them writing code, other times advising/overseeing/helping some internal team, but at some point they've done what was needed and it's see you later. Your actual full time employees though, you want them to stick around.

The last big company I worked at made it pretty easy to "team hop", which I'm sure cut attrition to the company overall by quite a bit. There was even a cool "sniper team" that would move around to assist different teams every few months. And of course there were the summer interns, most teams tried to make them net-positives and productive during their few months -- that is, even with some overhead of spinning up to the environment, having some team members mentoring them, and having to make sure their work is well understood enough by others to survive them taking off, you're still happier they were there than not. But IIRC no one was directly hired onto the sniper team, they were internal transfers. Maybe some were job hoppers in the past. But most teams interviewing new outside candidates for FT roles want the same sort of expected stability as everyone else, so of course too frequent job hopping isn't going to be seen positively.

I had a fun experience interviewing someone for a management role, he had previously left the company (after a year or so as a dev and about the same as a freshly transitioned manager) for another, but after maybe a year and a half or so at the other was thinking of coming back to the old one. I can't remember my phrasing but I basically asked him what sort of guarantees (I know I didn't use this word but it captures the desire) he could make that he wouldn't just leave again after a year or so, when this particular position really needed someone invested for at least 3 years. His answer was something like a pretty floaty "we never know what life will throw at us", which sure, there are no real guarantees here, but still, you could at least try and make me believe, like demonstrating a passion for the underlying product space or something, or heck even a simple mercenary view of trying to get a lot more RSUs that don't vest after that many years would be acceptable to me (if not others). Anyway, I recommended against him, for that and other reasons.

> There was even a cool "sniper team" that would move around to assist different teams every few months.

Were they actually good? I could see this being an absolute fly-by wharbargle.

I never heard complaints, and my own experience was with the stuff they were wrapping up for my team just as I was hired. It was solid and we extended it further about a year later on our own without issue. (Organized code, including some plsql, tests, and some useful docs were left behind.) I could see the concept going south somewhere else though especially if they're more thrust upon teams that don't want them by upper management.

I think both too much tenure and too little are both "warning signs". Nine times out of ten I'm going to prefer the two year per role candidate to the 20 years at the same enterprise dev shop candidates (who I've universally had the worst experiences with). But if they can't manage at least a year per engagement? That's a bit too active for me generally. I have more confidence in my ability to build an environment that'll encourage people to stay than I have in my ability to rehabilitate a developer with twenty years of ingrained bad habits because they've only seen how one (likely dysfunctional) environment operates.

There are costs to onboarding a new employee (not just in money, but also in time and attention from more-tenured teammates, finding good "starter" tickets for them to work on, longer standups, interviewing their replacement after they leave, etc)

For pretty much any team, there's some ramp-up time where a new employee won't be contributing much and may be taking more time/attention from your experienced employees and manager. (explaining how the system works, code reviews, helping debug why something's not working, etc etc) There's some break-even tenure below which it's a net loss for a team to have hired someone. It'll be different for each team and also different for each new-hire. Maybe it's only a couple days, or maybe it's 6+ months. Either way, managers should at least be aware of this when making hiring decisions. (exception: unless they're at a cushy enough gig where there's not much/any pressure to deliver)

> (exception: unless they're at a cushy enough gig where there's not much/any pressure to deliver)

Another exception: when the applicant is actually passing able/willing interviews.

Do you really think a good engineer would leave willy-nilly a good place to work? I've yet to see a good software engineer who loves interviewing for the process of it.

> Do you really think a good engineer would leave willy-nilly a good place to work?

No. Which is precisely why, via contrapositive, a string of short stints is a relevant signal that the person might not be a good engineer.

I agree about the cost of hiring and on boarding time but you should know by three months if it is going to work out.

There's also a cost to not having the proper head count

On the contrary, the default position is and should be that job hopping is a negative, and it should be assumed the job hopping is a red flag. What you should want is a company that says job hopping is fine, basically being a consultant. It sounds like you're not asking good questions in an interview to find if a company is a cultural fit, interviews are a two way street after all.

That's easy. Outsourcing companies don't care too much, as they lease your body to the highest bidder and don't care too much about the results.

Any other company will prefer someone, who will stay longer, because for 3 months or more (more complex product they have, longer time), you're more cost, than asset, because you don't know the product and need some level of babysitting.

Identity politics based, brain-washed mentality in action. I do functional programming for years now and write JS more than a decade, and don't consider this feature to be a monstrosity. If anything, it is a nice addition to the language especially when it comes to designing ORMs.

The fact that this became the most upvoted comment on hacker news signals me something sad about this sites moderation. In addition to the fact that other most upvoted comments(arguments) are lacking depth and good context:

1 - not standard so I won't use it(yet mitigating would be easy & basic and there is a major/popular implementation in typescript), 2- I don't like how it looks(decades long I'm an artist argument)

Good arguments & discussions usually require in-depth knowledge, given how fast programming communities grow, there will be people who make these shallow arguments and they will get upvoted(will have more people agreeing to them).

Sadly this means old communities like hacker news content and moderation will get spoiled by this behavior and standard committees will keep getting many noisy pushback & shallow criticisms as more people become programmers and will have tendency to share their newly formed opinions rather too quickly.

I like and ok with criticisms, however I hope and expect them to be in-depth, not disappointingly this shallow.

However there is no good alternative for Meta’s Facebook, despite its degrading web UI over the years. I dont think its that much of a problem growing at 1-2% per month instead of 20-25% for any new social network.

People should ideally stop using whatsapp and move over to Telegram as it seems to be the only one that has whatsapp UX parity. Thats what I did, and I also have signal, discord etc and I own no shares of Telegram.

> People should ideally stop using whatsapp and move over to Telegram as it seems to be the only one that has whatsapp UX parity.

UX parity?? Telegram's UX blows WhatsApp out of the water. Stickers, message edits, polls, location sharing, bots for public channels, audio chats, etc etc. It's not even close!

And I don't really want any of that. I want just send textual message to group of people for free. Maybe add an image, but that is it. I don't really care about anything extra.

But even that Telegram does better, because you can edit messages you've sent to correct typos, you can pin them in channels, and there are extra nice things which might come in handy ( when do you want to meet? A pinned poll and it's easy).

I use Zoom and Skype but Zoom has not come close to replacing Skype for me. I have skype-in with multiple landline phone numbers in multiple states. Zoom does not offer this yet.

Curious what you think Telegram has over Signal. If your motivation for leaving WhatsApp is because of privacy concerns both WhatsApp, Signal, and even iMessage for that matter are technically superior to Telegram. Was it personal preference between the two or network effects of the larger user base on Telegram?