Is there any other server side language (with or without frameworks) that support hot-reload or live-coding, so when we develop, all we need is:
Start the web server
Edit the source code
Try on the browser (without having to restart the server)
Similar to PHP
Some other language that I know able to do this:
ruby/sinatra
sinatra-reloader gem (sometimes not working)
rerun (*
nodejs
nodules module
node-supervisor module
nodemon (*
(* automatically restart server when there are changes, not really hot-reload
Is there any other language that are able to do this? and if possible, showing the error (filename and line number, or the full stack trace) on the browser (not in the terminal/console), so I don't have to switch from code-editor then to browser and then to console to see the error.
You can try Perl with the Mojolicious framework: http://mojolicio.us/ (using the morbo server).
Can also be achived with Groovy/Java using the Grails framework: http://grails.org
You can use Erlang to work as a web server, which is designed to allow you to hot swap whole modules of code while the program is up and running. Though, the functional programming paradigm does take a little while to get used to...
How to write a simple webserver in Erlang?
I hope this helps...
I think what you ask for is actually called live-reload, hot-reload is something I believe only Erlang can truly accomplish.
By configuring and adding plugins to Grunt or Gulp, you can watch for changes in any list / kinds of files and describe any action to be initiated. Here is a plugin for Grunt. With this method, any language can gain such ability.
As a side note, Django (Python) has auto-restart as well. But that does not mean Python language has it built-in, Django uses a Grunt-like trick to restart its dev-server.
Revel for Go could do this, or Beego, the difference is Revel only recompile when there are changes on the source code and on new request (so it's more efficient), Beego recompile every time there are source code changes.
EDIT: Beego 1.3.0 remove its hot reload feature T__T
Related
I've been going through the documentation at https://bazelbuild.github.io/rules_nodejs/ in order to put together a small web based application. I've got babel building the JS code, and http_server serving it, and ibazel watching it, and everything is working as expected: when I make a change, ibazel notices it and restarts the http_server rule.
The next thing I wanted to look at is getting autoreload in the browser so that the browser would automatically refresh when the change was compiled. My understanding is that this requires the http server to not be killed by ibazel, but instead to stay up and trigger a refresh via the ibazel_live_reload mechanism. I believe that http_server doesn't support this, but ts_devserver is explicitly mentioned in several places. However, ts_devserver doesn't seem to be maintained anymore (although I did find a devserver EXE in the npm package, there isn't a bazel rule that I saw to use it).
Is there a third party live development server that supports the ibazel reload mechanism - or am I missing something completely obvious?
Disclosure, I'm a core maintainer on rules_nodejs
As of rules_nodejs v3.0.0, ts_devserver has been renamed to concatjs_devserver to try and better namespace it (it has little to nothing really to do with Typescript). Its docs can be found here.
Note though that the concatjs_devserver comes with some compatibility gotchas, all dependencies have to be in named AMD/UMD or goog.module format for example, and may be tricky to use unless following the rest of the google3 toolchain.
We've (as the maintainers of rules_nodejs) tried not to wrap an existing devserver and publish it as of yet for various reasons, but it's something that has come up in discussion. I'm currently investigating some options in this space.
I'm not aware of any published devservers that currently support the ibazel protocol, there is a wrap of browsersync in the Angular Components repo which you may find useful.
I have been using webpack to build a server side app using express. This code is harder to debug since I don't have the immediate comfort of a web browser and if I use something like VS Code to debug, it won't accept breakpoints inside request handlers when using source maps. Besides it takes no time to compile if I just stick to Node compatible JS and skip all transpiling and whatnot. Further, if I use treeshaking, I can reduce the size, but what is the point of that when it is running on the server (no client will ever download it).
My point is that I don't see why one would want to create a bundle of server side code if the server don't have any issues with memory or other limiting factors. It's easier to read, takes no time to compile and is easier to debug.
So a question. Is it ok to have the server app as an npm package and deploy that? Is that what is common or what do people do?
The project my team works on is a TypeScript monorepo that includes a web application and server-side daemon processes. We use webpack for producing build artefacts for all targets.
I've read some posts saying there's no point using webpack server-side because it was designed for web (obv), and I can understand that point of view.
However, even if our code was JavaScript and didn't require any transpiling, we'd still use webpack for the server-side. I want a single, minimal set of files and no node modules to deploy to the servers.
Size itself doesn't matter that much for server side (though every bit helps), but running 'yarn install' on servers is out of the question IMO.
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.
I'm developing a private web application for a company and they ask me to use their server to host it. I would like to prevent them the access to the source code. How can i do that? Their server is running debian and they have the root access..
I found some solution like packaging the application in one executable file but the application have lot's of dependency and I'm using loopback.io framework; this make packaging very difficult..
Any different solution?
The answer is no, you cannot prevent them from seeing the source-code. If they own the source-code, then it is even unethic to want something like this. If you own the source-code, then minify it. But before you do that, think about it. Will it raise the trust of your client in you? Even binary source-codes can be reverse-engineered. With interpreted languages, like Javascript, you cannot even do that. If you are afraid they will not pay you unless you protect the source-code, then implement the project on a local server and create a video to back up your claim that the project is completed. Although, everything depends on the actual agreement, which, you understandably will not share with us.
You can't prevent them from seeing the source code, but you can make it harder to read with browserify and uglifyjs:
browserify index.js --no-bundle-external --node | uglifyjs -c > bundle.js
This unfortunately won't preserve the original stack trace of errors and will make it harder to debug.
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