Hello everyone,
I鈥檓 having a hard time formulating the question and it can be a bit confuse to me too at times, but here it is. For the context, so that you can have an idea of the shenanigans I鈥檓 used to program, I鈥檓 a PhD in compilation and did stuff related to security and performance. I have essentially worked in projects that are relatively low-level and system-oriented (compared to webdev, desktop application dev etc).
I usually code CLI tools, usually system-oriented libraries, and stuff like that. And sometimes I would like to hack simple yet cool frontends, typically a webapp to either visualize my processes/data or to manipulate the inputs or whatever. I鈥檓 not looking for a big solid webapp. What I would like to do is to write frontends that would be the equivalent of quick ugly glue Perl scripts for interprocess communication.
Typically, I could have a program I wrote doing stuff, I may add a little HTTP server feature to it as an entrypoint to its internal and then have a cute webapp to connect to it to visualize what is going on, idk.
As I said, I鈥檓 not trying to transform my applications into actual servers or microservices in order to build an entire web application on top. It is more like using a proper user interface (typically web) as a better pretty-printing/logging system/whatever.
I guess there must be frameworks, tools, architectures or whatever to suite my needs, but since I have never really done frontend projects, I鈥檓 in the dark right now.
If someone has any recommandation, it would be very nice. Thank you so much in advance!
Typically, I could have a program I wrote doing stuff, I may add a little HTTP server feature to it as an entrypoint to its internal and then have a cute webapp to connect to it to visualize what is going on, idk.
Are you saying you could add HTTP endpoints to your services which can then be queried for data? So REST APIs for example?
Do you want live updates on the UI or is a fetch visualization enough?
For simple fetch visualization, creating a simple web app with browser native JavaScript and HTML seems like a fine, simple solution for barebone/hacky visualizations.
If you want live updates, there鈥檚 a few alternatives. Polling from REST API, long-running streamed responses (http server sent events), or Websocket (continuous connection and communication). Websocket will need the capability on the backend server.
If you鈥檙e imagining a reporting/monitoring like tool/UI, using OpenTelemetry and one of many existing collect and store and display solutions could be relatively simple setup, with a bit more investment into serving OpenTelemetry data.
There鈥檚 various technologies and frameworks. You could choose any one, or choose one closer to your tech stack, whatever you use.
Are you saying you could add HTTP endpoints to your services which can then be queried for data? So REST APIs for example?
Yes, this is more or less what I鈥檓 thinking of.
Do you want live updates on the UI or is a fetch visualization enough?
Well, depends on what I am doing. Typically, if I鈥檓 working on a parser for a new language for instance, i think live update would be a confortable addition. But I guess that any decent JS framework would easily handle processing an input text change event into querying the backend etc.
I didn鈥檛 know Open telemetry. I鈥檒l take a look at it.
Given that I can setup my backend application to deliver the information (a REST API must be enough most of the time I think), what stack would you use to write the frontend asap? What I mean is I don鈥檛 want to create an entire Angular project and setup multiple files of stuff to have a minimal visualization of my outputs. I鈥檝e written some Vue.js back then, it was ok. I wonder if we can do even simpler today (with a framework that handles the dynamic aspects of the application, not with barebones JS).
Also, do we still use Bootstrap to have an out-of-the-box CSS with minimal effort? Is there something newer or better?
Thank you so much for your answer
I wonder if we can do even simpler today (with a framework that handles the dynamic aspects of the application, not with barebones JS).
You want a stateful application or a template-model-rendering system?
If not, the webbrowsers support fetch API and you can create HTML from that, or set values on the DOM elements.
Personally, I鈥檓 not too familiar with JS frontends in particular. I could name some random names, but don鈥檛 have experience or particular opinions. What I鈥檝e read, and intuitively agree with, is that many of the most popular frameworks introduce additional complexities and their own state system when the browser nowadays would cover those natively. Newer frameworks that make use of the current browser tech may be better. But I can鈥檛 name specific names.
I myself, in terms of web frontend frameworks, work with Blazor (dotnet). Upside being direct C#/dotnet integration and development and wide options, downside being the tech complexity of framework between browser and backend and a mixing of HTML and Razor concerns.
If it were me, I would probably create an
.htmlfile, add a<script>block, and use the fetch API to fetch the data from the backend and then render/display it via JS/HTML. It鈥檚 always possible to size up and add complexity later.Oh damn, thank you! I didn鈥檛 know that and it will most probably serve as a starting block to create the exact thing I need. Everything is still confuse is my head, I鈥檓 still not sure what I really want, but you clearly helped me. Thank you so much.
If it were me, I would probably create an .html file, add a <script> block, and use the fetch API to fetch the data from the backend and then render/display it via JS/HTML. It鈥檚 always possible to size up and add complexity later.
It is totally the kind of things I鈥檇 want to do, just an HTML file, some scripts to populate it and call it a day.
Great, I鈥檓 glad it helps. Good luck! :)