Hacker News Reader

Comment by chrsig | Hacker News Reader

I've been using nanogui[0] to fit the bill for personal uses.

To be honest though, I'm at the point where I'd really prefer an easy and lightweight library to setup a http and/or websocket server, and just make a ui in the browser. I've got a simple use case -- I'm just making a simple scene editor & debugging ui for a toy ray tracer.

I know there are a ton of different libraries out there for the task, but that just makes it hard to evaluate the quality of any given library. I haven't given any a shot, I've only gone so far as to look at them and ponder what the size of the user base is, and question if the project will go inactive in a couple years. Or if it's going to require me to pull in some other host of dependencies.

Recommendations from HNers welcome!

[0] https://github.com/mitsuba-renderer/nanogui

View on HN

Would redbean work for your purpose? It's very lightweight and fun to work with, though not suited for everything.

https://redbean.dev

Not exaclty -- it looks like it's pretty overkill for my needs

I'm looking for something more like websocketpp[0], or even just grpc without a requisite proxy. uWebsockets looks really promising, being header only, but in the fine print requires a runtime library. unfortunately, none of that ecosystem seems to use cmake, making integrating it that much more of a pain.

why use cpp for this, I'm sure some HNer will ask. the ray tracer itself is using cuda, that's why. I've also debated

- running it as a grpc server and having some proxy in a more web-accessible language

- creating python bindings and using python to make a websocket/http server for it

neither of those are out of the question, but they're not my first choices, because I'd like to keep the build & execution simple. introducing dependencies, especially other executables, is in conflict with that.

i don't need anything particularly scalable -- a threaded implementation, or one using select() would be fine, if not preferable.

[0] https://docs.websocketpp.org/

[1] https://github.com/uNetworking/uWebSockets

> To be honest though, I'm at the point where I'd really prefer an easy and lightweight library to setup a http and/or websocket server, and just make a ui in the browser.

Wouldn't that mean that the expiry date of your GUI is like: a few years or so?

Since web-stuff seems to change so constantly with breaking changes and revamps every few years being the norm.

Whereas a WIN32 app (or Unix or other) from 25 years ago probably still runs fine? I can't imagine the same for any web-app that was written for Netscape and now has to run in a modern browser.

nah, compatibility is longer than a few years. it can be practically impossible to deprecate stuff, even.

you see a lot of churn in the web ui world because browsers implement new features that new libraries take advantage of. it seems to be stabilizing a bit around react. the developers in the space do tend to reinvent the wheel more.

it's not that big of a deal to me though, because it's a pet project, not a professional product. if i want to show it off to non-technical friends/family, it's a lot easier for me to point them to a webpage than it is to have them install some binary I produce.

having a native gui isn't precluded going this route either, I'd just have a native gui connect via socket rather than interact directly.

> Whereas a WIN32 app (or Unix or other) from 25 years ago probably still runs fine? I can't imagine the same for any web-app that was written for Netscape and now has to run in a modern browser.

Sure, but then I'd have to learn all of the platform specific apis, or go with something like nuklear or nanogui (like i'm doing now). which is fine, sort of. it's not really the development I want to be doing, and it's got a frustrating workflow.

Just due to my background, having started my career in webdev, i feel more comfortable doing ui work in a browser than i do fussing with native or opengl based uis.

> you see a lot of churn in the web ui world because browsers implement new features that new libraries take advantage of

Also because of design language evolution (whether this is “fashion” or “advances in usability research” is a debate I’ll sidestep here); the old stuff still works fine, it just isn’t current style; if all you care about is “UI that works” and not “UI that looks and feels current”, web isn’t a bad target.

Reply on news.ycombinator.com