At the same time, when I see projects like his, V8, HHVM, etc. I can't help but wonder where we could be if all of that engineering effort had gone into more carefully-designed languages.
The problem is much bigger than the design of a language, the problem is producing something (not a language) people will use and growing software systems that meet varying demands as those products evolve in a way that is affordable. Of course there are all sorts of tradeoffs to make these things happen, most of which have nothing to do with idealized whiteboarding and language design. That stuff often irrelevant when you take into consideration all the various kinds of other situation-specific details people face to make things lots of people use.
That goes the same for products and for languages. And of course the two classes of processes co-evolve. Further, language design does not imply better products. It is tangential to all the other things that make a product happen. You have to hire good people, you have to identify meaningful problems and provide better solutions. You have to get it in front of people and you have to adapt over time to your core audience's needs. Use lua use php use C# whatever you do all your choices including that one need to be self supporting of each other. The developers have experience in x, y is what runs on the platform, devs more often know a than b and so are cheaper to find. Language design matters not in those scenarios.
Not defending any language design or any technical choices over others here at all, just saying if you want to see a change in the state of things sentiments like this are more like eating popcorn while you watch the world go by. Kind of like when you have an open source project and get requests for fixes but no pull requests. The most viable open source is build by a community of collaborators and is easy for new collaborators to join in and contribute to. If you don't have a community of users that care about your project it does not matter what technical decisions you make, what language you use and what design it follows.
So what matters more than language design is problem solving and community and getting more pull requests than the other guy, more conversions than the other app and shoulda, coulda, wouldas are popcorn on the theater floor.
Not every comment on the Internet needs to be actionable, but sure.
> Further, language design does not imply better products.
That's fair, but we aren't talking about products here. We're talking about an announcement of a language implementation. Jazz records won't cure cancer, but that doesn't mean we can't talk about jazz.
Not defending any language design or any technical choices over others here at all, just saying if you want to see a change in the state of things sentiments like this are more like eating popcorn while you watch the world go by.
My day job is working on a language, for what it's worth, so I can both eat popcorn and work to change the state of things.
I'd love to see more work go towards making cross platform UI easier to do in native languages. I feel like you could get a lot more mileage out of that, especially if you add WASM as a compilation target, then you can get the same ubiquity that JS has.
What are these native languages you speak of?
Really any of them. Swift UI is the only example I can think of where a group of folks are working on making UI easy and intuitive to create and manage inside of a native language.
Why is there not an effort to make something as intuitive in C++ or GO or Rust? C++ would probably be the hardest one, sure, and there are many UI frameworks for all of these languages but none of them are as simple or intuitive as Swift UI or how React / Vue works inside of JS.
I'd love to see some more experimentation in ways of building UI in native languages. Heck, even in managed languages like C# or Java they could use the same type of treatment.
I'm sure Facebook could have written React Native in C, C++, Go, Java or Rust, but take a guess at what the adoption rate and the hype around it would have been...
If Netscape/MS browser in the 90s had shipped with an embedded, sandboxed JVM with native browser APIs, then maybe the world would be very different today, but we work with what we have don't we all?
But JS and PHP aren't that. They both have a lot of good ideas in them but they are also both hampered by lots of initial mistakes in their design. JS because it was designed so quickly, PHP because it was cobbled together ad-hoc by someone who wasn't focused on the design of the language.
Semicolon insertion in JS doesn't represent a smart trade-off from the past, it was just a bad design whose author didn't have time to fix it before it hit the marketplace . Likewise, PHP's wildly inconsistent core library names aren't a sign of some thoughtful hidden order. They're because Rasmus lazily used strlen() as the hash function for strings and wanted them to go into different buckets .
> Skip is an experimental programming language developed at Facebook from 2015-2018.
> The Skip project concluded in 2018 and Skip is no longer under active development at Facebook.
(For the unawares, RN necessarily uses the system JSC on iOS per Apple requirements, but for Android RN bundles JSC into the APK.)
I don't understand how Hermes will differ from JSC/V8 in terms of functionality and performance. What functionality can be left out of Hermes as compared to JSC/V8 in order to shrink its sie?
What sorts of performance improvements will Hermes have that wouldn't similarly benefit JSC/V8, and why wouldn't Apple/Google include those in their own engines?
The key is that Hermes is optimized for a totally different environment and workload - RN apps from disk on slow Android devices vs. websites downloaded on desktop computers.
The fact that Hermes is architected for RN from the beginning is key. Bytecode is as compact as possible, and is mmap’d. mmap’d bytecode is a very deep change with huge benefits, but also limits some optimizations other engines rely on, such as inline caching.
Also note Hermes does not have a JIT to save memory and APK size. A lot of the heroic perf work in V8/JSC is in the JIT which is not useful in most RN scenarios/environments.
Link to the talk, from FB employee announcement made at React Conference today, 15 minutes length. Linked 2 mins in, because the audio is poor to start.
It sounds like Hermes is exclusively for running React Native on mobile. They could start building React directly into Hermes— the reconciling algorithm for example, or maybe even some real parallelism.
Very curious to see how all this keeps evolving.
At the moment Hermes isn't compatible with ES6 (it's missing a lot of stuff). Perhaps, since part of the build step for RN anyway is transpiling, they don't need to provide all of ECMA's features. ES5 is more simple, less complex so I wonder if some performance can be had there.
But since they are building an engine strictly for making native apps using JS, there may be shortcuts or other stuff they can drop that JSC/V8 normally have to worry about but that's just speculation.
I'd love to see more info addressing your questions!
RN apps are rarely CPU bound though, so they don't necessarily benefit as much from those same optimizations.
It's really easy to build a React Native app, but not easy to build a really good one.
Hermes can make many more assumptions and so the engineers, even if they built something very similar to V8, can probably dial the knobs much more differently to optimize for what Hermes cares about.
Will Hermes be able to solve this debugging issue?
A Quick zero-to-20mph Guide
How it works
1. Results in less to load into memory WHY? It has no Just-in-time (JIT) compilation, instead compiles to bytecode ahead-of-time (AOC). By comparison most (all?) modern browsers have a tricky blend of both.
2. Has no effect on application CPU performance
3. Chrome debugger will connect DIRECTLY to the Hermes engine within the app (simulator or device). By comparison, Chrome debugger uses its own V8 engine to execute code, instead of the JsCoreEngine (?) that React-native uses by default
1. Time from load until first user interaction: 4.3s -> 2.3s
2. APK size: 41mb -> 22mb
3. Memory: 185Mb -> 136mb
Tl;dr AoT can be more resource intensive as a one time cost while JIT uses and limits runtime resources
Are Android versions of RN apps faster because Android's native V8 allows JIT, and Hermes also employs JIT?
Currently we use V8 with bytecode caching on Android, since it provided better startup performance than the JSC engine that normally ships within RN. So the baseline is likely already faster than stock RN.
V8 runtime Memory Impact: 30MB
Hermes runtime memory impact: 21.5MB
V8 time to interaction: 1.4s
Hermes time to interaction: 1.1s
We have done similar experiments on a full react-native-windows application, replacing the Chakra JS engine (also already with bytecode so faster than stock RN) with Hermes and had app boot time on a low end device go from 3.8s to 3.1s.
1. runtime memory reduction: ~25%
2. Boot time reduction: 20%
3. Time to interaction reduction: 20%
For apps with significant boot times, and runtime memory consumption, this is valuable.
This assumes that the reductions are purely proportional to the total and not (at least partially) fixed.
Here is a video comparing start times for a Hermes/non Hermes RN app:
I’m currently at Chain React in Portland and they just gave a talk on Hermes. I tweeted a few screenshots that show other perf numbers/technical details for those who are interested.
And what are these "optimizations for running React Native on Android". Just reducing startup/boot time or what?