# Exchange Resource to use Javascript with Perspective

**URL:** <https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937>\
**Category:** Ignition Exchange\
**Tags:** perspective\
**Created:** [November 15, 2023, 5:05pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937 "2023-11-15T17:05:47Z")\
**Posts on this page:** 18\
**Page:** 2

<div class="post-metadata">

**Author:** ![Felipe\_CRM](https://avatars.discourse-cdn.com/v4/letter/f/dfb087/32.png) [@Felipe\_CRM](https://forum.inductiveautomation.com/u/Felipe_CRM)\
**Post date:** [March 26, 2024, 4:31pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/21 "2024-03-26T16:31:15Z")

</div>

> [@paul-griffith](#):
>
> a future where we can deliver a single compatible scripting language that works in Vision, Perspective, _and_ on the Gateway. That's _absolutely_ a better deliverable than telling end users they have to learn a _third_ programming language to use Ignition.

Would IA consider something like [Brython](https://www.brython.info/index.html) to bridge the gap between Python and JS?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 26, 2024, 5:08pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/22 "2024-03-26T17:08:43Z")

</div>

Having never heard of Brython, my first thought was that it was using an approach like [Pyodide](https://pyodide.org/en/stable/), that is, using WASM, but actually it's relying on on-the-fly transpilation of (pure) Python code to JS... so with Brython you've got:

1. The same compatibility limitations as Jython (no C extensions, reliant on an external translation layer understanding each new Python version's syntax)
2. A similar maintenance situation (we'd be relying on the `brython-dev` organization, which doesn't accept external funding)
3. A 'fractal' scripting language(s) problem. Brython is Python 3, so wouldn't be able to run in Vision or anywhere on the Gateway - **only** in the browser. So we'd be introducing Python 3...except, not everywhere 😄

Basically: It's a **really hard** problem.

> [@paul-griffith](#):
>
> it's possible there's a future where we can deliver a single compatible scripting language that works in Vision, Perspective, _and_ on the Gateway

This is still the future I'm most optimistic for. WebAssembly gets better every day, and is close to being "mainstream" usable. It's also got _great_ third party momentum behind it - every major browser supports it, it's not owned by a single organization, etc. It _also_ addresses some significant security concerns with the current "just blindly run code authored in the Designer on the Gateway" model, with restricted access to external interfaces and built-in limitations on memory usage and runtime. With WASM, we'd be able to offer a _parallel_ (Jython will almost certainly never go away, for backwards compatibility reasons, but may in some distant future be disabled by default) execution environment that's polyglot - if you want to write JS, you can, and we'll run it on the backend or on the frontend as appropriate. If you want to use Python 3, you can. If you want to use Kotlin, you can. And so on, and so on. There will probably be one or a few "blessed" languages we provide documentation examples in, but if we get to that point, there's probably no point in preventing end uses from making those choices.

However, all of this is still very much theoretical, with absolutely no timeline to implement nor guarantee it even will happen as I've described here.

---

<div class="post-metadata">

**Author:** ![Felipe\_CRM](https://avatars.discourse-cdn.com/v4/letter/f/dfb087/32.png) [@Felipe\_CRM](https://forum.inductiveautomation.com/u/Felipe_CRM)\
**Post date:** [March 26, 2024, 5:17pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/23 "2024-03-26T17:17:09Z")

</div>

I agree with you on the limitations (and personally I'd accept #1 as it's no different than what we already have), although I wasn't necessarily talking about directly plugging Brython into Ignition, more the general concept of having a Python 2.7 to JS parser (in-house dev) so users could use a familiar syntax for client-side scripting.

Of course that's a whole extra thing to develop and support so I don't blame y'all for saying no right now 😅

EDIT: I can already imagine all the forum posts and support tickets for "why can't I use `system.foo.bar()` from the Perspective Client Scripting component" 😆

---

<div class="post-metadata">

**Author:** ![andrew.budaiev](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/andrew.budaiev/32/72921_2.png) [@andrew.budaiev](https://forum.inductiveautomation.com/u/andrew.budaiev)\
**Post date:** [March 26, 2024, 10:26pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/24 "2024-03-26T22:26:28Z")

</div>

Is it possible to make an expression language so powerful that you won't need another one?

In game development, for ease of use, visual scripting languages are used. In Unreal Engine, they utilize [Blueprints](https://dev.epicgames.com/documentation/en-us/unreal-engine/blueprints-visual-scripting-in-unreal-engine) and Unity offers [Unity Visual Scripting](https://unity.com/features/unity-visual-scripting). Which is allowing non-programmers, such as art teams, to do some work. However, the backbone of these engines remains C++/C#.

Is it feasible to have something similar in Java? I suppose it's a long shot.

---

<div class="post-metadata">

**Author:** ![zacht](https://avatars.discourse-cdn.com/v4/letter/z/ea5d25/32.png) [@zacht](https://forum.inductiveautomation.com/u/zacht)\
**Post date:** [March 26, 2024, 10:39pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/25 "2024-03-26T22:39:36Z")

</div>

> [@andrew.budaiev](#):
>
> Is it possible to make an expression language so powerful that you won't need another one?

> **[Standards](https://xkcd.com/927/)**

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 26, 2024, 10:46pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/26 "2024-03-26T22:46:18Z")

</div>

An **expression** language powerful enough to encompass all other languages would be a purely functional language. Lisp is fun, and Haskell's cool, but how many new projects are getting made in them?

Making an "IAScript" or whatever bespoke general purpose language has been floated as well... but it has lots of the same problems, _plus_ it's an ongoing maintenance debt for us to manage.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [March 26, 2024, 10:54pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/27 "2024-03-26T22:54:28Z")

</div>

> [@andrew.budaiev](#):
>
> Is it possible to make an expression language so powerful that you won't need another one?

> [@paul-griffith](#):
>
> Making an "IAScript" or whatever bespoke general purpose language has been floated as well...

I've thought about this at times as well... or just using Lua.

What's special about Python (though rapidly becoming less special because we're stuck on Jython 2.7) is/was the vast ecosystem of libraries you are/were able to use.

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [March 26, 2024, 11:26pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/28 "2024-03-26T23:26:40Z")

</div>

> [@paul-griffith](#):
>
> if you want to write JS, you can, and we'll run it on the backend or on the frontend as appropriate. If you want to use Python 3, you can. If you want to use Kotlin, you can

I can only imagine the mess this will create with answering posts on the forum 😬

"Well... to do it in JS, do this  
Python3, like this  
Kotlin, like this  
Rust, like this  
Go, like this  
YoMamma, like this 😉 "

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 26, 2024, 11:38pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/29 "2024-03-26T23:38:38Z")

</div>

While this is true, the nice thing is that syntax really isn't _that_ different between most "mainstream" languages right now. It's not Lisp or Haskell or APL or Brainfuck 😂

---

<div class="post-metadata">

**Author:** ![Ahmed\_Alsaadi](https://avatars.discourse-cdn.com/v4/letter/a/6a8cbe/32.png) [@Ahmed\_Alsaadi](https://forum.inductiveautomation.com/u/Ahmed_Alsaadi)\
**Post date:** [October 21, 2024, 5:59am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/30 "2024-10-21T05:59:07Z")

</div>

I don't understand the resistance against JavaScript and web development in general. Perspective is as close to web development as you can get with a WYSIWYG editor, but it has considerable limitations that could be removed. I would love to see an "advanced" toggle to remove required props like direction, wrap, etc., and allow these to be controlled via CSS instead. There are many other quality-of-life improvements that could be made as well.

Ignition is incredibly useful for tags, tag historian, communication, IoT, and everything else SCADA-related. However, I wish the development experience was better for those of us with software engineering backgrounds. Are we a tiny minority, and/or is the implementation effort just too large?

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [October 21, 2024, 11:51am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/31 "2024-10-21T11:51:15Z")

</div>

If you want complete control over the front end you can always buy the web dev server to make Ignition function as a REST API server to provide all your tag data etc, and then you can make your front end completely from scratch in vanilla js, react, vue, whatever you want. It is among the cheaper modules to purchase but for good reason - now the entirety of the front end is on you with no Ignition niceties or components that automatically know how to work with things like tag history. Any thing that goes wrong front end wise is completley on you to fix.

Regarding the second point, I think some people have asked for this on the forum before, but where I work for instance, the biggest thing to know (for everyone else besides me lol) is PLC's and all the hardware that go along with an automation project. Learning javascript would probably rank near the absolute bottom of the list of skills to have because we're able to make Perspective do everything we need it to do for a SCADA system and customers seem to know it by reputation now and are willing to pay for it.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [October 21, 2024, 12:55pm UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/32 "2024-10-21T12:55:54Z")

</div>

> [@Ahmed\_Alsaadi](#):
>
> limitations that could be removed.

Right, but then IA would have to officially **support** the _unlimited_ functionality. Perspective exists to allow us simple **engineers** to make beautiful web-based HMIs. If there was an "advanced" toggle, then any 3rd-party help hired to move projects along will _ **break** _ things for the engineers and technicians who have to take care of this stuff for 20 years.

The limitations are _ **deliberate** _.

---

<div class="post-metadata">

**Author:** ![Ahmed\_Alsaadi](https://avatars.discourse-cdn.com/v4/letter/a/6a8cbe/32.png) [@Ahmed\_Alsaadi](https://forum.inductiveautomation.com/u/Ahmed_Alsaadi)\
**Post date:** [October 22, 2024, 3:18am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/33 "2024-10-22T03:18:16Z")

</div>

> [@pturmel](#):
>
> Right, but then IA would have to officially **support** the _unlimited_ functionality. Perspective exists to allow us simple **engineers** to make beautiful web-based HMIs. If there was an "advanced" toggle, then any 3rd-party help hired to move projects along will _ **break** _ things for the engineers and technicians who have to take care of this stuff for 20 years.
> 
> The limitations are _ **deliberate** _.

I fully understand the concern and I myself work with non-software engineers who will also work on the Ignition HMI. The last thing I'd want to do is give them something that I'll have to spend an eternity explaining.

I still think that having the option to do **some** custom web dev on the HMI would undoubtedly speed up the initial process of creating the skeleton framework of the HMI layout/design and would allow me to create some custom components that the operators themselves have expressed as HMI features that they'd love to have. An 'advanced' toggle hidden away behind permission, access, or web dev module layers could definitely co-exist with the current system and make a great product even better.

But it seems like IA have weighed the pros and cons and decided against it, which I respect 🙂

---

<div class="post-metadata">

**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\
**Post date:** [October 22, 2024, 8:24am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/34 "2024-10-22T08:24:28Z")

</div>

> [@Ahmed\_Alsaadi](#):
>
> create some custom components

Thats what custom modules are for

---

<div class="post-metadata">

**Author:** ![Ahmed\_Alsaadi](https://avatars.discourse-cdn.com/v4/letter/a/6a8cbe/32.png) [@Ahmed\_Alsaadi](https://forum.inductiveautomation.com/u/Ahmed_Alsaadi)\
**Post date:** [October 25, 2024, 1:44am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/35 "2024-10-25T01:44:19Z")

</div>

Yes but that's a time-consuming, non-trivial task that's hard to maintain even with a team of software engineers. I was thinking more along the lines of a native solution rather than using hacky workarounds like the Markdown abuse that you came up with, which is something that can only be used sparingly for obvious reasons.

---

<div class="post-metadata">

**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\
**Post date:** [October 25, 2024, 6:37am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/36 "2024-10-25T06:37:39Z")

</div>

Well there is also injectables, where you could write in some custom html component where all the perspective logic resides so you would "only" need to call that component through markdown...

But in my opinion thats the custom module is going to be easier.

> [@\[feature-748\]Perspective Favicon](https://forum.inductiveautomation.com/t/feature-748-perspective-favicon/24642/29):
>
> Soo i got something for you mage Create these files (and injectables folder) (depending on install folder ofc) "C:\Program Files\Inductive Automation\Ignition\data\modules\com.inductiveautomation.perspective\injectables\head\_bottom.txt" "C:\Program Files\Inductive Automation\Ignition\webserver\webapps\main\newFavicon.ico" In the head\_bottom.txt put this: \<script\> const oldLinks = document.querySelectorAll('link[rel\*="icon"]'); oldLinks.forEach(e =\> {e.href = '/newFavicon.ico';}); \</script\>…

> [@Importing alternative checkboxes](https://forum.inductiveautomation.com/t/importing-alternative-checkboxes/97051/9):
>
> Most of these seem possible to do with just some basic components... You will need some different css though. Mainly you will have to bascily rename all css class selectors with psc- infront I guess you could techincally create custom html too. You could put the creating of this in the injectables, than use markdwon to utilse them would be quite compact in the views itself... Though this is not a trivial thing to do. especcially to get some feedback back into perspective... Probably easier to …

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [October 25, 2024, 11:26am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/37 "2024-10-25T11:26:57Z")

</div>

> [@Ahmed\_Alsaadi](#):
>
> I was thinking more along the lines of a native solution rather than using hacky workarounds

You say you understand IA's support concerns, but this statement suggests you do not. If IA offers a native solution, IA has to support it. 🤷‍♂️

> [@Ahmed\_Alsaadi](#):
>
> used sparingly

This is supportable.

> [@victordcq](#):
>
> custom modules

This puts the support burden on the module author, not on IA.

---

<div class="post-metadata">

**Author:** ![Ahmed\_Alsaadi](https://avatars.discourse-cdn.com/v4/letter/a/6a8cbe/32.png) [@Ahmed\_Alsaadi](https://forum.inductiveautomation.com/u/Ahmed_Alsaadi)\
**Post date:** [October 25, 2024, 11:42am UTC](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937/38 "2024-10-25T11:42:09Z")

</div>

I was only replying to Victor's suggestion of using custom modules to specify what I originally had in mind from my previous comment.

[Previous page](https://forum.inductiveautomation.com/t/exchange-resource-to-use-javascript-with-perspective/81937.md?page=1)