On the one hand, there is the physical world. Temperature, vibration, pressure sensors. Arduino and ESP32 microcontrollers that take readings 24/7. COM ports through which bytes of data flow. Wires, soldering iron, oscilloscope. It’s a world of signals, noise, and real-world measurements.

On the other hand, there’s the digital world. Real-time graphs, databases, cloud services, web interfaces. It’s a world of visualization, analysis, and decision-making.

For a long time, these worlds were separated.

Engineers who knew how to work with hardware often stopped at the console or Excel. Web developers were creating beautiful interfaces, but they couldn’t get data from the sensor. Python scripts analyzed data, but did not have a convenient GUI for colleagues.

But what if there was a bridge?

A bridge that allows you to receive data from the Arduino via the COM port and immediately display it on a beautiful graph in the application window? A bridge that allows you to turn a Python script into a full-fledged program with buttons and menus that can be sent to a colleague as a single file? A bridge that allows you to receive data from ESP32 from anywhere in the world via the cloud?

This bridge was built. And it has some powerful supports: Python Eel, Electron, and Neutralino.

This book is your guide to this bridge.

Why this book? And who is it for?

When I first started building tools for my lab, I was faced with a paradox. There was a lot of information, but it was scattered. Web development tutorials didn’t talk about COM ports. Examples for the Arduino ended with “flashing LEDs” and simple interaction with sensors. I had to use trial and error, spending a lot of time, to gather an understanding bit by bit: how to make sure that the button in the interface actually turns on the relay?

I wrote this book to save you that time and get rid of those mistakes.

This book is for you:

Table 1. This book is for you

Experimental Engineer — A quick way to create a control panel for your installation without learning a complicated GUI

Technical Student — Graduation project with real hardware and a modern interface

Researcher/Laboratory Technician — A tool to collect data without depending on the IT department

Python Developer — The ability to “screw” a convenient frontend to your scripts for the evening

Our philosophy: from simple to complex

The internet is full of holy wars on the holiwar theme of “Which framework is best?”. This book does not participate in them. Our main goal is to give you the tool to solve the problem.

We will follow the path of gradual complication:

— Part 1: Understand why you need your own app at all.

— Part 2: Master Python Eel — The Easiest Way for an Engineer

— Part 3: Connect the Arduino and learn how to work with COM ports.

— Part 4: Go IoT — Get ESP32 data from the cloud via MQTT.

— Part 5: Look at alternatives and learn how to package apps for colleagues.

Unique Feature: Emulation Mode

One of the main problems of engineering software is dependence on hardware. What to do if the Arduino is not at hand? Or is it in another laboratory?

In this book, you’ll learn how to implement an emulation mode (DEBUG_MODE). You’ll be able to test the interface and logic of your application by generating plausible data programmatically. This will speed up development by 3—5 times and allow you to demonstrate your application to the customer without having to bring the installation with you.

What awaits you inside?

Each chapter is a ready-made solution that can be copied and adapted:

— Emulation mode — test code without Arduino/ESP32

— Real-Time Charts — Chart. js + Python

— Working with COM ports — pyserial, error handling

— IoT monitoring — MQTT, HiveMQ Cloud, GitHub Pages

— Packaging in. exe — PyInstaller, one file for colleagues

The source code for all the apps mentioned in the article is available in an open repository on GitHub:

https://github.com/Book-From-the-sensor-to-the-interface/sketch_for_book.git

Technology is more than just tools. These are capability extenders. They blur the boundaries between “hardware” and “program”. As an author, my job is not just to teach you how to use the three frameworks, but to give you the freedom to create tools that make your engineering work easier.

Ready to blur the boundaries between sensor and interface? Then let’s start our journey.

Best regards,

Ivan Galut.

Part 1. Introduction to Software Engineering

Why does an engineer need his own application?

What is this chapter about?

You’ve probably heard the phrase,“Why write an app when you have Excel or Serial Monitor?”

Sometimes it sounds like the truth. But in practice, ready-made tools are often not suitable for the specific tasks of the laboratory or production.

In this chapter, we’ll look at four key reasons why an engineer should write his own software:

— Productivity (routine automation)

— Access to equipment (COM ports, GPIOs, sensors)

— Autonomous operation (without internet, in the workshop, in the field)

— Visualization and control (real-time graphs, control buttons)

You’ll see why tasks like “thermocouple data collection” or “motor vibration monitoring” are better solved by your own app than by universal tools.

1.1. Excel and the console are not a panacea

Imagine: you are conducting a series of experiments. You need to take readings from the sensor every 100 ms, save them to a file and immediately see the graph to understand whether the parameter has gone beyond the permissible limits.

In Excel:

— No direct access to the COM port (macros or plugins required).

— Real-time data updates slow down on large volumes.

— You cannot send the “Turn on heating” command back to the device.

In Serial Monitor (Arduino IDE):

— Only text, no graphs.

— No saving data in a convenient format (CSV/JSON).

— You cannot create control buttons.

And in your own application, all this is possible. And it is even necessary.

1.2. Reason No1: Access to equipment

Web applications (in the browser) run in a sandbox. They don’t know where the file is on the drive, they don’t see USB devices (without complex APIs).

Engineering desktop application:

— Reads data from the COM port directly (via Python pyserial).

— Works with local databases (SQLite) without limitations.

— Controls relays, motors, power supplies through the interface.

Example: An application for calibrating pressure sensors. It has to poll 10 sensors one by one, compare the readings with the reference and write the coefficients to the device’s memory..

1.3. Reason No2: Real-Time Visualization

An engineer thinks in graphs. A table of 1000 numbers will not say anything about the trend.

Modern web technologies (Chart. js, Plotly) allow you to build beautiful, interactive graphs right inside the desktop application.

Advantages of your UI:

— Instant response: The graph is updated as data becomes available.

— Interactivity: You can select an area, zoom in, save a screenshot.

— Alarm: Color changes to red if the value has exceeded the threshold.

1.4. Reason No3: Autonomous Operation

The Internet is not always reliable. Workshop, basement, field conditions… Often there is no network at all.

The web service depends on the connection. Desktop application:

— Works completely locally.

— Stores data on the device.

— Syncs them to the cloud only when the network is available (if necessary).

Example: Engine vibration monitoring system at a remote pumping station. The application writes data to a local file 24/7. Once a day, when there is a connection, it sends a report to the server.

1.5. Reason No4: Productivity and Automation

Routine eats up time. If you run a test on the same scenario every day, automate it.

Your app allows you to:

— Record the test script (heat to 50°C, wait 5 minutes, take readings).

— Start it with one button.

— Immediately receive a ready-made report (PDF/Excel).

1.6. When is your app redundant?

Honesty is important. You don’t always need to write software.

Use ready-made tools if:

— You just need to take readings once (a multimeter + notebook will do).

— The task is one-time (you should not spend 2 days on the code).

— There is ready-made industrial software (for example, LabVIEW), which has already been purchased and configured.

But if your product is a tool for daily work, your app often provides better UX and time savings in the long run.

1.7. What have we learned?

— Off-the-shelf tools (Excel, Serial Monitor) are often limited for engineering tasks.

— The key advantages of your software are access to hardware, visualization, autonomy, automation.

— Modern frameworks (Eel, Electron) allow you to use web technologies to create a user-friendly UI.

— The choice between “write yourself” and “take ready-made” is a matter of frequency of use and complexity of the task.

Practical task

— Think about the three tools or processes you use in your work (e.g., oscilloscope data collection, test logging, heater control).

— For each, answer:

2.a. Does it have automation?

2.b. Which functions take the most manual time?

2.c. Which of the four reasons (access, visualization, autonomy, automation) could improve this process?

— Imagine you’re building an application for one of these processes.

3.a Write 2—3 sentences: What is the main problem your app will solve?

Example: “I’m building a panel to test temperature sensors. Now I record the readings manually in the logbook. The application will allow you to automatically collect data from 4 sensors at the same time, build a graph and save a report in CSV. This will save 30 minutes on each test.”.

In the next chapter, we’ll compare traditional GUI approaches (Tkinter, PyQt) with modern web wrappers so that you understand the trade-offs and choose the right tool.

Architectures Overview: Traditional GUIs (Tkinter, PyQt) vs WEB Wrappers

What is this chapter about?

You have already understood why an engineer needs his own application. Now the main question arises: “What to write in?”

If you know Python, it seems logical to use standard libraries for interfaces. But there is a nuance: an engineer needs not just buttons, but graphs, logs, and convenient layout.

In this chapter, we will compare two approaches:

— Traditional GUIs (Tkinter, PyQt) are classics of Python development.

— Web wrappers (Eel, Electron) are a modern hybrid of Python + HTML/CSS.

— Architectural trade-offs — what you gain and what you lose in each case.

— Why web technologies often win for engineering problems.

You’ll see why we’re focusing on Python + Web in this book, and when to choose the good old Tkinter.

2.1. The Classic Path: Tkinter and PyQt

When a Python developer hears “I need an interface”, the first thought is Tkinter. It’s built into Python, doesn’t require installation, and works out of the box.

Example of Tkinter:

import tkinter as tk

def on_click ():

label.config (text=“Data received!”)

root = tk.Tk ()

label = tk.Label (root, text=“Waiting…”)

label.pack ()

btn = tk. Button (root, text=“Request”, command=on_click)

btn.pack ()

root.mainloop ()

Pros of traditional GUIs:

— Native: The app looks like part of the OS (especially PyQt).

— Lightweight: Tkinter does not drag the browser with it and weighs kilobytes.

— No server: No need to set up a local web server, everything works in one process.

Cons for an engineer:

— Visualization: It is difficult to build a beautiful interactive graph in Tkinter (you need matplotlib, which is heavy and not always interactive).

— Layout: Aligning elements (“grid”) in Tkinter often turns into a pain. It is difficult to make an adaptive interface for different screens.

— PyQt entry threshold: PyQt is more powerful, but it has a complex syntax (signals/slots) and requires learning the Qt framework.

Engineering Verdict: Tkinter is suitable for a simple “on/off button”. But if you need to display charts in real time, logs, and dashboards, you will spend more time fighting the interface than on the logic of working with hardware.

2.2. The Modern Way: Web Wrappers (Hybrid Apps)

The idea is simple: logic in Python, interface in the browser.

You write the backend in Python (working with COM ports, calculations), and the frontend in HTML/CSS/JS (buttons, graphs, Chart. js). A special shell (Eel, Electron) connects them.

Example of an Eel architecture:

# Python (backend)

import eel

eel.init (‘web’)

@eel. expose

def get_sensor_data ():

return 42.5 # Read from the port

eel.start('index.html’)

<! — HTML/JS (frontend) — >

async function update () {

let val = await eel.get_sensor_data () ();

document.getElementById('value').innerText = val;

}

</script>

Pros of web wrappers:

— Visualization: Libraries like Chart. js or Plotly allow you to build stunning graphs with a few lines of code.

— Layout: CSS gives you full control over the design. It’s easy to make a dark theme, adaptable for tablets.

— Division of responsibility: The engineer writes Python, the designer (or a ready-made template) is responsible for the beauty.

Cons:

— Weight: Even a simple application pulls the browser engine along (although Eel uses the system browser, which is lighter).

— Difficulty: You need to know the basics of HTML/JS (but for an engineer, this is the level of “copy and change numbers”).

Important: In this book, we use Eel because it is as easy as possible for a Python developer. Electron is more powerful, but requires knowledge Node. js, which is redundant for laboratory tasks.

2.3. Comparison Table: What should an engineer choose?

Let’s look at the numbers and facts. Let’s imagine that we create a temperature dashboard with a graph.

Comparison table: what should an engineer choose?

Difficulty of the start

Tkinter / PyQt: 3/5 (average)

Web wrappers (Eel): 5/5 (very low)

Comment: Eel is easier for a beginner in GUI

The beauty of the interface

Tkinter / PyQt: 2/5 (legacy view)

Web wrappers (Eel): 5/5 (modern web)

Comment: Web looks fresher

Charts

Tkinter / PyQt: 2/5 (Matplotlib)

Web wrappers (Eel): 5/5 (Chart. js, Plotly)

Comment: Web charts are more interactive

App weight

Tkinter / PyQt: 5/5 (easy)

Web wrappers (Eel): 3/5 (medium)

Comment: Tkinter wins on size

Working with COM

Tkinter / PyQt: 5/5 (straight)

Web wrappers (Eel): 5/5 (straight through Python)

Comment: There is parity here

Training

Tkinter / PyQt: You need to learn the GUI framework

Web wrappers (Eel): It is enough to know the basics of HTML

Comment: Many students know HTML

Conclusion. If your goal is to quickly make a convenient tool for yourself and your colleagues, web wrappers benefit from ready-made visualization libraries

2.4. Why are we choosing Eel for this book?

In the first book, we looked at Electron, NW. js and Eel as equals. But there are nuances for engineering tasks:

— Python is an engineer’s language. Most of the scripts for Arduino, data processing, and calculations are already written in Python. Eel allows you to use them without rewriting.

— Electron is redundant. It requires Node. js and assembles its browser. For the engine control panel, it’s like shooting a cannon at sparrows.

— Eel is a bridge. It doesn’t require a deep dive into web development. You call Python functions from JS as easily as you do from another Python module.

Our philosophy: Don’t become a web developer. Use web technologies as a tool to display data, leaving Python to work with hardware.

2.5. When should I choose Tkinter?

Honesty is more important than fashion. There are cases when web wrappers are not suitable:

— Ultra-light utilities. If you just need a window with a single input field, which should weigh 5 MB.

— Work on old PCs. Sometimes there are computers with 2 GB of memory in the workshops. Launching the browser can be problematic.

— Complete isolation. If the security policy prohibits the launch of any browser engines (rarely, but it happens).

But for 90% of the tasks of a modern laboratory, a hybrid approach (Python + Web) is the gold standard.

What did we learn?

— Traditional GUIs (Tkinter) are lightweight, but difficult to layout and render.

— Web wrappers provide a modern interface and powerful graphics out of the box.

— Eel is ideal for engineers: the logic is in Python, the interface is in HTML.

— The choice of tool depends on the task: for dashboards — the web, for micro-utilities — Tkinter.

— In this book, we focus on Eel as the most balanced tool.

Practical task

— Find screenshots of interfaces on Tkinter and web technologies (for example, Grafana dashboards or any web applications) on the Internet.

— Compare them visually:

— 2.a. Where is it easier to read data?

— 2.b. Where do graphs look more modern?

— Think about your current project (from Chapter 1):

— If you were to do it on Tkinter, how long would it take to build the chart?

— If on Eel, how long will it take to connect Chart. js?

— Write a short conclusion (2—3 sentences): why is a hybrid approach suitable for your task?

Example: “To monitor vibration, I need 4 real-time graphs. On Tkinter, I’d spend a week setting up matplotlib. On Eel, I will take a ready-made template Chart. js in 1 hour. I choose Eel.”

In the next chapter, we’ll take a closer look at the tools: Python Eel, Electron, and Neutralino. We will analyze their philosophy and understand why Eel will become our main working tool.

Introduction to Tools: Python Eel, Electron, Neutralino. Their Philosophy and Application in Engineering

What is this chapter about?

You already understand why an engineer needs his own application and why web technologies in a shell are the right choice.

Now it’s time to get acquainted with the three main tools of this book:

— Python Eel is a minimalistic bridge for Python developers.

— Electron is the industry standard for complex products.

— Neutralino is a lightweight, modern alternative without Node. js.

In this chapter, you will learn:

What problem each of them solves in an engineering context.

What is the philosophy behind each framework.

Who is their target audience — and why you’re among them.

What are the strengths and weaknesses of each for the tasks of the laboratory.

This chapter will help you not just “choose a framework”, but understand which language to use.

3.1. Python Eel: “My Script Deserves an Interface”

History and philosophy

Eel was born in 2017 from a simple idea:

“Why not use HTML/CSS/JS for the frontend, and leave all the logic in Python?”

Unlike Electron and Neutralino, Eel doesn’t embed a browser. Instead, it:

— Runs a local Python web server (via bottle or gevent-websocket).

— Opens the system browser window (Chrome, Edge, Safari).

— Connects Python and JavaScript via HTTP/WebSocket.

Eel’s philosophy:

Not to become a web developer. Use web technologies as a tool to display data, leaving Python to work with hardware.

Target audience

Table 2. Target audience

Experimental Engineer — Your logic is already in Python (pyserial, pandas, numpy)

Researcher/Laboratory Technician — Need a GUI in an evening, without learning Node. js

Technical Student — Graduation project with real hardware and

modern UI

Data Scientist — Visualize model results in an application window

Strengths for Engineers

— A very simple start: 10 lines of Python +10 lines of HTML = finished application.

— Full access to the Python ecosystem: pyserial, pandas, numpy, scikit-learn, opencv — everything works out of the box.

— Minimum entry threshold: You don’t need to know JavaScript in depth — basic function calls are enough.

— Ideal for scripts with GUI: Control panels, data collection, visualization.

Weaknesses

— No built-in access to native OS APIs: No menus, trays, out-of-the-box notifications (additional libraries like pystray are required).

— Limited UI features: Complex interfaces (drag-and-drop, animations) are more complex than in Electron.

— Call performance: Every Python JS call goes through HTTP/WebSocket (not critical for 95% of tasks).

— Build in. exe: Requires PyInstaller, which can be cumbersome with large dependencies.

Case Study: Arduino Dashboard

Here’s what a typical Eel app for an engineer looks like (from your projects):

# main.py

import eel

import serial

import threading

DEBUG_MODE = True # Emulation of real hardware!

eel.init (‘www’)

@eel. expose

def get_ports ():

ports = serial.tools.list_ports.comports ()

result = [port.device for port in ports]

if DEBUG_MODE:

result. append (“EMULATOR”)

return result

@eel. expose

def connect (port):

if DEBUG_MODE and port == “EMULATOR”:

threading.Thread (target=emulate_data, daemon=True).start ()

return {“status”: “success”}

# real connection to the COM port…

eel.start('index.html’, size= (800, 600))

<! — www/index.html — >

async function update () {

let data = await eel.get_sensor_data () ();

// Updating the graph in Chart. js

}

</script>

What this gives the Engineer:

— Emulation mode — test code without Arduino

— Real-Time Charts — Chart. js + Python

— Packaging in. exe — PyInstaller, one file for colleagues

Important: In this book, we rely on Eel as the main tool, because it is as close as possible to the thinking of an engineer: Python for logic, HTML for beauty.

3.2. Electron: “Web Application as a Desktop Product”

History and philosophy

Electron was developed in 2013 at GitHub as an internal tool for the Atom editor. The idea was simple:

“Why not use the same technologies you use for the web to build desktop apps?”

Electron philosophy:

A clear division of responsibilities: the Main process (Node. js) manages the OS, the Renderer process (Chromium) is responsible for the UI.

This makes the architecture predictable, scalable, and secure.

Target audience

Table 3. Target audience

Web Developer — You know JavaScript/TypeScript, React, Vue

Product Team — Build a complex tool with a long-term

See

Engineer with an IoT project — Need a complex UI + cloud sync

Strengths

— Mature ecosystem: electron-builder, DevTools, TypeScript support.

— Clear architecture with process isolation.

— Huge community and documentation.

— Full access to the OS API: menus, trays, notifications, dialogs — everything out of the box.

— Support for all modern web frameworks: React, Vue, Svelte.

Weaknesses for engineers

— High memory consumption: Each window is a separate Chromium process (~150 MB minimum).

— Large distribution size: Minimum ~50—70 MB even for “Hello World”.

— Difficulty for beginners: You need to understand IPC, preload, sandbox.

— Requires knowledge Node. js: If your logic is in Python, you will have to build a Flask server separately.

Case Study: Electron + Python (Flask)

When it is justified:

— You need a very complex UI (editors, dashboards with dozens of charts).

— Scaling is planned (development team, versions, updates).

— Native integration (tray, menu, autoplay) is required.

For most engineering tasks, this is redundant. Electron is like shooting sparrows from a cannon if you just need to read data from the sensor.

3.3. Neutralino: “Light and Modern”

History and philosophy

Neutralino is the youngest of the three (appeared in 2020). Its mission:

“Build lightweight, cross-platform applications without relying on Node. js and heavy browser engines.”

Neutralino philosophy:

Use the system WebView (like Eel), but with a native API and no Node. js.

Target audience

Table 4. Target audience

Engineer with constraints — The app must be <20 MB in size

Utility Developer — Need a lightweight tool for colleagues

IoT — enthusiast — Planning to run on low-end devices

Strengths

— Very lightweight: Distribution ~2—5 MB (10—20 times smaller than Electron!).

— No Node. js required: Fewer dependencies, easier to build.

— System WebView: Uses Edge WebView2 (Windows), WebKit (macOS), GTK (Linux).

— Native API: Access to the file system, dialogs, tray — without additional libraries.

— Security: Sandbox by default, no Node. js in context.

Weaknesses

— Young Community: Fewer examples, less documentation, fewer ready-made solutions.

— Limited API: Not everything in Electron is available out of the box.

— Requires knowledge of JavaScript: Logic is written in JS, Python is connected separately.

— Fewer debugging tools: DevTools are there, but not as powerful as Electron.

Case Study: Lightweight Sensor Monitor

// main. js (Neutralino)

Neutralino.filesystem. writeFile (‘data. csv’, sensorData);

Neutralino.os.showMessageBox (“Data saved!”, ‘info’);

When it is justified:

— It is necessary to distribute among colleagues (small size).

— Running on weak computers (workshop, laboratory with old fleet).

— Simple UI (buttons, graphs, logs) without complex animations.

3.4. Comparison at a glance

Table 5. Comparison at a glance

Primary Language

Python Eel: Python

Electron: JavaScript/TypeScript

Neutralino: JavaScript

Architecture

Python Eel: Local server + browser

Electron: Chromium + Node. js

Neutralino: System WebView

Distribution size

Python Eel: ~30–60 MB*

Electron: ~50–150 MB

Neutralino: ~2–5 MB

RAM consumption

Python Eel: 80–150 MB

Electron: 120–200 MB

Neutralino: 50–100 MB

Difficulty of the start

Python Eel: (Very low)

Electron: (Medium)

Neutralino: (Low)

Access to the OS API

Python Eel: Restricted (via Python)

Electron: Complete

Neutralino: Full (native)

Ecosystem Python

Python Eel: Complete

Electron: Via Flask/HTTP

Neutralino: Via HTTP/CLI

Ideal scenario

Python Eel: Script with GUI, Data Science

Electron: Complex product, team

Neutralino: Lightweight Utility

* The size of Eel is highly dependent on Python dependencies: pandas + numpy +50 MB, torch +500 MB.

3.5. When to choose what?

Engineering checklist

Choose Python Eel if:

— Your logic is already in Python (pyserial, pandas, numpy).

— The UI is simple: buttons, graphs, tables, logs.

— Users are technical specialists (colleagues, laboratory assistants).

— You need it quickly: a prototype in an evening, a diploma in a week.

— There are no requirements for native menus/trays.

It is the choice for 80% of engineering tasks.

Choose Electron if:

— You need a very complex UI (editors, IDEs, dashboards).

— A development team and long-term support are planned.

— Native integration is critical (tray, menu, notifications, autoplay).

— Users are the mass market (public product).

— You know JavaScript better than Python.

Choose Neutralino if:

— The size of the distribution is critical (<20 MB).

— Running on weak computers (old PCs on the shop floor, in production).

— Simple UI, but native integration (dialogs, files) is needed.

— You want to avoid dependence on Node. js.

— We are ready to put up with a young community.

3.6. Our Philosophy for This Book

In the first book, we considered Electron, NW. js and Eel on an equal footing. But there are nuances for engineering problems:

Table 6. Our Philosophy for This Book

Main focus

The first book: Electron (Industry Standard)

This book: Python Eel (engineer language)

Target audience

The first book: Web Developers

This book: Engineers, researchers, students

Working with hardware

The first book: Mentioned

This book: Central Theme (COM, MQTT, Arduino)

NW. js

The first book: Discussed in detail

This book: Excluded (inferior to Neutralino)

IoT

The first book: Not considered

This book: ESP32 + MQTT + Cloud

Our philosophy: Don’t become a web developer. Use web technologies as a tool to display data, leaving Python to work with hardware.

3.7. Real-World Example: From Arduino to Cloud

In this book, we will follow the path of gradual complication:

Table 7. Real-World Example: From Arduino to Cloud

Part 2

Project: Engineer’s Calculator

Technology: Eel + HTML/JS

Who is it for?: Newcomers

Part 3

Project: Arduino Monitoring

Technology: Eel + pyserial + Chart. js

Who is it for?: Engineers with iron

Part 3

Project: Emulator without an Arduino

Technology: DEBUG_MODE + random

Who is it for?: All (tests/demos)

Part 4

Project: ESP32 IoT Monitoring

Technology: MQTT + HiveMQ + GitHub Pages

Who is it for?: Advanced

Part 5

Project: Electron + Flask

Technology: Electron + Python backend

Who is it for?: For complex UIs

Why such an order?

— Eel first, because it’s the fastest way for an engineer to get results.

— Then there are COM ports, because this is the main task of laboratory applications.

— Then IoT — because ESP32 opens up the world of remote monitoring.

— In the end, Electron is an alternative for those who need more features.

What did we learn?

— Eel is the choice for Python developers who need a GUI without diving into JavaScript.

— Electron is the choice for products where scalability, security, and team are important.

— Neutralino is the choice for lightweight utilities with a minimal distribution size.

— None of them is “better” — each solves its own problem.

— For engineering tasks, Eel is often optimal because Python is already an engineer’s language.

Practical task

— Imagine three different projects:

— A) A panel for collecting data from 4 temperature sensors (COM port, graphs, saving to CSV).

— B) Web dashboard for monitoring equipment on the shop floor (access from a browser, users throughout the country).

— C) An easy utility for calibrating the device (weight <20 MB, running on an old PC in the laboratory).

— For each project:

— 2.a. Choose one of the three frameworks.

— 2.b. Justify the choice with two reasons (for example: “Eel, because the basic logic in Python and UI is simple”).

— Think about it: is it possible to solve the same problem on another framework?

— What difficulties would arise?

Sample answer:

— A) Eel — logic in Python (pyserial), UI is simple (graphs Chart. js), users are laboratory assistants.

— B) Electron + Flask — you need access from a browser, complex authorization, mass users.

— C) Neutralino — Critical size, running on an old PC, simple UI.

In the next chapter, we’ll organize everything we’ve learned and give you a clear algorithm for choosing: “When to use Eel, Electron, or Neutralino?” — with a table, examples and control questions.

Selection criteria: when to use which framework?

What is this chapter about?

You have already become familiar with three approaches:

— Python Eel is for engineers living in the Python ecosystem.

— Electron — for complex products with a powerful UI.

— Neutralino is for lightweight utilities without unnecessary dependencies.

Now it is time to move from theory to solution. In this chapter, you will learn:

How to choose a framework based on the real requirements of the project (hardware, data, users).

What are the five key questions to ask yourself before the start?

How to compare frameworks objectively — not by hype, but by numbers and constraints (size, COM ports, complexity).

By the end of the chapter, you will have a personal solution map that you can use in future projects.

4.1. Five Questions Before Choosing

Before you write code, answer these questions. Honest answers will save you weeks of work.

1. In what language is the basic logic written?

— Python? Most likely, Eel.

— Why: pyserial, pandas, numpy are already at your fingertips. No need to rewrite algorithms in JavaScript.

— JavaScript/TypeScript? Electron or Neutralino.

— Why: If your logic is already in JS (for example, a web dashboard), there is no point in setting up a Python server.

2. How complex is the user interface?

— Simple forms, buttons, graphs? Eel is perfect.

— Example: Arduino control panel, temperature monitoring.

— Complex animations, drag-and-drop, code editors? Electron.

— Example: IDE, a complex schematic designer.

— Minimalism, standard elements? Neutralino.

3. Do I need access to native OS features?

— COM ports, GPIOs, files? Eel (via Python) or Electron (via Node. js).

— Nuance: In Eel, this is a single serial string. Serial (). In Electron, you can install npm packages and configure preload.

— Trey, system notifications, menus? Electron (built-in).

— Nuance: In Eel, you will need additional libraries (pystray), in Neutralino — a native API.

4. Who is your user?

— Colleagues in the office / Laboratory assistants? Eel or Neutralino.

— Why: You can collect one. exe and forget it.

— Millions of users (public product)? Electron.

— Why: You need auto-updates, code signature, tamper-proofing, and a beautiful installer.

5. What are the size and performance requirements?

— Does the installation have to be <20 MB? Neutralino.

— Why: Electron weighs ~150 MB even for “Hello World”. Eel is library-dependent (pandas + numpy = +100 MB).

— Is> 300 MB memory critical? Avoid Electron for simple tasks.

— Why: Each Electron process is a separate Chromium.

4.2. Comparison Table: Objective Metrics

Let’s look at the numbers. Let’s imagine that we’re creating a sensor dashboard with a real-time graph.

Table 8. Comparison Table: Objective Metrics

Backend language

Python Eel: Python 3.7+

Electron: JavaScript/Node. js

Neutralino: JavaScript

Comments for Engineer: Eel wins if the logic is in Python

COM Port Access

Python Eel: Direct (pyserial)

Electron: Through serialport (npm)

Neutralino: Through a plugin or backend

Comments for Engineer: Eel is simpler: import serial and everything works

Min. Distribution Size

Python Eel: ~30–60 MB*

Electron: ~150 MB

Neutralino: ~5–10 MB

Comments for Engineer: *Depends on Python libraries

RAM consumption

Python Eel: 80–150 MB

Electron: 150–250 MB

Neutralino: 40–80 MB

Comments for Engineer: Neutralino is the lightest

Difficulty of the start

Python Eel: (Very low)

Electron: (Medium)

Neutralino: (Low)

Comments for Engineer: Eel only requires pip install

Charts (Chart. js)

Python Eel: Works out of the box

Electron: Works out of the box

Neutralino: Works out of the box

Comments for Engineer: Parity: Everyone uses web rendering

Emulation mode

Python Eel: Easy (Python code)

Electron: Requires mocks in JS

Neutralino: Requires mocks in JS

Comments for Engineer: In Eel, you can include DEBUG_MODE a single variable

IoT (MQTT)

Python Eel: paho-mqtt (Python)

Electron: mqtt. js (Node. js)

Neutralino: mqtt. js (JS)

Comments for Engineer: Eel is more convenient if data processing is in Python

Packaging (.exe)

Python Eel: PyInstaller (simple)

Electron: electron-builder (More difficult)

Neutralino: neu CLI (Simple)

Comments for Engineer: Eel is more familiar to a Python developer

Important: The size of Eel is highly dependent on Python dependencies. A clean script is 30 MB. With pandas + numpy, it can grow to 150 MB.

4.3. Selection algorithm: step-by-step instructions

Text version of the algorithm:

— Step 1: Is your logic in Python?

— Yes Go to Step 2.

— No Look towards Electron or Neutralino.

— Step 2: Do I need a complex UI (animations, editors)?

— None (buttons, graphs, logs) Python Eel.

— Yes Electron (with a Python backend via Flask/SocketIO).

— Step 3: Is the size of the app (<20 MB) critical?

— Yes, Neutralino (but you will have to write logic in JS or build a Python server separately).

— No Stay on Eel.

— Step 4: Do I need to work with COM ports?

— Yes, Eel will give the simplest solution (pyserial).

Remember: you can always combine approaches. For example, heavy computing is in Python (via subprocess from Electron), UI is in React.

4.4. When is NONE of the three suitable?

Sometimes the correct answer is not to use any of them. This is normal!

Consider alternatives if:

— The app must be less than 5 MB Look towards Tauri (Rust + WebView).

— Plus: Very lightweight, safe.

— Con: Requires knowledge of Rust for the backend.

— Requires maximum performance (video, 3D) Native development (C++, C#, Qt).

— Pro: Full control over the hardware.

— Minus: High entry threshold, long to write.

— You make the mobile app Electron/Eel/Neutralino not working on iOS/Android.

— Solution: Flutter, React Native or Kivy (Python).

Note: Tauri is a decent competitor to Electron with a distribution size of ~3—5 MB, but it requires knowledge of Rust. We don’t include it in the main triad, as our goal is Python and web technologies for engineers.

4.5. Frequent traps beginners

Table 9. Frequent traps beginners

Choosing Electron for a simple “COM port reader”

Consequence: A user downloads 150 MB for a single button

How to avoid: Ask, “Do we really need Electron?”

Expect a native menu from Eel out of the box

Consequence: Frustration, search for non-existent features

How to avoid: Know the limits: Eel is not a replacement for Electron

Use time.sleep () on the main Eel thread

Consequence: Interface hangs when reading data

How to avoid: Use threading or asyncio

Build an Eel application without a virtual environment

Consequence: Conflicts of libraries, huge sizes

How to avoid: Always use venv before PyInstaller

Forget about emulation mode (DEBUG_MODE)

Consequence: Impossibility of tests without iron

How to avoid: Implement emulation from day one

4.6. Our Picks for This Book

In the first book, we looked at Electron, NW. js and Eel on an equal footing. But there are nuances for engineering problems:

Table 10. Our Picks for This Book

Main focus

The first book: Electron (industry standard)

This book: Python Eel (the engineer’s language)

Target audience

The first book: Web developers

This book: Engineers, researchers, students

Working with hardware

The first book: Mentioned

This book: Central Theme (COM, MQTT, Arduino)

NW. js

The first book: Discussed in detail

This book: Excluded (inferior to Neutralino/Eel)

IoT

The first book: Not considered

This book: ESP32 + MQTT + Cloud

Our philosophy: Don’t become a web developer. Use web technologies as a tool to display data, leaving Python to work with hardware.

What did we learn?

— Choosing a framework is all about analyzing requirements, not following a trend.

— The backend language is the main filter: Python Eel, JS Electron/Neutralino.

— Eel is optimal for engineering tasks (COM ports, data, Python libraries).

— Electron is needed for complex products with a mass user.

— Neutralino is the choice for lightweight utilities with a size limit.

— Always ask yourself five key questions before starting.

Practical task

— Describe your actual or hypothetical project (1—2 sentences).

— Example: “A tool for analyzing server logs with graphs and filtering”.

— Go through the selection algorithm from section 4.3.

— Fill in the table:

Table 11. Our Picks for This Book

Backend language

Your answer:?

Suitable framework:?

UI Complexity

Your answer:?

Suitable framework:?

Do I need native APIs? (COM, files)

Your answer:?

Suitable framework:?

Target audience

Your answer:?

Suitable framework:?

Size restrictions?

Your answer:?

Suitable framework:?

— Conclude: why is this framework the best choice?

Example of filling:

— Project: “Heater control panel via Arduino”.

— Backend: Python (pyserial, threading).

— UI: Temperature Graphs, On/Off Buttons

— API: COM port is required.

— Conclusion: Eel is ideal because it allows you to use the full power of Python to work with the port and quickly make a GUI in HTML/Chart. js. Electron is redundant, Neutralino will require an extra Python communication setup.

Now you are ready for the practical part of the book.

In Part 2, we’ll dive deeper into Python Eel, from installation to building your first graphing application.

In Part 3, we will connect the Arduino and learn how to work with COM ports.

In Part 4, we’ll go IoT with ESP32 and MQTT.

The choice is made — it’s time to write code!

Part 2. Python Eel — An Engineer’s Essential Tool

Quick Start with Eel. Installation, Project Structure, First Launch

What is this chapter about?

You’ve chosen Python Eel, which is a great solution for an engineer who wants to quickly create an interface for their script.

Now it’s time to move from theory to practice. In this chapter, you’ll be able to:

— Install Eel and check for functionality.

— Create a project structure “right” from day one.

— Write your first app in 10 minutes.

— Launch it and see the result in the browser window.

— You’ll understand how Python and JavaScript “talk” to each other.

By the end of the chapter, you will have a working application that you can develop further — add graphs, buttons, work with COM ports.

5.1. Why Eel? Quick Start Philosophy

Before writing the code, let’s answer the question: why Eel?

Table 12. Before writing the code, let’s answer the question…

Tkinter

Time to First Window: 15 minutes

Entry threshold: Medium

Ideal for: Simple utilities

PyQt

Time to First Window: 1–2 hours

Entry threshold: High

Ideal for: Complex Commercial Products

Electron

Time to First Window: 2–3 hours

Entry threshold: High (needs Node. js)

Ideal for: Web Developers

Python Eel

Time to First Window: 10 minutes

Entry threshold: Very low

Ideal for: Engineers, Data Science, Automation

Our philosophy: An engineer doesn’t need to become a web developer. He needs to quickly wrap his Python script in a user-friendly interface. Eel does just that.

The Eel is a bridge, not a replacement.

— Python remains for logic: calculations, COM ports, files, data.

— HTML/CSS/JS remain for beauty: buttons, graphics, layout.

— Eel connects them with two simple function calls.

5.2. Installing Eel: Step-by-Step

Eel is installed through the standard Python package manager pip.

Step 1. Validate Python

Important: If you have multiple versions of Python, use py -3 — version (Windows) or python3 — version (macOS/Linux).

Step 2. Create a virtual environment (recommended)

It’s a good practice to isolate project dependencies:

Why is this necessary? When you package the application in. exe (Chapter 8), PyInstaller will only collect the libraries that are installed in the virtual environment. This will reduce the size of the distribution and avoid conflicts.

Step 3. Installing Eel

Step 4. Verify the installation

If there are no errors, the installation is successful!

5.3. Project structure: Right from day one

One of the main mistakes beginners make is to lump all files into one pile.

Key rule: All HTML/CSS/JS files must be in the folder that you specify in eel.init (). By default, this is the www folder.

Why such a structure?

Table 13. Why such a structure?

www/ — Eel is looking for an interface here. Single folder = order.

main.py — Application logic. Do not mix with the frontend.

assets/ — Icons, logos. Easy to find when assembling.

data/ — Data that the application creates (logs, CSV).

5.4. First Application: “Engineer’s Calculator”

Let’s create a simple application that shows the power of communication between Python and JavaScript.

File 1: main.py (Backend)

Note: The @eel. expose decorator makes the function accessible from JavaScript. Without it, the function will remain “inside” Python.

File 2: www/index.html (Frontend)

File 3: www/style. css (Styles)

File 4: www/app. js (Interface Logic)

5.5. Running the app

Step 1. Launch via Terminal

Step 2. What will happen?

— Python will run a local web server (usually on http://localhost:8000).

— A browser window with your interface will open.

— You will see a form with the “Voltage” and “Current” fields.

Step 3. Checking the work

— Enter 220 in the voltage field.

— Enter 5 in the current field.

— Click “Calculate Power”.

— You will see: Power: 1100.00 W

Congratulations! You’ve just created your first desktop application in Python Eel!

5.6. How does it work? Architecture under the hood

Let’s understand what happens “under the hood” when you press the button.

Здесь есть иллюстрация

Зарегистрируйтесь или войдите, чтобы увидеть ее и другие изображения

Есть аккаунт?

Figure 1. How Eel connects the browser window and the Python backend

Key points:

— Local server: Eel raises a mini-web server in Python (via bottle or gevent-websocket).

— System browser: Eel does not embed a browser (like Electron). It opens your system Chrome, Edge, or Safari.

— Two pairs of parentheses: eel. func () () — the first passes arguments to Python, the second makes a call and returns a Promise.

5.7. Eel Startup Modes

Eel supports multiple window opening modes:

Table 14. Eel supports multiple window opening modes

mode=‘chrome’

Description: Opens in Google Chrome

When to use: Cross-platform if Chrome is installed

mode=‘edge’

Description: Opens in Microsoft Edge

When to use: Windows 10/11 (recommended)

mode=‘firefox’

Description: Opens in Firefox

When to use: If the user prefers Firefox

mode=‘default’

Description: Default system browser

When to use: Maximum compatibility

mode=False

Description: Do not open browser (server only)

When to use: For debugging or web access

5.8. Common mistakes and solutions

Table 15. Common mistakes and solutions

White screen

Cause: Wrong path to www/

Solution: Check eel.init (‘www’)

eel is not defined

Cause: Not connected /eel. js

Solution: Add a <script src="/eel. js”> </script> in HTML

Function is not called

Cause: Forgot @eel. expose

Solution: Add a decorator to Python

Two pairs of parentheses?

Cause: Eel Syntax

Solution: eel. func () () — is normal!

The port is busy

Cause: Another Eel launched

Solution: Close the previous process or specify port=8081

5.9. Preparing for the Next Step: Emulation Mode

In the next chapters, we will work with COM ports and Arduino. But what if you don’t have a device handy?

We’ll implement an emulation mode (DEBUG_MODE) from the start.

Important: We’ll come back to this in Chapter 10, but you already understand the philosophy: test without hardware, deploy with iron.

What did we learn?

— The eel installs in 1 minute via pip install eel.

— Project structure: main.py + www/ folder with HTML/CSS/JS.

— Python JS bundle: @eel. expose decorator + call eel. func () ().

— The first application works in 10 minutes without deep knowledge of the web.

— Startup modes allow you to choose the browser and window size.

— A virtual environment is a good practice for future packaging in. exe.

Practical task

— Create a project according to the structure from section 5.3.

— Run the calculator from this chapter.

— Modify the app:

— 3.a. Add a third field: “Resistance (Ohm)”.

— 3.b. Create a Python function calculate_resistance (voltage, current) that returns resistance according to Ohm’s law: R = U/I.

— 3.c. Add the “Calculate Resistance” button and display the result.

— Experiment with the startup mode:

— 4.a. Change the window size to (800, 600).

— 4.b. Try mode=‘chrome’ and mode=‘edge’ — is there a difference?

— Add error handling:

— 5.a. What happens if I enter 0 in the current field when calculating resistance?

— 5.b. Implement the check in Python and return a clear error message.

In the next chapter, we’ll dive deeper into the mechanism of calls: how to pass complex data (lists, dictionaries), how to call JavaScript from Python, and how to handle errors. You will learn how to build a two-way bridge between the backend and the frontend.

Pairing Python and JS. Function Calling, Data Passing, Asynchrony Without UI Locking

What is this chapter about?

Бесплатный фрагмент закончился.

Купите книгу, чтобы продолжить чтение.