Anyone making UI's using the 2026 web control?

[BertMcMahan]

Holy cow, thanks for posting! I'll dig into this for sure 😄

[Andrey_Dmitriev]

---

@MichaelS78 wrote:

Added note: there is no webserver needed for this at all.  It is entirely possible to add an API to be able to use both the JS interface and a webAPI but this demo was to show the JS node and the power of no webserver!  I have already made multi UI apps with multiple VI's all of which are using the browser as the full page UI. And it works on Linux 🙂

---

Thanks for sharing! That gave me a some additional ideas. However, yes, the WASM-based solution cannot be loaded directly from a local file due to security restrictions. Technically the WebAssembly module is fetched by the generated JavaScript code, and those resources need to be served from a web server, no other way.

In theory, it is possible to bundle the WASM binary into the JavaScript file as a Base64-encoded string. However, this would significantly increase the size of the JavaScript bundle and would require additional loading and initialization logic. I'll investigate later what can be done in this area and see whether there is a practical solution.

[Andrey_Dmitriev]

---

@Andrey_Dmitriev wrote:That gave me a some additional ideas.

---

Today during my lunch break, I played around with this a bit more. In general, it is not necessary to keep the JavaScript separate from the HTML. We can embed everything into a single HTML file, which is very convenient for small projects (or even supply JS from LabVIEW). Copilot can generate the entire code, including the JavaScript and a trivial "API" for external control, so it works:

And I can't stop playing with it. This is also fully AI-generated code, no single line was typed manually:

And it is also possible to control the JavaScript from inside the Browser Control, of course:

Finally, in the project from my previous comment, where Rust code was compiled to WASM, I encoded the WASM as Base64, put it into JavaScript, and then embedded everything into the HTML. This makes it possible to run the Rust/WASM application completely serverless, directly from a local HTML file, same as JS.

The downside is that it produces a relatively large file. In my case, the resulting HTML file is about 12 MB in size.

So, it is possible to use JavaScript, or even Rust via WASM, inside Browser Control, which could be quite useful. I occasionally notice some strange delays, especially when closing VIs that use it, as well as some issues with pull down list, but for an initial draft it is perfectly acceptable. Overall, it works well, and I had a lot of fun experimenting with it.

The attachment contains complete projects with six examples (plus one original NI example). Feel free to use them as a getting started or modify them as needed.

[MichaelS78]

That is fun then graphics are nice. Has anyone looked at my example? Mine is also 100pc LLM generated UI but the idea ofy example was to start a framework idea for complete UI use. Maybe if I posted videos it would get more attention? 🙂

The example has menus, graphs, dialogue box. Theme switching.

It highlights the gap of JS promise support which if we get traction NI might add.  I have examples with moveable splitters and rich multicolumn tables.

My event que to LabVIEW and structured command API is supposed to be ready for UI helper abstraction.

[Andrey_Dmitriev]

---

@MichaelS78 wrote:

That is fun then graphics are nice. Has anyone looked at my example?

---

Yes, yes, actually your example was very helpful, especially the call pattern like return get_angle(). Thank you!

If you have more examples, please don't hesitate to share them. It's nice to collect "design patterns" and "best practices" snippets here in this topic, especially since the example shipped by NI is fairly simple.

However, wrapping an entire GUI has both pros and cons and should be used depending on the situation. There is no silver bullet. For example, I expect some performance penalties when transferring large amounts of data, such as X-ray images, where a single image can easily be 32 MB in size. It is somewhat similar to the managed/unmanaged code boundary in C#, so it should be used carefully.

In addition, this approach introduces an extra dependency compared to a native LabVIEW-based GUI, as well as some additional challenges when debugging JavaScript code.

On the other hand, one of the biggest advantages is that AI can be used very effectively in this area.

[Yamaeda]

That demo was awesome Andrey!

For some reason the Sorting selection is non-selectable for me, i'm stuck with Bubble.

If you change the Select tag to  <select id="alg" size="3"> it works as expected.

[Andrey_Dmitriev]

---

@Yamaeda wrote:

That demo was awesome Andrey!

For some reason the Sorting selection is non-selectable for me, i'm stuck with Bubble.

---

Thank you! Yes, this is small issue in html/js, needs to be fixed, for the moment you can use keyboard keys with arrows to switch between modes, just click to the control, then use keyboard

[Yamaeda]

Change the Select tag to  <select id="alg" size="3">

[Yamaeda]

The Drop down works correct if you open the HTML directly (Edge in my case), but not in the control, so we might have found a bug!

[MichaelS78]

One of the big use cases I have is making nice looking data entry dialogue boxes for users.  With with almost no code which is possible to flatten any cluster to json. Send that to JavaScript which dynamicaly builds a pop up dialogue. LabVIEW can't do that at all! Even better, extending it to receive a JSON schema and use that to populate and enforce limits, default values, help text and drop down lists.  The UI becomes dynamic and intuitive.

I'm pretty sure the menu handler I included is easier to use than native LabVIEW menus! Not to mention custom icons in menus 🙂

I agree not great for huge data sets but for general purpose UI use the new node with LLM help is cool. 

Last comment: can anyone else comment on lack of JavaScript Promise support, and how neat it would make my example framework?