The resource makes use of jquery and velocity libraries.
IA doesn't want this on the Exchange. Feel free to email me and I can send it. email@example.com
Yeah, folks already get confused between the expression language and Jython, multiplied by the different execution scopes. Adding another base factor to that (with its own execution scope...) is not a winning combo.
Even if this is true then why do other SCADA solutions or platforms support JS directly? I don't mention a name here but almost everyone does that. So surely they find a way to that problem
It is a quite bad idea to pass all UI data manipulation to the server to handle when we have a lot of horsepower on the client side. This causes client number limitation on one Ignition Server and the response is quite slow over the internet.
JS is faster, and it run on the client side, and give a lot of amazing option to the user which is not possible in other scripting language.
Also, I believe if IA opens this capability, the dev team doesn't need to add more components to Perspective and they are free to do better things as people themself can create new components and functionality and share it in exchange.
For example in the current version of the input box in Perspective, it doesn't support debouncer(Add some delay before exposing user key press). The debouncer logic is quite simple in JS with setTimeout() and clearTimerout() functions to implement.
But as of now, we need to go through to create a new module for our own custom input components which is hard and costly and loads extra code(resources) at Perspective Startup.
Especially when you are not a programmer by trade and you will start making changes in the mess that is web development, IA will have to triple its support budget probably.
The inspection tool in the browser could be used to debug js (it has breakpoints and such)
But yh, adding yet another langaugue the common designer would need to know seems not great.
And for the advanded js userers there is the markdown or component development avaible.
If you have a team of webdevs who can create even bigger js features/pages, then why do you need igntion and not just devolop the whole app in js?
As the one who started all this js stuff, i dont mind there not being a dedicated way to do this, it would be messy anyways even if they made somethign that worked in views. But yeah i did look into it, because there were some small things i wanted to change here and there... So there being a markdown which accepts html is rly nice, even if its ugly/hard to use.
For example you use frame work x from Tatsoft
Which is base .net and support js and python 3 and .net language like c#
There are other solutions like myscada or webiq which base on node us and support is in client side for user
oh i dont know anything about other platforms, ia was the first scada platform i used.
Well anyways, if they have the budget to hire a js support team than good for them, but before i found out the js-injection in markdown, there wasn't really any talk about js. And even after, now there are only a handful of users who use it (unless maybe copypaste a solution of mine). So i dont think for now there is a big enough market for them to support this. Most people still struggle with css, let alone js.
Anyways the css stylesheet (which probably exists because of me) is great. So maybe they will find something for js too after a while If more and more js tricks start to exists on the forum or like this exange resource that poped up.
or an update to webdev module (tho no idea how those resources work there ive not used it)
You'll have none of those in 8.3, guaranteed. Offering alternatives to Jython is something we want to do, but as I mentioned in the dev panel at ICC, there isn't a solution out there right now that's compatible with our technology stack (and without significant non-technical drawbacks).
I already said I was on board with this capability! But the fact remains - for at least 90% of our users, Perspective as it is works well enough and offers enough functionality for them to accomplish what they need today. Everything we bundle into the platform or a first-party module like Perspective has to be supported more or less forever. There are absolutely use cases for "power users" like you, who are over-represented on this forum. Joe and Jane Doe working in a small factory have no use for those advanced capabilities. We have to try to cater to both audiences at the same time. Right now, the way we cater to power users is the module SDK.
Like I already said, I could see an enhancement to the Webdev module that made it easier to integrate custom JS with Perspective - that would be an olive branch to folks like you who want that extra power and flexibility without overwhelming "regular" users.
JS is not faster than Java. It is probably faster than Jython. But with things like WASM GC support getting integrated into browsers, 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. That's absolutely a better deliverable than telling end users they have to learn a third programming language to use Ignition.
OMI from what I've played with it is just a cleaned up window/graphical window manager that uses WPF instead of WinForms. It uses and works with the same graphics designed in System Platform with some additional components. Any old .Net controls you were using with InTouch have to be converted over to WPF (I have some that I can't get working because there's no WPF equivalent), but otherwise, it's still a desktop application that's more modern than InTouch, but last time I tried using it, there were limitations that prevented a lot of functionality we needed from working, so we didn't use it. I haven't tried it with 2020 or 2023 yet as we haven't had a client request it since 2017 when it came out. Now our clients that are still currently using Wonderware are looking at switching over to Ignition due to cost savings and potentially better functionality as well.