HACKER Q&A
📣 saurabhnanda

State-of-the-art for server rendered webapps (non-SPA)?


At my company we have about 80,000+ LoC of AngularJS (v1) in production, which we still actively develop and maintain. We've also dabbled with Angular2/Typescript & Elm for the newer features. However, off-late, I am getting increasingly put-off with the amount of complexity SPAs bring into the stack. Especially for user-interfaces that aren't very interactive (or don't need to maintain a lot of state in the browser).

I remember Rails apps from 5-7 years ago where the entire HTML was rendered by the server. Where required, there was pjax/turbolinks and some hand-written jQuery for client-side validations or show/hide buttons. What is the current state-of-the-art for these kinds of apps?

Think about the billing page of a typical SaaS app [1]. Does it really require to be an SPA communicating with the backend only via APIs? Can't it be made of simple HTML pages that do FORM POSTs? What's the best way to handle the following in 2019 (or 2020!), without resorting to full-fledged SPAs:

  - Showing/hiding UI elements
  - Possible values of one dropdown depending on the value selected in some other dropdown
  - Copying billing address to shipping address
  - Value of a radio button showing/hiding some form fields
  - (I hope you get the point...)
PS: Having some type-safety would be an added bonus, because I've been recently bitten by the Haskell bug :)

[1] Display list of available plans, let the user pick & configure the plan, make a payment, and move on. Typically it will be used once or twice in a user's lifetime.

  👤 open-source-ux Accepted Answer ✓
Many of the government services available via GOV.UK are designed to be accessible and usable even when JavaScript is disabled. These services are not designed as SPAs (and all the better for it).

For example, here is a demo of an accessible autocomplete drop-down list that uses JavaScript. When JavaScript is disabled, the list becomes a standard HTML drop-down list.

https://govuk-location-picker-demo.herokuapp.com/

Here is the generic code for the autocomplete on GitHub:

https://github.com/alphagov/accessible-autocomplete

And here is a blog post about dealing with a large amount of form inputs:

https://accessibility.blog.gov.uk/2019/04/08/accessibility-l...

👤 SigmundA
Server side Blazor is pretty interesting, renders everything in type safe .Net on the server then uses websockets to update dom and bridge javascript. Supports client side webassembly execution model too but not stable.

Not exactly lightweight and I guess still a SPA approach but pretty state of the art in server side rendering I would say:

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

👤 dhruvkar
I've been using Python to generate a static Hugo site from a (sort of) CRM API.

Mainly because there's no real API, and there's a just a bunch of scrapers.

The funny upside has been that customers really like the speediness of our "real time inventory" (it's a re-generated Hugo site every 25 minutes).

👤 thijsvandien
Have a look at Elixir/Phoenix with LiveView. While it’s the state of the art, I’m not sure it would suit you better than sprinkling some JS over an otherwise server-rendered page.