Very interesting. Thank you!
I feel the pain. Been there. Done that.It'll work, and it will look like crap, too.
Making a modern web page that looks good requires an in depth understanding of HTML and CSS. Personally I think it's all a big mess and I'd rather not waste my life thinking about it. To that end I use bootstrap to style things: https://getbootstrap.com/docs/4.0/examples/I'm interested in something modern that would look good.
Well... if you want a web page you need something to answer to HTTP requests from the web browser.I'd prefer not to have to install and configure a web server per se.
Thanks! So that's 2 votes for Bootstrap, and 2 votes for node.js/express.Heater wrote: ↑Mon Feb 05, 2018 5:56 pmMaking a modern web page that looks good requires an in depth understanding of HTML and CSS. Personally I think it's all a big mess and I'd rather not waste my life thinking about it. To that end I use bootstrap to style things: https://getbootstrap.com/docs/4.0/examples/
Code: Select all
<!doctype html> <html lang="en"> <head> <!-- Required meta tags --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> <!-- Bootstrap CSS --> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous"> <title>Hello, world!</title> </head> <body> <h1>Hello, world!</h1> </body> </html>
No idea. XML is horrible. HTML/CSS is much the same.Why did XML fail to replace HTML/CSS?
Yes, I will keep it simple. A modest use of Bootstrap will be good enough and good for my blood pressure
Oh, no. XML is what you want it to be. I will admit writing XSL transforms is sort of a mind-bender.XML is horrible.
Code: Select all
<!-- This will be rendered as a super-stylish automagic accordion thing --> <accordion width="100%" rhythm="fast" version="1234" render-for="IE-4-win"> ... </accordion>
So what? Let form follow function. Work out how to make it work first, then you can worry about making it look pretty. It's not like you can escape writing that core logic, and then you can simply wrap it inside a web/app framework that has some default CSS/themes that make it look better.
Good question. Let's see...But, really, why even involve a web stack?...
You give a lot of generic features (all of which are debatable), but the fundamental question is about what makes sense on a case-by-case basis. Very few people seem to actually sit down and figure out why, for example, the HTTP protocol is the best choice for their API (hint: it often isn't).
Same is true for most modern GUI builders.1) Creating a GUI in a browser is easy. One can put up all kind of buttons, text boxes, etc, etc. with very little effort. Yes it might look like crap but it's there and it works.
Only so long as the browser supports the features you're using, or the machine supports the browser you're targeting. The solution is only "cross platform" in the sense that you have to appeal to the lowest common denominator.2) A GUI in a browser is cross platform. Such a GUI can be viewed on any machine that has a browser, which is everything useful now a days.
But a big need for all your users to connect to your server, or to set up an HTTP server running your stack on their local network.3) No need to distribute separate builds for all your users platforms: Windows, Mac, Linux, Ios, Android etc, etc.
Again, as with #2, assumes they already have everything they need that's compatible with your solution. If they don't, per #3, I'd rather have the option of using a framework like Qt to create a port for my simple app connecting to a lightweight backend rather than try to get a port of a modern web browser running.4) No need for your users to install anything. They just use it. Boom.
The problem with browsers is that they try to do everything like that. If you don't use most of it, it's all just bloat that makes your solution more cumbersome than it needs to be. The last thing I want is yet another web site that won't load on a RPi 0W.5) There is a lot of capability in the browser that can be used easily form all the layout options, fonts, images, sound, video, accelerated 3D graphics etc, etc. Much easier than doing that in a typical GUI tool kit.
You seem to be focusing solely on the view layer, whereas I was mainly talking about the model and controller layers. While tiny devices can most certainly serve up a RESTful interface using web APIs, I still say defaulting to that kind of solution is a mistake when a more lightweight protocol might actually more features that are useful to a particular project (e.g., stateful transactions).6) A half decent and complex web interface can be served up by even the smallest devices now a days. No need for them to have screens and all the resources required for them to great a GUI.
If you think that using Node won't result in the same mess as other web stacks, you have quite a MEAN journey of discovery waiting for you! My point remains that there are a lot of other great solutions out there, and it's a real shame that so much of the industry has become focused only on web development. For the OP's simple requirement of "configuration and control of some apps on a Pi", I see no reason to believe that anything layered on top of HTTP is the right solution.Now, I wonder what you mean by "WEB stack"? Traditionally that implied all that weight of Apache, PHP, SQL, etc, etc. All of which is a big complicated mess.
"debatable"? I can demonstrate the truth of all my 6 points above if you like.You give a lot of generic features (all of which are debatable),...
Ha! No. Now you have changed the subject from building a GUI to web stacks, including a database, a web server framework and a particular JS GUI framework. MEAN can also include build systems, packaging systems, language translators, testing frame works, etc. See the whole mess here: http://mean.io/If you think that using Node won't result in the same mess as other web stacks, you have quite a MEAN journey of discovery waiting for you
The problem isn't their "truth", it's that they're one-sided. It's easy to point out only the positive things you see when you argue in favor of something. It's better for everyone to do a more complete analysis before picking a solution.
Again, it's not just about the view layer. There is no such thing as a singular "web interface" GUI. What you have is an HTML resource that transacts with an HTTP server in some fashion. How easy either of those are to create depends greatly on your choice of web stack (or the choice to not use one).1) Yes, creating a GUI in modern GUI builders can be easy too. My experience of these recently is limited to qtcreator and Lazarus and there I would say they are still not as easy as a web interface.
Uh, that's actually the controller layer. Again, the real issue is what really needs to be done. If it can be better accomplished by something other than HTTP, I say it's a good idea to see what other tools are out there to get the job done.6) Yes, I'm focusing on the view layer. How to get those buttons, dialogs, images, etc onto a screen and user input back to an application. Beyond that it's up to you. Making interactions stateful over HTTP is not rocket science.
That's the way the web works these days, though: you have to expend effort to avoid the bloat. You pretty much can't separate "building a GUI" from an underlying web stack unless you plan on coding all your HTML by hand. I eagerly await the alternative "truth" that either you can offer or the OP can develop that doesn't involve a lot of extra libraries to make the web GUI work.Ha! No. Now you have changed the subject from building a GUI to web stacks, including a database, a web server framework and a particular JS GUI framework. MEAN can also include build systems, packaging systems, language translators, testing frame works, etc. See the whole mess here: http://mean.io/If you think that using Node won't result in the same mess as other web stacks, you have quite a MEAN journey of discovery waiting for you
Personally I try to avoid all of that as much as possible. Most of it is not required for small hobby projects. Most of it I loath anyway.
I'm not interested in mindless bullet point lists. I want to solve problems. Other than saying they want a web page, I see nothing in the OP's description that actually requires one or even tips the scales in favor of one. There are many ways to set up the code that models "configuration and control of some apps on a Pi". There are many ways to control them other than a web API. There are many ways to access those controllers other than an HTML interface. My point remains that the root problem still needs to be specified and solved. To jump straight to "use a web GUI" as a default solution is just bad advice.Yes, there are other great solutions out there. Please indicate one that checks all the points of my list of web interface features.
I started by requesting a way of making a web gui that wouldn't suck.droleary wrote: ↑Sun Aug 05, 2018 3:35 pmThere are many ways to set up the code that models "configuration and control of some apps on a Pi". There are many ways to control them other than a web API. There are many ways to access those controllers other than an HTML interface. My point remains that the root problem still needs to be specified and solved. To jump straight to "use a web GUI" as a default solution is just bad advice.
And the answer, HTML + CSS, has been given, but it's useless to spend any time on the view layer until you've figured out a workable solution to the actual problem at hand. Anything can be given a web GUI, to whatever degree of non-suckage you wish, depending on how much work you want to put into it yourself. There are even platforms like Adafruit IO that you could leverage, which offers a web on top of MQTT. What's going to work best for you is pure guesswork until you get more specific on what you want to do.
I'd be surprised if there weren't already a solution to that out there (e.g., have the RPi configured to act as an AP by default so that a user can connect and give it the "real" network settings). If it has a web interface, odds are still pretty good that it's going to be built on a particular web stack, and that's what you're going to need to get working in full despite only a fraction of the code being needed to do the actual network setup. I'm simply advocating for a more lightweight solution, but if that doesn't interest you, so be it.What needs to be controlled? I'm not entirely clear on that, but since the device is a headless Pi 3 the usual initial chicken-and-the-egg network setup step is part of it.
.Uh, that's actually the controller layer.
I do agree. Analyse the problem requirements first. The select a solution. A user interface solution can range from a LED and a push button to a 3D animated data presentation.Again, the real issue is what really needs to be done. If it can be better accomplished by something other than HTTP, I say it's a good idea to see what other tools are out there to get the job done.
I never even implied that. My "notion" is simply that the web should not be the first/default choice when it comes to developing software solutions. That's it.