I am confused about the utility of native client in Chrome other than say using the language of your choice and running faster.
Can one accomplish anything in native client that you cannot do in javascript? By anything, I mean functionality, not a better/faster way of doing the same thing. For example, javascript cannot open a UDP socket, but native client can.
Your first line addresses two points where Native Client provides utility. NaCl is good for C/C++/assembly coders to bring an application written in their language of choice to the web, and NaCl helps applications run faster/with better performance/more efficiently (aka with less use of battery). Native Client also provides threaded applications, allowing programming models (and the performance that goes along with threads) to run natively on the web (aka not with web workers).
The Sockets API is available to all chrome packaged apps, the distinction is that the API makes the sockets directly to a NaCl application, which is faster and has the benefit of porting existing native applications to the browser without modifications. There are also a variety of other APIs, like Game controllers, hardware decode (coming soon), and Fullscreen/Mouselock. Find the full list of Pepper APIs that enable NaCl capabilities here: https://developer.chrome.com/native-client/pepper_stable/c/index#pepper-stable-c-index.
For Portable Native Client, the most notable capabilities are the ability to use threading, and portable intrinsics (SIMD). Perhaps writing core logic that can run cross-platform (aka a C/C++ "model" that can interact with different views on different platforms) isn't a strict capability, but it is a benefit of using NaCl, especially for developers also using Objective C/Android NDK to build native mobile versions of their application.
Related
Our team intends to use JavaScript library observablehq/plot from an app written in C# and running on .NET 5. As a proof of concept, we were able to successfully use that library running in a separate process on Node.js. The downside of this approach is that we would need to implement all data serialization and inter-process communication ourselves, and we would need to bundle Node.js in our app installer. We are looking for an alternative approach that would not require Node.js, but instead would directly host V8 JavaScript engine in our .NET app. Currently, we are considering using ClearScript package for that. While we were able to successfully run simple JavaScript code using it, we discovered that observablehq/plot and its dependencies use some APIs that are present in Node.js, but are apparently unavailable in ClearScript out-of-the-box (it seems that Node.js implements some of those APIs in JavaScript, and some in C++). Making those implementations available to ClearScript running in .NET app looks like a significant task whose cost I cannot estimate at this point.
I would like to ask if anyone had to solve the same or similar problem, and what approach would you recommend? Is there an easy way to make all necessary APIs available to observablehq/plot running on ClearScript? Should I consider hosting Chromium/Edge browser engine in the .NET app instead? I haven’t yet tried this, but I assume it is possible because my understanding (correct me if I’m wrong) is that WebView2 control can be used in WPF apps running on .NET, and it is implemented using Chromium and V8 JavaScript engine. Is there any other approach you can recommend?
Update: The app GUI is built on Avalonia and SkiaSharp. It is possible that eventually we will choose another charting library, perhaps, one not written in JavaScript. But my task at hand is specifically to investigate whether and how we can use JavaScript libraries in our app, taking observablehq/plot as an example, and investigate its features and performance characteristics.
If you are building a WPF desktop app you should try a WPF based chart library that feats your needs.
Open source libraries:
OxyPlot
InteractiveDataDisplay
ScottPlot support pan and zoom.
Paid libraries:
Telerik RadChart
DevExpress
More info about WPF charts in this post.
If you are using Blazor WebAssembly:
Use jsRuntime and JSObjectReference to import and call your Javascript observablehp library.
If you are using Xamarin.Forms the best professional library out there is probably SyncFusion:
Syncfusion Charts
Update:
Avalonia Framework only will support this through a webview / embedded browser as you stated above. Here you have 3 options:
Cefnet is a .NET CLR binding for the Chromium Embedded Framework
CefGlue same than above
WebView Avaloria-CefGlue
For more usefull tools and libraries to use with Avalonia please refer to Awesome Avalonia.
Can I write my web-site only in JavaScript being sure that my code is concealed from anyone? In this respect, is Node.js, like Apache, can be given access to through an Internet-provider?
The answer to both of your questions is yes.
Node.js can completely replace Apache (assuming you are willing to re-write all of your PHP as JavaScript). If you have your Apache running in reverse-proxy mode between your server and client, you can even handle some requests in Node.JS while handing others in PHP. This will allow you to maintain original functionality while changing the code out, and also allow PHP to handle more mundane tasks.
While you cannot prevent raw JavaScript from being read through any means of obfuscation, you can prevent people from reading your code by note making use of standard JavaScript at all. You can use a NativeExtension for Node to add an extension handler for encrypted JavaScript files:
require.extensions[".jse"] = function (m) {
m.exports = MyNativeExtension.decrypt(fs.readFileSync(m.filename));
};
require("YourCode.jse");
This will convert your JavaScript code to a .jse, which you would then package for production. Considering the encryption is done inside the native extension, the encryption key wouldn't be revealed.
Hope this helps! :)
Yes, you definitely can. It may, however, take a while to transition existing code, and if this is for a corporate institution, you'll have to ask your coworkers and your boss/supervisor. Good luck, and remember, always document your code in JavaScript (no types) all languages.
NodeJS is much faster: http://www.hostingadvice.com/blog/comparing-node-js-vs-php-performance/
Many more libraries: http://npmjs.org
Only need one language for everything
Comparing PHP with another technology like Node.js which is meant for an entirely different type of task, comparer must mention the difference of use-case/context in which one is suitable over others.
Let's talk about in terms of a different area of execution because we can not Disgrace any of them and both have its own priority.
If you talk about in terms of Application Domain.
PHP :
CMS (Content Management Systems) like WordPress, Drupal also use PHP which makes it possible to be used in creating blogs, websites, e-commerce sites, etc.
Used in developing CPU-intensive applications like meteorology applications and scientific applications.
should be used in applications in which the client does not have to interact with the server again and again
PHP 7 is based on the PHPNG engine that speeds up PHP applications more than the previous PHP interpreter (Zend Engine 2.0). Thanks to PHPNG, your apps see up to the 2x faster performance and 50% better memory consumption than PHP 5.6.
NodeJs:
Nodejs is ideal for developing highly scalable server-side solutions because of its non-blocking I/O, and event-driven model.
Used massively in Real-time applications like chat applications, blogs, video streaming applications.
Used in developing single-page applications like resume portfolios, individual websites.
Node.js should be used for the applications which require a lot of interaction between client and server.
For some tasks, Node.js may be faster than the “standard” web server with PHP because it runs as a single thread with non-blocking IO for each connection, hence there is no memory overrun. Due to this, Node.js is useful when there is a need to process data in real-time (chats, games, video, big data streams without logic)
PHP is Still alive and he has learned its lessons from Node.JS
ReactPHP enables developers to write PHP-based socket server to process requests constantly as well as Node.js does it (yes, Node.js is faster, but the fact is that PHP can also do it). The same thing with Workers (the classes responsible for running asynchronous jobs and synchronizing their results) or Amp (libraries that are used for writing non-blocking asynchronous code). Hence, it is easy to create long-running processes using PHP. Additionally, there are a lot of tools for supporting and managing these processes (such as supervisord).
So, the same tasks may be performed either with PHP or with Node.js. The question “what tool to use” is a question of personal preferences. you can use Node.js for tasks involving big data flows and PHP for tasks involving complex logic, high-load tasks, for dealing with external utilities, applications, and OS.
From the scalability perspective, there are no big differences between PHP and Node.js, it is more important to consider the project’s architecture.
Dayle Rees (a Laravel Framework contributor and developer): For a long time PHP was the butt of many language jokes, but I honestly feel that it’s becoming not only a popular language but a powerful one. PHP7 is great. The speed boost is one thing, but having optional support for full type hinting is a game changer. We’ve also got modern tools like Laravel and Composer, breathing new life into the language and its supporting community. With this in mind, I think it’s unlikely that Laravel will move from PHP. I think it’s more likely to gain further integration with front-end tools to provide a complete application building platform. That’s where I see it heading in terms of future expansion. I’m sure the Node will continue to excel when dealing with microservices and threaded applications.
The most important and most awaited News from PHP is, PHP is scheduled to receive a Just In Time (JIT) compiler in its next major version PHP-8 (most probably in sep-2021).This is going to boom the php and it breaks all his limitation due to JIT.
Wrap up
To wrap up Both have some pros, both have some cons but the amazing thing is both are created by intellects to make the web development better. While selecting the technology the question shouldn’t be which one is better but which one can serve your project needs in a better way. Understanding your project and business logic can give you a clear idea about selecting the right technology for your project.Moreover, one more important thing to consider is the skills and proficiency of the developers using the technology, how they use them and apply to the project.
I currently have a Qt-based GUI application that simply provides a graphical dashboard (guages, graphs, and such) displaying real-time data provided by another application via a TCP connection. For architectural and security reasons, I have been told that my TCP connection is no longer allowed, and that an HTTPS websocket will be my only conduit. It was suggested that I convert my app to a webapp using HTML5 and Javascript. However, I'm not a web programmer, but may consider this an opportunity to learn a new technology. I want to understand the landscape a little better before making a decision. So, I think my choices are:
Convert my app to a web app, giving me all the advantages/disadvantages of web-based apps. More work for me, as it's a new technology and I already have the Qt/TCP version working fine. If this is the suggested approach, any suggestions on a development environment/tools would be appreciated.
Convert my current Qt app to us a client HTTPS connection rather than a TCP connection. Not sure this is possible. From what I've read, this may not be possible with QtWebKit. Seems strange?
Maybe there's another choice I'm not considering?
You can also use a mixed approach, using WT library. It's c++ (and QT inspired) based.
It has a nice toolkit and supports websockets.
http://www.webtoolkit.eu/wt/examples/
Porting requires a lot of work. On Qt side there are at least two implementations of WebSockets:
QtWebSocket, Qt-based websocket server implementation and alpha-state implementation of websocket client.
WebSocket++, Boost-based websocket server and client implementation.
I just went through a similar exercise for work recently. We settled on the Google Web Toolkit (GWT) framework for doing our web apps. It's completely java-based, meaning you write (almost) everything in Java and the GWT compiler converts it to Javascript for you. We used the GWT-EventService plugin for pushing data from the server to the clients.
I wish I had know about this WT library before we started though, that looks interesting.
You can also have a look at QWebSockets, which is a pure Qt implementation of websockets, both for client and server use.
Update: this library is now an integral part of Qt
Is it possible to subscribe to a JMS, and receive messages from within a node.js app? Is there a node.js module that will allow this, like the amqp module for amqp messages?
Currently the messages are received by a Java app. However, I am trying to switch to javascript.
Thanks
Short answer:
No.
Longer answer:
JMS is nothing but an API interface specification in Java. You cannot really use JMS without Java. So, to use generic JMS (any vendor), you need to have some Java glue code (such as seam, or something more custom made) between the JMS implementation and your JavaScript (node.js) app.
AMQP, on the other hand, is more than an API. It's actually a standardized wire protocol, and could therefore be implemented in any language. JMS does not have this luxury.
That said, there might be options for you if you choose to go with specific vendors.
I know out of my head that Apache ActiveMQ has AJAX support, and the same goes (at least partially) for IBM WebSphere MQ as well as JBoss HornetQ (http://www.jboss.org/hornetq/rest.html).
Other options, other than REST/AJAX, is trying to implement or find implementations of the different Wire protcols different JMS vendors uses. For Apache QPid which supports AMQP, this would be easy. STOMP is another lightweight protocol supported by multiple JMS implementations, such as ActiveMQ and HornetQ that you can find node.js/java script libraries for around the Internet.
A more time consuming option would be to write an extension to node.js using a specific implementation C/C++ API (if there is any..) and connect using that. It would (probably) be more reliable than the REST/AJAX approach but also way more time consuming
I'm looking at two different mobile frameworks--Rhomobile and PhoneGap--as platforms for creating cross-platform mobile apps. Both frameworks offer similar capabilities in terms of platform support, wrapping a web app into a native executable, and using HTML/JS for the front end.
The primary differences between these two frameworks is how the app/business logic is handled. Rhombile uses a stripped-down version of Ruby that can include various Ruby libraries/gems/etc., giving you access to most of the capabilities of Ruby and its extensions. PhoneGap uses the HTML5/JS/CSS stack.
I'm looking to develop an IRC app and an RSS reader app. Ruby has numerous libraries for these kinds of things. I'm not as clear on JavaScript. I've not been able to find any IRC libraries for JS, and the various RSS libraries I've found appear to depend heavily on server-side/PHP programming as well.
Is JS with HTML5 (WebSocket) a viable option for this kind of application, or am I better off sticking with Ruby?
Based on the answers I've seen here, and the research I've conducted, here is what I have concluded:
Ruby has a large library ecosystem for various programming tasks. I've found no shortage of pure-Ruby gems that can be added to Rhomobile via its extension API for parsing RSS, and for implementing IRC functionality.
JavaScript, even with such library packages as JQuery and Prototype, seems much more focused on the display side of mobile development. The available libraries for IRC and RSS parsing seem thinner and, in many cases, dependent on server-side programming for the heavy lifting.
As a result, I am going to go with Rhomobile, as Ruby is better suited for the domains that I am targeting with my apps. Of course I will still have to learn JavaScript to handle the UI side of the equation, which I will do.