There are no tracking or monitoring cookies on this site. There are only cookies used for documentation examples related to cookies.
Close

Processing...
This may take a few seconds.

Single page applications

This section refers to websites that are classified as single page applications.

There are 2 types of single page application websites that we can do in Active CSS:

  1. Websites that use fetch/ajax calls to the server after the first page load to load up further content. This is the most common method of building an SPA, so you can find the documentation on the Regular ajax websites page.
  2. Websites that live in a single HTML file and store page content inside template tags and then load up page content from there when needed. This can be found on the Offline interactive websites page.

Both of these can be done in Active CSS from the front-end, using a front-end routing technique. Obviously you still need a back-end server of some kind to serve the files, whether they are static or dynamic, from memory or whatever.

A properly working SPA will work with the browser navigation, fully. No matter where you navigate to, the page loads as expected, keeping you fully in the SPA at all times - even after a page refresh. You get a smoother experience, and when they are done right they really do live up to the hype. Your website will feel more like an app.

The current official methods for going full SPA are complicated. And that goes for JavaScript methods that are currently being proposed and chewed over. This is because all proposals need to fit in with JavaScript syntax. There is a in-built syntax barrier to simplicity because JavaScript is an API that does not tie in seamlessly with the browser's event-driven context. The browser is an event-driven OO GUI platform. It just is. The objects are the HTML elements, and methods and properties are attached to elements. Inheritance happens on the page. It's a pretty neat and tidy OO experience building sites without JavaScript, and it's pretty simple to work with. It is a great implementation of the OO philosophy, in my opinion.

What happens in OO JavaScript with classes and that sort of thing is of a different flavour and nothing to do with the browser at all. Take a look at it for real. OO in JavaScript is just one of a few programming methods you can use to get things done. It isn't superior to other methods. It's just what you have been taught. JavaScript OO for building websites does not mimic reality, and your lecturer probably needs to take a look at the logic for this. He may be inadvertently helping to make coding more difficult than it needs to be. Why is this? The answer is that the reality of website building lies in the browser GUI interface, which already has it's own OO environment. So there are actually now two OO environments and there is an inherent added complexity when using JavaScript OO for building websites, right there. Frameworks attempt to make things easier. This is the underlying reason why we need frameworks. Most frameworks, however, do not have a syntax designed for the browser, as odd as that may seem.

It does not matter, regardless of any JavaScript programming method chosen - OO, functional, framework or otherwise (and don't get me wrong - I absolutely adore coding in JavaScript) - JavaScript syntax is not truly in the browser context and so is always going to be more complex to work with. HTML, CSS and ACSS are all coding methods designed for the browser. That is why they are easier to work with. They work solely with the OO reality of the browser. All these points I'm making explains why native JavaScript coding is perceived to be hard. To be truly simple to work with, a language syntax needs to fully match the context of the programming environment. That would be a programming maxim. It is a bit late for JavaScript to adjust its syntax too dramatically at this point in time. So you often end up jumping through hoops to get things coded to spec, and you see extremely lengthy debates on how best to extend the JavaScript language itself.

So any SPA method proposed that needs to work with a general-purpose language such as JavaScript is bound to be geared towards more experienced programmers, as it would require more in-depth programming knowledge. Which is fine, for experienced programmers. Regular website developers (who have a life outside coding - I know - weird right?) will miss out though. Plus there will be a massive delay before any final proposal becomes actually able to be used in production due to cross-browser catch-up.

The Active CSS method is a lot simpler. Whether or not it works with what you need is your call to make. If you rely on a lot of JavaScript, it may not be sensible to use. And if you are that good anyway, using popstate events and ajax calls in JavaScript isn't hard to do for one-off projects. I had to do that myself recently, while upgrading an old function-based app to be a true SPA that some other guy had written in native JavaScript. I didn't resort to an overly complex framework just to do this, which would have meant a full rewrite in React and an additional use of the back-end which would have slowed things up in different ways. It was easier, more practical, suited my autistic spectrum speed performance needs, and a lot quicker in practice just to use native JavaScript as I ended up doing, and ACSS wasn't used at all. But to be able to do this, you need to fully understand how JavaScript handles events and the history object, which isn't trivial.

But for regular websites or websites that are built purely with ACSS, HTML and CSS the method described in the following pages is by far the easiest and most logical method to get an app-like experience. Read it carefully and try it out. It really is very logical.