Would this be for running scripts and performing computations headlessly or would you like to do more with it?
Do you still consider this the case in the latest Rhino 9 WIP? I use VSCode daily and have found the Script Editor to be quite close for most of my scripting needs.
We all take it for granted, but I have to say, grasshopper is such an advancement in computational geometry that if it were not a commercial product it would be a candidate for Nobel prize in mathematics. it has, by my ignorant opinion, changed the way we all work with geometry, It is that much of an advance over what came before.
That said, we all forget this as we work with it every day, and in typical craftsperson fashion, blame the tools when something doesnāt go well, rather than our own limited thinking.
My 2 centsā worth: An ESC function would be great, or a āsupervisorā mode (or some such name) that stops the calculation if over a specified time (5 minutes, 5 hours, whatever)
I believe G2 is async, and so your solution wonāt lock up as youāre doing stuff, or if you accidentally create a week long computation. This should achieve what esc would have done in G1 
.
great!
To be fair, I have not tested Rhino 9 and Iām rarely using Rhino atm. So my knowledge is abit outdated. I have seen improvements here in the forum but Iām not aware of the current status. But if you think about what VSCode offers nowadays, you could imagine that many more features can be used in this editor apart from writing code. Essentially you can use AI agents, Git Client, Test execution, Pipeline management, Customization, static analysers, profiler and many other things. You embed another language, just download the respective extension.
Regarding the CLI, I could imagine to do many things such as running it headless, serializing, to configure parameters, to build dynamic templates, to autorun integration tests. To modify settings, such as Galapagos, reports/exports etc. I also like the idea to build CLI first. But this is a conceptional thing
This might be an unpopular opinion (and perhaps MacOS-specific?), but I just wish that Grasshopper worked like every other app/window and didnāt insist on doing the the āNo *I* get to ride in the Front!ā thing.
MacOS has lots of perfectly nice built-in tools and behavior for switching between apps and windows (hot-corners, command-tab, stage-manager, ā¦), but of course none of them work to switch between Rhino<>GH windows, which is a bummer. Personally, Iād love to be able to turn that GH behavior off and just have it behave like all the other apps and windows on my computer.
What I really miss from macOS is the ādouble click on the header to collapse the GH windowā behaviour that is there on Windows. That would be pretty useful ā also to circumvent this.
Grasshopper should have been more parallel. Components like List Item should be able to operate on multiple list inputs simultaneously.
In the absence of an Unentwine component and the inability to rename Entwine in- and outputs (not to mention the inability to propagate the nicknames to downstream components), there should be a dedicated combined data throughput component for many in- and outputs.
Think of the User Text component, which has a Content input and key/value outputs that it propagates by just wiring the Content in- and outputs. Now apply this to non-geometric data where āContentā would be replaced by āDataā and the key/value in- and outputs would be replaced with any type of data in/out (it wouldnāt even need to be matching in item count nor data structure).
I havenāt tested Rhino 9 yet, but my experience with the Rhino 8 script editor (both in Rhino and GH) is a clunky mess, 90% of the time itās in my way rather than helping, the interface is confusing, help and find are buggy and jam the editor, basic functions (for me) are missing. My point is: it doesnāt have to necessarily compare to a specific IDE, but please let savvy users do their scripting thing in their IDE of choice (be it VSCode/Codium/JetBrains/Visual Studio/NeoVIm/eMacs/SublimeText, you name it).
I understand Iām slightly hijacking this topic, so Iāll stop here, but soon I would like to plead this cause in a dedicated thread.
Youāll always end up with multiple List Item components or similar ones (or you need to entwine/ perform extensive data management):
I find this topic especially relevant when recalling an earlier thread where McNeel mentioned that
If thatās the case, then keeping GH1 evolving shouldnāt be seen as wasted effort ā itās still the daily tool for most users. Many of the ideas shared here (better Rhino integration, loops, UI polish) could strengthen both GH1 and GH2ās future. It would be great if this feedback didnāt just fade into the transition but helped shape how the ecosystem grows in the coming decade.
I would love to be able to toggle between the graph view and some kind of code view. So I can work in either and can toggle back and forth whenever I want. Iām not sure how it would work or if its even worth it, but conceptually i like the idea for being able to flip between the 2.
This would allow for AI to help me with my graph and understand my graph better. And then I can use the benefits of the graph for troubleshooting, visualizing, getting specific outputs, etcā¦without having the downsides of logging/print statements if traditional code.
This is a really good topic and question in my opinion, also answers are really interesting.
My problem with the ārebuiltā idea however is I donāt believe it is a good idea for GH generally. Total rewrites are generally very risky in terms of success, especially for such successful tools.
Iāve checked yesterday that I have 30+ plugins installed for GH. Itās very rarely for me to have a full script doing something without any external plugin. I also still look for information about GH in the web a lot to solve something, and I very often find some existing useful info. What Iām trying to say is IMO GH success is a combination of a great product + community phenomenon that happened. Without the community and external plugins such tool is not that powerful. Expecting that the same phenomenon will happen again (no matter how good the rewrite could be) is questionable.
Especially when the rewrite is completely different than the original version. It takes some time to learn any node editor. It takes some time to learn how to create custom plugins for any node editor. Iād have to have really crucial problems with GH1 which are solved by rewrite version to decide that Iām okay to spend months to learn the rewrite. But then when I look at the problems I have, they are not that much painful.
TLDR In my opinion GH1 is too good for the total risky rewrite. Iād prefer small improvements on GH1 version instead.
Just to add on a top of this: simple change of area and volume components some time ago made a big stir in my work as the new components disconnected themselves. Imagine tracking down 100 of them among 7000 components, some inside blocks, in several different scripts.
Any larger updates could become a real headache for established workflow.
With the rise of generative AI and code synthesis, the notion of dedicated, static node sets is starting to feel outdated. A more modular, connected, and intelligent system could transform Grasshopper 2 into a living, evolving ecosystem ā one where functionality is shared, composable, and truly on demand.
Iād love to see Grasshopper evolve toward a dynamic, on-demand node system ā essentially a global pool of all existing nodes (official and community), where components are searched, referenced, and loaded only when needed by a particular definition.
This would be similar to how modules or classes work in traditional coding: you simply import what your script requires. Grasshopper could follow a similar pattern, automatically fetching or virtualizing nodes as needed, keeping the environment light, fast, and organized. Grasshopper could suggest, generate, or combine nodes dynamically based on intent or description.
Beyond that, I imagine this as part of a shared codebase or distributed node repository, where individual contributors donāt have to maintain isolated plugins anymore. Instead of 100 people building 100 plugins (some with overlapping nodes), we could have one collective, modular library ā where each node is a unit of functionality discoverable through a dynamic smart search interface, independent of who authored it.
Contributions could be versioned, improved, and merged all while keeping the node discovery process unified and transparent.
And this model could also support paid or premium nodes, where co-authors can choose to license or monetize components within the shared ecosystem. Instead of requiring upfront plugin purchases, access could be usage-based, with a lightweight token or per-compute model. That way, authors are rewarded when their nodes are actually used, while users can freely explore and integrate both commercial and open-source nodes within the same dynamic framework.
Isnāt that pretty much what Yak/the package manager does?
Not quite ā Yak is great, but it still works at the plugin/package level, not the node/function level.
What Iām describing is more granular: instead of installing an entire plugin just to access a single useful node (like a mesh edge analyzer), Iād like to search for that functionality directly, see a list of available nodes across all sources, and load just that node on demand.
So, rather than managing dozens of plugin installations for only a handful of components, the system would let me reference or fetch individual nodes > more like searching a global function library or AI-assisted code repository.
This approach would also enable AI-assisted discovery: the system could suggest related nodes or algorithms from across libraries that might fit what Iām doing even ones Iām not aware of or donāt know the right terminology for. For example, if Iām working on a pattern, Grasshopper could propose relevant nodes or generation methods automatically ā e.g. āserpentine,ā āCairo pentagonal tiling,ā or āPenroseā and even show a reference image plus or an example script/definition to drop in.
What Iām suggesting is an intelligent, node-level search and suggestion layer on top of that something that makes Grasshopper lighter, smarter, and far more discoverable.
This could even evolve into an āexpert modelā, where Grasshopper understands what youāre trying to achieve and proactively suggests nodes, patterns, or workflows ā¦ almost like a domain-aware assistant that bridges geometry, data, and logic.
Ah yes, that would indeed be cool. But would probably be quite difficult in practice (i.e. because a component may depend upon e.g. a .dll that ships with the Yak package).
