GraalVM has so many surprising capabilities. But one thing I haven't seen, but would like to, is to be able to run a GraalVM application in a browser. Sources like this (Top 10 Things To Do With GraalVM) shows interop with Node.js, but not running a compiled application in the browser.
Is this possible? If so, is there documentation on this? Thanks!
Well, it looks like this may be possible using Webassembly. From the Graal VM lead Thomas Wuerthinger: https://twitter.com/thomaswue/status/943592646915878912?lang=en
Webassembly is useful for statically typed languages (as LLVM
backend). I am not aware of any Ruby, R, or Python implementation
successfully targeting Webassembly. Graal VM will be able to run via
Webassembly in the browser. It also has a "native" mode with
standalone binaries.
So if you're coding in something like Clojure or Python and planning on compiling to Webassembly via Graal VM, you would likely run up against the same restrictions that Webassembly has, such as the browser sandbox and only being able to access web APIs. It will be interesting to see if those boundaries can be communicated through error messages or other compile-time checks.
It would be very interesting to see a browser that embeds GraalVM and can run its engine for languages, even if only for JavaScript initially.
Currently, there's no such browsers, as far as I know. Maybe an interesting first step would be to take Electronjs, and try replacing the version of node they use with the version of node.js from GraalVM. It's not trivial, since they introduce some changes to the stock node.js and GraalVM introduces some changes when replaces the JavaScript engine with its own implementation.
However, it definitely should be possible to achieve.
Related
There are a lot of questions on this topic, but they don't seem to distinguish between executables for desktop or server-side apps. I suppose my first question would be: what's the difference? For example, Zeit/pkg says they are a "node.js binary compiler", whereas nwjs (formerly node-webkit) says they are a "an app runtime based on Chromium and node.js".
I tried zeit/pkg and it works great, but have read that there can be performance issues unless it's configured properly. I wanted to make sure I was choosing the right tool and came across nwjs. It seems to do a lot of the same stuff pkg does, but has a larger following, as well as more docs and a robust api. Can I use nwjs as a server-side executable (i.e. not using the desktop feature) the same way I would use pkg?
This answer states that nwjs "is an option, but it really isn't set-up to do a server - client type relationship", but then a comment says "you can launch a server from node-webkit just in the way you launch it in Node.js. It's just that node-webkit provide another way beyond B/S architecture".
So, is nwjs effectively the same as pkg, or fundamentally different?
I realize that there's also Electron, which states "build cross platform desktop apps" and appears similar to nwjs. I'm not trying to get into a Electron vs nwjs debate, but rather desktop vs. server, if there's a difference.
you got most things already, only few clarifications are needed. Reason nw.js / Electron declares itself as for desktop application is, it's core architectural design is intended to integrate node.js with chromium to have UI enables create application does have UI. You can still use part of those framework (node.js side) without initiating visible ui, in that case behaviorwise it'll be similar to plain node.js does. Still there is caveat, like as it tightly integrated with chromium in core already for some cases you should have screen to chromium correctly initiates (or creating virtual buffer as lot of CI does, or etcs).
Also, when your concern is performance, I'd doubt using UI framework for server side work achieves what you desire - while there won't be huge, integration between node to chromium have overhead compare to bare node.js obvioulsy.
Getting back to original question, I feel question itself is somewhat vague. If the intention is truly server side application probably you won't need to package it but correctly deploy node and its dependency modules or packaging it sort of installable manner instead of creating single binary as pkg does.
I'm trying to understand if there is any other way to access the WebKit API directly from from a Haskell (ghc-7.10.2 currently) program without having to go through something like webkitgtk3, which is a Haskell wrapper around WebKitGTK.
It appears WebKitGTK does not expose the full WebKit API, for example these are offered by WebKit:
HTMLCanvasElement # developer.apple.com
CanvasRenderingContext2DClass # developer.apple.com
but not by WebKitGTK:
WebKitDOMHTMLCanvasElement # webkitgtk.org
Is there any way to access the WebKit API of a running WebKit.app or Safari.app especially on OS X but also Linux and Windows?
P.S. Some background to this: I'm developing an application using GHCJS, but since GHCJS is so much slower (and doesn't integrate with all Emacs IDE features, I think), I also want to be able to compile the same (or almost the same) code base using GHC. So I got familiar with webkitgtk and even spent several days trying to get webkitgtk-2.4.9 to build on OS X via Homebrew, because webkitgtk3 only currently builds against 2.4.9, only to find out that the nice and fully featured Canvas API which WebKit exposes is not at all available through WebKitGTK. Hence the search for alternatives. And it is also for this reason I'm adding ghcjs — it is very likely that other users of GHCJS will find this post interesting.
This question already has answers here:
Is it possible to create desktop applications with node.js? [duplicate]
(5 answers)
Closed 7 years ago.
Is there a way to compile a node.js application?
I maybe very late but you can use "nexe" module that compile nodejs + your script in one executable: https://github.com/crcn/nexe
EDIT 2021: Nexe's latest release is from 2017 and it appears that development has otherwise slowed, so the more-widely-used alternative from Vercel should also be considered these days: pkg
Node.js runs on top of the V8 Javascript engine, which itself optimizes performance by compiling javascript code into native code... so no reason really for compiling then, is there?
https://developers.google.com/v8/design#mach_code
EncloseJS.
You get a fully functional binary without sources.
Native modules also supported. (must be placed in the same folder)
JavaScript code is transformed into native code at compile-time using V8 internal compiler. Hence, your sources are not required to execute the binary, and they are not packaged.
Perfectly optimized native code can be generated only at run-time based on the client's machine. Without that info EncloseJS can generate only "unoptimized" code. It runs about 2x slower than NodeJS.
Also, node.js runtime code is put inside the executable (along with your code) to support node API for your application at run-time.
Use cases:
Make a commercial version of your application without sources.
Make a demo/evaluation/trial version of your app without sources.
Make some kind of self-extracting archive or installer.
Make a closed source GUI application using node-thrust.
No need to install node and npm to deploy the compiled application.
No need to download hundreds of files via npm install to deploy your application. Deploy it as a single independent file.
Put your assets inside the executable to make it even more portable.
Test your app against new node version without installing it.
There was an answer here: Secure distribution of NodeJS applications. Raynos said: V8 allows you to pre-compile JavaScript.
You can use the Closure compiler to compile your javascript.
You can also use CoffeeScript to compile your coffeescript to javascript.
What do you want to achieve with compiling?
The task of compiling arbitrary non-blocking JavaScript down to say, C sounds very daunting.
There really isn't that much speed to be gained by compiling to C or ASM. If you want speed gain offload computation to a C program through a sub process.
Now this may include more than you need (and may not even work for command line applications in a non-graphical environment, I don't know), but there is nw.js.
It's Blink (i.e. Chromium/Webkit) + io.js (i.e. Node.js).
You can use node-webkit-builder to build native executable binaries for Linux, OS X and Windows.
If you want a GUI, that's a huge plus. You can build one with web technologies.
If you don't, specify "node-main" in the package.json (and probably "window": {"show": false} although maybe it works to just have a node-main and not a main)
I haven't tried to use it in exactly this way, just throwing it out there as a possibility. I can say it's certainly not an ideal solution for non-graphical Node.js applications.
javascript does not not have a compiler like for example Java/C(You can compare it more to languages like PHP for example). If you want to write compiled code you should read the section about addons and learn C. Although this is rather complex and I don't think you need to do this but instead just write javascript.
Haxe has Apache httpd modules and can compile to PHP code. These are 2 options I know to make a web application that runs on the server. You can start a http server with nekotools, but this is supposed to be used for development only.
Are there any more options?
I can always use the NekoVM from within a C or C++ program, running a web server or interfacing to FastCGI. Or compile to C++, using a FastCGI or web server library. But I want to hear about solutions that are actually used.
I have a VPS with nginx, so no mod_neko or mod_tora. PHP isn't a problem, but I'd rather wouldn't use it (for irrational reasons).
More correctly there is an Apache module for the nekoVM. (You do need necessarily haxe to produce neko binaries)
To your question:
As far as I know there is currently no possibility to use the C++ target for webserver application, but some people are playing arround with some stuff.
As you said, you could use PHP
mod_tora or mod_neko on a Apache setup. (Why not use Apache?)
OR: the probably most interessting thing for you be: Link 1 and Link 2 (neko as cgi / fastcgi)
hxNode uses node.js. Don't know if anybody uses hxNode, but node.js got some good press lately.
I'm continuing to keep hxNode up to date and expanding it with the node.js spec.
I'm using it for my own projects and debugging it as I come across stuff.
Currently, hxNode, has the node.js api defined in Haxe, this is the standard node.js asynchronous API. Also, I've started to recreate the Haxe standard API using this API, so for example, js.FileSystem has been implemented, this makes use of the fact that latest versions of node can call fs module syncronously.
Other things which I'm working on with this API, servlet's sitting on top, and mongo bindings based on chriskv's mongo native drivers.
bd
I had a fresh look at Haxe again recently and realized that I had overlooked some of its elegance before. But I guess it lacks some visibility among the developers still.
So my question is, does anybody here use it for production? If so, how do you use it? What are the gotchas or difficulties you encounter? Do you recommend it for future projects?
I use Haxe to develop all my Flash applications, and I love it. I develop on Linux and with Emacs,
and I really like how I can make Haxe fit within my preferred development environment. I just use
simple Makefiles that look something like:
project.swf: Project.hx
haxe project.hxml
It's really easy to get started in Haxe, and it's very elegant. I've
had no problems at all using Haxe as compared to using the Adobe Flash
builders, and have developed a bunch of big projects including PanningPedagogy, The Orchive,Cantillion and Audioscapes.
I've released the source code to all of these as GPL on SourceForge, check them out at:
https://sourceforge.net/projects/panning/
https://sourceforge.net/projects/orcaannotator/
https://sourceforge.net/projects/cantillion/
https://sourceforge.net/projects/margridflash/
You might find some useful information in the lists of Projects Using Haxe and People Using Haxe.
My company uses Haxe for production use. For programming swf content is absolutly no problem on the technical side. Using it on the server side is a little bit harder. If you Haxe for PHP you sometimes have some problems with typing (this is more or less a PHP problem). The neko vm is very stable and very very fast but it takes some time to get it running with all you other server software (mysql, apache - mod_rewrite), but once you got it you it is very stable.
We used it for generation swf applications, tried the possibilies of Haxe JS. Also we created socket server for a multiplayer game and start to generate all our webpages with Haxe PHP or neko.
The community is very helpful, the documentation is sometimes a little bit to short.
This is only my opinion and the experiences I made.
For those of us who don't know what Haxe is, it's a programming language for developing web apps. It has multiple compiler targets (Flash, php, JavaScript, and the Neko language's VM)
Welcome to haxe [haxe.org]
Haxe entry on Wikipedia
Haxe are currently gaining more popularity as a cross-platform development (mainly for game development) tools thanks to NME/OpenFL: http://www.openfl.org/
Write once in Haxe and deploy it to Flash, Android, iOS, and more..
HaxeJS is very good for web production, it allows to use all the underlying js modules while giving extra abilities like pre-processor, typed fields, conditional-compilation, classes, haxe libraries, refactoring and auto-completion from IDE etc.. plus its very quick to compile and output ready-to-use js files.
I haven't tried microsoft typescript, but so far I've been using HaxeJS for both client and server (nodejs) on a few production projects and it feels a great choice. The only issue is if i want to share js libraries or npm modules with others, I'll probably need to rewrite the js by hand then.
We used it at a previous internship, for an internal web system. We only compiled to js and I just once compiled some minor code to both js and C#. I can say it worked quite well and many custom widgets were made at the time. Debugging the produced js wasn't that bad either, but it sometimes didn't produce the code you wanted it to (I remember one string comparison issue in js, where the reference was being compared instead of the value). The code was deployed in production and had worked fine for years. I'm pretty sure they still use it today.
That was in 2013, I haven't used it since. One problem I did have was trying to compile code made in version 2.08 using version 2.10. It needed some minor, but non-obvious adjustments. I can't quite comment on more recent releases, but I'd be a bit careful on not breaking large pieces of code by upgrading to new versions of the compiler.
You compile, haxelib run flow run "target" in target you type for example web, and thats all, in your bin, folder you get your files, remember to configure your project.flow file acording to your target and project.