The original web 1.0 where each state had an url and was rendered sequentially from scratch was actually arguably much better than the stateful event-driven UI mess we have now.
Moving from raw native ui frameworks very similar to todays js UI libs to HTML pages was a big paradigm shift, but was IMO better for most standard apps.
I've been thinking for a long time that it would be a good idea to build a client-side library where each state has an URL. Essentially just take the classic backend view rendering technique and move it to the client. Could work out really well I think. Event-driven techniques can then be reserved for really interactive apps like games.
Classic example... I login to the EMR system my GP's office uses, and click around a bit, looking at test results, notes, etc. Then, for whatever reason, I happen to reload the page or click the "back" button. Boom, I'm out of the application and have to login again from scratch. Grrrrr... SPA's and this fancy stuff have their place, but let's not pretend that it doesn't come with a cost.
Moving from raw native ui frameworks very similar to todays js UI libs to HTML pages was a big paradigm shift, but was IMO better for most standard apps.
I've been thinking for a long time that it would be a good idea to build a client-side library where each state has an URL. Essentially just take the classic backend view rendering technique and move it to the client. Could work out really well I think. Event-driven techniques can then be reserved for really interactive apps like games.