@@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
@@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.
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.
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.
@@_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
@@vaisakh_kmYeha 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.
@@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.
@@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.
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.
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.
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.
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._
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)
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.
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
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.
@@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.
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
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.
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?
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.
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.
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
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.
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.
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.
@@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).
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.
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.
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.
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)
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 ❤
Hmm i mean just alone the web browser for most of the websites is several gigabytes. But yeah i’d say we have to have at least 15mb size of a binary because apple decided so in there macho check, for memory 45mb ram is crazy huge..
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.
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)
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.
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.
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.
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”
What if... we just programmed in C? Python is doing the same thing and I just can't wait until people figure out that it's just not worth using an interpreted language.
You should. These kinds of projects are for mega corps that realized they made a poor technical decision but have so much source code it's more time efficient to rewrite the compiler than it is to rewrite their actual code. If you happened to have made the same mistake as those megacrops you can profit from their efforts, but starting a new project on top of tech like this is moronic.
I think they're pronouncing it like we do the Greek god it was named after in American English: "Her-meez" rather than like the actual Greek pronunciation.
Would be cool albeit unlikely to see native WASM in a browser without glue code. Then we can finally drop this dumpster fire and let the best solutions win. The only reason JS has been resuscitated this long and every ounce of life squeezed out of it is purely inertia. If you told everyone "Hey code in whatever language you want, as long as it can target WASM" then we'd finally see some low-level performant frameworks EASILY composed using higher level languages. Not just high-level languages optimized to hell so people can have terrible-but-better performance. People are out here ragging on BTC but JS devs are the real ecological disaster.
Hey idk if anyone will read this but these videos keep triggering my tinnitus. I think the sibilance on your mic is causing loud high frequency transients. Try using a pop filter or you can add a low-pass filter in post.
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.
I think trying to mangle a dynamic runtime driven language into a static result is never going to work well. It's like trying to build a boat from a car. Even if it works it's not comfortable and not a great experience compared to just building a boat. We should just iterate with new languages and try to make static code easier to write. My personal opinion is that dynamic languages should just die, static languages are superior in speed, usability and maintenability. Dynamic languages have little benefit in quicker development when starting a project but as soon as the project gets bigger the languages fall apart.
And yet, JS and Python are by far the most used and understood languages. Not by coincidence. Static langs are nowhere near as flexible. Just imagine the analog of require('somefile.json').some?.val in some other languages like Java--don't forget the error handling. You can literally write 2x the code with half the functionality. Most of the gripes with dynamic langs are people that are inexperienced or don't know how to modularize code (which btw, node handles very well). It's also a great reminder that static types are not a replacement for unit testing. The _only_ way you can make sure code works the way it's intended is to thoroughly test it at runtime, and if done exhaustively, that also happens to catch possible type issues.
@@extremeheat7947 I disagree. JS ist mostly successful because of historic reasons and the dynamic nature of the web. And even this monopoly is being shaking by static solutions based on wasm. Python itself is a horrible language and is mostly successful through the libraries people wrote in static languages like c/c++. If python libraries where written in python no one would use the language. But this is unrealistic since python is designed to be horrible for complex code preventing library development in it. The dynamic import of code is a clear security and reliability problem. If you know the code your program uses it will work safely. If you rely on foreign code refrenced by something like a filename you open security problems and risk crashes if set resource is just not there. About inexperienced developers I think it's exactly the opposite. Especially beginners like dynamic languages since you by definition don't have to care or know about typing. And especially experienced developers often favor typed languages (see for example the development of ts for js) for their stability, reliability and efficiency. I agree that without tests you can't be sure code works (like if(i < x)... ) can most often not be ensured with compile time checks or types. But things like enums, generic builder types and structural patterns based on strong type systems can prevent incorrect code in a compile time error making a test for such cases literally unreachable. Another point is the location of the test vs the guards a type system provides. Tests (partly for correct library use) are most often written at application level. While type based guards are written once by the library developer (that definitely understands the library better than any user) this gives grater safety and less burden on the library user.
Meanwhile there isn’t any restrictions on making a union with every base type and then a array of it to store arbitrary things would be still faster than anything in js probably.
@@extremeheat7947I suspect more people are simply not capable in there mind. Like people avoiding pointers though they are a fundamental concept of the chip they are working on. E.g these languages are for people that can’t handle less abstraction.
Even with performance, Javascript is such a mess nowadays. We need a new compiled, static typed language for the browser, with all the features that we need today. It doesn't matter how many third party tools we make, Javascript and React will always be bad.
@@akam9919 WebAssembly has many limitations. To use it, we require a javascript interface. So Javascript is the main runtime. Every time we call a Webassembly function, javascript calls the function, which will serialize the parameters, then deserialize them in the Webassembly memory. When the webassembly function returns some data, it has to be serialized again, then deserialized to a javascript type, which is stored in javascript memory. This required interface between WebAssembly and Javascript is a nightmare. We should ditch the entire Javascript runtime, and create an interface directly between the browser and the Webassembly runtime. I can write a Webassembly function that fetches something in the network in Rust. But, behind the lines, it is generating Javascript code to do the networking. Think of all the overhead every time it has to send a message and parse between the two runtimes. Big corporations have big money towards preventing javascript from being removed from the browser. So it won't happen any time soon, sadly.
Please define bad. It’s not like other languages don’t have their flaws and annoyances. JS is a very useful tool for a lot of problems. And it’s not for a lot of other problems.
Rescript, F#, Vlang, KotlinJs, there are plenty of interesting languages out that compile to js. Anything static on runtime can be done with any lang that compiled to webassembly. It just happens to be the case, that a shitty, interpreted prototype based language is a great choice for the web with its specific requirements.
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.
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
I am a big supporter of languages being able to be optionally compiled and having granular opt-in for this.
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?
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?
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
@@vaisakh_kmYeha 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.
@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.
As a native dev checking out the web world, this is pretty exciting stuff. 👌🏼
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.
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.
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)
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.
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
The good news is: Segfault is now a Frontend thing!
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.
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
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.
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
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?
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.
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
@@nitsanbh gcc 5 for life.
Perfect placement of META and AMAZON logo
I love his accent more than the actual topic he discussed.
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?
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!
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
The logo got me 😂😂 0:32
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.
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.
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.
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.
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).
It's really amazing how little Theo knows about C#
Why wouldn't this exist in the first place, coders are silly.
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.
What about AssemblyScript?
It is basically just compiler for typescript with static types.
Kudos on the stache. It's the star of your show.
final a video of Static Hermes, let's go
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.
you look like... like three different actors at once and that is cool
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. 😅
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.
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)
Didn't know Slavoj Žižek could also talk about code.
0:31 that's a big one
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 ❤
A timer app that weights 45mb and consumes 100mb of your RAM is a crime against humanity.
Hmm i mean just alone the web browser for most of the websites is several gigabytes. But yeah i’d say we have to have at least 15mb size of a binary because apple decided so in there macho check, for memory 45mb ram is crazy huge..
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.
FMLA? Floating-point fused Multiply-Add to accumulator, thats soooo obvious!
xdd
Not gon lie when I saw the title I assumed the C was the speed of light constant 😂💀
I'm happy for faster js, but my brain hurts from looking at that bit shift shenanigans function
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)
full screen on the yt video would be cool
Music to my ears
Reminds me of what GraalVM was trying to do with Java. It seemed pretty cool, I'm not sure how feature complete it is.
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.
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
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.
Someone will end up saying js can do math
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.
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
0:30 😂
When people put the same effort into their runtime/compiler as they put into complaining about performance...
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”
"This is what makes hermes so different [by doing the exact thing every other performant language does]" hmmmmm
so different in JS ecosystem
ChatGPT convert this JS to C. "As a large language model..." 😢
My first langauge was C/C++ when I was 6. I am used to low level optizations.
What about code push?
HAshahhah the meta/amazon conglomerate logo 💀💀
What if... we just programmed in C? Python is doing the same thing and I just can't wait until people figure out that it's just not worth using an interpreted language.
You should. These kinds of projects are for mega corps that realized they made a poor technical decision but have so much source code it's more time efficient to rewrite the compiler than it is to rewrite their actual code. If you happened to have made the same mistake as those megacrops you can profit from their efforts, but starting a new project on top of tech like this is moronic.
Blasphemy !
Building desktop apps with JS, and using a library like Sharp for image manipulation!
static hermes is very impressive!
I think they're pronouncing it like we do the Greek god it was named after in American English: "Her-meez" rather than like the actual Greek pronunciation.
They are generating C code from JavaScript the worst of all languages? Sound like a horror movie to me.
The generated code will be the same in awe fullness.
Would be cool albeit unlikely to see native WASM in a browser without glue code.
Then we can finally drop this dumpster fire and let the best solutions win. The only reason JS has been resuscitated this long and every ounce of life squeezed out of it is purely inertia. If you told everyone "Hey code in whatever language you want, as long as it can target WASM" then we'd finally see some low-level performant frameworks EASILY composed using higher level languages. Not just high-level languages optimized to hell so people can have terrible-but-better performance.
People are out here ragging on BTC but JS devs are the real ecological disaster.
Wasm for the dom
Static what? Her mess? 😄
I'm curious how it compare with AssemblyScript. I know it target WASM but hey, you can compile module.wasm into C code.
Hey idk if anyone will read this but these videos keep triggering my tinnitus. I think the sibilance on your mic is causing loud high frequency transients. Try using a pop filter or you can add a low-pass filter in post.
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.
"raw speed"
I mean this is really cool...
Could it happen for the browser as well in the future?
That would be crazy
20:09 - it stands for: "fuck my life AAAAAAAAA (in two dimensions)", I'm pretty sure...
fuck my life on two axes, this is my last retort.
I wish the Audible App would use Flashlist for the Library View 😢
I want to find new channels about react native development, y'all got any reccommendations?
I think trying to mangle a dynamic runtime driven language into a static result is never going to work well. It's like trying to build a boat from a car. Even if it works it's not comfortable and not a great experience compared to just building a boat.
We should just iterate with new languages and try to make static code easier to write.
My personal opinion is that dynamic languages should just die, static languages are superior in speed, usability and maintenability. Dynamic languages have little benefit in quicker development when starting a project but as soon as the project gets bigger the languages fall apart.
And yet, JS and Python are by far the most used and understood languages. Not by coincidence. Static langs are nowhere near as flexible. Just imagine the analog of require('somefile.json').some?.val in some other languages like Java--don't forget the error handling. You can literally write 2x the code with half the functionality. Most of the gripes with dynamic langs are people that are inexperienced or don't know how to modularize code (which btw, node handles very well). It's also a great reminder that static types are not a replacement for unit testing. The _only_ way you can make sure code works the way it's intended is to thoroughly test it at runtime, and if done exhaustively, that also happens to catch possible type issues.
@@extremeheat7947 I disagree. JS ist mostly successful because of historic reasons and the dynamic nature of the web. And even this monopoly is being shaking by static solutions based on wasm. Python itself is a horrible language and is mostly successful through the libraries people wrote in static languages like c/c++. If python libraries where written in python no one would use the language. But this is unrealistic since python is designed to be horrible for complex code preventing library development in it.
The dynamic import of code is a clear security and reliability problem. If you know the code your program uses it will work safely. If you rely on foreign code refrenced by something like a filename you open security problems and risk crashes if set resource is just not there.
About inexperienced developers I think it's exactly the opposite. Especially beginners like dynamic languages since you by definition don't have to care or know about typing. And especially experienced developers often favor typed languages (see for example the development of ts for js) for their stability, reliability and efficiency.
I agree that without tests you can't be sure code works (like if(i < x)... ) can most often not be ensured with compile time checks or types. But things like enums, generic builder types and structural patterns based on strong type systems can prevent incorrect code in a compile time error making a test for such cases literally unreachable. Another point is the location of the test vs the guards a type system provides. Tests (partly for correct library use) are most often written at application level. While type based guards are written once by the library developer (that definitely understands the library better than any user) this gives grater safety and less burden on the library user.
Meanwhile there isn’t any restrictions on making a union with every base type and then a array of it to store arbitrary things would be still faster than anything in js probably.
@@extremeheat7947I suspect more people are simply not capable in there mind. Like people avoiding pointers though they are a fundamental concept of the chip they are working on. E.g these languages are for people that can’t handle less abstraction.
What if we just didnt use js for backends tho? Or is this some wasm magic that runs in the browser?
The idea of giving JS devs access to raw pointers should terrify you.
PyTorch/Torch ported into Static Hermes? God, I hope this is possible.
Or we could just start writing code in a better language?
That's Dear ImGui... a GUI library in C... not JavaScript.
is it like bun or replacing bun now
"Is it possible to transpile js to static language?" Js wouldn't be able to run if it was not possible. (sorry for capital j in js)
Even with performance, Javascript is such a mess nowadays. We need a new compiled, static typed language for the browser, with all the features that we need today. It doesn't matter how many third party tools we make, Javascript and React will always be bad.
Like web assembly?
@@quintencabo which is often just as if not slower than JS? (also, not exactly a language, more of a build target)
@@akam9919 WebAssembly has many limitations. To use it, we require a javascript interface. So Javascript is the main runtime.
Every time we call a Webassembly function, javascript calls the function, which will serialize the parameters, then deserialize them in the Webassembly memory. When the webassembly function returns some data, it has to be serialized again, then deserialized to a javascript type, which is stored in javascript memory.
This required interface between WebAssembly and Javascript is a nightmare. We should ditch the entire Javascript runtime, and create an interface directly between the browser and the Webassembly runtime.
I can write a Webassembly function that fetches something in the network in Rust. But, behind the lines, it is generating Javascript code to do the networking. Think of all the overhead every time it has to send a message and parse between the two runtimes.
Big corporations have big money towards preventing javascript from being removed from the browser. So it won't happen any time soon, sadly.
Please define bad. It’s not like other languages don’t have their flaws and annoyances. JS is a very useful tool for a lot of problems. And it’s not for a lot of other problems.
Rescript, F#, Vlang, KotlinJs, there are plenty of interesting languages out that compile to js. Anything static on runtime can be done with any lang that compiled to webassembly.
It just happens to be the case, that a shitty, interpreted prototype based language is a great choice for the web with its specific requirements.
looks amazing
what the point of writing cpp in javascript just to transpile it to llvm bytecode that will translate it to ml?
Porrfor is similar
Porrfor mention