I notice that there are many advantages of using Hermes engine in React Native.
I think the biggest difference from the existing JavaScript engine(JavascriptCore) is the compilation method(AOT compile).
but I leave a question because only the advantages are explained, and there is no mention of the disadvantages. Is there any disadvantages or limits in Hermes engine used in React Native?
I heard that the disadvantage of the AOT compilation is control AOT version is hard. Is hermes engine overcome this advantage by limiting the supported version??
If there is no limits or disadvantages except for version dependency, Why React Native does not use AOT compile at first?
Hermes on iOS is community supported, and has lagged behind in first class support to this point. You may encounter issues if you have 'use_frameworks' in your Podfile. Intl support has to be polyfilled and can be a little tricky to set up correctly. There are probably other newer APIs which are missing. You still should choose Hermes for a new project, and if able I would definitely switch to it for any project that can support it easily. if you have an existing and complicated project with many dependencies you will be adding more complexity to your builds so just be aware of that.
we want to highlight some of the most exciting progress we've made over the past two years to push Hermes towards being the best JavaScript engine for React Native. Looking forward, we are confident that with these improvements and more to come, we can make Hermes the default JavaScript engine for React Native across all platforms. Read More
Related
It has so-called JS client. But all the docs or demos are written from the point of Python developer.
Does bokeh has standalone, non-python JavaScript API, and is it used by anyone in non-python environments?
Does bokeh has standalone, non-python JavaScript API
As of late 2019: Somewhat! (See below for more context)
and is it used by anyone in non-python environments?
Yes, definitely, though pure-BokehJS usage levels are still low compared to Python APIs. Improving the JS story is a 2020 goal.
A little history
The Bokeh project was started in 2012 with the explicit goal of providing Python developers a way to publish interactive visualizations in the web, without themselves having to get into "web tech", i.e. JavaScript. As such, the BokehJS library (which has always existed) was originally mostly a largely undocumented implementation detail. It didn't really help that the Bokeh developers themselves were not JS experts at the time. (Some of us still are not!)
As things progressed, and features like CustomJS callbacks and the ability to make custom extensions were added, the BokehJS side of things became more and more publicly exposed. That said, until fairly recently, BokehJS development has been very fast and furious and we were not in any position to provide guarantees around core API stability or expend resources on documentation that would likely be out of date very quickly. As two examples, in the last year BokehJS was completely re-written in TypeScript, which rendered any old CoffeeScript extensions or callbacks deprecated. Additionally the entire layout system was re-vamped to afford much higher performance.
Current status
For some time, there has been a fairly stable "high level" API for BokehJS, and you can find details of that in the Developing with JavaScript chapter of the users guide. Additionally, all the low level "models" and their properties are 100% aligned up between Python and JS, so the Python Reference Guide actually has all the information you might need to use models on the JS side as well.
We are very interested in improving BokehJS for pure JS usage in the coming year. We have been getting some very helpful issues from folks actually using BokehJS directly. Some major hurdles will be overcome with the upcoming 2.0 release, but there will still be work to do to really provide a great user-experience for JS devs. This is actually a fantastic opportunity for any interested JS devs to have a big impact by offering their input, advice, and collaboration. Anyone so interested should head over to the Bokeh project Discourse.
I am adding a typescript project to a VS2015 MVC 5 project (that makes it ASP.NET 4, not asp.net 5 or asp.net 6 code: only the MVC is version 5). This is the sole target for all aspects of my question, I cannot use generalized or theoretical guidance on typescript, node.js, module loaders, etc.
The problem is simpler with ASP.NET Core. But that's not what I'm facing. All the usual sources of examples and guidance avoid or provide scraps when it comes to ASP.NET 4 MVC 5 because it is hard. And no one will state exactly how hard or what precisely are the obstacles.
Worst, Typescript documentation is like Open Source Documentation: you can only get one issue, one step deep. This produces a research workflow consisting of endless-issue-tree-recursion.
I understand opinions, I even have one. But I'm looking for the experiential answer, what is the one combination that has proven to work for a production team.
So here are the specific items that need to be addressed and made to work within the confines of a working, medium-sized ASP.NET 4 MVC 5 LOB app:
Visual Studio's version of typescript. This is an installation issue (using node most simply) and the Tools/options - typescript settings have to match.
Browser-style testing (typically manual TDD workflow) or node.js testing (automated). This has to be chosen up-frontly to prevent more issue-tree-recursion. We are going with browser-based... phantomjs using WallabyJs.
NPM #types/library-name: supposed to fill a node_modules folder with both library-name and library-name.d.ts based only on a package.json with #Types references. But actually requires the package.json to hold a reference for both the #types/library-name and the library-name to work in my VS 2015 ENT v3 and asp.net 4 mvc 5 project. And all the versions specified then require manual correction' and even then the version look-up process is a little suspicious. This #types process may not be the way to go with ASP.NET 4 MVC 5, but I can't tell what the correction alternative might be. #Types is currently the only recommended option for typescript.
Which version of ECMAScript: es6 is apparently too far ahead. es2015 is likely, but this (maybe) appears to have relationships to several of the other issues. Supposedly, these designations are the same, but there are two places they can be set. I've chosen es2015 in tools/options/typescript. But getting any of these (now 3) settings wrong could be a problem.
Module system: CommonJs is for node and automated testing, and VS development testing is automated only for server-side, and VS UI tests are a manual process. So AMD, require JS is probably an option for VS, but it adds its own workflow and maintenance and considerations that are really hard to get right in ASP.NET. Using ASP.NET bundling and triple-slash references (dependable) might work, but after you have put the libraries in node-modules, you would want to use the full path into node-modules in the file name slug in an import statement. This is all very clumsy and involves the most guesswork. But solving this whole item might be the 'key' for the overall question.
There are probably a lot of other, smaller issues. But someone who has done this will have solved all the mentioned items and the others as well.
What I'm looking for is all the settings across all these issues in detail based on a working Typescript app in ASP.NET 4 MVC 5 implementation for browser-based unit/behavior tests in VS 2015. Those who have done it will understand.
Thanks very much for your consideration.
What you're missing is separation of concerns, in spite of the initial benefit of such starter templates, they start to cause incidental dependencies and complicate the mental model. It's much easier to have your front end in a separate project.
Regardless:
Visual Studio's version of typescript.
Always use the very latest available. This controls the version of TypeScript which powers the IDE. You will probably end up compiling in a separate process or in the browser during development. Again you will want to use the latest but it will likely be installed with a different package manager.
Browser-style testing (typically manual TDD workflow) or node.js
testing (automated). This has to be chosen up-frontly to prevent more
issue-tree-recursion.
Firstly, I definitely agree with the importance of choosing up front but, if it is still possible, just unpleasant, to add tests to an existing project.
TDD workflows involve automated testing as they rely on rapid feedback. This is orthogonal to whether you run your tests in the browser or using NodeJS.
You should use whichever approach makes the most sense for your application and that may be a mix of both.
Since you are writing a frontend JavaScript application you will likely want to run some tests in the browser. However, as Uncle Bob (Robert C. Martin) has stated, views should be dumb and require little testing. My interpretation of this is that we should not spend too much time testing things like Angular or React components to ensure that they render correctly, and instead focus on testing behavioral elements of the system such as services and plain old functions.
That said, you may well want to run tests of your client side services against an actual browser runtime, as opposed to just Node.js, and that is reasonable.
There are a number of testing libraries to help you with this. I do not have a specific recommendation besides to say that you should find a reliable test runner, and a simple assertion library. Tried and true testing libraries like QUnit and Tape are examples of solid options.
One last note, it is important that one not confuse the concept of integration testing with running tests in a web browser, it's perfectly valid to run TDD style tests, which implies unit tests, in a web browser.
NPM #types/library-name: supposed to fill a node_modules folder with
both library-name and library-name.d.ts, but requires the package.json
to hold a reference for both the #types/library-name and the
library-name to work in my VS 2015 ENT v3 and asp.net 4 mvc 5 project.
Simply put this goes to back to decoupling your front end from your back end. Visual Studio and certainly ASP.NET have nothing to do with versioning your types packages.
If a package comes with its own type declarations then you don't need to install an auxiliary types package otherwise you do.
Either way install JavaScript and TypeScript dependencies using a JavaScript oriented package manager (such as NPM, JSPM, or Yarn).
Do not use NuGet for these!
As you suggest there are versioning issues, it's currently a difficult problem in TypeScript. However once again it has nothing to do with ASP.NET or Visual Studio.
Which version of ECMAScript: es6 is apparently too far ahead. es2015
is likely, but this appears to have (maybe) relationships to several
of the other issues.
ES6 is the same as ES2015, the latter being the name under which the former was ultimately released. ECMAScript now follows a yearly cadence, roughly, with ES2017 just around the corner.
The nice thing about having a transpiler, such as TypeScript, is that you can use the latest features from es2017 and still target es5 for emit and you'll be fine.
Module system: CommonJS is for NodeJS and automated testing, and VS
development testing is automated only for server-side, and VS UI tests
are a manual process. So AMD/UMD require JS is probably the option for
VS, but it adds its own workflow and maintenance and considerations.
Using triple-slash references (dependable) might work, but after you
have put your/their libraries in node-modules you would want to use
the full path into node-modules in the file name slug in an import
statement. (solving this whole item might be the 'key' for the overall
question).
This is a very complex subject and probably the only one of your questions that you really need to spend a lot of time considering. As I said earlier using NodeJS or not is orthogonal to automated testing. But if you're targeting NodeJS natively with your test code then you will need to use CommonJS output.
For the actual application code, the choice has nothing at all remotely to do with whether or not you are using Visual Studio, I'm sorry for reiterating this but it really is important that you separate these ideas.
The question of which module format to use for your front end application code is a very important and contentious one.
Triple /// references are not a module format but rather a way of declaring the dependencies between global variables that are declared and referenced across multiple files.
They do not scale well, working acceptably when you have only a handful of files.
Triple /// references should not be used. They are not a modularity mechanism and their use is completely different from using any of the module systems/module formats you mention, including CommonJS.
Never combine them with a module system, which is what you would have to do in order to run your tests under NodeJS or load your app with RequireJS or anything else.
RequireJS is an excellent option which would imply AMD modules as you say. RequireJS does not require any use of triple slash references. In fact they should be avoided as the plague when using this format or any other module format!
I recommend strongly against using UMD modules. Isomorphic JavaScript is a problematic idea, and it offers you no benefits since you are creating a browser application with a .NET backend.
Many developers actually do use CommonJS modules in a browser. This requires bundling them continuously, using tools such as Webpack. This approach has advantages and disadvantages. The primary advantages are the ability to lean on existing NodeJS JavaScript server-side tools, such as npm, by way of Webpack or Browserify. This may not sound like a big advantage but the amount of rich tooling available for CommonJS modules is nothing to scoff at, making it a strong option.
Consider using the System module format and the SystemJS loader via jspm to both manage your packages and to load your code. With this approach, you gain the advantages of RequireJS, are able to run your tests under NodeJS and the browser using jspm run without needing to switch targets formats or bundle your code just to test it. There's also no need to bundle your code during development, although this is supported. More importantly, you gain the advantage of writing future compatible code, as it offers the only module format and loader which correctly models the semantics that ES Modules will eventually have when implemented natively in browsers. JSPM has first class support for TypeScript, Babel, and Traceur.
For posterity here is the description of the System module format taken from the link above:
System.register can be considered as a new module format designed to support the exact semantics of ES6 modules within ES5. It is a format that was developed out of collaboration and is supported as a module output in Traceur (as instantiate), Babel and TypeScript (as system). All dynamic binding and circular reference behaviors supported by ES6 modules are supported by this format. In this way it acts as a safe and comprehensive target format for the polyfill path into ES6 modules.
Disclaimer:
I am a member of the JSPM GitHub organization, playing a role in maintaining the registry and have made very minor contributions to the jspm cli.
I'm working on a React Native project that uses Realm for React Native.
It works without problems but now, I am faced with a problem of writing Android Service that would use the same Realm instance. Is it possible and how would I do that?
I think you can communicate from Java to React Native through Native Modules and do your Realm-related code in Javascript as you normally would.
Otherwise, Realm for Android's multi-process support for non-encrypted Realms will arrive in Realm-Java 2.0.0 (and that part is actually in with the snapshot), which will most definitely support this use-case; when the core version of Realm-React-Native (currently 1.5.0) and Realm-Java (previously 1.5.1, now 2.0.0-rc4) will be the same (2.0.0).
So not yet, but actually quite soon. I'd estimate a month or two at most from the time of writing.
EDIT: According to https://github.com/realm/realm-js/issues/984#issuecomment-297716769 the only way to get the same core and sync and object-store versions reliably for your app is if you build Realm-JS and Realm-Java from scratch and use them in your application like that.
I've just discovered TideSDK and it seems to be a really great tool, but I have one requirement : I need to use some native code (for managing USB devices for example) and so I need communication between this native code and the web app, is such a thing possible with TideSDK?
Yes, working with native code in TideSDK is possible. Our SDK is modular and we have been reorganizing the code structurally to make it easier to do the sort of thing you want. At a modular level, you will be contending with support for multiple platforms typically.
A module should extend to all platforms that you are supporting. We expect to have documentation to help developers (familiar with native code) to better understand the SDK. This should include some module boilerplate to help you get started. At this point, we have yet to prepare this more detailed documentation. We have much to do and sometimes progress seems slow despite all the great efforts going into TideSDK.
TideSDK is a large and complex SDK but don't let this frighten you off. It is extensible and we will be shining light on this soon with module development guides. It would be cool to talk more on IRC about this with you so feel free to drop by at any time. Perhaps the functionality you are speaking of is of general use ie. to extend the APIs for everyone.
There are possibilities to work together with the core developers of TideSDK on modules and to contribute to this great open source project. Other possibilities also include sponsoring module development if this something that you need more immediately for a project. Hope this helps.
I am thinking about using PlayN to manage "common code" in Java and use PlayN to generate iOS, Android, and HTML native versions of the common code.
I figure I could then use the playn-generated native code and link with actual platform specific code (such as UI).
In other words,
Common Code libs in Java-> PlayN -> Native Commond Code Libs -> Link with Native App
Is the use of Play for the above workflow/pipeline appropriate? Any challenges?
Thank-you...
Firstly, you have to specify what you mean by "native" code for the different platforms.
On Android, your java files are specifically compiled/prepared for dalvik. So they are already "native" of a fashion, no work needed to be done here. If you want to get C/C++ native code for Android using the NDK, you're out of luck. PlayN doesn't do this and this is a hard problem (going from Java to C++)
If you take a look at the Maven modular layout of how PlayN is intended to be used, it isn't difficult to define a Factory interface in the common code and pass in a platform specific implementation for each module. It's no big deal to support Android specific functionality this way.
For the HTML version, you can use HTML libraries no problem using JNI, although really garnering specific functionality of the browser I'd imagined of limited value compared to what PlayN has already exposed. The one thing that is useful is text/keyboard input, although I'd recommend triplePlay https://github.com/threerings/tripleplay UI library as they've solved this, and it's an active project.
As for iOS, this might be more complicated as the iOS module is a bit of a hack where the compiled Java classes are run through an JVM runtime for .net (IKVM) and then uses the Monotouch tools to compile the whole thing to native code for iOS. See https://github.com/samskivert/ikvm-monotouch
So for iOS, you won't be able to bind the code to any form of native version, and what you have access to via the toolchain method depends very much on what Monotouch has catered for iOS (quite a lot I imagine), and also what IKVM-Monotouch has supported (I imagine the bare minimum to get PlayN working).
I'm not familiar enough with the Flash pipeline to give you an appraisal, although I think that it's quite flexible.
The above answer is written assuming your app is actually a game. If it is not and you intend to use the standard widget libraries for various platforms on mass, it should be possible. Choosing a good MVP framework would be good here, and depending on the assumptions it makes on different host environments will determine how easy the whole thing will be.
I'd recommend reading and comparing https://developers.google.com/web-toolkit/articles/mvp-architecture and perhaps look at questions like What is your favorite GWT MVP Framework?
...although a lot of these frameworks might be GWT specific and not really have catered to being reused on other platforms.