Deciding Which Node to Use?

Rookie question: What is the logic in deciding which node to use when there are several that do more or less the same thing? For instance - there is a View.IsTemplate node in Clockwork, and a View.IsTemplate in the OOTB nodes. Off the top of my head there are several iterations nodes to get & set parameters (case insensitive & type/instance are at least mostly obvious.)

@Chad_Clary

The logic is: if it works it works.
It’s all zero’s and one’s. Start thinking if 1+1=3.
And … if Node to Code gives you something nice you’ve chosen the right node.

Marcel

Whenever possible I stick with OOTB nodes, as they are less likely to be deprecated as the result of a new OOTB node making it obsolete. It also means you don’t have to worry so much about “why doesn’t person X have package Y installed” when troubleshooting why I graph isn’t working.

4 Likes

The logic is: if it works it works.
…
And … if Node to Code gives you something nice you’ve chosen the right node.

Good logic! I’ve not tried the node to code - I’ll keep that in mind though.

:beers:

Another consideration is what the node offers. Using the nodes you referenced we can see that the OOTB appears to not work with all view types and the clockwork one does.

imageimage

I do agree, that it can be tough using custom packages for a variety of reasons, but for the most part, us package creators are pretty nice people. :slight_smile:

10 Likes

Understatement of the year

4 Likes

A little bit off topic - but still there is a problem on the table with having all the needed packages installed.
There is an issue placing set of packages on the local server in teh office and everyone in the office to access them. - Correct me if I am wrong .
So for me sticking to OOTB nodes is better. Of course I love what all the package creators are doing but you can undertsand my point.

I’ve seen this exact environment work quite extensively. Are you having issues? Feel free to PM me.

Until you run into something that does not exist of course. :wink:
MEP Space Nodes anyone?

1 Like

Of curse! When something is not existing may be the best way is to write Python and not even create custom node because again you face the problem that if someone else is trying to run your script he should have the custom definition as well.

Completely understand your concerns. (This thread is probably not best for this though, lol)

That being said, I’m not about recreating work that is already done.<- (In reference to recreating nodes all in python)

1 Like

Neither am I. I regularly deprecate clockwork nodes that have OOTB counterparts. Every custom node that doesn’t need maintaining any more is a good node.

2 Likes

@Andreas_Dieckmann, I wanted to clarify my comment a bit.

My comment was definitely not about the clockwork counterpart from above. It was in reference to,

I was just imagining someone painstakingly recreating ZeroTouch nodes with Python just to eliminate a dependency on a package. At the end of the day, hopefully Dynamo 2.0 will fix the issue with knowing where nodes came from and whatnot.

2 Likes

No worries John. No misunderstanding here. Just wanted to voice my agreement with what you wrote.

2 Likes

I get the different functionality, but that is kind of why I asked. Assuming I don’t need a view that the OOTB node can’t get, is there any reason to pick one over the other?

And yes - package creators are awesome! :beers:

1 Like

Hey, if it works, it works. :slight_smile: Using an OOTB node also eliminates some of those dependencies. Which often makes it easier to share?

3 Likes