Part of this problem might be that there's too much discussion on the client side for me to see wood for the trees.
Anyway, here's what I want to do. I need a platform independent server-side implementation of WebSockets. I'd like it to run in NodeJS.
Now, 99% of what I've found on this topic talks about socket.io. But so far as I can tell, that is not WebSockets, it's a special "extra" protocol in its own right. I need something that works "by the (not-yet) standard". There's a good reason for that, and it's non-negotiable, trust me on that.
So, I tried WebSocket, but that requires (or appears to require both python and, worse, Visual Studio) to run on Windows. I need something that is platform independent and doesn't need special things like this.
I also tried node-websocket-server, but I can't get that to work at all. The example on the main page fails for me. It seems to accept a connection, but the client doesn't see it, neither side gets to send anything, and the client immediately sees the connection as closed. Indeed, all I ever get is a "connection" callback, and then it seems to die. Running in debug mode didn't tell me anything useful, except for some internal error about some object or other not having a flush() method. I half-suspect this is a defunct project?
So, I'm out of ideas. Is it possible to persuade socket.io to work purely by the (non)spec for WebSockets? Is there a way to get node-websocket-server to behave that I've failed to find. Is there a way round the Visual Studio dependency in websocket, or is there some other NodeJS based tool that meets all my requirements?
Oh, one other thing, I'd like the tool to coexist peacefully with "connect" as I'm using that for my regular document serving.
I had the exact same problem that you're facing at the moment when I tried to use Socket.IO on a different platform without a direct port of the client (and without the motivation to port it myself).
I ended up moving my code to use ws which is a standards based websocket implementation for node without the added sugar from socket.io.
It works extremely well in my case over several different platforms but you would need to rework most of the connection/reconnection code etc.
Website : link
GitHub : link
NPM : npm install ws
Socket.io uses WS under the covers so you may hit the same installation issue on Windows. You may find that it complains that you need to install Visual Studio 2010 for the ws component to work.
However, you can configure the version of Visual Studio used by node-gyp that runs the C++ compiler via an environment variable.
Examples:
set GYP_MSVS_VERSION=2012 for Visual Studio 2012
set GYP_MSVS_VERSION=2013e (the 'e' stands for 'express edition')
For the full list see
- https://github.com/joyent/node/blob/v0.10.29/tools/gyp/pylib/gyp/MSVSVersion.py#L209-294
This is a painful for Windows users of NodeJS as it assumes you have a copy of Visual Studio installed which many non-dev end users will never have. So I'm lobbying Joyent to the encourage them to include web sockets as part of CORE node and also to ship a GNU gcc compiler as part of NodeJS install so we can permanently fix this problem and not have to force Windows node users to tweak their environment or download anything else.
Feel free to add your vote at:
https://github.com/joyent/node/issues/8005#issuecomment-50545326
NOTE: The Joyent team have indicated that socket.io will fall back to using a slower implementation when compiling ws fails. In other words your code will still run - just not as fast. This is not clear for end users performing an install of any app that depends on socket.io or ws as it display red error text during the install process leading users to assume that the install failed, when in fact it will work albeit slowly.
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 am a full-stack developer but since I installed my new antivirus program
(malwarebytes) I receive always the following nodification (see image below).
I work a lot with node.js (REACT, REACT-Native) therefore I am unsure if that is a virus.
I guess it is.
They provide a JS function convince Windows Defender
not to report back on files.
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 planing to make a web app which will allow you to have a Linux Terminal on a web page so that you can execute any command an get the response as if you were in front of your linux terminal.
I planed to use NodeJS as it is server side JavaScript, asynchronous and fast.
Also I saw this wich does exactly what i'm trying to do, I peeked in the source code, but didn't found something useful, I also analysed it with google chrome developer tools on the network tab, but there is absolutely nothing even while executing some commands and getting responses. How is this possible ? what technology do you think they used ?
So I wanted to get your advice, your experience in order to start it the right way.
I firstly decided to use NodeJS, but if there is another programming language or Framework more appropriate for this kind of application please let me know.
If you want a real terminal in the browser using node.js on the backend, you might give tty.js a try.
Alternatively you can use the pty.js module manually which is used by tty.js. Along with that, you could also use xterm for doing the browser-side terminal emulation.
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