As developers we are perpetual students. We work in an industry where the only constant is change. NetSuite recently released the 2nd version of their SuiteScript API. The new version made promises(literally) of asynchronous execution of scripts, the ability to process large amounts of data without governance and a smaller footprint by using the global objects more effectively. The new API improved on some of the flaws of the 1st version of the API (SuiteScript 1.0). It was sleek, fast and definitely cutting edge but when do you adopt this sleek new API? Do you stop coding using SuiteScript 1.0? What is the cost to move forward? Do the obvious performance benefits outweigh the learning curve associated with adopting the new API?

Moving to SuiteScript 2.0, or any new API, is sometimes warranted by necessity to use a new feature. The ability to use promises to speed up execution would be necessary when a script was taking too long using the old synchronous execution methodology. The benefit here would be faster execution times.

The map/reduce module is yet another reason upgrading may be an easy decision. The need for speed again is key. Not only does map/reduce support asynchronous execution of scripts but it also supports a larger data set. More data less time!!! It’s hard to turn away from SuiteScript 2.0. Any of us who have had any experience with governance will appreciate this method too as its not subject to the same rules as SuiteScript 1.0 scheduled scripts were. In the end you get more done with less cost.

Even the smallest change can be the biggest attraction. The message module provides a sleek way to deliver a message to a user when a form is loading. For customizers the ability to provide the user with a consistent experience is key. No one likes clunky alert style errors that are noticeably added to the application after the fact. It leads to amateurish software. The message module allows customizations to look professional and creates a consistent user interface resulting in a happier user.

No major move is without some cost. While the SuiteScript 2.0 has a more object oriented style the change can be costly. The module style requires developers to write scripts in a totally new style. Even the simplest search can necessitate a new script. This is a completely new style to developers who are used to writing long scripts with multiple searches and lines of code that’s far from modular.

The cost of updating existing code to the new style is also an important cost decision. Developers don’t like to waste anything. If I write code to do a particular task and/or function, it’s a finished product. Its thoroughly tested and optimized for efficiency. To use this code in SuiteScript 2.0 would require a rewrite. Luckly Netsuite realized this and allowed the two APIs to coexist but at some point I would have to rewrite code that I know works. A high risk for this reward.

As with any new API at the time of my learning the Intellisense was not working in the Suitecloud IDE. Developers who are taking on the task of coding in this style need all the help they can get. Intellisense is my best friend when I don’t know an API. Not having it when I started this endeavor was like trying to write code in Windows notepad. I could do it but it would be sooo hard to. Intellisense is a core requirement for any new API. Maybe I was an early adopter but this is necessary when making the decision to make a move.

Good, solid documentation and examples are the second requirement to using a new API. Being pioneers doesn’t afford you such luxuries. My experience with Suitescript in general is there’s not a lot of solid examples out there. This fact grows even more when you move to 2.0 the age of the product is evident in the number of samples you can find. This is fine because Netsuite’s core documentation is all you really need to get moving but in this case the samples were limited here too. I could not find adequate samples to see how to utilize a new module. This has changed since this article was written and now you should be able to find adequate samples in Netsuite’s documentation.

So onto the big finale. You want me to tell you to move to SuiteScript 2.0. The answer in my opinion is to move forward in stages. Leave existing code as it is. When new opportunities come up consider using the new API in your estimates. Remember the new features of this API is what drives the innovation. Some of these features are unavoidable. The need for these features will thrust you into this amazing new API.
If you’re looking to transition your NetSuite implementation to the next level with SuiteScript 2.0, you know where to find us.  Happy coding!!!