I don't know why isn't anyone basically just compiling Typescript to C# or Rust or something faster at this point instead of compiling to Javascript and running in a dynamic runtime. (yes, I say compiling, `transpiling` is bullshit, its not even a word)
Let's face it. Developing a new JS framework has become the minimum requirement for an internship application at a startup that will last as long as the initial vc funding will take it.
Hey, I'm currently watching this video but I right away wanted to comment that your diagram and explanation on runtime and framework was probably the clearest I've come across yet. Thank you for this... helpful for me navigating this stuff
I wrote an HTTP server in C++ using Drogon. It was ridiculously fast when serving pre-rendered pages, going up to a million req/s, easily beating Go doing the same. However, as soon as I started doing a bit of templating using various existing and naive JSON-in-the-middle approaches this dropped way down, sometimes to under 100k req/s. I then spent a bunch of time writing an inline templating engine based on libfmt that was able to go close to 700k req/s on a real workload. Oh, and by the way, the server in question was only ever intended to serve a single lone user at a time on a closed network, so that time spent turbo optimizing the hell out of it was suuuper worthy.
@@kyle8575 there are multiple very clear jumpcuts in that part of the video so it's definitely them acknowledging it and choosing to ignore it rather than just being lazy lol
Wait a second, you had Spider Monkey right next to Tokio and we didn't even get a TOKIOOO? What have you become, Prime? I love Go as much as the next dev, but let's not forget where we came from.
clearly not, why do u think we keep making more electron garbage and offsetting any advancement in CPU tech by making our programs more bloated with 408349 layers of abstraction?
nope, we're wasting time making "flashy" new runtimes in "flashy" new languages using js engines that *aren't* v8 (💀) and not contributing to node.js... these runtimes are gonna go nowhere lmao
If only people invested all this effort into something that makes sense, unlike JS on backend (or anywhere else, really)... For some reason, re-lipsticking the pig seems to be the preferred modus operandi of our industry.
I appreciate that the benchmark Bun uses for its built-in builder is Three.js, which is a fairly large project. It's at least a real benchmark. In a way though, their hand was forced on that front, because they were just copying the benchmark that esbuild was using, since they wanted to demonstrate that bun was faster than esbuild.
2019: fastest thing in the world was release of a new JavaScript framework 2024: scratch that fastest thing in the world is release of a new js runtime environment
Presumably by "executed natively," they mean when WinterJS is compiled to x86-64 (or some other native instruction set) versus it being compiled to WASM to run inside of a browser-like application. They're not taking about the JavaScript code itself.
like seriously, if i were to done my projects and building portfolio at the same rate as JS making another framework i will probably rich enough i'll retire in my 20, having my own yatch, and living on a mansion rather than thinking of hopping jobs and risking myself of early heart attack.
Sale a new JS runtime to a group that is using VSC (roughly mid 2016), NodeJS before 14, Angular 11, and will not give their devs "ng" command access. For those that do not know what is "ng", it is sort of like "npx" but specifically for Angular builds. To get those commands to work you have to put those "ng" commands into package.json
The speed shouldn't be their selling point, but having a wasmer runtime is actually really dope. Wasm will slowly take over. It's already being added to k8s as a runnable type because it solves a lot of the problems that docker does, but lighter and static with basically no cold start times
Zig, if I recall, is basically an extension to C. Unless you're writing the assembly by hand, you aren't going to beat C anytime soon since, unlike C, rust actually stops you from shooting yourself in the foot. Unfortunately, these safety checks add instructions that slow down your code.
Cant we create a compiler that compiles js code to machine code that is optimised and all the good stuff that will make js a good option for the server?
The issue is that I've branched out from JS....honestly, I don't think it is the best language for backend stuff. Ironically, because the fragmentation is horrible.
I don't really see the appeal for frond-end/full-stack apps for this over Bun. Bun is in the same order of magnitude in speed and, most importantly, has amazing DX with Typescript and package management. This seems to be tailored to edge functions, which makes sense, because its made by Wasmer
The only thing that would shake the JS runtime space is a compiler with 2-3x performance. Sticking with standard JIT Javascript is just going to be slow regardless.
Mayank Choubey made a "real-world application benchmarks" of bun and rust and go. Summary: don't use JS for backend. It's only fast at returning hello world. Once you start talking to a DB, and dealing with Tokens and serializing, you become slow with JS.
Me: loves scheme The world: Nobody develops serious software in Scheme. There are too many implementations and they all work differently. JavaScript: has Node, Deno, Bun, WinterJS, all the different subtly incompatible browser runtimes, QML, GNOME... The world: 😍
The description was framework soup. I also hate synthetic benchmarks for the reasons you mentioned. We got them in console wars especially, and practical benchmarks often show that the marketing department reasons don't make as much of a difference as the marketing department says. Real-world ones are better. Synthetic gaming benchmarks on a recent SSD shootout? The top SSD DESTROYS the others. Real-world benchmark for gaming? The fastest SSD loaded... 2 seconds faster. The mid-grade SSD vs one that's in the next "bang for the buck bracket"? Often .25 seconds to 1 second. Once the game is loaded, you aren't going to feel it. To be fair, synthetic benchmarks for storage tends to be better than most, but people tend to read too into them. WHY ARE YOU BUYING THAT HIGH-END SSD, EVEN THOUGH IT'S ONLY $10-20 MORE? "Uh... even though it's going into a PCIe 2.0 system and the SSD is PCIe 4.0 or 5.0 or whatever, you still get improved 4k performance. That 4k performance is one you can often feel, and 4k won't bottleneck PCIe 2.0." And indeed, we felt a difference in the system. It was also only $10-20 more, it was from a better brand, and the reasons pile up. It made a very sluggish system into one that's life just got extended by 2-5 years.
This kind of stuff is basically the equivalent of premature optimization. Let's make a wild assumption and say this gives you a 100x increase in request processing time. Going from the numbers on these tests, let's say you go from serving "Hello" at 2k/s to 200k/s. This is the equivalent of going from 0.5ms per request to 0.005ms per request. Any real application is going to spend a lot of time parsing the request, almost certainly going to a database, and then building and serving a response that probably could have been cached. Let's be optimistic and say all that takes 10ms. The actual runtime, all of it, accounts for less than 5% (in the worst case at 2k/s!) of time between getting the request and sending the response. Stop optimizing the 5%, optimize the 95%: file sizes, template complexity, caching, database queries.
Not implement async_hooks? Dear god, that is the best feature in node and any language I have ever seen! I rely on it so much and when used strategically it makes writing code such a joy! I would not give that up for any speed improvement.
Check the math. Go did 201k/sec. Bun did 155k/sec. WinterJS (according to their benchmark) has ~130% the throughput of Bun. Which gets to you .... drum roll please .... 201k/sec. Likely parallelism settings is the reason for absolute difference in your benchmarking.
Love you even more that you started with XNA, it''s still trash - but as far as quick opem-dev platforms from a first-party console company goes - it was pretty slick. They should have legit kept XNA alive.
SummerJS is just around the corner
Just after SpringJS
@@lhard123lyes because we need to port it from Java
@@azizsafudin 💀💀💀💀💀
Lets not forget about AutumnJS
Then we will get SeasonsJS
at this rate js runtimes will outpace new AI models.
I was gonna say they will outpace new js frameworks, but maybe that goes a little too far.
@@nekekaminger Frameworks are at 10x release speed
@@justpatrick_ai will create the frameworks
Seems like there's a Moore's Law for Javascript frameworks and runtimes.
I don't know why isn't anyone basically just compiling Typescript to C# or Rust or something faster at this point instead of compiling to Javascript and running in a dynamic runtime. (yes, I say compiling, `transpiling` is bullshit, its not even a word)
Let's face it. Developing a new JS framework has become the minimum requirement for an internship application at a startup that will last as long as the initial vc funding will take it.
Anything less can be done by Devin 😅
lol
A Year out of school for me and I still can't get my first tech job.
@@Doomlovesearth2is it that bad?
@@justhit6673 Yep.
"Hardware is 100 times faster, which let me write programs that are 100 folds slower." - Modern Web Developers
Ahaha, soooo true 😂
Read it in Jonathan Blow's voice
Yes because game devs doesn't write unoptimized games nowadays.
JS runtimes are the new to-do apps
While I was watching this video, 2 new runtimes, 8 new frontend frameworks, and approx 1 billion js libraries were released.
So is just those 3 big thing again:
1. Google V8 for node
2. Apple JSC for bun
3. Mozilla SpiderMonkey for WinterJS
I'm here for Mozilla...
@@LucasBonafe Which one is better nowadays?
AFAIK V8 does memory great, SpiderMonkey is so-so, JSC is known to be the slowest before iOS 17.
Hey, I'm currently watching this video but I right away wanted to comment that your diagram and explanation on runtime and framework was probably the clearest I've come across yet. Thank you for this... helpful for me navigating this stuff
"blazing-fast" made my day
"Blazingly fast" is the new "making the world a better place"
when you just started to learn rust and need a motivation to proceed. xD i'm also a beginner BTW lol.
how fast is a blaze anyway.
Days since last JavaScript tool: -9000
0 programmers were scolded by their chief
But then another one was gone, their number was FF
I like the format of trying to explain things using the whiteboard
"ahem" technically it's a blackboard.
What’s with the all the racism guys? It’s just a board.
Person of color board
@@coldestbeerSo... not-white-person board?
Who needs excalidraw
Only trust benchmarks where you can run it yourself on your own machine and see the numbers
I wrote an HTTP server in C++ using Drogon. It was ridiculously fast when serving pre-rendered pages, going up to a million req/s, easily beating Go doing the same. However, as soon as I started doing a bit of templating using various existing and naive JSON-in-the-middle approaches this dropped way down, sometimes to under 100k req/s. I then spent a bunch of time writing an inline templating engine based on libfmt that was able to go close to 700k req/s on a real workload.
Oh, and by the way, the server in question was only ever intended to serve a single lone user at a time on a closed network, so that time spent turbo optimizing the hell out of it was suuuper worthy.
Dude JSON makes everything slower. I use Rust/Axum and just switching from JSON to MsgPack gave 10-100 times speedup depending on message size.
Love it when he tells his editor to do something and he doesn't listen XD
I noticed this in another video as well, looks like he's slacking off :D
@@kyle8575 there are multiple very clear jumpcuts in that part of the video so it's definitely them acknowledging it and choosing to ignore it rather than just being lazy lol
@@imaadhaq540 In that case, I stand corrected. Going to delete my original comment as I don't want to spread misinformation.
Was just reading this article, and wished I had your input and boom! Here it is, thanks
That lightning reminds me of something else :P
"WINAMP Winamp winamp. It really whips the lamma's ass"
Based-ass comment
Wait a second, you had Spider Monkey right next to Tokio and we didn't even get a TOKIOOO? What have you become, Prime? I love Go as much as the next dev, but let's not forget where we came from.
are we still making JavaScript runtimes? haven't we learned anything?
clearly not, why do u think we keep making more electron garbage and offsetting any advancement in CPU tech by making our programs more bloated with 408349 layers of abstraction?
nope, we're wasting time making "flashy" new runtimes in "flashy" new languages using js engines that *aren't* v8 (💀) and not contributing to node.js... these runtimes are gonna go nowhere lmao
because they only know JavaScript
@@FlanPoirotit’s not even abstraction. Just garbage.
@@32gigs96It's both. The JS way of doing things is framework on top of framework on top of an already slow, heavily abstracted language
If only people invested all this effort into something that makes sense, unlike JS on backend (or anywhere else, really)... For some reason, re-lipsticking the pig seems to be the preferred modus operandi of our industry.
Then... invested the effort somewhere else yourself? Such a weird take, let the people build the stuff they want.
Maybe don't yell at water for flowing and instead get a hose?
I love it when there's something new in JS, it's always advertised as fastest or faster
I love how the thumbnail is Prime looking towards the future but as soon as you click he's shaking his head and already upset. Classic Prime 😂
I appreciate that the benchmark Bun uses for its built-in builder is Three.js, which is a fairly large project. It's at least a real benchmark.
In a way though, their hand was forced on that front, because they were just copying the benchmark that esbuild was using, since they wanted to demonstrate that bun was faster than esbuild.
2019: fastest thing in the world was release of a new JavaScript framework
2024: scratch that fastest thing in the world is release of a new js runtime environment
Lol “Fastest” and “SpiderMonkey” are words that have no business being in the same sentence as each other
To be fair, most of the speed are host questions, not scripting engine questions.
"SpiderMonkey is not the Fastest JavaScript engine."
@@tjmnkrajyej know what? Touché.
Every js framework: Speed
Reality: Slow + 70gb RAM per button.
Native languages: look what they need to mimic a fraction of our power
Presumably by "executed natively," they mean when WinterJS is compiled to x86-64 (or some other native instruction set) versus it being compiled to WASM to run inside of a browser-like application.
They're not taking about the JavaScript code itself.
I always make applications that only serve "Hello World" responses so this fits my one use-case!
Oh God, they're writing whole new JS runtimes now! Dx
like seriously, if i were to done my projects and building portfolio at the same rate as JS making another framework i will probably rich enough i'll retire in my 20, having my own yatch, and living on a mansion rather than thinking of hopping jobs and risking myself of early heart attack.
new frameworks - > new runtimes - > new specific computing hardwares
LOOK WHAT THEY NEED TO DO TO MIMIC A FRACTION OF C++'S POWER
can't wait to see what runtime comes out next month
So we're spamming runtimes now? Javascript is truly one of the languages of all time.
JavaScript is unhinged
Sale a new JS runtime to a group that is using VSC (roughly mid 2016), NodeJS before 14, Angular 11, and will not give their devs "ng" command access.
For those that do not know what is "ng", it is sort of like "npx" but specifically for Angular builds. To get those commands to work you have to put those "ng" commands into package.json
I was gonna say something about "haha javascript runtimes are the new javascript frameworks" but then I saw its made by wasmer and I went like 🥰🥰
Your statement isn't incorrect and I don't get why Wasmer doing it is better
I fully enjoyed* this video.
From the creators of “yet another JS framework”…
YET ANOTHER JS RUNTIME :D
I love that you paying attention to details. Asterisk ✳️ I was not aware of this 😅
uses gimp like a pro
i bet he can make a circle in 2 steps
Real men draw circles freehand.
I draw circles using the html canvas API
The speed shouldn't be their selling point, but having a wasmer runtime is actually really dope. Wasm will slowly take over. It's already being added to k8s as a runnable type because it solves a lot of the problems that docker does, but lighter and static with basically no cold start times
Can’t resist, I’m gonna day it. ‘Blazingly fast’
the new js framework everyday became the new js runtime everyday
I started ingoring newJS Runtimes and Frameworks. For my needs, I can still use NodeJS and get everything done. :)
Idea: take Primeagens "whiteboard" character drawings and turn it into a font.
Then use that font while coding. In VSCode
Zig, if I recall, is basically an extension to C. Unless you're writing the assembly by hand, you aren't going to beat C anytime soon since, unlike C, rust actually stops you from shooting yourself in the foot. Unfortunately, these safety checks add instructions that slow down your code.
We've switched from constant releases of new JS frameworks to full JS runtimes. What's next?
"...because at the end of the day, you're still running JavaScript."🏆
Can't wait for SummerJS, MonsoonJS, SpringJS, FallJS
Can't believe Theo did "TOKIOOOOOOOO" and Prime didn't Sadge
Cant we create a compiler that compiles js code to machine code that is optimised and all the good stuff that will make js a good option for the server?
Just use another language lol
@@FirstYokai yeah i currently do my backend codes with spring boot.....but is it possible in js thats the question
@@FirstYokai bravo problem solved🤦🤦
@@Vinu-kj6qgit’s literally v8. V8 does this. It’s a JIT compiler
JS is not a static language, so, no, it can't be optimized.
The issue is that I've branched out from JS....honestly, I don't think it is the best language for backend stuff. Ironically, because the fragmentation is horrible.
I don't really see the appeal for frond-end/full-stack apps for this over Bun. Bun is in the same order of magnitude in speed and, most importantly, has amazing DX with Typescript and package management. This seems to be tailored to edge functions, which makes sense, because its made by Wasmer
I really look forward to the day I understand all the code stuff you talk about easily.
December.js Jaunary.js February.js and so on.
when do we get a package manager and registry for runtimes?
thanks for hands-on test/duel between go and bun
XNA... That was a shoutout I was not expecting!
bro my brain can't handle this anymore, that fact that I just started installing bun hours ago 💀
"Hey flip edit this...." Flip does not edit and we watch prime awkwardly mumble to himself setting up a new project 🤣🤣
Shoutout to all of the Super Mario Kart enthusiasts, for those who are actually aware of its existence
Spidermonkey best name ever
About fucking time for a new JS something
HAHAHAHA
Goood video, although, lets check if there is something new already out maybe 😅
The only thing that would shake the JS runtime space is a compiler with 2-3x performance. Sticking with standard JIT Javascript is just going to be slow regardless.
Mayank Choubey made a "real-world application benchmarks" of bun and rust and go. Summary: don't use JS for backend. It's only fast at returning hello world. Once you start talking to a DB, and dealing with Tokens and serializing, you become slow with JS.
Last few days i successfully compiles Boa (JS runtime in Rust) to pure WASM, no WASI, no bindgen. So i guess that's a plus.
11:15 We've gone too far, the JS runtimes are becoming sentient. They're Tweeting!
🤣😂 "not like you are getting anywhere. 90% of startups fail anyway. " brutal.
Absolutely here for the Mario Kart reference! ⚡️
I’ll just close my eyes for 1 year and let all these frameworks battle it out
Me: loves scheme
The world: Nobody develops serious software in Scheme. There are too many implementations and they all work differently.
JavaScript: has Node, Deno, Bun, WinterJS, all the different subtly incompatible browser runtimes, QML, GNOME...
The world: 😍
Guess I'm sticking with node until we get the over 20+ new runtimes and one of them actually ends up being useful
The description was framework soup. I also hate synthetic benchmarks for the reasons you mentioned. We got them in console wars especially, and practical benchmarks often show that the marketing department reasons don't make as much of a difference as the marketing department says. Real-world ones are better.
Synthetic gaming benchmarks on a recent SSD shootout? The top SSD DESTROYS the others. Real-world benchmark for gaming? The fastest SSD loaded... 2 seconds faster. The mid-grade SSD vs one that's in the next "bang for the buck bracket"? Often .25 seconds to 1 second. Once the game is loaded, you aren't going to feel it.
To be fair, synthetic benchmarks for storage tends to be better than most, but people tend to read too into them. WHY ARE YOU BUYING THAT HIGH-END SSD, EVEN THOUGH IT'S ONLY $10-20 MORE? "Uh... even though it's going into a PCIe 2.0 system and the SSD is PCIe 4.0 or 5.0 or whatever, you still get improved 4k performance. That 4k performance is one you can often feel, and 4k won't bottleneck PCIe 2.0." And indeed, we felt a difference in the system.
It was also only $10-20 more, it was from a better brand, and the reasons pile up. It made a very sluggish system into one that's life just got extended by 2-5 years.
You get the lightening bolt in Mario Kart when you're losing really badly. The only thing you should feel then is shame, utter shame!
When you shout you sound like Michael Scott from the Office
Time to update my project to use the new runtime. This will fix all my problems
when will we get a Rust powered JS runtime?
The Winter is coming ❄️
This kind of stuff is basically the equivalent of premature optimization. Let's make a wild assumption and say this gives you a 100x increase in request processing time. Going from the numbers on these tests, let's say you go from serving "Hello" at 2k/s to 200k/s. This is the equivalent of going from 0.5ms per request to 0.005ms per request. Any real application is going to spend a lot of time parsing the request, almost certainly going to a database, and then building and serving a response that probably could have been cached. Let's be optimistic and say all that takes 10ms. The actual runtime, all of it, accounts for less than 5% (in the worst case at 2k/s!) of time between getting the request and sending the response. Stop optimizing the 5%, optimize the 95%: file sizes, template complexity, caching, database queries.
TL;DR: Your web application isn't slow because of your runtime, it's slow because of your own code and file sizes
Kind of a bummer he didn't test bun again with JSON stringify/parse.
Not implement async_hooks? Dear god, that is the best feature in node and any language I have ever seen! I rely on it so much and when used strategically it makes writing code such a joy! I would not give that up for any speed improvement.
Stockholm syndrome?
@@mattetis Lmao
Before we find out that it was written by Devin 😂😂
invalid video: at 1:42 you didnt do the "TOKIOO" scream
they released new JS framework like every nanosecond
LOL took me a while to notice it was your Pixel that was getting notifications and not mine.
Check the math. Go did 201k/sec. Bun did 155k/sec. WinterJS (according to their benchmark) has ~130% the throughput of Bun.
Which gets to you .... drum roll please .... 201k/sec.
Likely parallelism settings is the reason for absolute difference in your benchmarking.
Bun's mistake was using a binary format for the lock file. That's not something I want to be committed, and it belongs in the cache folder.
But deep down you do care, I bet we will see a todo application in 3 hours time testing wasmer against all frameworks. We are with you Primetime.
Love you even more that you started with XNA, it''s still trash - but as far as quick opem-dev platforms from a first-party console company goes - it was pretty slick.
They should have legit kept XNA alive.
Waiting for spring.js or fall.js
If only we could put this much effort into upbuilding underused languages like Go, Kotlin, Dart, etc. Make some libraries for that!
They are multiplying like Bacteria
Instead of taking a plane, some people keep trying to make their bike faster. 😂
This is partly why I am going back to Java, there you have Spring and it has been running for the last 20yrs 😌
This would be fine if it was 0.1 instead of 1.0 as they claim.
We want NUMBER GO BIG!
201x - new js lib each day. 202x - new js runtime each day. 203x - new js sublang each day
Its so nice that Nikola Tesla explains us computer science.
Every framework should have it's own runtime.