When does a plugin require going through VS Code versus just using Rhino’s ScriptEditor?
This was a question I had in response to a post talking about building plugins for Grasshopper on LinkedIn using VS Code.
Their response was to
Use VS Code when you’re building a real plugin. You need a compiled .NET project, references and debugging, versioning.
Could some experts on here chime in and please make this a little more clear? I’ve been using ScriptEditor for a plugin and it appears to have all this features. In the future is ScriptEditor going to be the way or VS Code? So confused…
So when you’re writing in the script editor, your instructions are interpreted - the interpreter goes through your code line by line and turns it into machine code for your processor.
When you writing in VSCode etc. you’re going to compile the plugin first - turning the instructions into machine code before you run them.
Generally this means that your code will run faster if it is compiled rather than scripted, however it becomes harder to troubleshoot. For example if you were developing a plugin and shared a script editor with me, it would be quite easy for me to break in and read your code - I will have a harder time doing that with a compiled component.
You might want to take a look at this ScriptEditor guide which covers how you can make Rhino plugins or GH addons right inside the script editor that comes with Rhino 8.
Hey Luis! Yes I know. My question is what’s the difference between doing that and using VS Code and when to choose one over the other? Is the ScriptEditor more correct way of doing it now?
Makes sense, but this is still confusing because the ScriptEditor in it’s current form is something new since Rhino 8 which was long after Long’s course. That’s why I’m confused. Is the ScriptEditor the more correct way of doing it know? The ScriptEditor compiles your code as well and the result is a Yak package anyone can install.
I think this terminology “a real plugin” is very gatekeepy and very unhelpful. Some of the most incredible plugins I’ve seen are made using the Script Editor. If it works for you, keep using it until it doesn’t. And if that happens then we can add more features for you, or help you migrate to VS Code or Visual Studio or whichever IDE you like, if that’s what you actually need.
I think the best way to think of the script editor is that it is “batteries included”. If you want to make a plugin, certainly if you’re newer to plugins, it’s awesome. I use it quite a lot and I hope some day to win a hackthon using it >:)
VS Code (or another IDE) will also let you also make a plugin, outside of Rhino, and offers a more advanced programming and debugging experience. If you don’t need these features, I wouldn’t worry about them until you feel like the script editor is constraining you.
The script editor exists to make Rhino and Grasshopper Plugins and is very good at this. Better than VS Code in some ways, and it will continue to get better at doing just that.
The correct way is whichever way works for you. That’s why we try to make different avenues of plugin making available to anyone.
I hope these comments don’t come across as adversarial @Artstep I just want to help un-confuse @aidan.newsome !
This is only true for python. The Script Editor compiles C# the same as VSCode does, and Grasshopper is run as normal.
This is only true for C++. C# compiles to IL and is run by the Just In Time Compiler.
This is generally true! But @aidan.newsome I wouldn’t worry about speed too much
I think too, this is only really true for C++. C# is very extremely to de-compile unless it’s obfuscated. I wouldn’t worry about obfuscation, I think people worry about this stuff too much. Just enjoy your projects
Long does have some excellent courses. Well worth watching! I took one of his courses a while back and really enjoyed it
Thank you for such a thoughtful reply Callum. This helps me a lot.
I had made this other post a few days ago about one of those limitations (perhaps) that I’m running into with the ScriptEditor.
Is this issue one of those reasons for me to move to VS Code for a plugin project? It seems like my the libraries I’ve included in my ScriptEditor are indeed packaged in the Yak and extracted into the associated libs/ folder upon install, however the path’s don’t appear to be get automatically added to Python’s sys.path at runtime and currently my workaround is that I manually add them to sys.path anytime I change the code in the library. And this obviously doesn’t work for production. Not sure if I’ve phrased that all correctly.
The only similar issue I can find is maybe this…
Maybe you or someone on the team can confirm if that’s a bug or if I’m doing something incorrectly…
Thanks, Calllum. No worries it’s a fine workaround for internal use. More just trying to figure out if I’m doing something wrong or if this is an actual bug.
I’ve not really been keeping up as much as I should have been lately - I’m curious though, profiling the script usually shows ScriptEditor components running slower than compiled counterparts though? It’s doing something extra isn’t it?
I wish I could just enjoy projects - everyone wants 3 NDAs first
