181–190 of 196 posts
Earlier quoted context omitted.
Just-js is not really a Javascript: https://github.com/just-js/just . .Net in that list much closer to what everyone assumes.Net is.
Looks like Javascript to me https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
Earlier quoted context omitted.
Maybe not .net, but I've worked on 3D graphics in the browser and can say with confidance that rewriting your app in C or C++ could see orders of magnitude perf increase over JS.
Comparing a pure js implemention to code using opengl or webgl, I imagine several orders of magnitude difference is likely. But a decent js implemention of 3D graphics-something would use one of the available tools for such applications. Making the difference considerably smaller. Or is you experience different?
The three major blockers I remember were:
1. Render contexts are created on the main thread and the user of the library gets no control over this. This means all driver overhead and library function calls block the main thread, which matters a lot when trying to hit 8ms/frame.
2. Loading textures asynchronously (in another thread, not Javascript async/await) was straight up impossible due to poor architecture. This means app startup was 500ms instead of 5ms. Maybe not a big deal to you, but our use case necessitated quick (a few frames at worst) startup.
3. The renderer used a scene graph, which was hilariously slow to traverse for large numbers of objects. Impossible to optimize by anyone as far as I can tell. Scene graphs just don't work well in JS.
If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.
> If you care about performance that much you should be using neither. Unfortunately by the time the coding industry understand this , we'll already have a fifth JS runtime that will promise to solve all the performance issues that exist within the 4 others... Node.JS / Electron are some of my most favorite tech , but if I need performance I'll go with Kotlin / Go / Rust , it's just simpler IMHO.
Node.js is getting faster, for free, because things like Deno and Bun exist.
If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.
If you are buying into JS/TS the very last thing you are getting is DX. I have never worked with such a low quality ecosystem ever before and I hope I won't have to endure it for too much longer. If you want DX you are better off with JVM, Rust or something similarly well designed. Hell, Go has better DX than JS/TS and that is a pretty low bar. Real build systems, real module systems (instead of like 3 competing inco…
Earlier quoted context omitted.
> to see if the lack of surrounding ecosystem will actually affect their project for projects of any significant size, that answer is a resounding "yes".
I think engineering is more nuanced than that, personally.
for anything that can plausibly grow in scope and team size (which, let's be honest here, is most complex projects), it almost never makes sense to go without an existing ecosystem. it becomes difficult to hire, difficult to train, difficult to pass off maintenance, slows down velocity of shipping, makes your team gradually re-invent a worse version of the framework/tooling you initially tried to avoid, etc.
i've been on both kinds of projects. when i build something solo it's a work of art in code size, API consistency, and performance...and that feels truly amazing. but unfortunately it's not something that is feasible with bigger and more diverse-skillset teams. ever-growing scope and shipping features quickly usually means giving up performance and well thought out design.
Earlier quoted context omitted.
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.
> 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, j…
For example, go can handle about the same amounts (be advised that this tests are for 4 cores, so results have to be divided): https://github.com/smallnest/go-web-framework-benchmark
Related flagged article with good context/comments that a lot of HN readers probably didn't see because it got flagged: https://news.ycombinator.com/item?id=33199351
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 yo…
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 irresponsi…
For work of speculative value (most startups...), optimising for dev efficiency is IMHO the right thing to do.
Earlier quoted context omitted.
Ah yeah in the submitted article they say the updated benchmark used “ latest Bun…” - so does that mean that it was just tested using a released version (lacking multithreading) instead of a nightly build (with recently added multithreading)? As an aside, I’ve now seen a couple of HN submissions relating to Bun and there’s been a vibe that there’s conspiracy or foul play afoot in each. That’s a little … unusual. What…
> As an aside, I’ve now seen a couple of HN submissions relating to Bun and there’s been a vibe that there’s conspiracy or foul play afoot in each. Kinda weird IMO That's inevitable when companies with big investments have to market a performance-oriented product to a public that doesn't fully understand the nuance of software performance running on modern hardware. The average JS dev doesn't really know what's happe…
And the original benchmarks of bun vs deno had bun using a native-code http server against a deno using a js-code http server, afaik. And the bun-specific-fork-of-react vs deno + normal react, was suspect too.
When you import “react-dom/server” in Node, it actually loads “react-dom/server.node.js” When you import “react-dom/server” in browsers or Deno, it loads “react-dom/server.browser.js” When you import “react-dom/server” in Bun, it will load “react-dom/server.bun.js”. https://twitter.com/sebmarkbage/status/1560609478227030016
Its not so much of a useful thing to just focus so much on what you use to benchmark.
Reminds of:
https://www.theregister.com/2021/01/28/nvidia_tpc_benchmark/
https://www.zdnet.com/article/futuremark-reverses-nvidia-did...
Like, you wouldn't be impressed if it was react bun vs preact deno, right?