SuiteCommerce and SuiteCommerce Advanced are two web applications built by NetSuite to run on the NetSuite platform. Their codebase is identical on a fundamental level, but there are crucial differences in how this code can be accessed by developers that means that they should be treated as two separate products.

Note that due their similarities, it is common to use the term ‘SuiteCommerce’ to refer to both products. For the purposes of this article, we will be careful to use each term in a specific way.

Locked Bundles vs Unlocked Bundle

So, if we start from the understanding that these two products ‘run the same code’, as it were, the question becomes: how there can be a technical differentiation between the two? From a technical point of view, the most fundamental difference is that a SuiteCommerce web store runs from a locked bundle, whereas SuiteCommerce Advanced is unlocked.

In terms of NetSuite, this means that source code upgrades and updates are handled by NetSuite. When new code is available, it is pushed out to accounts that have the bundle. This is what makes the SuiteCommerce edition more of a ‘software-as-a-service’ offering than the Advanced edition. For more information on this release process, see The SuiteCommerce Release Process.

For a developer, what this means is that you are able to modify all of the source code in a SuiteCommerce Advanced web store, but not in a SuiteCommerce web store. Since the introduction of The Extension Framework and Extensibility API it has generally be good practice not to do this anyway, as it is usually preferable to layer your customizations on top of the source code, rather than making customizations to it directly.

How Do You Customize a SuiteCommerce Site?

So, if the bundle is locked, how do you customize the web store? We have built a number of interfaces and mechanisms that allow you to plug new code into the code base. The collective name for all of these is Commerce Extension Framework. There are three important parts:

  1. Extensibility API – a layer of JavaScript that runs throughout the SuiteCommerce code base that has components for various areas of the web store, methods for manipulating the DOM and triggering actions, and events that listeners/handlers can be attached to
  2. Extension and Theme Developer Tools – your customizations are developed locally using specialist proprietary tools, and are split up into extensions (functional changes) and themes (look-and-feel changes)
  3. Extension Manager – after deploying your changes to your NetSuite account, they are compiled together and activated on your site’s domain, so that they are called when a user visits your site

An illustration of how the SuiteCommerce bundle has multiple layers and APIs that connect them. Extensions and themes plug in to the extension management system, which connects to a SuiteCommerce site via the extensibility layer.

In other words, your customized code runs as a separate layer to the core code of your web store (which we, NetSuite, provide).

It is also worth pointing out that changes to a web store can also be made through the Site Management Tools, various configuration records, enabling features, and other avenues such as bundles, SuiteApps and scriptable cart.

What are the Benefits of Developing on SuiteCommerce Versus SuiteCommerce Advanced?

As SuiteCommerce runs as a locked bundle, the biggest benefit is that it is automatically updated whenever a new version comes out. This makes it a good choice for people who prioritize getting the latest and greatest core features.

Conversely, web stores running on SuiteCommerce Advanced bundles are not automatically migrated to new versions. Some people prefer this as it means that they have much more control over the code their site runs. Therefore, SuiteCommerce web stores are much closer to a SaaS (software-as-a-service) model than those running SuiteCommerce Advanced, which could be characterized as being as PaaS (platform-as-a-service) model.

Do note, however, that we are talking specifically about the web store bundles here: some new features that can affect web stores are delivered through alternative channels, such as the NetSuite application core code, extensions built by NetSuite, and other third-party customizations. However, the majority of our new features, enhancements, and issue fixes, are delivered through either an update to the bundle, or through one of the other channels which also requires you to update your web store’s bundle.

In short, running SuiteCommerce is the easiest way to ensure you are running the latest and greatest NetSuite code. Sites built using SuiteCommerce can be built much more quickly, and require far less effort to maintain. Conversely, SuiteCommerce Advanced offers more freedom to the developer to make ‘under the hood’ customizations.

Depending on the complexity of your customizations, you may find them difficult or even impossible to do on SuiteCommerce; therefore, in those scenarios, SuiteCommerce Advanced may be a better fit.

What are the Limitations of Developing on SuiteCommerce Versus SuiteCommerce Advanced?

As mentioned, the primary mechanism for introducing JavaScript-powered customizations to a SuiteCommerce site is through the extensibility API. While this has component coverage for a much of the site, numerous methods, and also cancelable events, there will always be things not covered by this API. Depending on your customization’s requirements, you may find this limiting.

A temptation for a developer, at this point, would be to introduce customizations that touch core modules and classes. For SuiteCommerce sites, we consider this bad practice, and this is because of the SaaS nature of the product.

As the core bundle is automatically updated on SuiteCommerce sites, you run the risk of your customizations (and possibly your site) breaking following a code upgrade. For example, if a developer extends a core module to add a new method and we change the way that module behaves, the customization may longer work as expected. In a best-case scenario, an auxiliary feature no longer works; in a worst-case scenario, the site no longer functions and orders can no longer be placed.

You may not think it likely that the module you are using could change, but as we migrate our code to TypeScript and SuiteScript 2.0 you may find a seemingly stable module or method no longer behaves as expected.

Those with longer memories, may remember the Elbrus release where we split the Item Details module in multiple smaller modules.

This issue may not arise on a SuiteCommerce Advanced site as a developer has much more control over how and when the core code is upgraded, giving them more time and space to make necessary changes to avoid a breakage.

Furthermore, we believe SuiteCommerce customers (as opposed to SuiteCommerce Advanced) are more likely to value a ‘hassle-free’ approach to their site — such that developer intervention is minimized as much as possible. Regular work at every release by a developer to test and maintain unsafe customizations could cause costs to spiral.

Remember, while the limitations in SuiteCommerce may be frustrating for developers, we want to emphasize that they are in place to ensure the smooth operation and upgradeability of these kinds of sites. We ask developers write their customizations responsibly, as to not introduce instability to their customers’ sites.

For more information, see Build Sustainable and Stable Extensions.

Can You List All the Limitations Individually?

No. It’s hard to be specific about this when it comes to the types of customizations our customers have built or want to build. I also don’t think it would be beneficial to approach customizations on SuiteCommerce in this way.

The core tenet of developing of SuiteCommerce is that you approach customizations in such a way that you ensure they are non-breaking across versions and sites (ie you ensure the site can be easily migrated to new versions). The primary trade-off of working on the Advanced edition is that you lock the site’s code in time so that you can make fundamental changes to its source. If you are planning a customization to a SuiteCommerce site that brings it so close to the edge where it might compromise its ability to be upgraded, then you should stop and consider whether it is worth it.

In other words, if you find yourself wanting a list of limitations, then it’s possible that you’re already close to or past the limit of what is recommended.

What Practices Should I Avoid in a SuiteCommerce Extension?

When it comes to SuiteCommerce sites, we strongly recommend against involving core modules. For SuiteCommerce Advanced sites, it is more acceptable as your site’s code version will remain stable, but you may run into difficulty when it comes to migrating to a newer version or applying your extension on another site.

This includes, for example:

  • Including a core module in a require() or define() statement
  • Extending (extend()) a core module to add or overwrite a method or property
  • Wrapping (_.wrap()) a core module’s method to change its output
  • Modifying a core module’s or object’s prototype; for example:
    • Use addChildView() to add a child view, rather than SomeView.prototype.childViews.MyChildView
    • Use addToViewContextDefinition() to add a new property to a view’s context object, rather than SomeView.prototype.getContext.MyNewProperty

While discussing this topic, allow me to also include some things we never recommend a developer do in any production code:

  • Accessing a core module’s or object’s private methods (eg, application.getLayout() is generally OK, but application._layoutInstance is not)
  • Accessing the SC global variable
  • Editing core module code directly (if absolutely necessary, we recommend using overrides instead)

But The Extensibility API Doesn’t Have a Component or Method I Need!

Then please tell us. Contact NetSuite support and ask to raise an enhancement request. Let us know things like:

  • What you are trying to do
  • The use cases you are trying to support
  • How valuable those are to your business (eg ‘must have’ or ‘nice to have’)
  • How you might achieve it through modifying core code (if you know)