
Ask HN: State-of-the-art for server rendered webapps (non-SPA)? - saurabhnanda
At my company we have about 80,000+ LoC of AngularJS (v1) in production, which we still actively develop and maintain. We&#x27;ve also dabbled with Angular2&#x2F;Typescript &amp; 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&#x27;t <i></i>very<i></i> interactive (or don&#x27;t need to maintain a lot of state in the browser).<p>I remember Rails apps from 5-7 years ago where the entire HTML was rendered by the server. Where required, there was pjax&#x2F;turbolinks and some hand-written jQuery for client-side validations or show&#x2F;hide buttons. What is the current state-of-the-art for these kinds of apps?<p>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&#x27;t it be made of simple HTML pages that do FORM POSTs? What&#x27;s the best way to handle the following in 2019 (or 2020!), without resorting to full-fledged SPAs:<p><pre><code>  - Showing&#x2F;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&#x2F;hiding some form fields
  - (I hope you get the point...)
</code></pre>
PS: Having some type-safety would be an added bonus, because I&#x27;ve been recently bitten by the Haskell bug :)<p>[1] Display list of available plans, let the user pick &amp; configure the plan, make a payment, and move on. Typically it will be used once or twice in a user&#x27;s lifetime.
======
open-source-ux
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/](https://govuk-location-
picker-demo.herokuapp.com/)

Here is the generic code for the autocomplete on GitHub:

[https://github.com/alphagov/accessible-
autocomplete](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...](https://accessibility.blog.gov.uk/2019/04/08/accessibility-
lessons-dealing-with-a-large-amount-of-form-inputs/)

------
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](https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor)

~~~
nocubicles
Server Side Blazor looks very interesting and I've been meaning to try it out.

But do you have experience with it to answer the question OP had?

I.e How does it work with Server Side Blazor:

    
    
      - 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...)

~~~
SigmundA
I don't have any experience with it I also keep wanting to try it it out.
However the examples in the docs make it pretty clear how to accomplish those
things, you have events that trigger a cshtml rerender to update the dom with
c# code.

The example on the main page increments a counter using the @onclick event of
a button, the @ denotes a server event.

If you ever used webforms back in the day it has some similarities.

------
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).

~~~
sethammons
Very similar to something I crafted up back in maybe 2003. The site was slow
to load due to a bunch of sql queries on under powered hardware. Updated it to
take a "snapshot" of the front page ever 10 minutes and make that the live
version. Serving static content was so much better of an experience.

------
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.

~~~
raihansaputra
Actually, for all the requirements listed LiveView is perfect. Interactivity
can all be defined server-side without adding any JS; Forms can be validated
server side before submission; I assume implementing dynamic forms will be
easier to do once on the server side instead of having to do it twice or send
a schema over to the FrontEnd. OP should really look into LiveView.

