Reinvent the wheel

[stokito]

In NPM repo there are a lot of ready to use servers like the command line https://www.npmjs.com/package/http-server

If already supports many features and has a lot of contributors (but many PRs are still opened since 2016).
I don't know if it depends on NodeJS and it's http package but anyway.
Maybe you can just use it and turn this app into UI to it with a friendly installer?

I see that you have a size concerns and this is great that you care about it.
But if something is written in JS it simply can't be small and fast. But can be popular.

In my case I'm looking for an easy to install server for self-hosting that I can explain to my friend on a phone how to install. And it needs for some UI with visualization of what happens.
The 200 Ok Chrome app was ideal candidate but it doesn't work anymore.

[terreng]

The original version of this program was actually based on an npm package called send. I think I also looked into that package you linked, which has more features. Ultimately I think it was a better idea to write a custom solution because it has enabled us to implement additional features. We have complete control over the web server. We also needed to support security-scoped bookmarks on macOS, which is a security feature for apps on the Mac App Store. We wouldn't have been able to do that without a custom solution.

When it comes to size, Electron + Node isn't great. A better long term solution for this project would be to switch to Tauri for the UI (which doesn't require bundling Chromium like Electron does), and rewriting the web server code in something like C++. That would make the program faster/more efficient, use less energy, and make the installer much much smaller. This is something we've discussed in #52.

[stokito]

We have complete control over the web server.

That's a great and important, I agree. Just using an existing code makes contribution easier. That library already have 70 contributors who knows it's code. It's better tested but what is more important just safer. Having a simpler and modular code is more important for open source product because it allows more people to adopt for their needs, extend or contribute.

While the SWP will get more users you'll receive more and more feature requests that aren't easy to implement like partial PUT requests or support of sendfile syscall on Linux, UPnP, or pre-gzipped content.

Instead you can delegate that to that server but instead focus on UI, configuration wizards and documentation.
For example add some analytics or WAF are also something that users will ask you soon.

I even had an idea to use SWP as UI but start locally a BusyBox httpd.

Correct me if I'm wrong: main target audience are Junior developers?
Or a power users who wants to host their own site.

Using the C++ will just kill the main advantage of the project.
We already have weborf web server that is simple, written in C and has a nice GUI. But even for me it would be easier to contribute to SWP instead of the webborf and it's QT interface.

Yes, the 90mb of installer is a lot but... it's the same size of a simple TODO app on Android.
You can try to minimize it's size but anyway it will be too big. And you'll never make it smaller than 8kb of BusyBox http.

BTW the Miranda IM
also has some Web Server plugin that even works.
And it's probably the smallest possible webserver for Windows. So if you are going to rewrite it you can have a look on it as a good start.

[terreng]

I want to clarify two things about this project:

The purpose of this project is to fill the void left by the deprecation of Web Server for Chrome. The scope of this project is in its name: "Simple".

While I would like this program to be able to support hosting public websites, it is primarily intended for local development or LAN web servers.

Now I'll take a moment to briefly address some of your comments and suggestions:

Just using an existing code makes contribution easier. That library already have 70 contributors who knows it's code. It's better tested but what is more important just safer. Having a simpler and modular code is more important for open source product because it allows more people to adopt for their needs, extend or contribute.

I agree, and this is a good point. There are certainly advantages and disadvantages to either approach. That said, as it is right now, I don't think we'd be able to switch because there are several things that we may not be able to implement without deeper control of the web server and filesystem functions. I think we should reconsider the idea of relying on other projects if we decide to move away from Node.js. For now though, I think we'll stick to a custom solution. I welcome comments @ethanaobrien if you have any.

While the SWP will get more users you'll receive more and more feature requests that aren't easy to implement like partial PUT requests or support of sendfile syscall on Linux, UPnP, or pre-gzipped content.

Instead you can delegate that to that server but instead focus on UI, configuration wizards and documentation.
For example add some analytics or WAF are also something that users will ask you soon.

This is another good point. However, I'm not sure how many of these advanced features we will support. These aren't features that Web Server for Chrome supported, and we may decide that they're out of scope for the simple nature of this project. We have also provided a way for users to write plugins to implement custom features that aren't a part of the program, which is designed to let others implement features that are beyond the scope of this project.

Correct me if I'm wrong: main target audience are Junior developers?
Or a power users who wants to host their own site.

Simple Web Server is for anyone looking for just that, a basic web server. We imagine that many users are developers, but we've also heard from users who just needed a way of hosting files via a web server. I think many power users may also benefit from the ease of use. That said, power users are not a primary consideration.

Using the C++ will just kill the main advantage of the project.
We already have weborf web server that is simple, written in C and has a nice GUI. But even for me it would be easier to contribute to SWP instead of the webborf and it's QT interface.

The program you linked appears to only be available on Linux, so I fail to see the comparison. I don't see how the programming language we use has any effect on the simplified user experience, which is what I see as the main advantage to this project.

Yes, the 90mb of installer is a lot but... it's the same size of a simple TODO app on Android.
You can try to minimize it's size but anyway it will be too big. And you'll never make it smaller than 8kb of BusyBox http.

I'm not sure what exactly you're advocating for here. If we can provide the same simplified user experience with a much smaller download size and reduced resource consumption, then I think we should. That said, it's not our primary focus.

[ethanaobrien]

I agree, and this is a good point. There are certainly advantages and disadvantages to either approach. That said, as it is right now, I don't think we'd be able to switch because there are several things that we may not be able to implement without deeper control of the web server and filesystem functions. I think we should reconsider the idea of relying on other projects if we decide to move away from Node.js. For now though, I think we'll stick to a custom solution. I welcome comments @ethanaobrien if you have any.

Yes, while we were implementing the server I started running into several incompatibilities between our code and the send package that caused many things to not function as intended. Our implementation does the same thing, but is just dumbed down to be more simple.

This is another good point. However, I'm not sure how many of these advanced features we will support. These aren't features that Web Server for Chrome supported, and we may decide that they're out of scope for the simple nature of this project.

Upnp actually was supported in web server for Chrome, it's just not supported because we assume the people looking to put their website on the internet have the knowledge to do it themselves

Using another language like C++ would also take away the cross compatibility, since the system APIs are different on each OS

[stokito]

There is a popular webserver HFS. It's Windows only and written in Delphi. But now it's author switched to TypeScript and created a thord version https://github.com/rejetto/hfs
It looks impressive, have a look.

Also I just discovered few Rust webservers and listed here https://github.com/yurt-page/docs/blob/main/webservers.md