No-JS and AngularJS

How to support No-JavaScript users while using AngularJS?

Currently, DBpedia generates all of its HTML describing a resource at the server, with minimal added JavaScript. Visiting entities that don’t understand JavaScript (security-freaked users and bots) currently have access to all of the HTML shown to the user. However, the whole point of SPA and AngularJS is to use JavaScript to update the page, which results in a clear problem here. At one hand, we want to make a beautiful dynamic SPARQLing SPA and on the other hand, we need to support the visitors that don’t understand JavaScript.

Solving this would require adjustments on both client- and server-side.


When the user lands on a DBpedia entity page from some other page, we query the server. The VSP code of the VAD plugin will generate the HTML and send it back to the user.

To enable AngularJS, we just insert our JavaScripts and alter some HTML at the server.


Now, let’s talk about the client-side (and AngularJS). In the previous post, in the toy setup, we were getting the triples describing some entity through a Angular service that SPARQLs to the DBpedia SPARQL endpoint.

When AngularJS is inserted in the current server HTML response, Angular takes control. It will SPARQL to DBpedia to get the description, putting extra load on the server and the network. We are doing double work here (a solution to this will be discussed in the next paragraph(s)). If Angular routes were configured properly and the URLs are correct, clicking on a link to another DBpedia entity should result in Angular doing its thing (SPARQLing DBpedia and displaying the new entity information) instead of requesting all-new HTML from the server.

We need to avoid double work. The server has already done a lot of computing to generate the HTML when the visitor is landing on a DBpedia entity, which involved querying the triple store. And then Angular sends a SPARQL query to the endpoint, which again results in (the same) querying of the triple store. We distinguish two solutions to this problem:

  1. use RDFa scraper on the HTML
  2. include JSON at the server could be used for the first option. It should be called from the Angular service generating the triples (that currently only SPARQLs to DBpedia).

For the second option, we would need to make a few more alterations of the server code. However, there is probably much less load on the client compared with using the first option. In my opinion, this option is better, but it depends. This option was iplemented in the toy Angular setup as follows: the Angular service that is currently just SPARQLing to get triples about some entity now first looks at the page and searches for a special hidden element in the page HTML containing JSON code. Then it parses the JSON (jQuery.parseJSON) and uses that object for display and then removes the element containing the JSON. It doesn’t query DBpedia. However, this implementation can be considered a jQuery hack, it is not a very Angular way of doing things.

Server-side (again)

When going with the second option (HTML+JSON), we need to adjust some server side code to put the JSON in the HTML. Probably, this results in just a small computational overhead.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s