Why a browser-native HMI holds up next to a panel.

A proprietary runtime is a piece of software one company maintains. A browser is a piece of software three companies compete to maintain for free. That difference is the whole argument.

The same Aquavane dashboard rendered at three widths side by side: laptop with a full sidebar and six line-flow stations in a row, tablet with an icon rail and stations wrapped to a grid, and phone with a hamburger and stacked cards.
One design, three widths. Laptop, tablet and phone, rearranged by settings in the editor rather than a second build.

Every traditional HMI/SCADA platform ships its own client: a Windows-only runtime, installed per panel, updated by hand or through a fleet-management add-on you also pay for. NEXT HMI's client is whatever browser is already on the device. That sounds like a smaller claim than it is, so it's worth taking apart.

You're not maintaining the client

Chrome, Edge, Safari and Firefox get security patches from companies with far bigger security teams than any HMI vendor has. A traditional runtime gets fixes only as fast as its one vendor ships them. With a browser, the operator screen benefits from all that work, as long as the device is allowed to update. A panel that's air-gapped, or frozen for validation, keeps the browser it shipped with and needs the same deliberate update plan as any runtime. The browser doesn't remove that job. What it changes is that the patches exist, and quickly.

One design, every screen size

You build a screen once and it adapts. A row of gauges on the panel at the machine becomes a column on the phone in the maintenance engineer's pocket. You set that per element in the editor, so there's no second project and no separate mobile version to keep in sync. Features shows the same screen at three widths.

The project format is the thing that ages best

Screens, alarms, themes and translations are stored as plain text files. They aren't locked in a database or in a format only one tool can open. So they work with the version control your software team already uses: you can see exactly what changed and who changed it, and roll back. Ten years from now, a text file opens in anything. A proprietary project format that its vendor has revised three times might not.

One server, not an engineering workstation

The editor runs in the same browser as the operator screens, so there's no separate engineering workstation to license, install and keep patched. One server talks to your PLCs and feeds every screen. That's one box to install, one port to open, and one thing to explain to the customer's IT department, instead of a Windows workstation, a runtime and a licence dongle.

Where this argument runs out

Honestly, it runs out in two places.

Protocols. Today NEXT HMI speaks OPC-UA and nothing else: no native S7, Modbus or EtherNet/IP. A controller behind an OPC-UA gateway works fine. A plant committed to a fieldbus with no OPC-UA path has a real gap. MQTT and Beckhoff ADS are on the roadmap but not shipped. The full list is on Specs.

Locking down the panel. A dedicated runtime comes locked down. A browser has to be put in kiosk mode so operators can't open tabs or leave the screen. That's a one-time setup per device, but it's work a panel vendor would otherwise do for you.

None of this argues against the browser. The browser-native design is the part that ages well. The rest is about what exists yet.

Sources: Features for the responsive and property-source mechanics referenced above, Specs for protocols and system requirements.