One of the most popular tools in the Computational Design (CoDe) space is Grasshopper. It's a powerful tool that let's you do a wide range of things, ranging from parametric modelling to structural optimization to particle simulation. It's known as a visual programming tool, letting you essentially script the steps needed to accomplish your task but not as granular as actual programming.

We -- the people in CoDe Space -- tend to use Grasshopper for everything in our day-to-day work. The tool has this alluring promise of endless possibilities. This promise often hides the flaws in plain sight and we try to do things with Grasshopper that it was never designed for.

So this article is me making a case against Grasshopper for certain projects. It's about identifying situations where Grasshopper shouldn't be used. We can use Grasshopper sparingly in these scenarios or create bespoke tools -- by programming -- to solve these situations. But the idea is to be aware of Grasshopper's inherent limitations.

Large Scale Collaboration

Grasshopper scripting is very much a solo activity. Without any collaborative features like shared editing or version control. It's difficult to use Grasshopper in a team environment, especially if the team has more than 5 people.

Collaboration is made even harder because of Grasshopper's flexibility. You can get the same result through many different steps. This means it's harder to set standards and structure to the way people work. I.e. You can't tell people to always extrude a curve first.

In programs like Microsoft Word or Excel, not only do you get shared editing, you can define templates for people to work off. This shared understanding of the structure makes it easier for people to work together. So unlike these programs, teams need another way to manage their Grasshopper scripts.

There are a few workarounds for this problem. Techniques like Space Grabbing or setting up a Distributed Data Model (DDM) for the project with your team members will help manage a team of Grasshopper users.

The bottom line is that collaboration in Grasshopper is possible but you have to put your own measures in place because Grasshopper won't help you out. Unlike other programs, Grasshopper doesn't give you a native team environment to work in.

Large Scale Script Usage

One of the most enticing things about Grasshopper is the speed which you can build a tool for others to use. This speed comes from Grasshopper being an environment where you can forgo all traditional software development needs, like a User Interface (UI) or the code architecture.

This speed comes at a cost. Namely deploying and maintaining Grasshopper scripts is quite difficult. Not to mention the user experience (UX) of the tool can be clunky and overwhelming. Each of these problems deserves a closer look, let's start with the first one.

No Proper Deployment Pipeline

Grasshopper scripts are just files that sit on your computer. So for someone else to use your script, they need to copy your Grasshopper script onto their own computer. That means, If you have a 100 users, they need to make a 100 local copies of your Grasshopper script.

This gets messier if your Grasshopper tool is made of multiple scripts and uses external plugins. Not only do they have to copy your Grasshopper script, they also have to make sure that they have all the right plugins and other relevant files on their computer.

You might get away with doing this for a few people but certainly not 100. if you have resources in IT -- or the skills -- you can deploy these files to their computers using code. But these are all band-aid solutions to a problem that Grasshopper was never designed for.

Hard to Maintain

Once you do get your Grasshopper tools to your users, how do you roll out updates and bug fixes ? Since Grasshopper scripts are just files, you either have to override them or you have to manually update them. Overriding the files is problematic because there might be local changes, you users have made that they want to keep.

As hard as it is to deploy Grasshopper files, it's even harder to maintain them because unlike traditional software development, you can't just release an updated to the tool, you have to manually roll out those changes.

Bad User Experience

It is very likely that the users of your tool have little to no Grasshopper experience. This makes for a bad UX because the Grasshopper script can look like a rat's nest to them.

Imagine, if you were new to Grasshopper and that is the first thing you see

There are again some workarounds to this by using UI plugins like Human UI or the Rhino RCP panel. But your users will inevitably come face to face with the raw Grasshopper script. Although this problem is small compared to the last two, the UX of your tool should still be an important consideration.

Processing Large Data

Another attractive feature of Grasshopper is it's similarity to other traditional programming interfaces. Its granular control and speed makes the scripting experience very inviting. This creates the impression that Grasshopper performs similarly to other programming interfaces. After all, Grasshopper is known as a visual programming tool.

But there is significant amount of background logic that Grasshopper is doing to make the scripting experience so seamless. This additional processing is a burden for handling large datasets. if you need to process a substantial amount of raw data -- numbers and text -- then Grasshopper is not an efficient solution.

This is because Grasshopper keeps the states of your data at any given time. This is what let's you work with components in a non step-by-step way. To understand this, let's look at an example of what a computer sees when you try to move a line.

When you are doing this with a traditional programming interface -- like C# or Python --, the program "throws" away state A and only keeps state B in memory. This means, if you needed to keep state A, you have to explicitly tell the computer to keep it. Now, if we compare that to a more Grasshopper way of doing things.

Grasshopper doesn't "throw" state A away because you might have to use it later -- like rotating the newly created line. So instead of cleaning up old states, Grasshopper keeps the states of all the components in the canvas. This leads to a very smooth scripting experience but if you have 1 million objects and 100 components on your canvas, you can start to imagine that this overhead drastically impacts the performance.

Like with all the other problems, you can get around this by using the scripting components in Grasshopper or you can make your own components which gives you access to parallel processing and more.

Final Thoughts

Grasshopper is an incredibly powerful tool that offers great possibilities. But, like all tools, it has its limitations and challenges. We need to be mindful of these challenges when we use Grasshopper, especially when we try to use it in large teams or as a tool for others.

Knowing these challenges will help you make better decisions on when and how to use Grasshopper. It doesn't mean that you should stop using Grasshopper altogether. But it does mean that you need to be mindful of its limitations and that there might be other tools out there that are better suited for your needs.

Remember, the best tool is the one that helps you get your work done most efficiently.

Thanks for reading

Braden