Developing in NetSuite — what it’s really like!

The NetSuite platform allows customizations via 3rd party code. This is a review of what development for NetSuite is all about.


NetSuite solely uses JavaScript, referred to by NetSuite as SuiteScript. Using JavaScript on the client side most developers would be familiar with, but NetSuite also uses it on the server side. A lot of business logic can therefore be run either on the client or server side, or both. Although seemingly beneficial, in practice there will be few occasions where this will prove useful. The positive is that the NetSuite core libraries are identical on the server and client side, so it’s easier to learn.

As an example, let’s look at the API to get the contents of a remote URL: nlapiRequestURL. This API connects to the url passed in as parameter and returns an object containing details of the response. For SuiteScripts, this API is available in client and server scripts, which is kind of cool because cross site scripting limitations mean you can’t do this kind of thing on the client side directly. So what NetSuite does is pass it through the server (behind the scenes) when it’s called from the client side. It’s one less thing for developers to worry about, it’s just that the request will take longer.

Client side

Using JavaScript makes client side development very powerful. Because JavaScript can be used to manipulate the Document Object Model, a developer can do just about anything such as including external JavaScript from other websites. As an example, this is how we created this TotalCheck address validation integration. But because NetSuite uses neither jQuery nor Prototype, it either means going back to basics, or you need to include jQuery yourself.

Server side

On the server side, the NetSuite core libraries are very basic, apart from all the built-in APIs to manipulate the NetSuite data, helper libraries, such as an XML parser, are not built in. Also, because NetSuite is fairly unique in using JavaScript on the server side, you will also struggle to find many helpful community open source libraries. Nowadays backend developers are spoilt by frameworks such as Ruby on Rails or Django and have all the tools at their disposal such as geo-location libraries, XML parsers, image processing, and integrations with 3rd party services such as Amazon S3. Nothing like that will be available for JavaScript.

Script types

NetSuite has these four main types of scripts: Client, User Event, Scheduled, Suitelet. There are more types but these 4 will highlight all the possibilities of the platform.

Client scripts are exactly what you’d think, they run on the client side. You can write code on a set of events which happen on a client form: page init, field change, save, etc. These handlers are intended to perform custom input validation but you can do very advanced client side stuff as there is no limit to what JavaScript can be executed.

User Event scripts run on the server side, in response to records being opened or saved. The script runs on the server side. In particular the “Before Save” handler is useful as you can use it to make further modifications to records when they are updated.

Scheduled scripts can be run on the server at scheduled intervals. Apart from the obvious use case, to run certain checks on a daily basis, these types of scripts are also used to deal with script governance. A script is only allowed to take a certain amount of time and resources. So if your script has been running for too long, you can write code to handle this elegantly by rescheduling itself immediately. This doesn’t mean it executes over several days: when a script invokes a scheduled script it is run almost immediately again, this just seems to be the way NetSuite manages the server load.

Suitelets are also server side scripts and behave like web apps. This script type allows you to build up custom pages and forms, and handle GET/POST requests from them. NetSuite has a library which lets you build up a NetSuite-style form in your Suitelet, but you can also create custom HTML output.


All script types enforce governance, which means you can only use a limited number of resources per script execution. This is to prevent scripts running on the NetSuite servers from taking too long or putting too much of a load on the server. For client scripts there are also governance limits, which apply to the APIs which interact with the server side.

Development environment

When you want to develop an app for NetSuite, you can get a free development environment. The environment seems to be fully functional and it comes with accounts for two developers. When you are ready to release your code you can create a bundle using SuiteBundler. You can control where to deploy your bundle or you can even make it publicly available.


So, on one hand developing in NetSuite is quite powerful. There is really not much that cannot be done. But like many things in NetSuite, this comes at the trade-off of ease of use. In terms of the development framework, this means it doesn’t have some of the features that mature platforms nowadays offer out of the box, such as:

  • No source code version and release management. This is sorely missing from NetSuite. To make a change to your code, you upload a new version of a file to the file library. When you collaborate with other developers this can cause problems. You need to implement your own deployment strategy while your app is under development.
  • No testing framework. Modern, mature frameworks have us spoilt with all the tools to do coverage testing, automated unit testing and regression testing. NetSuite offers nothing of the sort, which is especially painful given that JavaScript is not a compiled language.
  • No ability to store application values. Something like the registry on Windows. There is no ability to store for example simple name/value pairs. The only way to store persistent data is by creating records.
  • Lack of server side libraries. I’ve named some examples before. Not having the in-built ability to for example parse XML is something you can work around but it just means more work to build apps. Partly because JavaScript is the server side language, there are no communities providing libraries either.


If as a developer you are choosing a platform to develop for, NetSuite is not an obvious choice. Be prepared to read a lot and spend a lot of time developing things from scratch. But if you are being asked to create an app for a customer who already uses NetSuite, what the client asks for is almost certainly possible, because there are almost no limits to what can be customized. But with power comes great responsibility.

6 thoughts on “Developing in NetSuite — what it’s really like!

  1. Adam says:

    Just thought I’d weigh in with my 2-penneth having spent the last year or so working on-and-off on customising Netsuite for a client.  Personally I have found the whole experience thoroughly depressing and, whilst I finally feel like I have enough of a handle on things to be able to get jobs done without wading through pages and pages of docs, changes are rarely as straight-forward as you would think, usually hard work and never ever fun!

    For me the biggest problem is the docs.  Granted there are plenty of them but they go on and on and on and are full of buzz-words and marketing terms that to my mind just make them even harder to read.  I remember when I started, I kept getting completely brain-fried trying to figure out whether I should be looking at the docs for ClientSuiteScript, ServerSuiteScript, SuiteBuilder, SuiteFlex, SuiteFlow, SuiteTalk etc etc etc and not being able to find a suitable simple definition for each.  On plenty of occassions I have been caught out by out-of-date documentation.  And Netsuite have now just rejigged it all, I’m sure to deliberately hide things  from me again, now that I had started to know my way around 😉  To me Netsuite feels like a bad hangover from a bygone age of software development.  Both jQuery and Rails have been mentioned in the comments and for me they both provide an illustration of what is great about modern-day programming and why Netsuite doesn’t feel like a modern-day piece of software.  Both of them are quick and easy to get started with, generally don’t require a great deal of work in order to get a working result yet have the power under the hood to do pretty much anything you ask of them.  Sure Netsuite generally has the power but whether or not you can find it is another matter.  I have also found myself resulting to nasty, dirty hacks on numerous occasions – particularly when customising the customer-facing web front-end.   I generally try to take pride in the code I produce and that is something that you are often forced to abandon when working with Netsuite.  Netsuite feels very much like something that does 10,000 jobs in a mediocre (or sometimes inadequate) way rather than excelling at anything in particular, a mindset typical of many other pieces of software produced at the turn of the century.I would agree with you Vincent, Netsuite’s script debugger hardly constitutes a testing platform.  It’s basically an equivalent to something like Firebug (tho to be honest even Firebug kicks seven shades of *&%$ out of it) and may or may not be of use depending on what type of script you are developing.  Lyle, you said Netsuite is not an IDE which is completely true, but the way that we have to develop for Netsuite means that most of the tools that we usually turn to on a day to day basis will not work.  Therefore in order to develop software at the level we would like, I don’t think it is unreasonable to expect Netsuite to provide suitable replacements of their own, particularly since they seem to have little regard for the conventional ways of doing things preferring instead to force developers to adjust to their way of doing things.  As for version control, I settle for keeping my own script library in a git repo but there are plenty of things this doesn’t cover and it would certainly be nice to have something built-in.

    I noticed elsewhere on your blog that you are looking to start a Netsuite focussed StackExchange site.  Well I am off to give my vote for that and would definitely use it, but to be honest I think the reason there is little community support is that Netsuite is not a product that inspires a community.  As a business their questionable sales tactics are well-documented else where on the web (incidentally that dev environment you said was free my client was told would be £1000 a month!), whilst development on their platform is a difficult, time-consuming and un-rewarding process.

    Anyway, I have ranted more than long enough but to finish I will say that if I was sat in a room with the Netsuite devs I would ask them to stop thinking about what they can add to Netsuite and start focussing on what can be removed, retuned, refined and improved



    • Hi Adam,

      I couldn’t sympathize more with your comments. NetSuite try to be everything without being great at anything. If you look at other emerging, successful products and services on the web that are currently emerging the opposite is true.

      The enterprise market they are trying to capture are surely very impressed with NetSuite feature list. Salesforce doesn’t compare feature wise but what it does is much better. With products like this, they tend to be almost exclusively bought by the people that don’t have to live with it day-to-day.

      Anyway, just glad there’s someone out there sharing some of the same frustrations I’ve had as well.


    • Hi Jason,

      First off, I’m not familiar with Volusion, but that’s an ecommerce solution, right? NetSuite is much more than ecommerce (it’s also an ERP and CRM system). Are you just after a website front-end, or do you need to a business management backend as well? Do you also sell goods offline? What volumes are you shipping? Those are just some of the questions that come to mind.

      From a developer perspective, I really like Magento. This is because it allows you to build anything you could ever want in your ecommerce website. The management side is very simplistic compared to a complete CRM/ERP system like NetSuite but can still serve the purpose of some small/medium sized businesses.

      What’s your experience with Volusion? Have you used it in any project?


  2. Myoung Son says:

    Nice Post Vincent. We use NetSuite as well I have come to LOVE and HATE NetSuite. =( I love the fact that as a developer, you can almost customize all solutions if you really wanted to but hate it in a sense that it’s not clear sometimes. One note about your code versioning. I do agree with you and we use SVN to keep track of the changes. 

    • Thankyou. Yes, SVN is the solution there. That way, I guess it’s just a matter of being diligent of checking in before uploading code to NetSuite and keeping your code up to date.

      As long as all contributors do use the same repository. A problem for me was that the developers from NetSuite Australia themselves had their own way of uploading and it just added a lot of overhead…

      I think Heroku’s mechanism is fantastic. Heroku is a Ruby on Rails hosting platform. The way to upload code is just to commit to the heroku instance’s repo. Heroku use git instead of SVN but it means that when you upload files they get merged instead of overwritten!

Leave a Reply

Your email address will not be published. Required fields are marked *