I agree almost 100% with what @Isofruit brought up. I would like to be specific and say that I'd like .NET-style validation, with controller methods mapping to routes, their arguments being used to generate JSON validators automatically, and the ability to use annotations to customize it further.
> Since that is a limitation of the HTTP server prologue uses: I'd love a > framework that has the ability to deal with large file uploads and downloads. > Namely, if I wanted to upload a file that is 350 MB large, the server should > be capable of handling that. You should check out @pwernersbach's excellent [MicroAsyncHttpServer](https://github.com/philip-wernersbach/microasynchttpserver) library. It's slightly faster than `httpx` when multithreading, and it's nearly 100% API-compatible with stdlib's `AsyncHttpServer`. The difference is that it doesn't load bodies entirely into memory, and instead lets you stream them. I worked with @pwernersbach a month or two ago to clean up the library a bit and make it more usable so I could use it in a web framework I was writing. Unfortunately, I ended up hitting many hurdles in that search, but TL;DR if you want to do multithreading with `asyncnet`, stay away from ORC for now. I did a deep dive into all the HTTP servers I knew a few months ago in [this thread](https://forum.nim-lang.org/t/10080) if you're interested in reading about my thoughts on the general state of HTTP servers in Nim. * * * @jasonfi > I'd say Next.js, mainly because of React being reactive and having excellent > tooling. I think fullstack web frameworks are good in theory, but tying your backend teck to your frontend tech is a bad longterm decision, because it makes migration very difficult. They also usually don't have very good performance, but unlike a backend where the only shared things are data type definitions (generated with OpenAPI/Swagger or similar), with a fullstack framework, your library is inextricably linked to your entire project, not just frontend. When it comes to a fullstack framework in Nim, I simply am not comfortable shipping the massive bundle sizes that Nim JS produces. It sounds fine until you realize that, as of the time of posting, [forum.js](https://forum.nim-lang.org/js/forum.js?t=2022-10-0110%3A01%3A28) is 793.69KiB uncompressed, and 114.94KiB gzipped, partially due to bizarre codegen like this: // ...continued... case 97: case 98: case 99: case 100: case 101: case 102: case 103: case 104: case 105: case 106: case 107: case 108: case 109: case 110: case 111: case 112: case 113: case 114: case 115: case 116: case 117: case 118: case 119: case 120: case 121: case 122: case 65: case 66: case 67: case 68: case 69: // ...continued... Run For size reasons alone, I don't think Nim JS is suitable for most websites, and even many web applications.
