I think using a better variable name for the "pipeline" result is a much better approach

One can definitely go overboard with this, though. I have had to read a lot of code where someone broke something up into several functions that only had the effective of forcing me to constantly bounce around all over source file to figure out what was going on without improving clarity at all.

Ugh, I absolutely hate reading code with a ton of variables that are only used once, because each introduction of a variable is a new thing that I have to first parse and then track to figure out what it does. I would much rather read a pipeline that expresses what is going on concisely without introducing extraneous elements. In particular, I thought that the pipeline at the start of the article was perfectly clear and did not need any of the subsequent modifications.

When you start to bump into any of these concerns, I'd recommending extracting the functions themselves, rather than breaking the pipeline... which was not something mentioned or explored.

Actually, my first architectural decision was to not use JavaScript.

Why would I bother to read this if they didn't bother to write it?

It's definitely got the worst defaults compared to the alternatives.

pnpm, Bun, and Deno have all made better choices about their defaults. pnpm blocks postinstall scripts, Bun requires explicit opt-in for them, Deno’s permission model is restrictive by design.

npm is bad

Time to roll back various workarounds in dozens of projects.

Is a patch level release with three items listed as "chore" really news worthy?

the client side can be as fast or faster than the ‘server’ side.

That's not the case on a lot of JS-heavy sites, though. A lot of logic runs on the main thread, which slows things down. The only way to run things off the main thread is by using web workers, but that adds extra serialization/deserialization overhead.

That also has the potential to create securiity concerns at both ends

Generally, the more logic you have on the client-side, the more likely you are to have security issues relating to untrusted input or behaviour. The client is a completely untrusted environment (since a user can do whatever they want with your JS code), and increasing the amount of logic on the client side increases your attack surface there. Any code on the server-side can be trusted, since you wrote it and users can't modify its behaviour.

It's a garbage article.

It's not checking other's claims, it's not saying anything new, it's not even listening to the majority of the parties.

For each of the parties (node, deno, bun): they are incentivised to only release benchmarks that make themselves look good, and are disincentivised to release benchmarks that make themselves look bad.

This article only uses benchmarks from one party then declares it the winner.

So, it's garbage.

I don’t see any products or services being promoted in this article.

That's kind of the point. You're not supposed to.

They're farming links so search engines see their domain as more important. That way, their entry will appear higher up on search results against competitors for their paid products.

What are your thoughts on this 2023 comparison?

So to confirm, you don't trust blogs where the company is selling a product or service, even if they don't mention it in the article? If so, that would cover a lot of articles shared on this instance.

https://www.repoflow.io/pricing

I don't trust much at all.

Bro, how are generators going to be faster?

This is an AI article.

My results:

Firefox:

Loop: 44ms - timer ended

Generator: 4580ms - timer ended

Node (uses same engine as deno, chrome, edge):

Loop: 30.577ms

Generator: 1.533s

Safari (uses same engine as bun):

Loop: 605.222ms

Generator: 2804.669ms

Bun (same engine as Safari but without needing to apologise for Safari):

[17.52ms] Loop

[297.17ms] Generator

Generators are going to be slow because:

• they're going to be stack switching so much in JS runtimes which adds a lot of overhead
• JS doesn't have the other language features (yet) that you want to use with generators, which makes less folks want to use generators, which makes implementers not want to spend time optimising them. (Why bother trying to inline generator state when it's probably going to change once the adjacent features come in?)

Until generators don't rely on stack switching, they're always going to be super slow.

For what? I don't see any products or services being promoted in this article.

I think it's a poorly hidden advertisement.

People who care about performance are using loops

Well that depends, generators are faster than loops when you're using Bun or Node.

This benchmark is pretty useless.

There's no benchmark code shown to see if they're doing something wrong or cherrypicking.

Also, they only tested on arm64? Why weren't they testing on x86-64?

And what the hell is this test?

Common data transformation pattern, map then aggregate with reduce.

People who care about performance are using loops, not map(). Why are you even testing the slow path?

I don't think they mention maintenance burden specifically. Using a framework with packages means you have to track upgrades, do upgrades, check release notes, breaking changes, support and end of life cycles, license changes, etc. It's a have maintenance burden if you keep it live, even if you don't intend to make any changes.

Vanilla doesn't have this problem. Server-side has it too, but in a slightly different flavor.

The heavier and integrated the framework, and the more additional packages you include, the heavier the burden.

That may not be the wisest choice. For one thing, the client side can be as fast or faster than the 'server' side. Sending data to a 'server' which is 'serving' as a mainframe (reverting to a model from the past) will consume more time and bandwidth. So much for the performance goals.

That also has the potential to create securiity concerns at both ends (which were not intense in those bye-gone days of yesteryear). Furthermore, wny should the client trust the quality of the code the 'server' uses? The popularity of the 'new' frameworks aside, the cost of bandwidth and processing by the 'server' will be born by the 'client'. I'm not seeing any pluses except for thin clients, and big potential pluses for the 'serving'.

Sites that only use vanilla JS can still be heavy, too. I think the underlying message is to do the heavy processing on the server side, and keep the client side relatively light.

This is also why frameworks/libraries like Astro and htmx are becoming more popular. Both of them focus on having minimal frontend JS. htmx effectively reverts back to a pattern that was somewhat common 20 years ago - a small amount of reusable JavaScript to handle common use cases, that hits the server and inserts its response HTML somewhere on the page. I was a web developer back then so it's been interesting to see old patterns come back.

I can't speak for the performance of frameworks, but today's 'vanilla' javascript both compiles and executes blisteringly fast. The better-optimized it is, the better. Staying away from modern syntactic sugar may also help.

I can understand that those who choose to use frameworks may be newcomers, or may have productivity pressures. Neither source of slowdowns can be blamed in JS itself.

But this headline distorts that reality by leaving out the fact that the article itself is about using JS frameworks. Whatever the 'long-term performance goals' may be, writing the fastest code can't hurt them. Suggesting otherwise is a disservice to JS.