I now make extensive use of ESLint and JSDoc in my JS programming as it really helps track the meaning of variables/objects which I find more important than a fixed declaration of type - though that is certainly helpful sometimes and also helped by ESLint.
Using a decent code editor like VScode with ESLint properly configured eliminates loads of silly little errors that I make because I'm not a full-time developer. JSDoc helps me keep track of what everything means.
RED object for coding the Editor panel for a node was especially frustrating. Also the TypeScript descriptor for Node-RED is far from complete unfortunately (and I don't know enough about TypeScript to be able to offer improvements to the authors). But it is great when it works because it offers up descriptors of objects and variables integrated into your coding. Even across
required external packages and libraries.
Thanks for the advice. I admit I've avoided "learning" eslint thus far. I do use vscode (almost exclusively now) - it is tremendous.
Perhaps the years of brain fade since those heady days will also help. We shall see.
I too am a relic of those days, so please forgive the ramblings of a grumpy old man. I've never coded for a living but have always written code as part of my job. So, I could easily have some of the history and technology wrong, but it seems that each language family reflects a slightly different view of the world. In particular JS is looking out from inside a web browser, where it has very little control of its destiny. Trying to make it feel like a procedural language with synchronous function calls, subroutines, and so on (which I sorely miss) would be self-defeating.
I've used it extensively, but with an academic/institutional license so that cost was not an issue. LabView and some other flow-based programming tools like Extend (now ExtendSim) strike me as what you get when a C programmer does flows. Node-RED can't avoid having its JS foundation show through and probably shouldn't try.
Oh, that describes me well enough
I have but not for a long time. BASIC (various types), COBOL, PL/1, APL, FOCUS, ACUMEN, FORTRAN, REXX, VBA, Visual Basic mainly.
Non-professionally used languages include PERL, C/C++, PASCAL, LISP and an old favourite FORTH.
I've seen some other simulation software that was graphical. Nice but highly specialised.
Indeed and indeed.
And an excellent choice it was too!
I was not so much thinking about the
And I think the above sums up the feelings of many, certainly myself.
Sometimes they are only complex because of the tools you have to use.
Ah but think of the benefit to your brain of learning new things!
I love the challenge of creating new ways of doing things.
Absolutely! Please don't construe by disdain for JS as anything other than the annoyance of having to change ones ways. Having said that, I don't think JS is the answer to everything, but NR is certainly the answer to many things and along with that must go JS.
It's all good, really.
It might not be the solution you're after but TypeScript really does go along way in helping to facilitate complex projects. I've noticed many contrib nodes are written in TypeScript so "vanilla" JS is not the only option. E.g. https://github.com/tbowmo/node-red-contrib-mysensors
I'm currently involved in a 10 developer project (on its 3rd year) which includes the main React based frontend code written in TypeScript and a cross-platform Android/iOS app built with React Native also in TypeScript. I would consider the code base incredibly difficult and regression prone to work with if we weren't using TypeScript. It has made it possible even for new developers joining later to do big refactorings on the code that would have likely never happened otherwise.
I'm so reluctant to write plain JS these days that at one point I spent a lot of time trying to find a way to hack in TS support also for function nodes but unfortunately didn't get further than managing to add TS syntax highlighting to the embedded ICE code editor... There is a project called ts-node which allows running TS code without a separate compilation step that might help in achieving this though.
I have ported our back-end code at work from plain JS to Typescript without regretting it a bit. Especially I wouldn't want to miss the support that VS Code provides for Typescript projects. I have even found some bugs and edge cases during the porting process that would have gone unnoticed for a while in plains JS.
TS doubtless is good for complex projects if you are a professional developer and are working with it day-in-day-out. Especially if you are working in larger, pro, teams.
JS has a number of advantages for us not least of which is its flexibility, generally simple syntax and the wealth of Internet support available - tutorials, references, etc.
If we want to gain some of the advantages of TS without being forced to use it, we can us VSCode and JSDoc.
On top of what Julian mentioned, TypeScript isn’t the easiest language to get started with, even after years of programming experience with both static and dynamic typed languages. The official documentation is always lagging behind when an update comes, and some of the new syntax that got introduced over a year ago still hasn’t made it to the actual documentation, unless you consider blog posts about new releases and the changelogs part of the documentation for the language itself. For example, the exclamation mark syntax is similar to how things work in Swift, which is how I understood how to use it in the end. But it’s only explained in the changelog.
What I mean to say is that the written documentation itself is not enough to learn the language. Obviously there’s video tutorials and tutorials to get started per frontend framework, but for me such a form of learning does not work. For me it’s books and text based documentation, or not at all. Most of why I gave it a chance in the first place was because of Anders Hejlsberg, and Turbo Pascal being my first actual programming language. Except any of my turbo pascal experiments from when I was 12/13 I can still read and understand, and the TS code I wrote back in March is already difficult to read now.
So while TS does indeed give possibilities because of the static typing, it’s not always the best solution.
You have probably been asked this many,many times but is there a way to get a copy or info on how you did this? I think your swim lane effort is great and perfect for my situation?
Thanks in advance.
Perhaps this preview could spark your interest ?