In specific, if you keep the same programming language, in my case Go, across your applications, you can share a lot of logic, data models, and you get a consistent developer experience, and an easier to maintain system.
This direction may seem unorthodox, but it has many reasons that make it a success, and a joy to work with, and extend.
To give some background, the previous SPA I helped create and worked with, that consumed my API’s data, was created using Vue.js 2, SCSS with scoped styles (horror!), VueX, and TypeScript.
This combination has quickly lead to spaghetti code of terrible quality, and lots of it. To make matters worse, there was a transition of API v1 to v2, where some data models changed, and the developer decided to refuse that change, and write his own mappers, to convert those v2 data models to v1, and vice-versa, in order to comply with my API, which he was interfacing with.
As you can imagine, this has lead to an unmaintainable project, that no one dares to touch.
So I decided to follow my beloved KISS principle, and to go ahead and get started on writing a SOLID coded Go application, that will act as the API consumer, and spit out processed HTML for the client’s browser.
I want to list some of the advantages that I have found, and am sure anyone will find when doing things more in an “old but gold” old-school approach of building websites, server side rendered:
- In my case, one language for the whole platform 😀 Go !
- Native browser features, like remembering how far in the list of the previous page you were when you go back.
- SEO is greatly improved, and you don’t even need to think about it as much. Search engines will easily crawl your site, and will read correctly formed HTML.
- Security improvements, due to not exposing application code, or API calls in the client’s browser.
- Simpler front-end applications, no mapping, no state management, no problems. API data directly to HTML.
- Go is a well designed, compiled, statically typed and concurrent language. Why not use it for client-facing applications?
- The standard library of Go is great, and can power most of your needs without additional thrid-party dependencies.
- High-concurrency and asynchronous process capabilities in the client-facing applications.
- Accessibility is greatly improved due to the HTML being delivered as already rendered, and we can care more about writing semantically correct HTML, instead of caring so much about the newest JS framework.
- Mobile devices, web-views, and embedded devices are better supported, without inconsistencies.
- Cross site scripting attacks risk is greatly reduced.
- Hacking/Defacement through DOM manipulation is no longer possible.
- Severe speed improvements, both on first, and on subsequent loads.
As for the SPA fans out there, I know it has its use cases, but let’s face it, JS is doing so much more than it should since React and buddies came along, this has gotten way out of hand and it is time to stop.
Thanks for your attention, and I look forward to seeing comments.