Docs: Recommend Servez

[greggman]

1. Servez has an app version which some people find easier

2. http-server has been semi-abandoned. It has issued errors
   on windows for > 6 months and is using deprecated and
   discontinued libraries.

   In response to seeing it wasn't working well for windows
   users and that the maintainers showed no interested in fixing
   it I created a command-line version of
   servez.

[Mugen87]

If any thing I would recommend to use the more popular serve project.

However, I do understand that you are the author of servez and of course prefer your project.

In response to seeing it wasn't working well for windows
users and that the maintainers showed no interested in fixing
it I created a command-line version of

It's true that the bug fixing process was not optimal. However, it's important to clarify that the issue is actually fixed: http-party/http-server#569

[donmccurdy]

We had trouble with serve before, in #14264. It's a fine service, but has some design decisions that cause its URLs to be inconsistent with how we deploy to threejs.org/.

I like the idea of offering a GUI in the list — probably relevant to more users than PHP and Ruby. Whether we should use it in the project's CLI instead of http-server, I don't have a preference.

[Mugen87]

I like the idea of offering a GUI in the list

I'm okay with extending the list in this way 👍 . But I vote to keep the popular http-server as the default server in the article.

[greggman]

separate from picking servez I'm curious why you believe continuing to recommend http-server is a good thing?

For one, even if after 6-8 months they finally got it working correctly again on windows there's still the issue that it's based on a discontinued library. It's based on ecstatic which says

This package has been deprecated

Author message:

jfhbrook/node-ecstatic#259

Worse, for various reasons it's stuck at version 3.3.2.

Basically http-server is dead based on the lack of movement. It seems not good to me to recommend such software. I recommend you choose something else.

I offered servez as one suggetion. it's a very thin wrapper around extremely popular and still supported libraries, express and serve-index. servez supports pretty much all the same command line arguments. It will even generate a fake https cert for you so you can run VR/AR (you'll get a warning in the browser but you can click through it). I recently used it to update VR samples to r112.

[Mugen87]

Maybe we should give http-server a chance to remove the dependency to ecstatic? Have the maintainers officially stopped the project?

@thornjad Can you please say something to @greggman's objections? I personally like http-server and see no need to look for alternatives or recommend them as long as the project is maintained.

[greggman]

The proof the project is not maintained is the fact that it was broken for so long.

http-party/http-server#525

That issue took from mid August to mid November to get fixed. As for ecstaic there has been no response in over 3 months

http-party/http-server#568

I don't really understand why the cling to http-server. If someone installed servez on your computer and renamed it http-server you'd likely not even notice the difference. Again, not saying you should go with servez per-say, just not understanding clinging to a project for which it seems arguable the maintaners no longer have the bandwidth to deal with.

[greggman]

Here's some others

https://www.npmjs.com/package/node-static

https://www.npmjs.com/package/local-web-server

https://www.npmjs.com/package/serve

[thornjad]

http-server is obviously maintained, though we're still picking up momentum on it after a long period of nothing happening. The real issue at heart is that the active development team is only three people, all of whom have busy lives and work on other projects as well. To that end, we very much welcome contributions, and could use more maintainers.

It should also be pointed out that ecstatic embodies the central functionality of http-server, and the maintainers of http-server were also actively working on that project as well, which directly improved http-server. At least until it was suddenly deprecated and temporarily removed from npm (npm was kind enough to restore from their backups).

On the issue of ecstatic being deprecated, moving off of it is a large effort. Right now I'm planning on having the 0.13.0 release of http-server contain its own version of ecstatic to get rid of any deprecation concerns. Beyond that, we're working on rewriting entirely, which will allow us to get rid of the need for ecstatic and a couple other libraries, and provide a better API.

In terms of alternatives, serve is the usual candidate, though I've also heard complaints about architecture before. You might also put https://www.npmjs.com/package/superstatic into the mix, it seems decent from a look.

[thornjad]

@greggman that's a good point about http-party/http-server#568 though, I'll make a note of this there

[Mugen87]

@thornjad Many thanks for your detailed comment in this thread 👍.

[mrdoob]

@greggman I think adding servez to the list is a good idea. Do you mind reverting the http-server change from this PR so it can be merged?

[greggman]

I changed the PR. It just adds servez the app

Just a note like I mentioned above.

servez, both the app and the command line support https that just works (for some defintion of works).

In the GUI you check the https box. In the command line you use servez -S. In either case it will make a local cert which makes it possible to test VR/AR on your phone served from your local computer. The browser will give a warning but you can click "advanced' and then "proceed to <ip-address>" and test out your VR / AR on your phone.

AFAIK none of the other servers listed do this which means there is easy no way to test AR/VR on phones using the other servers. To be clear many other servers can serve https if you figure out how to make your own certs. The difference is servez will make a cert for you if you don't provide one.

I wasn't sure how to fit that into the doc. Maybe it belongs in another PR if it's at all important or maybe it belongs in the VR doc. I know AR/VR is probably not that popular a topic especially given AR/VR support is still only an experimental thing in the browsers. I needed it to test the XR support when you guys deprecated the VR support. I tried making my own certs and using them with http-server. I could never get it it work (not http-server's fault, my fault for not understanding how to make a cert that Chrome/Firefox will actually accept). Someone pointed out a library that does for you so I added that to servez to let me test.

[mrdoob]

In the GUI you check the https box. In the command line you use servez -S. In either case it will make a local cert which makes it possible to test VR/AR on your phone served from your local computer.

I have not had that problem before. As far as I understand localhost is supposed to be a secure origin so it doesn't need https? I've not seen this issue when doing VR/AR on Android.

I've not tried this with Oculus Quest though.

[greggman]

In the GUI you check the https box. In the command line you use servez -S. In either case it will make a local cert which makes it possible to test VR/AR on your phone served from your local computer.

I have not had that problem before. As far as I understand localhost is supposed to be a secure origin so it doesn't need https? I've not seen this issue when doing VR/AR on Android.

How do you serve a page from localhost on android? I serve on my PC which means my android device is seeing them not as localhost.

Here is what I get when I use an http server on my PC and then connect to that from Android

when I use servez -S I get this flow

click advanced

click proceed

[mrdoob]

How do you serve a page from localhost on android? I serve on my PC which means my android device is seeing them not as localhost.

You have to enable port forwarding on chrome://inspect.

After doing that (and with the phone connected to your computer) if you go to localhost:8000 in your phone it'll request directly from your computer's.

[mrdoob]

Merging this for now.

[mrdoob]

Thanks!

[greggman]

I don't really want to open an issue for this but I just want to point out some more minor pluses to the command-line version of servez over http-server

1. servez exits immediately with Ctrl-C on Windows

   http-server (and most node based servers) when you run on Windows and press Ctrl-C you get a second prompt "Terminate Batch? (Y/N)". It's a minor annoyance. servez doesn't have this issue

2. servez continues to serve files even if text is selected in the Command Prompt on Windows

   Windows console has this issue, if you click the mouse on the window it will start a text selection, while that selection is started output to stdout is blocked. This freezes the app. The user doesn't understand why their page is not (re)loading and in frustration tries all types of things. It often takes a while to figure out there is a selection in the command prompt, maybe only a single character big so it looks like a cursor, and that to stop the selection they have to press enter.

   The command line version of servez doesn't have this issue saving people this frustration.

[thornjad]

For the first issue, I don't know much about Windows, would you expect Ctrl-C to always work without confirmation? If that's a Windows pattern, it's not http-server's place to change it. That being said, do you know how servez side-steps it?

That second point is a really good one, would you open an issue over at https://github.com/http-party/http-server about continuing to serve even if stdio is blocked?

[munrocket]

How to start examples in three.js over HTTPS with http-server?

I am tried servez for this. It's looks almost the same as http-server but better and with security audits in npm pakage.

@thornjad Ctrl-C is working as always.