BajaScript

BajaScript is the bridge between the browser and the live station. It is the JavaScript API that lets HTML5 interfaces read points, subscribe to changes, and invoke actions in Niagara – the engine behind every modern, responsive Niagara dashboard. Software Pile builds interfaces on it that stay live and stay fast.

What BajaScript Makes Possible

  • Live data binding: browser widgets that reflect station values in real time via subscriptions, not polling
  • Interactive control: operators adjusting setpoints and invoking actions with proper permission checks
  • Custom HTML5 dashboards that go beyond what stock PX and Hx views allow
  • Efficient subscription handling so many widgets and sessions do not overload the station

Modern Interfaces, Real Data

BajaScript paired with a proper build pipeline and WebSocket transport is how we deliver Niagara UX that feels like a modern web app rather than an embedded control screen – without losing the live connection to the station that makes it useful.

Describe the interface you want and your Niagara version. We will build it on BajaScript with performance in mind from the first line.

What Is BajaScript?

BajaScript is the JavaScript client library that lets code running in a browser talk to a live Niagara station. It exposes the Niagara object model — components, properties, actions and permissions — to the browser, so a web interface can resolve an ORD, read a point, subscribe to changes, and invoke an action without the page having to poll a server for updates.

It is the reason a modern Niagara interface can behave like a web application rather than a refreshing page. Everything responsive in an HTML5 Niagara UX module is ultimately going through BajaScript.

How Is BajaScript Different from the Baja API?

They model the same thing from opposite sides of the connection. The Baja API is the Java API used inside the station and inside Workbench — it is where server-side module logic, drivers and components live. BajaScript is the browser-side counterpart, giving JavaScript access to a similar component and subscription model over the network.

The practical consequence: work that must run whether or not anyone is looking at a screen belongs in a Java module built on the Baja API. Work that exists to present and interact belongs in BajaScript. Putting control logic in the browser is a recurring design mistake — it stops the moment the operator closes the tab.

How Do BajaScript Subscriptions Work?

Rather than repeatedly asking the station for values, a BajaScript client subscribes to the components it cares about and the station pushes changes as they occur. This is what keeps a dashboard live without generating constant request traffic.

Subscriptions are also where most performance problems originate. Each subscribed component costs the station resources, and those costs multiply by the number of concurrent sessions. A dashboard that subscribes to several hundred points and is left open on a dozen workstations is a meaningfully different load than the same dashboard viewed once.

What Are the Common BajaScript Performance Mistakes?

  • Subscribing to everything on page load. Subscribe what is visible; subscribe the rest when it becomes visible.
  • Never unsubscribing. Views that are navigated away from but never torn down leave subscriptions alive and accumulate load over a shift.
  • Resolving ORDs in a loop. Batch resolution instead of issuing one request per point.
  • Ignoring the station under load. An interface that feels fine on a lab station can degrade badly on a production Supervisor already serving alarms, histories and other clients.
  • Treating the browser as trusted. Permissions are enforced by the station, not the interface. Hiding a button is presentation, not security.

Which Niagara Versions Support BajaScript?

BajaScript is the client library behind Niagara HTML5 UX work and is used across current N4 development. The exact version and packaging matter: the library, the build tooling around it, and the module format all move between Niagara releases, so an interface written against one N4 version is not automatically portable to another. Scope any interface work against your specific Niagara version rather than against “N4” in general, and expect retesting as part of a station upgrade.

When Should You Use BajaScript Instead of Px?

Px remains the fastest way to produce conventional operator graphics, and for many stations it is the right answer. BajaScript earns its extra effort when you need something Px was not designed to produce:

  • Interfaces that must work well on phones and tablets, not just a workstation.
  • Custom visualizations — charts, floor plans, or aggregations that combine station data with an external source.
  • Public or tenant-facing views where the look must match a brand rather than look like a control system.
  • Screens that pull from several stations or from a system outside Niagara entirely.
  • Workflows with multi-step interaction and validation rather than a single setpoint adjustment.

If the requirement is a conventional equipment graphic for an operator on a desktop, Px is usually the cheaper and more maintainable choice. We will say so.

How We Build BajaScript Interfaces

Interfaces are scoped against your Niagara version, station architecture and expected concurrency, then built with a proper module structure and a Webpack and Babel build pipeline so the result is a signed, versioned Niagara module rather than loose files dropped on a station. Subscription behaviour is load-tested against realistic point counts and session numbers before handover, and the code is yours.

Related services: Niagara graphics and operator dashboards · custom Niagara module and driver development.