6 ms·

From the docs: "Hermes is an open-source JavaScript engine optimized for running React Native apps on Android." Looks like it's available for iOS now too :) A

From the docs: "Hermes is an open-source JavaScript engine optimized for running React Native apps on Android." Looks like it's available for iOS now too :) Announcing React Native 0.64 with Hermes on iOS https://reactnative.dev/blog/2021/03/12/version-0.64 https://reactnative.dev/blog/2021/03/12/version-0.64

dgellow 5y ago
And with "React Native for Windows" and "React Native for macOS" (both are still experimental): https://microsoft.github.io/react-native-windows/docs/hermes https://microsoft.github.io/react-native-windows/docs/hermes
- mirekrusin 5y ago
  Microsoft just gain a ton of respect by putting it out, upfront description etc, I’m impressed by collaboration and plain statements.
  - pjmlp 5y ago
    And on Windows it uses WinUI/UWP actually. The recent XBox dashboard has been remade with it.
    - dgellow 5y ago
      On Windows native components can be in C++/WinRT or C#, which is quite nice. Typescript for the glue, managed C++ for the heavy lifting. That's a great compromise IMHO, at least in theory. I'm still a bit skeptical because I haven't seen yet WinUI or UWP applications with a passable user experience.
      - pjmlp 5y ago
        Agreed, you can see how I have been an heavy advocate of it, and see it not only as a much better COM, but also what .NET v1.0 should have been (it was the original idea anyway, Ext-VOS). However nowadays I have become quite sceptical on what it will ever be, and looking forward to what news BUILD 2021 might bring. C++/WinRT tooling still doesn't match C++/CX, doing UI in .NET or ReactNative (QML style) seems to be the workaround for it, endless list of Github issues on WinUI, Reunion and all WinRT bindings, community talks with lots of previews, and state of current tooling. Then the various UI teams seem to be competing to which of them will get more developer mindshare. So it is a mess, that I hope BUILD will get a more clear picture.
        Cullinet 5y ago
        totally understand that kind of pain : actively thinking about writing driver primitives to shim into the ui library layers to get the eventual sensibility we need. I've spent a inordinate amount of time on figuring out how to hire a truly dedicated windows native interface team and the only solid conclusion that I've come to is it's necessary to also recruit to write tooling for the designers to work with. we have a application that happily doesn't need a gui but to be used widely needs a excellent gui. it looks like we'll need at least as many people on interface as for our core application. the tooling, oh the tooling..
      - Cullinet 5y ago
        Woz dug the windows phone in the earlier lumia stages prior to the wp8 NT kernel with everything else gutting. this is the one book I most want for Christmas - the true account of what happened to the windows phone interface. I was constantly in awe to behold the developments as they happened ; literally "too good to be true" electrocuted me in my chair every time I read the latest.
  - kabes 5y ago
    Yeah. Never thought I'd read how to use a facebook javascript engine for macOS on a microsoft site.
    - jbverschoor 5y ago
      Why not? Microsoft and Facebook have been lovers since the beginning.. Even in terms of UI design of the earliest of facebook.
      - WorldMaker 5y ago
        Also, Microsoft has a long history of being one of the largest software developers for macOS. Even when deep in the worst Windows versus Mac OS competitive years, Microsoft still shipped a lot of software to Mac OS. (Most of it Office products.)
madeofpalk 5y ago
Interesting - I would have thought custom JS engines/runtimes would be a no go for both iOS and the iOS App Store.
- lucideer 5y ago
  Definitely fine for Android (there's plenty of them), but I would've thought the same for iOS. Now that I think of it though, I think the Apple ToS that prohibit browsers are about function (app used to browse the web) rather than internals (language support in the engine).
  - pritambarhate 5y ago
    Apple's ToS prevent any kind of interpreted language in iOS apps. > 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user. Basically embedding any interpreted language inside the app is frowned upon by apple. But historically they have allowed JavaScript and Lua scripts to be embedded in apps.
    - fpoling 5y ago
      That does not ban the interpreters. It prevents interpretation of downloaded code. But as long the sources to be interpreted are bundled with app, it is OK at least from that section.
    - Cullinet 5y ago
      "Such apps must make the source code provided by the Application completely viewable and editable by the user." arguably the ability to view source was what created the possibilities of the Web, and as such I don't read this term to be restrictive but instead merely trying to get the best outcome for everyone. disclaimer being that I have spent a large part of the past year evaluating a ios app for commercial release that both relies on decades of proprietary design and which probably doesn't have a significant future unless it is opened extensively or completely.

dgellow 5y ago

And with "React Native for Windows" and "React Native for macOS" (both are still experimental): https://microsoft.github.io/react-native-windows/docs/hermes https://microsoft.github.io/react-native-windows/docs/hermes

mirekrusin 5y ago
Microsoft just gain a ton of respect by putting it out, upfront description etc, I’m impressed by collaboration and plain statements.
- pjmlp 5y ago
  And on Windows it uses WinUI/UWP actually. The recent XBox dashboard has been remade with it.
  - dgellow 5y ago
    On Windows native components can be in C++/WinRT or C#, which is quite nice. Typescript for the glue, managed C++ for the heavy lifting. That's a great compromise IMHO, at least in theory. I'm still a bit skeptical because I haven't seen yet WinUI or UWP applications with a passable user experience.
    - pjmlp 5y ago
      Agreed, you can see how I have been an heavy advocate of it, and see it not only as a much better COM, but also what .NET v1.0 should have been (it was the original idea anyway, Ext-VOS). However nowadays I have become quite sceptical on what it will ever be, and looking forward to what news BUILD 2021 might bring. C++/WinRT tooling still doesn't match C++/CX, doing UI in .NET or ReactNative (QML style) seems to be the workaround for it, endless list of Github issues on WinUI, Reunion and all WinRT bindings, community talks with lots of previews, and state of current tooling. Then the various UI teams seem to be competing to which of them will get more developer mindshare. So it is a mess, that I hope BUILD will get a more clear picture.
      - Cullinet 5y ago
        totally understand that kind of pain : actively thinking about writing driver primitives to shim into the ui library layers to get the eventual sensibility we need. I've spent a inordinate amount of time on figuring out how to hire a truly dedicated windows native interface team and the only solid conclusion that I've come to is it's necessary to also recruit to write tooling for the designers to work with. we have a application that happily doesn't need a gui but to be used widely needs a excellent gui. it looks like we'll need at least as many people on interface as for our core application. the tooling, oh the tooling..
    - Cullinet 5y ago
      Woz dug the windows phone in the earlier lumia stages prior to the wp8 NT kernel with everything else gutting. this is the one book I most want for Christmas - the true account of what happened to the windows phone interface. I was constantly in awe to behold the developments as they happened ; literally "too good to be true" electrocuted me in my chair every time I read the latest.
- kabes 5y ago
  Yeah. Never thought I'd read how to use a facebook javascript engine for macOS on a microsoft site.
  - jbverschoor 5y ago
    Why not? Microsoft and Facebook have been lovers since the beginning.. Even in terms of UI design of the earliest of facebook.
    - WorldMaker 5y ago
      Also, Microsoft has a long history of being one of the largest software developers for macOS. Even when deep in the worst Windows versus Mac OS competitive years, Microsoft still shipped a lot of software to Mac OS. (Most of it Office products.)

madeofpalk 5y ago

Interesting - I would have thought custom JS engines/runtimes would be a no go for both iOS and the iOS App Store.

lucideer 5y ago
Definitely fine for Android (there's plenty of them), but I would've thought the same for iOS. Now that I think of it though, I think the Apple ToS that prohibit browsers are about function (app used to browse the web) rather than internals (language support in the engine).
- pritambarhate 5y ago
  Apple's ToS prevent any kind of interpreted language in iOS apps. > 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user. Basically embedding any interpreted language inside the app is frowned upon by apple. But historically they have allowed JavaScript and Lua scripts to be embedded in apps.
  - fpoling 5y ago
    That does not ban the interpreters. It prevents interpretation of downloaded code. But as long the sources to be interpreted are bundled with app, it is OK at least from that section.
  - Cullinet 5y ago
    "Such apps must make the source code provided by the Application completely viewable and editable by the user." arguably the ability to view source was what created the possibilities of the Web, and as such I don't read this term to be restrictive but instead merely trying to get the best outcome for everyone. disclaimer being that I have spent a large part of the past year evaluating a ios app for commercial release that both relies on decades of proprietary design and which probably doesn't have a significant future unless it is opened extensively or completely.