[Community] What are you building with ChakraCore? #2575
Comments
|
Just as a quick Note, I tend to be blunt, but Here's the feedback...
Nothing involving ChakraCore... I lost interest in ChakraCore due to issues with getting changes into the main development branches.
Poor. Although some of this is timezone differences and lack of feedback, but in general things are in a fashion where things mostly feel like things are being completely ignored. Although Some of my issue is that I can't afford a more modern Mac OSX system. The Mac I own is a laptop using an Intel Core 2 Duo chip, and takes more than 30 minutes to even attempt to compile ChakraCore.
More detailed guidelines on what is required to get code changes integrated into the main development tree.
I have some documentation I wrote, and created a pull request for the chakracore samples involving OSX/Linux.
Making better use of the CMake build engine will greatly improve overall end user experience. A system similar to how GLFW and/or libSDL in general show a reasonable solution for embedding. All of this is part of my pull requests.
I was, but not anymore due to the poor experience I had when trying to get things merged into the development branches. I had multiple pull requests I submitted over 3 months ago and none of them where accepted. Also, as a quick note, It's generally a well accepted practice for major change sets to occur as multiple commits with a single pull request. I see multiple commits per pull request in the Linux kernel development, Xorg/X11 development and more. |
|
Hi, Currently I am discovering the technology on my side. I am really interesting in it because of your benchmarks. I have been thinking about distributing my own NodeJS binary embedding my business logic in order to provide a way to write some code in Javascript as it follows: const myAPIAction = require('my-api-action');
const promise = myAPIAction.Do();
promise.then(() => {
// do your stuff
}).catch(() => {
// do your stuff
});All the transactions with my APIs are done with a faster protocol than HTTP. My customer can focus on his API implementation and his front-end without having to develop all the part communicating with my APIs. Using the Node-ChakraCore providing the Neutral VM I can also provide a proper working environment to my developers and whoever want to use my APIs. I could have done that using The idea could look strange however I am already communicating with some other APIs. So here instead of It's an idea I am currently exploring. About what I have done so far:
For the other points, nothing to say. For now it's pretty cool. Maybe not the place to talk about it. But it's not the same deal with the uwp npm module. I have been struggling with it all the week end for building a bluetooth scanner on my Raspberry Pi. The documentation is not that helpful. |
|
@JackTheRipper , the If you're working with bluetooth on Node.js on Windows, you might take a look at my |
|
For context, I work on dotnet/orleans with @galvesribeiro. Orleans is a framework for building distributed systems with .NET, used by a bunch of teams within MS (Halo, Skype, & teams in Azure) and outside of MS.
The intention is to build support for writing Actors using JavaScript/TypeScript, currently we support .NET languages. Actors are inherently distributed, so strong support for
So far, quite good. Gitter helps and the team seem quite receptive and willing to help. I haven't had to modify or compile it yet.
It was helpful, the samples were especially useful. Continuing to flesh out the API reference and samples will be useful. For example, JsValue is used in APIs, but the JsValue often has an expected runtime type (eg, a function), and that ought to be documented. |
I work on BaristaLabs/barista-sharepoint which is a SharePoint service application that allows devs to create microservices using JavaScript at runtime without requiring additional deployments to the farm environment. The current version of Barista uses Jurassic as a JavaScript engine. I'm aiming to create a more general-purpose project - BaristaLabs/barista-core - with ChakraCore in the vein of AWS Lambda and Azure Functions except open-source, xplat that can be deployed to commodity level hardware. Also, I maintain ChakraSharp that generates a low level ChakraCore C# binding using CppSharp
Great so far! The team is responsive and much thanks to @obastemur for getting the remaining api in for xplat. I have ChakraCore building on Linux/OSx/Win as part of my CI and things couldn't be better. Now I just need more time to devote to the project ;)
Sufficient. Xml Code Comments and examples within are great.
Maybe more high-level design type documentation. Also perhaps release notes, there's been a lot of work put into 1.4, for example, but it's unclear to me as an external what the goals of 1.4 are WebAssembly api seems daunting right now, but haven't had a chance to look much into it.
Only myself and gaining an understanding of the ChakraCore codebase. |
|
something is wrong with the GitHub editor, can't preview and set the format. [What projects are you working on?] [What have your experiences been when working with ChakraCore?] [Is our documentation helpful? If not, how can we improve? Were you able to find answers to your questions?] [Have you written any blog posts or made any other public documentation about your experiences with ChakraCore? We'd love to read them!]
|
|
|
i'm building enterprise web applications using ChakraCore for SSR of React uis. for my purposes it's a nice alternative to V8 |
full-stack projects.
Seamless. I've been using chakracore to test script blocks on my mac. Kudos @obastemur
I didn't need any documentation so far. Only build instructions.
Not yet :/
I am interested. If you set ...Accepting PR... label to simpler issues I can gladly take one or two. |
|
I will write up a bigger list in the near future. Something that could be addressed for xplat is marking the win32 only functions. https://github.com/Microsoft/ChakraCore/wiki/JsPointerToString for example. This took me a while to figure out why a simple sample wasn't compiling. |
|
@jasongin Node-Chakra is build from a fork (https://github.com/ms-iot/node/releases) of the Node-ChakraCore. Anyway thank you for the tip ! |
I would like to use ChakraCore to filter data by user-submitted javascript snippets.
I have had better experiences, but I am sure that's mostly bad luck. Trying to embed ChakraCore in a cmake project seems more difficult than I thought it would be. To be honest, cmake was one of the reasons choosing ChakraCore over v8. I found the following a little disappointing:
In most other libraries I use
I believe that examples on the function pages for the JSRT references would improve a lot.
No.
Yes, allow embedding using |
|
@likle have you looked at the cmake PR on chakracore? Been meaning to check it out in an actual project but it appears to use cmake better and exposes the static library in a way consumable via cmake. |
|
@jaredwy yes I did. As far as I remember there were more than one PRs regarding cmake/static linking. I was hoping it would be merged. Thanks for pointing that out ! |
|
|
We've got some amazing insights and feedback from you guys from the past week. Thanks everyone for replying! |
|
@kphillisjr you were definitely right about improving cmake embedding experience and thanks for bringing that to us! Sorry to hear you dissatisfaction, I think there were some pointers given at the time (1, 2, 3, etc.), but unfortunately people's opinions on things had diverged on those issues. We've done some work and checked in a cmake sample yesterday, which should achieve the initial goal of improving cmake embedding. There's also #2129 which we'll happily merge once some comments there got addressed. |
|
@JackTheRipper fascinating usage of node-chakracore 😄 If you have any feedback, feel free to let @digitalinfinity or @aruneshchandra know. |
|
@ReubenBond great to hear from you! It was fun chatting with you and @galvesribeiro on Gitter too. Hope you find the new JsCreatePromise useful.
Totally right. We will continue to publish samples and snippets and if you find a particular API reference is lackluster, I'm more than happy to edit it. |
|
@liminzhu once it got released on ChakraCore we will start using it and will definitively reach you guys back with feedback. |
|
@galvesribeiro awesome! Feel free to play with release/2.0 br now as well if you want to experiment early. |
|
@Oceanswave great to hear your scenario and glad you seem to be having fun! You can actually find release notes on the release page but we usually keep things on a high level. In case you're interested in webassembly, consensus was reached by four browser vendors today on the MVP design (see mail to CG). |
|
@liminzhu What @Oceanswave did with Mono/Net is interesting and could be helpful for others. I recall something similar for Rust from another user. We might have a part in wiki to promote those cool work though. |
|
@obastemur yeah, I think having a derivative work wiki (or a sec in the resource wiki) for interesting projects like what @Oceanswave has would be great. Let me look into it. |
|
@Oceanswave to tag on to @liminzhu's reply: https://github.com/Microsoft/ChakraCore/wiki/Release-Notes contains the high-level release notes for all released versions. |
Looks like @Fishrock123 and @darfink had done some work on that. See #1492 and #1441 for some discussion. |
|
@JohnMasen thanks for the feedback! I think you and I have already chatted on some thread to edit the
|
|
@alexhultman glad to hear you're playing with ChakraCore and thanks for the feedback! Is there any documentation enhancement that you would've found helpful back when you were learning the basics? |
I think the Resources page would be a good place for it. There have also been a few community projects which embed JSRT APIs in .NET and we could maybe link to those repos if we don't mind the implication of "officially" "endorsing" those projects. |
|
@likle thanks for the feedback and hope this new cmake sample can help you!
My perspective is that adding snippets about how to do basic things would probably be more helpful than adding individual examples for each APIs. Thoughts?
|
|
@liminzhu it is really interesting. Currently I am preparing a Docker image which builds only the Another image come on top of that one adding my It's not done yet but it looks sexy |
|
In fact I described my stuff already to @matthargett |
|
@liminzhu thank you and of course @obastemur for the helpful example. I personally really like the way others (e.g. cppreference, msdn and especially mdn) provide basic usage examples (usually in the bottom of the page). But I guess that is a matter of taste. Adding snippets about how to do basic things would of course also help a lot. :-) |
|
@dilijev opened an issue microsoft/ChakraCore-wiki#28 :). |
@likle I think we could probably arrange that. It's extra overhead to maintain documentation separate from the samples, so I'll leave the final call on that to @liminzhu but I've added this issue to track this request. microsoft/ChakraCore-wiki#29 |
Yes, there is :). Adding debug support outside of nodejs. Not being able to debug scripts when embedding the runtime into a C/C++ application is really almost a showstopper. It would really be great if chakracore offered a possibitly to just attach vs code without having to run the scripts inside chakra node js. |
|
I am saying this as senior year student who reads ChakraCore source code for learning purpose, and have plan to work on it as my hobby open source project (although I was very busy in last months and haven't worked on any specific thing other than small eval flag for "ch"). Lack of documentation is the most difficult barrier I have faced. Second, I may be wrong, but I am not aware of any coding style enforced from Microsoft on developers. V8 does follow Google C++ Coding Style. I think ChakraCore should have a complete code style too, something like what Google does have. BTW by coding style I don't mean only putting brackets in new line or things like these, I mean you should define a subset of C++ which allowed to use. (I am saying this again, I may be wrong about this, but at least I haven't seen any coding guideline) Third, Testing in ChakraCore is not that obvious. By obvious (other than lack of documentation of course) I mean we could have much better output than what we have currently in test outputs. Personally most of the time I am afraid to even look at the test output after I run tests. By cleaning output of test code the cycle of Implement->Compile->Test would be much easier. IIRC there was a way to run specific tests, but I am talking about more broader picture here, we should make testing as easy as possible. Four, I would love to see this thread to stay alive, we can share our experience with official developers here, and get answers, It would be much better experience definitely. I know we have gitter, but let do technical discussion in gitter. |
|
@voidstorm thanks for the suggestion! What we have now is debugging APIs sitting in ChakraDebug.h, which is one of the headers that need to be included for embedding ChakraCore. Our team is using it to shim the V8 debugging APIs and implement debugger for NodeChakraCore, which you may already know. I definitely understand your pain here, doing a bunch of work to implement a debugger is not ideal 😄 . My concern is that there's a huge chunk of things that just shouldn't be owned by a JavaScript VM and requirements very much vary for different hosts, e.g. debugger implementation, interfacing with debugging UI (VSCode), etc. That said, with our node efforts, maybe we can carve something out and make a library for other ChakraCore embedders. It won't be a plug-and-good-to-go debugger, but it can be something that at least makes life easier. AFAIK the debugging situation is similar between all standalone JS engines. Correct me if I'm wrong and I'd be happy to look more into it. |
This Coding Convention is the style we adhere to when coding ChakraCore. Microsoft at large leaves style up to the individual teams and we're happy to have that flexibility. We made the deliberate decision not to arbitrarily restrict the kind of code developers should write, preferring this minimal Coding Convention (i.e. style guide) to make code as legible as possible (with uniformity as a secondary concern). (Keep in mind, as stated in the coding convention, for older code which is formatted differently, we try to keep mainly to the style in the surrounding code.) |
|
@liminzhu @voidstorm this is correct. V8 for example provides the api for interfacing with the engine via a debugger https://v8docs.nodesource.com/node-0.8/de/d13/classv8_1_1_debug.html , but does not implement it for you. You can see the implementation of the node debugger here https://github.com/nodejs/node/blob/master/src/debug-agent.cc This uses the new chrome inspector protocol that is being pushed down into V8. |
We definitely would not turn away PRs which add non-trivial doc comments. We don't especially like the pattern of documenting Every Single Method™ because if a method is short or the naming is good, its purpose is largely self-explanatory. Generally, we like (or don't dislike) having some internal source code documentation for long or unintuitive methods, in the form of doc-style comments, as well as comments within the code. Additions of documentation within the code that explain the general purpose and usage of our classes would be welcomed. To somewhat justify the state of things: one of the reasons we don't have many documentation comments is that the overall design of classes can sometimes change rapidly while developing new features, adding optimizations, and fixing bugs, and we're more interested in implementing good quality code (reinforced with tests) than we are in documenting the behavior in prose comments (and more importantly, we don't want to always have to ensure that the documentation stays current and accurate as we evolve the code). For more abstract documentation about design, we feel source code comments are not the best place for this. Blog posts and Wiki entries would be better suited. We acknowledge that we should expand our Wiki documentation. |
The test output (i.e. baselines) were not really designed to be human-readable. We acknowledge this is a deficiency and are slowly converting tests as they need it. For the tests which have baseline files, the best approach is to diff the output (piped to a file) with the baseline file. Usually reducing the test to a simpler script with a repro of the exact issue is the best way to diagnose and fix a failure. We have a unit test framework which we introduced relatively recently which emphasizes testing through assertions, with emphasis on printing output ONLY when something is wrong. Some tests use this (especially the many tests with no corresponding .baseline file). Many older tests have not been converted to use this. For some tests it doesn't necessarily make sense to use it. It also makes running tests a little bit less straightforward (the working directory matters to load the test framework library). There's a low-priority PR open (see Issue #269 and PR #1399 by @Cellule) which tries to improve this. See rlexedirs.xml and the various rlexe.xml files for test definitions. Baselines are usually named after the tests so if you go looking through the tests directory you should be able to find them. Again, we acknowledge documentation needs to be improved in this area. There's a wiki issue open to track this: microsoft/ChakraCore-wiki#7 |
Agreed. Will add though:
|
|
hi Guys, https://github.com/JohnMasen/ChakraCore.NET key features:Read/Write javascript values |
|
@JohnMasen Thanks for posting the link to the project here! I've had my eye on that project and reference it occasionally among the team as an example of a third-party .NET wrapper for JSRT. |
|
@dilijev My Pleasure ：） |
|
@dilijev |
|
Hi @JohnMasen. Hope everything goes well with the family. We appreciate the interest and effort you’ve put into building something with ChakraCore. While we are not structured to support or promote third party stuff, we are thinking of creative ways of how we could share derivative projects build using ChakraCore with the community, incl. things like derivative projects wiki. Once established, we could surely add your project to that. |
|
Hi @liminzhu : |
|
@JohnMasen ah okay it's a note for everyone on the thread then. If anyone is interested, he/she can also fork the project and maintain it if that's okay with you @JohnMasen? |
|
Hope I'm not too late to the party:
I guess our project is most similar to DocumentDB's use of ChakraCore. The equivalent of stored procedures or in our case: calculations and analytics. We allow users to create custom logic that triggers as new events hit our database or they can trigger based off of web hooks or time based scheduling as well. Like DocumentDB which is a PaaS offering in Azure. Our database, which is optimized for streaming data, is also a PaaS offering in Azure. So we host ChakraCore in a multi-tenant cluster which is where the challenge lies.
We started the project using V8, and right as we completed the initial prototype to get the go ahead from the higher ups, ChakraCore was open sourced. I've been writing software since 1998, so I started in the object-oriented world of paradigms. C++ was more attractive to me, even though, there are ton of gotchas that will let you shoot yourself in the foot. I liked V8's C++ API, but at the same time hated it. The way that GC handles were exposed were annoying having to promote from local to global and vice versa. Initially I wasn't too much of a fan of the JSRT. The fact that ChakraCore is a bunch of C++ classes and then the API is a C abstraction that just typedefs everything to void* was annoying, but makes sense with a loosely typed language. Also doing something simple like extending the Date object required getting the global object and navigating to the prototype via JsGetProperty calls seemed verbose; however, I decided to give it a shot and see if I could switch out V8 for ChakraCore and started to like the JSRT more over time. I wrote simple classes like JavaScriptEngine to wrap the runtime and context, and JavaScriptObject to wrap the calls needed to fetch properties, set them, define them, control reference count, and add methods to them. After those were in place, it was easy. I even had promises working with async / await via JsNativeFunctions before the JsCreatePromise was added. So I didn't just switch out ChakraCore for V8 over Microsoft fanboism. In a multi-tenant cluster, you need to control the noisy neighbor problem. You need to cap memory for each "calculation," and you need to terminate scripts that are consuming too much CPU. V8 supported the memory cap, but ChakraCore supported the ability to have the JITter introduce more checks to see if you want to terminate the script via the runtime attributes. Also the experimental features already supported the asncy / await keywords with existing promises, and I loved that.
The best asset for documentation as of now is the OpenGL example. It covered everything from creating objects, adding native methods, Creating a class or setting up a prototype. It was a bigger help than the documentation. I think the documentation is lacking quite a bit. As of now ChakraCore.h contains a bunch of new APIs not yet included in the Wiki. In addition APIs like JsDefineProperty are abhorrent. There is nothing there that says the JsValueRef you pass in should be an object that contains the getters and setters, etc. Luckily Gitter resolved that. Documentation is the weakest part. Also defining properties should be easier. See V8 which easily allows you define properties with C++ callbacks including indexed properties.
So as I mentioned, we host it in a cluster in Azure (Service Fabric). ChakraCore is not quite optimized for having many different scripts loaded in different isolated environments. Since these need to run in parallel a lot, we have to essentially create a pool of runtimes with a single context that all have the same script loaded. It would be nice if either contexts could have multiple threads invoking a function in parallel. Or the ability to clone a runtime with some sort of copy-on-write setup. We have to create a lot of runtimes and it adds up. The biggest challenge we have is asynchronous code. Chakra is loaded by our mixed mode DLL. Most of our other logic is C# which uses Async everywhere. Getting that to work with the JSRT was big challenge. If Chakra had better async support that would help. That doesn't mean it has to place nice with .NET Tasks, but some sort of async APIs that we could wrap as a TaskCompletionSource helps. Finally I hate the fact the context is set as thread local storage. In an async world, you are never guaranteed that your function resumes on the same thread, so your JSRT calls with fail due to the context being not set or incorrect. As of now, we need to marshal all async call back to the thread that started invoking the engine to prevent it. That marshaling comes at a big cost. An overload to the APIs that allows the context to be passed could help with this, but would not be compatible with the current model. Additional features to help with the noisy neighbor problem helps too. Maybe a JSRT API that gives access to the Abstract Syntax Tree, so we can maybe do some static analysis to vet this user written code that we have to host. Or even better, maybe this already happens, but Chakra could have some APIs that do some form of static analysis looking for potential forever loops, etc. Finally, I'd like to contribute more and the existing "architecture" section of the wiki just doesn't cut it. Some wiki entries explaining the types "RecycleableObject" and other internal types would help us understand. |
|
@ninlar thanks for sharing your perspective. It was a very nice and construtive post.
As you probably noticed, JSRT APIs are by design very atomic :).
Yep I agree that documentation for some of the experimental APIs is not there is a problem. AFAIK the missing ones are the module APIs in ChakraCore.h and diagnotic APIs in ChakraDebug.h, which are ones most subject to change. Will spend time to add them in the wiki and mark as experimental.
API ref for
Not sure I fully understand why you have to use a single context since you mentioned 'in different isolated environments'. Do all scripts need to access the same data within a context? Nevertheless, a clean JavaScript way to think about paralellism is through SharedArrayBuffer (behind experimental flag in ChakraCore). You can implement something like a webworker that shares data between contexts (ofc it breaks the isolation and needs some special care). Then you can spin up multilple runtimes to map/reduce. JavaScript is a single-threaded model so it doesn't make much sense to allow multiple threads partying in the same context. For testing SAB, we probably will need to implement agent for ch, which you can look into.
JsCreatePromise is your friend. See thread.
Yep we've had similar requests before about parsing AST though for different purposes. The reason we didn't do it is that our AST structure is unstable. It needs the flexibility to changes all the time as we implement new language features.
We could definitely use a PR there :). |
With our efforts to enable cross-platform development, and recently, to enable the use of NuGet packages for ChakraCore development with .NET and Native apps (#85), as well as other work we've been doing to enable other scenarios, we're interested in hearing from the community about what you've been building with ChakraCore, and what you would like to build.
Besides the issues you file, the feedback you give us on Gitter, and other tags of the ChakraCore project, we don't have as much visibility into your needs as we would like, we're hoping to hear from you about anything you'd like to share with us about your projects.
Some questions we have in mind:
Below, I’m tagging some folks who replied to #85, various other GitHub issues, and/or on Gitter with interest in a NuGet package for .NET and/or Native apps, or have otherwise indicated interest in developing with ChakraCore:
@resnyanskiy @gulbanana @ormico @jimmcslim @Oceanswave @matthargett @Pre10der @MartinJohns @Fishrock123 @wickeda @JackTheRipper @dthompso99 @CatCatCatDog @fubar-coder @alexhultman @snowmantw @kphillisjr @TomSeymour @navidR @liydu @likidu @lwansbrough @atanasovg @galvesribeiro @ReubenBond @ninlar @kostaspl @lwansbrough, etc.
/cc @digitalinfinity @boingoing @liminzhu @bterlson @aruneshchandra @EdMaurer @sethgaurav
The text was updated successfully, but these errors were encountered: