20 ms·

Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over anoth

Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over another Id be shocked. It makes it equally surprising that this error from the Deno crew, who should all know better. In either case, I hope they announce a correction and move on to more important matters. If youre trying to shave another tiny bit of rps out of your boxes then thats an incredible success problem; not the kind 99.999 of companies will need.

ex3ndr 4y ago
Javascript is plagued with idea that it is slow while it is not. Many devs now have PTSR after arguing day after day that javascript is a good thing and not slow. Performance is a very important thing in js world for a peace of mind of devs.
- naillo 4y ago
  To be fair it did used to be quite slow. But that was like 10 years ago. General awareness hasn't caught up to the huge engineering efforts it seems.
  - chrisco255 4y ago
    It's been 14 years since the v8 engine was released. Node.js has been out longer than 10 years.
  - kitd 4y ago
    Ikr. You can regularly read some random dev tell the world "interpreted" Java is "too slow" for them.
    - andirk 4y ago
      Javascript isn't Java. Javascript follows ECMAScript, which also isn't Java. And ECMAScript isn't a language.
      - squeaky-clean 4y ago
        I don't know if they were making a JS joke but I have legitimately had newer programmers tell me that Java is an interpreted language because it compiles to a bytecode language which is interpreted by the JVM. Inversely I've had people argue that JS and Python are compiled languages because their interpreters convert statements into bytecode before executing them. When someone starts trying to argue those points I find its best to just give them a thumbs up and leave the conversation.
        andirk 4y ago
        Describing Javascript can be confusing. C++ compiles -> C compiles -> assembly language compiles -> 1-for-1 to machine code. But Javascript be like "Javascript is the programming language interacts with your browser" or "Javascript conforms to the ECMAScript specification that describes how the language should act but is implemented according to the browser vendor's interpretation of said specification, and is further compiled according the browser." And that only covers browsers' Javascript. And I'm not even sure if the above is 100% accurate.
- thinkingkong 4y ago
  I agree performance is important, but it’s optimistic for any dev to assume that this particular layer is the place where things will be slow. Introduce a single file or other 3rdparty IO dependent method on your HTTP response and poof
- maccard 4y ago
  > Javascript is plagued with idea that it is slow while it is not. I benchmarked a hello world in .net and node/express, and the .net version was multiple orders of magnitude faster than the node/express version. That's a starting point, and as you add more logic, that gap only grows in my experience. Javascript may be fast _enough_ for many cases, and in a tight JIT loop it may be faster again, but by any measure, js is not quick.
  - geysersam 4y ago
    No realistic, decently written, js application would be "orders of magnitude" faster if rewritten in .net.
    - maccard 4y ago
      And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever seen say - js is significantly slower. One example is the techempower benchmarks Fortune section[0]. It's a fairly basic app, but it tests a full stack web app in multiple languages, and it's pretty clear that js is fimrly in the middle of the pack, far behind the compiled options. If you have any sources to the contrary, I'd love to see them. [0] https://www.techempower.com/benchmarks/#section=data-r21&test=fortune https://www.techempower.com/benchmarks/#section=data-r21&tes...
      - LunaSea 4y ago
        JavaScript ranks higher than C# in your benchmark.
        maccard 4y ago
        See my other response here https://news.ycombinator.com/item?id=33224873 https://news.ycombinator.com/item?id=33224873
- deleted 4y ago
  [deleted]
pier25 4y ago
Exactly. Very few companies will need to reach 1000 reqs/s consistently, let alone 100k reqs/s. StackOverflow peaks at about 6000 reqs/s and it's an extremely popular website.
- swyx 4y ago
  got a source for this stackoverflow peak? also wondering what peak RPS is for HN. i feel like most (non consumer) startups would be like "ok if its good enough for HN its good enough for me"
  - ksec 4y ago
    >got a source for this stackoverflow peak? It is [1] ( and should be ) pretty well known. 1.3 BILLION page view per month, 6K RPS with 9 ( Fairly Weak ) Servers, Sub 20ms response time with zero caching. >also wondering what peak RPS is for HN. Less than 100 RPS for logged in users. The number were pre 2020 but I doubt the current number is significantly higher. [1] https://stackexchange.com/performance https://stackexchange.com/performance
    - coder543 4y ago
      > Sub 20ms response time with zero caching. I mean... to be clear, they do tons of caching[0], which is certainly critical for their ability to have a non-cached response time of 20ms. Most of their responses should be coming from a cache, given the type of site they run, otherwise they would need a lot more servers. [0]: https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we-do-app-caching/ https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we...
  - pier25 4y ago
    Their director of engineering did a podcast a couple of months ago: https://hanselminutes.com/847/engineering-stack-overflow-with-roberta-arcoverde https://hanselminutes.com/847/engineering-stack-overflow-wit...
- redleggedfrog 4y ago
bornfreddy 4y ago
You'd be surprised. I've had countless battles with (junior-wannabe-senior) devs who wanted to use a different framework simply because it is "fast". When you point out that this project will be a huge success if it has 10 req/s, the usual answer is "well it doesn't hurt", when it truth it does - if nothing else, because it diverts discussion from important matters (like consistency of the company's tech stack) to irrelevant ones. Dino makers are well aware of this. An otherwise great Python framework (based on Starlette) is even named "FastAPI" in an attempt to use this to their advantage (it is great for other reasons, not because of its speed). Unfortunately lots of devs are looking for silver bullets when it comes to speed, instead of detecting, determining, investigating and removing the bottlenecks.
- nesarkvechnep 4y ago
  Bet they, the junior devs, can’t even optimise their SQL queries.
  - GenerocUsername 4y ago
    Maybe they should use a faster db like nosql /S
  - postalrat 4y ago
    You would think by now that SQL databases would be pretty good about optimizing any query it receives.
- lillecarl 4y ago
  I've thought of the fastapi name as that it's fast to get going with rather than speed, it's python after all.
  - blooalien 4y ago
    Also what I thought … and indeed turns out to be the case in actual usage. It's quite fast to get a usable API up and running with FastAPI, starting from zero to the point of making useful requests to the API and getting back useful data. The actual speed of API access itself (the response times for the requests, etc) has never really been an issue I've wrestled with (me not being Twitter, etc. and not needing zillions of requests per second).
kotlin2 4y ago
But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.
- dmix 4y ago
  These sorts of things also build up over time. Usually when the underlying system is well thought out and performant it’s reflected in higher layers as well.
- thinkingkong 4y ago
  Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case. The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has to be fast so lets use this brand new thing” is the swan song of the eventually remorseful.
  - kotlin2 4y ago
    Bun has a philosophy that everything needs to be fast. Including things like CLI tools and process startup. Process startup being quick is important, especially in a severless environment. I understand your point, but it’d be nice to limit the discussion to Bun and Deno and not other theoretical possibilities.
    - hinkley 4y ago
      I appreciate that Bun wants to be fast, but what I need right now from Bun or Deno is a better concurrency primitive than sendMessage(). I’m so… angry that we waited all this time for a worker threads implementation in Node and what we got was this hot garbage. It’s a toy. There is no sane way to send multiple tasks to the same worker, because the results come back unordered and uncorrelated, unless you build your own layer on top of them. The public API should have been promise based, not event based.
redox99 4y ago
I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure. But if it's that JS execution is outright faster, it's a big deal. People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples 1) SSR with something like Material UI is slow, especially because of the CSS-in-JS. The server rendering the page can easily take 200ms or more. 2) Modern backend stacks. On an API I have I use Prisma + Apollo GraphQL. Some queries take 500ms. These same queries but using REST and knex are <10ms. There is no slow SQL queries here or N+1 issues, it's just prisma and graphql executing a lot of JS. In either case, the user experience is impacted because the website becomes slower. And a faster runtime would make these JS run faster, thus the web/api load faster.
- __alexs 4y ago
  They are all V8 so will all be approximately the same speed of JS execution I imagine?
  - detaro 4y ago
    They are not all V8
  - searchableguy 4y ago
    Bun uses javascript core. There is also overhead in passing structures and other communication required so that layer can change the number as well.
- weego 4y ago
  You've given 2 of the worst (imo) regressions in frontend dev in the last decade. If you're relying on innovation to make your existing tech stack not behave like dogshit when proven and trivial solutions exist, you're valuing the wrong things when choosing your stack.
  - azemetre 4y ago
    They may be the worst, but they have now become extremely common to find in a variety of company projects. Not just FAANG or FAANG-adjacent but boring insurance or healthcare companies too.
searchableguy 4y ago
Yeah. Performance is rarely a concern. Although they are pushing it for serverless where micro benchmarks may matter if they are related to execution and startup time. I think the benefit of deno or bun aren't as obvious when compared in the context of node on DX matter too. Most of the tooling and standard library can be used without using the cli and switching runtime. Tools like tsx simplifies running typescript code directly. It does pretty much what deno does internally using esbuild. The modularity of runtime doesn't matter to consumers even if it's pretty cool. FFI and security features are nice but I think the future is running sensitive code as a wasm module directly in separate isolated context. The browser compatibility is an awesome boost but most bundler will polyfill that for you out of the box and you will use a bundler with either deno or node most of the time. I know polyfilling is not perfect but it's good enough for most. I want to hear what strong reason people have for choosing to use either bun or deno in production. I use deno for writing scripts because it's so easy to run them especially if they have any dependencies but outside of that, I haven't reached out for it.
hinkley 4y ago
After a while you come to expect this to be the default state of the world. Then what surprises you is how often people believe benchmarks without asking to see the code.
thatwasunusual 4y ago
This is so true. Developers should focus more about time spent getting an application up and running (and to market) rather than how much time is spent serving an http request.
douglaswlance 4y ago
Claiming they're the fastest is a big marketing edge. It doesn't matter if they're only the fastest by 0.00001%.
jmartin2683 4y ago
It matters to the guy paying the AWS bill... or anyone who cares about their ecological impact. We have a duty to utilize resources as efficiently as possible, no different than anyone else. Building every new project on top of a mountain of abstraction that pushes resource utilization to few orders of magnitude beyond what is actually necessary to do the job is financially stupid at the least and socially irresponsible at worst. If you're an auto manufacturer and you discover something like fuel injection that will dramatically improve efficiency for your customers (the people paying that bill), not doing so makes you a terrible engineer. The 'developer velocity' argument is pure BS... there's absolutely no direct (or even really indirect) correlation there. If the ones you have need someone else to write 9 libraries so that they can build a REST API, you need better engineers.
- xyzzy123 4y ago
  For apps that are not successful, the entire output is waste, and the majority of the emissions burden is carbon output of the developers. For work of speculative value (most startups...), optimising for dev efficiency is IMHO the right thing to do.
  - jmartin2683 4y ago
    The only problem is that then you end up married to your mountain of abstractions. Designing things to work as intended from the outset is, in my experience, always the better path. It’s like ‘buy once, cry once’ for technical debt/effort.
eyelidlessness 4y ago
This microbenchmark in particular isn’t a reason I’d consider Bun. But the sum of many performance and DX considerations that have been put into Bun’s development—and that they are core motivating principles for the creator—certainly are. As for the error, I suspect it was an innocent mistake. I see no reason Deno would choose to mislead, when they’ve generally very publicly responded to performance deficits by acknowledging them and then actually improving real performance.
papito 4y ago
In a world where engineers just keep piling on cloud toys and oh hey microservices to solve very common problems, pretending that database and HTTP roundtrips are basically free, your choice of framework and language should not even matter. This is what's wrong with this industry.
spyder 4y ago
Here is a more realistic benchmark: https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x-faster-than-nodejs-and-deno-45od https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x...
imjonse 4y ago
Even when considering benchmarking errors, performance can be more objectively measured than developer ergonomics, good architecture, clear API and documentation, good implementation and other aspects that usually matter more than performance. It is usually the fun and immediately gamifiable aspect that more junior developers can and do easily optimize for.

ex3ndr 4y ago

Javascript is plagued with idea that it is slow while it is not. Many devs now have PTSR after arguing day after day that javascript is a good thing and not slow. Performance is a very important thing in js world for a peace of mind of devs.

naillo 4y ago
To be fair it did used to be quite slow. But that was like 10 years ago. General awareness hasn't caught up to the huge engineering efforts it seems.
- chrisco255 4y ago
  It's been 14 years since the v8 engine was released. Node.js has been out longer than 10 years.
- kitd 4y ago
  Ikr. You can regularly read some random dev tell the world "interpreted" Java is "too slow" for them.
  - andirk 4y ago
    Javascript isn't Java. Javascript follows ECMAScript, which also isn't Java. And ECMAScript isn't a language.
    - squeaky-clean 4y ago
      I don't know if they were making a JS joke but I have legitimately had newer programmers tell me that Java is an interpreted language because it compiles to a bytecode language which is interpreted by the JVM. Inversely I've had people argue that JS and Python are compiled languages because their interpreters convert statements into bytecode before executing them. When someone starts trying to argue those points I find its best to just give them a thumbs up and leave the conversation.
      - andirk 4y ago
        Describing Javascript can be confusing. C++ compiles -> C compiles -> assembly language compiles -> 1-for-1 to machine code. But Javascript be like "Javascript is the programming language interacts with your browser" or "Javascript conforms to the ECMAScript specification that describes how the language should act but is implemented according to the browser vendor's interpretation of said specification, and is further compiled according the browser." And that only covers browsers' Javascript. And I'm not even sure if the above is 100% accurate.
thinkingkong 4y ago
I agree performance is important, but it’s optimistic for any dev to assume that this particular layer is the place where things will be slow. Introduce a single file or other 3rdparty IO dependent method on your HTTP response and poof
maccard 4y ago
> Javascript is plagued with idea that it is slow while it is not. I benchmarked a hello world in .net and node/express, and the .net version was multiple orders of magnitude faster than the node/express version. That's a starting point, and as you add more logic, that gap only grows in my experience. Javascript may be fast _enough_ for many cases, and in a tight JIT loop it may be faster again, but by any measure, js is not quick.
- geysersam 4y ago
  No realistic, decently written, js application would be "orders of magnitude" faster if rewritten in .net.
  - maccard 4y ago
    And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever seen say - js is significantly slower. One example is the techempower benchmarks Fortune section[0]. It's a fairly basic app, but it tests a full stack web app in multiple languages, and it's pretty clear that js is fimrly in the middle of the pack, far behind the compiled options. If you have any sources to the contrary, I'd love to see them. [0] https://www.techempower.com/benchmarks/#section=data-r21&test=fortune https://www.techempower.com/benchmarks/#section=data-r21&tes...
    - LunaSea 4y ago
      JavaScript ranks higher than C# in your benchmark.
      - maccard 4y ago
        See my other response here https://news.ycombinator.com/item?id=33224873 https://news.ycombinator.com/item?id=33224873
deleted 4y ago
[deleted]

pier25 4y ago

Exactly. Very few companies will need to reach 1000 reqs/s consistently, let alone 100k reqs/s. StackOverflow peaks at about 6000 reqs/s and it's an extremely popular website.

swyx 4y ago
got a source for this stackoverflow peak? also wondering what peak RPS is for HN. i feel like most (non consumer) startups would be like "ok if its good enough for HN its good enough for me"
- ksec 4y ago
  >got a source for this stackoverflow peak? It is [1] ( and should be ) pretty well known. 1.3 BILLION page view per month, 6K RPS with 9 ( Fairly Weak ) Servers, Sub 20ms response time with zero caching. >also wondering what peak RPS is for HN. Less than 100 RPS for logged in users. The number were pre 2020 but I doubt the current number is significantly higher. [1] https://stackexchange.com/performance https://stackexchange.com/performance
  - coder543 4y ago
    > Sub 20ms response time with zero caching. I mean... to be clear, they do tons of caching[0], which is certainly critical for their ability to have a non-cached response time of 20ms. Most of their responses should be coming from a cache, given the type of site they run, otherwise they would need a lot more servers. [0]: https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we-do-app-caching/ https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we...
- pier25 4y ago
  Their director of engineering did a podcast a couple of months ago: https://hanselminutes.com/847/engineering-stack-overflow-with-roberta-arcoverde https://hanselminutes.com/847/engineering-stack-overflow-wit...
redleggedfrog 4y ago

bornfreddy 4y ago

You'd be surprised. I've had countless battles with (junior-wannabe-senior) devs who wanted to use a different framework simply because it is "fast". When you point out that this project will be a huge success if it has 10 req/s, the usual answer is "well it doesn't hurt", when it truth it does - if nothing else, because it diverts discussion from important matters (like consistency of the company's tech stack) to irrelevant ones. Dino makers are well aware of this. An otherwise great Python framework (based on Starlette) is even named "FastAPI" in an attempt to use this to their advantage (it is great for other reasons, not because of its speed). Unfortunately lots of devs are looking for silver bullets when it comes to speed, instead of detecting, determining, investigating and removing the bottlenecks.

nesarkvechnep 4y ago
Bet they, the junior devs, can’t even optimise their SQL queries.
- GenerocUsername 4y ago
  Maybe they should use a faster db like nosql /S
- postalrat 4y ago
  You would think by now that SQL databases would be pretty good about optimizing any query it receives.
lillecarl 4y ago
I've thought of the fastapi name as that it's fast to get going with rather than speed, it's python after all.
- blooalien 4y ago
  Also what I thought … and indeed turns out to be the case in actual usage. It's quite fast to get a usable API up and running with FastAPI, starting from zero to the point of making useful requests to the API and getting back useful data. The actual speed of API access itself (the response times for the requests, etc) has never really been an issue I've wrestled with (me not being Twitter, etc. and not needing zillions of requests per second).

kotlin2 4y ago

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

dmix 4y ago
These sorts of things also build up over time. Usually when the underlying system is well thought out and performant it’s reflected in higher layers as well.
thinkingkong 4y ago
Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case. The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has to be fast so lets use this brand new thing” is the swan song of the eventually remorseful.
- kotlin2 4y ago
  Bun has a philosophy that everything needs to be fast. Including things like CLI tools and process startup. Process startup being quick is important, especially in a severless environment. I understand your point, but it’d be nice to limit the discussion to Bun and Deno and not other theoretical possibilities.
  - hinkley 4y ago
    I appreciate that Bun wants to be fast, but what I need right now from Bun or Deno is a better concurrency primitive than sendMessage(). I’m so… angry that we waited all this time for a worker threads implementation in Node and what we got was this hot garbage. It’s a toy. There is no sane way to send multiple tasks to the same worker, because the results come back unordered and uncorrelated, unless you build your own layer on top of them. The public API should have been promise based, not event based.

redox99 4y ago

I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure. But if it's that JS execution is outright faster, it's a big deal. People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples 1) SSR with something like Material UI is slow, especially because of the CSS-in-JS. The server rendering the page can easily take 200ms or more. 2) Modern backend stacks. On an API I have I use Prisma + Apollo GraphQL. Some queries take 500ms. These same queries but using REST and knex are <10ms. There is no slow SQL queries here or N+1 issues, it's just prisma and graphql executing a lot of JS. In either case, the user experience is impacted because the website becomes slower. And a faster runtime would make these JS run faster, thus the web/api load faster.

__alexs 4y ago
They are all V8 so will all be approximately the same speed of JS execution I imagine?
- detaro 4y ago
  They are not all V8
- searchableguy 4y ago
  Bun uses javascript core. There is also overhead in passing structures and other communication required so that layer can change the number as well.
weego 4y ago
You've given 2 of the worst (imo) regressions in frontend dev in the last decade. If you're relying on innovation to make your existing tech stack not behave like dogshit when proven and trivial solutions exist, you're valuing the wrong things when choosing your stack.
- azemetre 4y ago
  They may be the worst, but they have now become extremely common to find in a variety of company projects. Not just FAANG or FAANG-adjacent but boring insurance or healthcare companies too.

searchableguy 4y ago

Yeah. Performance is rarely a concern. Although they are pushing it for serverless where micro benchmarks may matter if they are related to execution and startup time. I think the benefit of deno or bun aren't as obvious when compared in the context of node on DX matter too. Most of the tooling and standard library can be used without using the cli and switching runtime. Tools like tsx simplifies running typescript code directly. It does pretty much what deno does internally using esbuild. The modularity of runtime doesn't matter to consumers even if it's pretty cool. FFI and security features are nice but I think the future is running sensitive code as a wasm module directly in separate isolated context. The browser compatibility is an awesome boost but most bundler will polyfill that for you out of the box and you will use a bundler with either deno or node most of the time. I know polyfilling is not perfect but it's good enough for most. I want to hear what strong reason people have for choosing to use either bun or deno in production. I use deno for writing scripts because it's so easy to run them especially if they have any dependencies but outside of that, I haven't reached out for it.

hinkley 4y ago

After a while you come to expect this to be the default state of the world. Then what surprises you is how often people believe benchmarks without asking to see the code.

thatwasunusual 4y ago

This is so true. Developers should focus more about time spent getting an application up and running (and to market) rather than how much time is spent serving an http request.

douglaswlance 4y ago

Claiming they're the fastest is a big marketing edge. It doesn't matter if they're only the fastest by 0.00001%.

jmartin2683 4y ago

It matters to the guy paying the AWS bill... or anyone who cares about their ecological impact. We have a duty to utilize resources as efficiently as possible, no different than anyone else. Building every new project on top of a mountain of abstraction that pushes resource utilization to few orders of magnitude beyond what is actually necessary to do the job is financially stupid at the least and socially irresponsible at worst. If you're an auto manufacturer and you discover something like fuel injection that will dramatically improve efficiency for your customers (the people paying that bill), not doing so makes you a terrible engineer. The 'developer velocity' argument is pure BS... there's absolutely no direct (or even really indirect) correlation there. If the ones you have need someone else to write 9 libraries so that they can build a REST API, you need better engineers.

xyzzy123 4y ago
For apps that are not successful, the entire output is waste, and the majority of the emissions burden is carbon output of the developers. For work of speculative value (most startups...), optimising for dev efficiency is IMHO the right thing to do.
- jmartin2683 4y ago
  The only problem is that then you end up married to your mountain of abstractions. Designing things to work as intended from the outset is, in my experience, always the better path. It’s like ‘buy once, cry once’ for technical debt/effort.

eyelidlessness 4y ago

This microbenchmark in particular isn’t a reason I’d consider Bun. But the sum of many performance and DX considerations that have been put into Bun’s development—and that they are core motivating principles for the creator—certainly are. As for the error, I suspect it was an innocent mistake. I see no reason Deno would choose to mislead, when they’ve generally very publicly responded to performance deficits by acknowledging them and then actually improving real performance.

papito 4y ago

In a world where engineers just keep piling on cloud toys and oh hey microservices to solve very common problems, pretending that database and HTTP roundtrips are basically free, your choice of framework and language should not even matter. This is what's wrong with this industry.

spyder 4y ago

Here is a more realistic benchmark: https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x-faster-than-nodejs-and-deno-45od https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x...

imjonse 4y ago

Even when considering benchmarking errors, performance can be more objectively measured than developer ergonomics, good architecture, clear API and documentation, good implementation and other aspects that usually matter more than performance. It is usually the fun and immediately gamifiable aspect that more junior developers can and do easily optimize for.