5 ms·

Genuine question as a rookie developer: I write a lot of internal tools for my company used in manufacturing/fulfillment. We generally deploy these as fleets o

Genuine question as a rookie developer: I write a lot of internal tools for my company used in manufacturing/fulfillment. We generally deploy these as fleets of Raspberry Pis. The front ends for these systems are generally pretty simple, they just walk an operator through what they should be scanning, and for hardware interaction I use a small node server. I serve a React App to these stations (from an internal server) to render this UI. What (modern) alternatives are there for this that do not use web technologies? I've recently grown an affinity for ruby and attempted to rewrite my frontend in Shoes, but the barebones documentation and lack of SO answers made that a huge pain in the ass, not to mention the added steps in deployment of updates. Going any other route just seems like so much more work for no true benefit.

orthecreedence 7y ago
Honestly, if what you're doing works, go for it. Using javascript/html as an internal tool for UI building seems like a fairly decent use-case. You could write your UI in some sort of native toolkit like QT/Gtk/etc but then you're pumping dev cycles into making something that already exists and works fine...for what? If everyone who uses your UIs already has a browser, then you've hit a sweet spot: your client software is already pre-installed on all the machines you need it to be, and the rest is serving HTML/javascript. The alternatives for you are probably pretty time-intensive for you and probably annoying for your users ("hey, install this program/app/etc"). I'd say if you want to rely less on JS and use more server-generated HTML, PHP might be the simplest option for you. People around here shit on PHP, but PHP was "serverless" before it was cool and has a lot of tools to do exactly what you're doing. But again, ask yourself what you gain by switching to another technology.
- pdimitar 7y ago
  PHP is definitely an awful recommendation for a RPi 4 though. There are lighter weighted options that optimise for minimum latency and minimum CPU overhead.
  - orthecreedence 7y ago
    If it's an rpi serving 400 req/s, yeah you're probably right. If we're talking more about maintenance by a handful of people and a few hundred internal users, PHP is fine and an rpi can handle that load just fine. What minimal alternatives would you suggest given the constraints?
    - pdimitar 7y ago
      As mentioned in a sibling comment of mine, there are some alternatives: - Elixir's Nerves: https://nerves-project.org https://nerves-project.org - Golang: + https://github.com/tinygo-org/tinygo https://github.com/tinygo-org/tinygo + https://gobot.io/ https://gobot.io/ + https://github.com/golang/go/wiki/GoArm https://github.com/golang/go/wiki/GoArm - Rust I suppose you can just directly compile for any SoC like the RPi.
karatestomp 7y ago
What do you mean by modern? Does QT not cut it? Tk might even be fine, depending on what you're doing—it runs on anything and is supported by damn near every language, one way or another.
itronitron 7y ago
>> What (modern) alternatives are there for this that do not use web technologies? In that case, Java is probably your best option.
rhinoceraptor 7y ago
There are a ton of options, but probably none of them are worth switching to. Web apps have a ton of advantages: 1. They work on every device: desktops, mobile, tablets, kiosks, etc. 2. To upgrade a client installation, you just need to refresh the page. There's no app signing keys, no special download server, or installation framework. You don't need to worry about installing ruby, python or any other libraries. 3. You have a huge pool of developers, since practically every company has some sort of web app. Also, any problem you run into will already be on Stack Overflow.
pdimitar 7y ago
You can likely look at languages that allow you to burn an entire mini-OS image with their runtime pre-installed on the SD card of the RPi (like Elixir's Nerves framework) or simply use a solid cross-compiled backend language with a fast web frameworks -- Golang and Rust come to mind here. But I agree with some of the posters here. If what you have works well you're much better off just iterating on it and not changing the tech stack.

orthecreedence 7y ago

Honestly, if what you're doing works, go for it. Using javascript/html as an internal tool for UI building seems like a fairly decent use-case. You could write your UI in some sort of native toolkit like QT/Gtk/etc but then you're pumping dev cycles into making something that already exists and works fine...for what? If everyone who uses your UIs already has a browser, then you've hit a sweet spot: your client software is already pre-installed on all the machines you need it to be, and the rest is serving HTML/javascript. The alternatives for you are probably pretty time-intensive for you and probably annoying for your users ("hey, install this program/app/etc"). I'd say if you want to rely less on JS and use more server-generated HTML, PHP might be the simplest option for you. People around here shit on PHP, but PHP was "serverless" before it was cool and has a lot of tools to do exactly what you're doing. But again, ask yourself what you gain by switching to another technology.

pdimitar 7y ago
PHP is definitely an awful recommendation for a RPi 4 though. There are lighter weighted options that optimise for minimum latency and minimum CPU overhead.
- orthecreedence 7y ago
  If it's an rpi serving 400 req/s, yeah you're probably right. If we're talking more about maintenance by a handful of people and a few hundred internal users, PHP is fine and an rpi can handle that load just fine. What minimal alternatives would you suggest given the constraints?
  - pdimitar 7y ago
    As mentioned in a sibling comment of mine, there are some alternatives: - Elixir's Nerves: https://nerves-project.org https://nerves-project.org - Golang: + https://github.com/tinygo-org/tinygo https://github.com/tinygo-org/tinygo + https://gobot.io/ https://gobot.io/ + https://github.com/golang/go/wiki/GoArm https://github.com/golang/go/wiki/GoArm - Rust I suppose you can just directly compile for any SoC like the RPi.

karatestomp 7y ago

What do you mean by modern? Does QT not cut it? Tk might even be fine, depending on what you're doing—it runs on anything and is supported by damn near every language, one way or another.

itronitron 7y ago

>> What (modern) alternatives are there for this that do not use web technologies? In that case, Java is probably your best option.

rhinoceraptor 7y ago

There are a ton of options, but probably none of them are worth switching to. Web apps have a ton of advantages: 1. They work on every device: desktops, mobile, tablets, kiosks, etc. 2. To upgrade a client installation, you just need to refresh the page. There's no app signing keys, no special download server, or installation framework. You don't need to worry about installing ruby, python or any other libraries. 3. You have a huge pool of developers, since practically every company has some sort of web app. Also, any problem you run into will already be on Stack Overflow.

pdimitar 7y ago

You can likely look at languages that allow you to burn an entire mini-OS image with their runtime pre-installed on the SD card of the RPi (like Elixir's Nerves framework) or simply use a solid cross-compiled backend language with a fast web frameworks -- Golang and Rust come to mind here. But I agree with some of the posters here. If what you have works well you're much better off just iterating on it and not changing the tech stack.