Ask HN: 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...)
[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. 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... 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: 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: 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. 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). 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. While that's a fine thing to do, I don't know how it helps with any of the things listed by OP. 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. 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.
- 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...)