ไม่สามารถเล่นวิดีโอนี้
ขออภัยในความไม่สะดวก
JS At The Speed Of C
ฝัง
- เผยแพร่เมื่อ 24 พ.ย. 2023
- What if JavaScript was fast? Like really, really fast? Static Hermes is making that dream into reality.
TWEET: / 1720103356738474060
TALK: • Static Hermes: the Nex...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
The effort that a js dev puts to keep using js is insane.
The JS market share is bigger than anything else, so I mean...
Js is the spaghetti code you wrote on a project and the whole application keeps building off it.
All of the other choices like Rust WASM are unwieldy dumpster fires which nobody uses, so I guess it's valid
@@okie9025lmao rust wasm is more weildy than js, at least I can guarantee someones dark reader isn't gonna fuck up my entire website by changing some class name or something
@@okie9025why wasm for native apps? why not computer's cpu architecture?
I love when I hear Javascript is slow from co-workers who only code in Python.
I work with python and js and my anecdotal experiences have always pointed to js being much faster than python, v8 already is magic to me!
@@KumarAbhinav2812..everything is faster than Python. Even PHP, which has a bad rep, is something like double the speed of Python.
@@KumarAbhinav2812makes sence that a JIT interpreter runs much more faster than a VM lol
@@lolcat69 Yep! But nothing stops python from being JITted either so :) in fact, I believe concentrated attempts like numba have already shown how great the benefits could be
I think their claim might not be completely unfounded. Many python data processing packages are written in C in a sense that python is just a “user interface” of C.
That meta/amazon logo combo was great.
Was a bit though to take, that joke
I worked at Amazon and every time I pointed out it looks like a dick at work people couldn't unsee it
Where?
I am a big supporter of languages being able to be optionally compiled and having granular opt-in for this.
As much as I like JavaScript, I think the language has already been pushed far beyond it's intended use case. Rather than try to adapt and evolve JS to fit every single use case, why not adopt a language designed from the ground up for the task, with native support for types, threads, memory management, etc.
Yep don’t use js outside pmuch anything related to websites i would probably say not even hosting it by that.
devs do what devs want. they do things...just because. but when people start using it....what does it say about general population
Static hermes is the thing I’m excited the most in JS land. Probably the biggest game changer in the last decade. If it works even more people will run to js.
Typescript though
@@_nom_ true, already feeling sorry for all libraries that ran from ts back to js, if this works libraries should be the first to make sure their code works well on sh
@@_nom_ JS will have types before static hermes
@@elvispalace im waiting here for 20 years now... still no types
@@kraldada6557 Search for "TC39 types proposal"
what a time to be alive!
Hold onto your papers 📜
I think you are watching a little too much of 2minutepapers
yes more JS script kiddies preaching they don't need to learn any other language
Is there a time to be dead?
And JS world domination continues
For general website development it was anyways the got to but more than that is still out of scope simply by the nature of the language. Would basically need as much helpers as the size of a web browser is to get anything interesting going.
Finally, someone is talking about it. I heard about it a while back when I was researching React Native. May be this is what will push RN ahead.
ikr, i also saw this a few months back if i remeber... and i wondered while it had very less views
@@vaisakhkm783Yeha right flutter has taken all the cross platform hype from RN.
Performance is not the only issue but outdated libraries might me the reason React Native is loosing or getting more interest.
The lengths that people will go to not learn anything but JS, me included
The people that did this stuff probably know how to code in other languages. They just want to enable more speed for the people that don’t get the concept of any language.
Cool vid Theo. JavaScript all the things. The idea of fullstack developer will never be the same. Love the idea of faster JS though, I imagine Web Assembly is similar for the web (although perhaps they're not static/AOT compilation)? How much will the web take from this?
I almost feel that allowing JS developers (like me) the ability to crash natively like C++ developers, might be akin to taking someone driving a Bumper Car and putting them into a Ferrari.
honestly, it probably won't be as bad.
I think it's more like going from Go Kart to Mazda Miata. They feel similar but the Miata can actually Leave the Ground if you drift on a downsloping freeway ramp.
_... And the JavaScript Dev realized that there was no longer any way to avoid typescript, and started using it, and everyone lived happily ever after. The end._
Hmm it’s not really faster for average joe js code. Also the title is clickbait.
JS was sold to C/C++ web devs as a "safer" option, "performance to the fire, in the name of stability"; Now JS devs wanting better performance are straying toward native "C/C++ style" value enforcement, and direct assembly injection. what a circle.
these applications will still be running inside a Java-VM, so any mangled asm will "probably" not take down the entire mainframe (these are the true horror's a JIT VM prevents)
As a native dev checking out the web world, this is pretty exciting stuff. 👌🏼
this "window manager" in one of the tweets seems to be dear imgui, which if a intermediate mode gui library written in C++. It's cool that you can interface with it though
Actually impressive that JavaScript can render ImGui, wonder if it utilizes something like DirectX
Im guessing its just native bindings, since its running on a phone its prob vulkan@@forwardtrack
@@forwardtrack no it's not, you can already run imgui in the browser through emscripten+webgl
@Theo, u forgot to mention one strong point. Local Storage access will be synchronous. No need of state managers or async code. This will be enormous!
i didn't understand this, what you mean "synchronous and no need for state managers", unlimited space in local storage ?¿
@@mikealejandro3938 No..what I mean is that, in order to read or write to storage currently, u need to do this asynchronously in both JavaScript and Node since JavaScript is not fast enough. Try to read something from local storage when u initialize a page without async. It will give u undefined since the interpreter could not retrieve it in time. With the new C compilation, u will be able to read and write to local storage without waiting which will really improve the speed of applications and also change development experience in JS since u no longer have to use things like state management across components. U just read directly from what u stored on storage. Plus local storage is persistent so think about storing large database like objects on client (encrypted of course) making ur apps faster. Check out a package called React Native MMKV which is used to store to local storage but uses native C++ allowing for faster read/writes.
Gonna be wild to see JS developers handle parallelism.
@@J1JordyYou mean they will not and it will break apart simply by the entire ecosystem not having any parallel execution except through abstractions prior. It will be fun to see how the entire language will deal with it especially with a GC build for a different execution.
The good news is: Segfault is now a Frontend thing!
The logo got me 😂😂 0:32
Inline usually means that you replace the actual function call with the function body where it gets invoked at compile time.
Yes. Except GCC is free to ignore it and inline what it fancies instead
This really makes me wish Bun was built on top of Hermes instead of JSC (though that’s still better than V8)
Please dont wish for such things. Static hermes is insanely good, normal Hermes is so slow that it is useless beyond mobile dev.
The only thing Hermes can do right is make an app start fast, the rest is at very slow speed because it does not to JIT, nor does it support the newest JS features.
@@philheathslegalteam is it actually so slow? I’ve only ever encountered it with React Native so I’m not sure how (non)performant it is elsewhere
@@philheathslegalteamQuite curious on this since I’ve been using Hermes for a while now and I can barely tell apart between native apps and RN apps with Hermes
@@PatrikTheDev its beaten by both JSC and V8 in React native too. The only reason we use Hermes in RN is that it provides a faster startup. Dont Get me wrong, I love that it makes my apps boot fast and wouldnt replace it with V8 or JSC at all, but it has forced me to make so many optimisations to help my app do well, optimisations which I otherwise wouldn’t have to do on web or node
Hermes is in fact slower than JSC and V8, but it does also consumes less memory and saves some cpu power from the user's mobile device as it needs your JS bunble to be turned into a bytecode executable for Hermes runtime, bytecode is actually faster than plain bundled and minified JS.
Hermes in constrat to V8 and JSC was built for the mobile space, which has its own needs, so for it's true purpose the performance is in fact good, tbh they can not be compared at least directly.
Bring in Low Level Learning, would be fun to see whats actually happening at the instruction level.
Especially if it can be compared to regular JavaScript code.
Kudos on the stache. It's the star of your show.
I'm curious how Static Hermes handles `Dict`, specifically when I'm trying to access a key that isn't set on the object. (Typescript would treat the value as `T`, whereas in runtime it would be `undefined`.) I imagine it would be an error like the array example.
There are a lot of string methods that consider index/position (eg: at, slice, includes, startsWith, endsWith, etc) that might also have different runtime behavior (when someone provides an invalid index). In general, I think people underestimate how significant of an impact the incompatibilities between loose/strict associated languages will have.
That being said, I think the association between TS and Static Hermes code will be a lot closer than the others I've seen:
- TS -> AssemblyScript
- Python -> Cython
- Ruby -> Crystal
What about AssemblyScript?
It is basically just compiler for typescript with static types.
is no one gonna talk about theo pronouncing hermes as "her mess"
no
he's just boujee like that
I think that's quite a common pronunciation. It varies between _Her-mez,_ _Her-miz,_ and _Her-meez_ across the world. Idunno know how the Ancient Greeks would've pronounced it.
@@andybrice2711there are correct ways to pronounce words, this video demonstrates it. Theo isn’t the one saying it right ;)
Err-Mez my man!
final a video of Static Hermes, let's go
I wonder how this compares to AsemblyScript to WASM, and then wasm2c.
From what I can gather this is only for converting JS to native, but using AsemblyScript & wasm2c you could share code between browser & native.
AsemblyScript is even more strict with types i32, u64 etc, so in theory should have more optimisation options than just number.
not sure how performance of assemblyscript is now, but when i tried it year ago it was worse than rust compiled into wasm, and rust compiled into wasm is usually slower than native rust (at least it was when i tested it in v8 js engine)
@@xshady2967 Yeah, I would expect Rust to WASM to be quicker, it's borrow checker memory manager alone I would expect to smash a GC based one. But Static Hermes would have the same issues here, even on Native as it will still need to use a GC of some sort. And of course WASM in V8, would likely also be slower than using wasm2c to make a native binary, the V8 wasm will be highly sand-boxed for security reasons.
Could it happen for the browser as well in the future?
That would be crazy
I'm curious how it compare with AssemblyScript. I know it target WASM but hey, you can compile module.wasm into C code.
looks amazing
Actually as a rn user, hermes is quite slow on some uses cases. JSON parsing functions is 5x slower and general date functions.
It's a work in progress. Make bug reports and feature requests.
I love his accent more than the actual topic he discussed.
I want to find new channels about react native development, y'all got any reccommendations?
What if we just didnt use js for backends tho? Or is this some wasm magic that runs in the browser?
All I want...is to be able to be able to make my JS library a DLL.
You got that right fella
And that would use what calling convention? And deal how with memory boundaries?
Why? And how would you deal with memory management?
Perfect placement of META and AMAZON logo
This is good
Music to my ears
It just feels strange how much energy and effort people are willing to invest, instead of just using a truly native language. I mean if I can crash the system with JS like i can with c++, i need to be at the same level as the c++ developer. At that point I could just learn the syntax of c++ and be done with it. But! What really excites me is what this can mean for the web in general. When JS gets so performant, that you can realistically program demanding games on it.
But pointers they will say. Also most of these people have not to much clue about the system underneath and that someone has to optimize for usage patterns of there terrible abstractions.
@@platin2148JS devs being afraid of pointers tells me that they should NOT be doing anything besides making pretty animations when you click on a button.
This is so awesome, but also so cursed. Insane how JS could be a viable option for stuff like this a couple years down the line
Roblox's Luau recently got native code generation for Lua, and it can work seamlessly with non-compiled Lua as well. There's no reason such a thing couldn't also work for JS. This seems like they're doing the same thing Roblox did.
V8, SpiderMonkey and JavaScriptCore already does "native code generation" through JIT compilation. What is discussed here is purely AOT compilation without JIT being a factor. This is non-trivial with any dynamic languages.
What projects like Cython and PyPy does to achieve "natively compiled Python" is taking a _subset_ of of the language that is non-dynamic (or not highly dynamic) and compile that into native code, while interpreting the rest. This is also what Luau does from what I've seen.
So yeah, there are good reasons why it couldn't also work for JS. Hermes' approach is likely the same as the above, since the dynamic nature of the language, without any type information, does not make it trivial to know types without running the code in the first place or more times in case of non-pure code that includes side effects.
As an excerise. Try to come up with a compiler which, without any type information, that can take a piece of JS code which returns a value randomly between a number, string and object, and statically compile it into native code ahead of time.
is it like bun or replacing bun now
🔥🔥
what the point of writing cpp in javascript just to transpile it to llvm bytecode that will translate it to ml?
That sounds like what Chris Lattner is doing with Mojo, to make Python code faster (different approach, but the static typing to make it faster is similar)
you look like... like three different actors at once and that is cool
full screen on the yt video would be cool
I wish the Audible App would use Flashlist for the Library View 😢
I'm very excited for this project but it does still leave some questions to me in terms of React Native:
- Is it only a C/C++ thing? How about "native" Java or Objective-C code?
- Will it be interoperable with Turbo Modules and JSI existing libraries?
- How about the legacy bridge? Will it keep support for it?
- How about Node existing libraries? Will React native be able to use such libraries in rn-windows or rn-macos because of this?
Well. This isn't solid right now. You can probably still influence the shape of things to come. You can ask Hermes these questions! They want feedback. Go help them ❤
Inlining functions i'm pretty sure takes the code that's in the function and just pastes it into whatever function you called it from so no additional stack allocation overhead is needed.
In assembly the instructions are directly called, therefore there is no function pointer and no stack prologue/end setup. This makes the code faster, however the generated binary gets larger, most compilers reserve the right to ignore inlines for that reason, they may also inline functions that aren’t declared as “inline”
I mean this is really cool...
What about code push?
crazy effort and love the where industry goes. humanity needs performance for several reason. but we also need programs that easy to build.
search of middle ground just makes everything better.
i believe js developer will be more type strict and better coders and js will become more user friendly C in time.
which is great.
i was keeping me away from js because of how bulky it is. i'm backend dev i want dont like extra layers between my code and cpu.
but this solution made me happy.
i'll definetly push my frontend devs to embrace typescript to get ready for hermes
Wow the speed of C with the dangers of JavaScript. JSers always fall for this kind of lingo. Save yourself the heartache and just pick up rust.
Static what? Her mess? 😄
Reminds me of what GraalVM was trying to do with Java. It seemed pretty cool, I'm not sure how feature complete it is.
I know this might be a little too out there but my god is it soothing to hear an indian accent teaching you anything code related; its an acquired taste like beer
Is it becoming Java without the script?
HAshahhah the meta/amazon conglomerate logo 💀💀
Wasn’t this video released months ago?
Duuude!
yoooooooooooooooo (i started watching)
It's really amazing how little Theo knows about C#
So basically, they made JavaScript a non-scripted language by adding types and it became faster, because dynamic typing which is the definition of a script, sucks in performance. So, basically, it's not a script anymore, per definition. And people could have just written code in a real language from the start. But here we are, full circle.
"raw speed"
Wasm for the dom
I love when they say: Fast as C. And we all pretend that the Garbage collector does not exists.
yea, it's clickbait
Precisely.
We all pretent it's fast JS, but it's actually fast TS
so i guess it would be more like as fast as go, because go is native binaries with a gc runtime
@@somenameidk5278 That's exactly what I thought when I wrote the comment. 😅
That's probably awesome but I'm not super excited seeing games because it's more the result of graphic chipset programming rather than actual code, you can write a super fast game in Python and a super slow game in C++, depending on how you handle the scene update flow
I highly doubt that you will be able to make anything a slow as python just by dabbling around. You probably will make it not the fastest but not as slow as any jit or gc’ed language.
Didn't know Slavoj Žižek could also talk about code.
Javascript devs will do anything but learn a new programming language.
I love learning new languages, grew up with C, C++, Pascal, C# etc etc, looked recently at GO / Rust / Zig etc. But the reason I like JS, or more specifically TS, is that I'm a lazy coder and as such love the DRY principle, and been able to use code I've written for the Browser, can be the same code I use to make a Native APP, the same code I can use inside a back end webserver etc.
JS devs carry the industry inovation
@@Weagle1337😂, yes, in their dreams.
just use what you want to use, and let JS devs use what they want to use
Someone will end up saying js can do math
Not gon lie when I saw the title I assumed the C was the speed of light constant 😂💀
This is going in a very different direction than I was hoping for a few years back...I was hoping to see CPUs get native/accelerated support for executing WASM bytecode, and also to see the garbage collector/runtime get refactored/divorced from JS so that JS can be compiled to WASM.
The GC is the worst part about JS and creates unpredictable behavior.
FMLA? Floating-point fused Multiply-Add to accumulator, thats soooo obvious!
xdd
I always had a completely different experience with JS. I never felt like "this is so slow", I rather always felt "you can actually do THAT with JS?".
The reason for that is that I always worked in several different language environments. When I used C, I did it because that was the language you used for coding, not because it was especially fast. Then I did some stuff in TCL, Perl or Ruby. That was not especially slow, because if performance was relevant, I would have used C or C++ to run it. Then came Java and C#. There I had more "this is too slow" moments, because I didn't expect it to be slow. There is JIT after all. It's not really interpreted like TCL, Lists are arrays, not strings.
I was surprised to see that graalvm is not much faster than regular Java (measured by just using it). I'm not surprised that you can transpile JS into machine code. Even without type annotations. In the absense of eval, it should be possible to infer most types. Who uses eval in real code? I sure don't.
YES!
All hail JavaScript
I'm happy for faster js, but my brain hurts from looking at that bit shift shenanigans function
0:31 that's a big one
My first langauge was C/C++ when I was 6. I am used to low level optizations.
Building desktop apps with JS, and using a library like Sharp for image manipulation!
static hermes is very impressive!
What is the browser Theo is using??
I think edge. or safari.
@@ark_knight I found out, it is arc
Arc Browser
Cool project. Who remembers asm.js however? It sounds a lot similar.
Asm.js was the opposite, it was "put your assembly in JS". This is putting your JS in assembly ;)
@@t3dotgg But asm.js was supposed to be run with this ahead-of-time compiler, which was compiling to a low level binary.
ChatGPT convert this JS to C. "As a large language model..." 😢
wow !!!!
Wait, I just finished rewriting all my JS tools in Rust...
Probably still consistently faster than this stuff also doesn’t come with runtime blob.
provide source for 0:07 because that seems very unlikely, probably a benchmark from 10 years ago.
Kind of crazy to think, Amazon helped RN devs in integrating Microsoft's Typescript onto Meta's Software.
Maybe not so much crazy, cuz Typescript itself is crazy good.
If you are going to learn all of the new functions/libraries to write code that can utilize thesee improvements, why not just jump on board a new language to handle optimization? Perhaps some like Rust WebAssembly? As you noted, the code for JS and C were very similar. Understanding how to code is the skill, the expression of that skill in any given language is almost trivial.
At this point just write code in an already existing language, because you will need to refactor so much of your existing code base.
Imagine:
- No more arbitrary field assignments, you will actually need to use the Map class.
- No more algebraic typing like in TS without actually including some differentiating field.
- No more extending native/library classes through prototypes (I could think of ways to implement but that would REALLY slow down compilation or you would need to obey some weird compilation rules on project structure).
- Probably a very strong reduction of implicit type conversion.
- You have to type all function input params. (maybe not on locally defined lambdas if they do it right)
Or we could just start writing code in a better language?
i love being early to a theo video, favorite youtuber ever
¿Is not this a way of doing TS, indeed?
I have to ask, why do you keep saying Hermes weirdly 👀
I like that they said “her-mees” like how Hermes is actually pronounced but he still insisted on saying “her-mess” for some reason
In greek it is actually an entirely different vowel sound than either of the ones you are using. And most languages don't pronounce words like the source language. This word in particular has a huge variation in pronunciation among world languages. This is a normal thing. It is called nativization. There is no objectively correct way to pronounce a word that is foreign to your language.
It’s a name, not a word.
@@zekinler Yeah, a Greek name. People need to stop telling people from other countries how words and names from other countries are "actually pronounced". Because: no. You're probably wrong about how it is "actually pronounced" (as you are about this one, which you deflected with meaningless language lawyering that was entirely irrelevant)
@@timseguine2 im of the opinion that you should pronounce the name of someone or something how they/the creator of that thing want it to be pronounced (not-including “gif” as that has pretty much been canonized as a noun, and not a thing with a name.)
@@timseguine2 i didnt intend to seem pedantic, i just chose to say less than “it’s a name, (something where it’s pronunciation very often doesn’t care about where it descends from, and is up to the named/namer), not a word (something which does actually care about its etymology).
0:30 😂
Hermes uses more AOT compilation then JIT compilation, JIT compilation is more of the run time stuff.
AOT is ahead of time compilation and it compiles the JavaScript into bytecode ahead of time, JIT is interpreting/transpiling JavaScript into bytecode at run time, rather then ahead of run time in a build step.
@@brys6577 you good mate
We already have c# which is almost simular in syntax as typescript
I honestly don’t understand why we don’t make something about that. C# as a language is so good but people neglect to use it because of .NET, but tbh C# isn’t just .NET e.g. you have MonoDevelop as well so we can make C# the new “JS” if we actually wanted to
@@IFone456 +1. C# is amazing. I did grow out of the object orientated paradigm after constantly doing web dev, but the language is great.
@@IFone456Static Hermes was created for React Native
Have you tried to go deep dive deeper into the internal code and on how it really works? this could be done if the JS is actually written in Web Assembly.. So from JS > Web Assembly and then into byte code... This could be possible..
It's amusing to watch JS soy devs rediscover all of the reasons that went into the design of strongly typed compiled languages and attempt to bolt them on to their spaghetti barrel/dumpster fire of a language/ecosystem.
I'm going with webassembly