Would IA consider something like Brython to bridge the gap between Python and JS?
1 Like
Having never heard of Brython, my first thought was that it was using an approach like Pyodide, 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:
- The same compatibility limitations as Jython (no C extensions, reliant on an external translation layer understanding each new Python version's syntax)
- A similar maintenance situation (we'd be relying on the
brython-devorganization, which doesn't accept external funding) - 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.
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.
6 Likes
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" 
2 Likes
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 and Unity offers 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.
3 Likes
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.
1 Like
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.
4 Likes
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 
"
9 Likes
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 
4 Likes
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?
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.
3 Likes
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.
5 Likes
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 
Thats what custom modules are for
5 Likes
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.
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.
2 Likes
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. 
This is supportable.
This puts the support burden on the module author, not on IA.
I was only replying to Victor's suggestion of using custom modules to specify what I originally had in mind from my previous comment.
1 Like