Good morning, I experimented with the (SPA) Single Page Applications that will be generally available in 25.1. Here were my takeaways if anyone is interested in trying it out. I'm not a JSX/React expert by any means, so would love to hear what other think if you've built something with SPAs. https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_48092943725.html Pros: 1. Includes a very comprehensive list of UI components. Seems to have everything you would need to build complex applications. 2. It was simple to get started and deploy the app for testing. 3. Lots of good code samples and studio where you can try components out. 4. Error logging was usually sufficient to determine where I messed up. Cons: 1. No local development. I could not find a way to test locally without deploying code to NetSuite. I'm used to building SPAs in other platforms like Zendesk/Stripe where you can do local development and see changes immediately. That is very helpful for front-end development where you're trying to tweak small details like styling. Good news is the deployment process is pretty quick - less than 5s. 2. While the base UI components have a lot of capabilities, there are no higher level components that allow you to integrate with native NetSuite functionality such as Records/Transactions. For example there is a DataGrid that can represent lines on a transaction. But you're adding all of the necessary functionality from scratch such as buttons for Adding/Removing lines, totaling amount columns, etc. Another example could be a dropdown to select a customer. With Suitelets, you have the option of specifying a source and NetSuite automatically generates the searching capability. You're not going to get any of that out of the box with SPAs. -- If you're used to building custom forms in Suitelets you might be disappointed by how much additional work is required to make things work. But, you can build much more powerful/friendly/modern user interfaces than you can with Suitelets. I'm not sure if NetSuite's intention was to replace Suitelets with SPAs, but that is what I was hoping to do. Unless NetSuite decides to add tighter integrations between SPA components and common NetSuite SuiteScript modules, I suspect adoption by enterprise customers will be lower and they will continue to be used mainly by 3rd party app builders.

I will give it a try, with the limitations you are mentioning I wonder if this would be better than: vite + svelte which allow me to use pretty much all that + native hash routes.

My first glance at this 'SPA' tech left me unimpressed. We've been building true SPAs on NetSuite for years using widely used tools/frameworks (primarily Angular in our case). I would hate to have to fall back to this tech which seems both proprietary and limited.

@Shawn Talbert How do you handles routes with Angular or React?

Are SPAs still only for SuiteApp projects (vs Account Customization projects) and do you still need to pay for SDN to be able to deploy SuiteApps?

@Mike Robbins I want to say I saw that in 2025.1 it was going to be enabled generally (i.e. for Account Customization projects, not just Suiteapps)

I mean server side routing like hash (#) routing, last time I try it with Angular it did not worked well with NetSuite.

yeah, its been a while but I think that hash (or the history api?) is all about keeping the route changes handled client side - no requests to the server

Just build it on Vercel.

Anyone tried SPAs with Account Customization projects?

We use Angular for SPAs fairly frequently on standard 'account customization' projects.

All the docs I see mention only the SuiteApp method and having a publisher ID (which is available only for an SDN partner). I'm not sure if I missed any documentation, but would you be able to point me to the docs that guide me through developing and deploying SPAs with ACP?

I'm not impressed with the "SPA" capability being introduced by NetSuite so not using it. We have a robust backend API package for NetSuite we call "Mediator" which works great as a backend for a standard Angular build. We host the HTML/JS in the File Cabinet and the SPA makes calls back to our mediator (which is in turn either a restlet or suitelet). That's it.

@Shawn Talbert has a solid approach. Works now and considerate of the future.

We use a thin mocking layer to support local development with fake data, and the mediator includes automated integration testing. It's much closer to 'real' application development than anything I've seen come out of NetSuite, including this new 'SPA' support.

ah okay, interesting. Thank you