Ask HN: With advent of SPA, are Rails/Django still relevant?

4 points by InGodsName ↗ HN
SPA isn't possible in these Frameworks right?

So if we can't use these frameworks then what should we be using instead

4 comments

[ 3.0 ms ] story [ 23.1 ms ] thread
Both frameworks support API-centered design. Your question doesn’t make much sense without knowing what your requirements for an application are, beyond 5hst it be rendered to the user as a single-page.
SPA is not a panacea for anything. It's also quite possible to integrate an SPA framework with a backend framework, they are orthogonal.

An SPA framework generally executes on the frontend in the users browser as Javascript. There may be build tools like webpack and browserify and babel, or one may y a simple spa.min.js file to include. Polyfills may be needed, even for such simple things as Object.values, as Javascript support varies across browsers and version.

The 2 backend frameworks you mentioned allow for front-end templating, which you really SHOULD use in lieul of the SPA-centric solution of "server-side-rendering" which basically takes advantage of Node.js running Javascript by hacking a client-side JS "template" to be processed by Node.js, which, unless your backend is ALSO Node.js based, requires an additional process and a totally different set of server tools than either Rails or Django.

There are a whole crop of app designs that basically use whatever backend with whatever SPA front-end in a more minimalist cohesive fashion. The basic idea is this:

1) server-template-rendered pages (NOT an SPA blob) that already have data affixed in them delivered as a response to a request on a given route path

2) judicious usage of Javascript on the front end only where needed, usually following the pattern of

A) the template assigns templated data to a Javascript object B) a Javascript virtual dom is created and mounted based upon the data in A C) normal XHRs or wss are used to send/get data from the server, with the response callback in an XHR setting the returned data into the Javascript object again, causing the Javascript virtual dom to redraw, as the data has changed.

Best of both worlds...

the main takeaway is to avoid making people wait for an SPA blob to download and then load it's data if the person is actually just interested in checking the contact info page, etc. SPAs serve a specific purpose, as a kind of interactive brochure that one is prepared to wait for initially, but later should move around quickly amongst it's various pages. I would go so far as to say that an SPA only really works best when the concept of "pages" is thrown away.

Rails has also influenced an entire new generation of frameworks in other languages like Amber, so the principles and concepts DO translate. there are active-record implementations in several other languages circa 2018
If all your business logic and validation are on the client side, you have either a trivial app or a security disaster waiting to happen.