Hey there @miljkovicmisa, great questions!
I’ll do my best to answer as many of them as I can in sufficient detail.
Tracking scripts, CTAs, and Forms
Spoiler
A common thing to do with SPAs is to handle routing so you can effectively have multiple different page-views in the same page. HubSpot as of today does not currently support URL routing. That doesn’t mean you can’t achieve the same effect though through other means like using query parameters instead of actual page URLs or other techniques.
I bring this up because it’s related to your question of loading the tracking scripts - if you’re not loading a new page and initializing the tracking each time it impacts what your data looks like.
This issue isn’t specific to HubSpot, and thankfully most analytics tools provide ways to accommodate for this. In most cases you load your analytics script on the page like normal, then use JavaScript functions to signal to the tracking script to log page views and events.
Google has a great doc that shows how to do it with Google Analytics.
Similarly to Google Analytics, you can do the same with HubSpot’s tracking code.
Regarding forms and CTAs their code only needs to be loaded as needed. Because both CTAs and Forms scripts modify HTML you want to ensure that your reactive code will not overwrite what those scripts inject. My method for handling this with Vue.js is to create an element surrounding the script tag, and apply a v-once. There may be a more elegant solution, that’s just a quick and simple way of doing it. Offhand I’m not sure of the React equivalent, but I’m sure one exists.
BarbaJS
Spoiler
I haven’t personally used barba.js but have worked on a project that used something similar. My understanding of Barba.js is that it tries to “fake” that routing experience with real pages. This technique may have some pitfalls when it comes to handling the loading of scripts, barbaJS has some hooks you can use to work around this in combo with the notes on script handling above. Unfortunately though the way barba.js works it likely will try loading the tracking codes every time you navigate to a new page. You may be able to wrap the {{standard_footer_includes}} in an element and tell barba.js to ignore it. I’d consult their Slack and GitHub for solutions to ignore blocks of code when transitioning to a new page. It’s likely a common question.
SEO and performance pitfalls
Spoiler
Generally most SPA advice is not specific to HubSpot, and you have the same considerations for all other platforms. There are a lot of great articles about performance of SPAs and websites in general though the recommendations are all based around these principles:
- Only send data to the client that it actually needs, when it needs it. (This applies to everything from images, to data, to scripts, to CSS).
- If it’s highly probable that data will be needed soon - give the browser hints to be able to prepare, perform preconnects, prefetches, etc.
- Compress/reduce the data being transferred as much as makes sense.
- Minimize the DOM manipulation that needs to actually occur to prevent slowness in client side rendering.
- Server-side rendering on HubSpot may look different than you’re used to since you’ll be using HubL.
SEO wise you can use JS to update meta tags as needed for different views, and Google states they do see those updates. Due to our current lack of page path routing at the moment, there may be limitations to how Google handles the meta information for the separate views. You may be able to work-around that by having clones of your page at each of the possible real webpage paths that your SPA would have for your views, and writing your code to show the correct view based on the page URL.
Can you build a performant SPA on HubSpot, yes. SEO may have technical limitations/challenges on the SPA itself due to lack of routing.
Is it worth it at the end of the day to build a SPA?
Spoiler
Use the appropriate tool for the job. If you’re making a brochure site - where it’s not super interactive, and is mostly informative and marketing focused. Then building it as an SPA likely isn’t going to give you benefits that really justify it.
That same site however could have SPA style pages where it makes sense. I’ve personally done this. For example: a product customizer page may have tons of views, and interactive elements. It makes total sense to use a reactive framework and potentially treat it like a single page app. That doesn’t mean the entire website needs to be an SPA just because you want to provide that experience for one page.
Consider the quality of the content editing experience you want to give content creators. If you go all-in on a framework, are you ensuring that they can still drag and drop? Are you ensuring that your code looks good in the page editor?
It also matters who the content creators will ultimately be for your project. If it’s likely to be just you and other devs, then likely that content creator experience isn’t something you’ll invest in as much as focusing on making your code easy to work in. If the content creators will be marketers, then you definitely want to make sure they have easy ability to control things. I suggest collaborating with the stakeholders and identifying up-front what should be customizable in the page editors.
Thank you so much for the great questions! If you have any follow up questions I’m happy to chat on our developer slack. We’ve got a channel for #js-frameworks-in-hubspot-cms, love to talk to you there about it 