> It is possible to build extremely dynamic websites that are not SPAs

Possible, but not easier.

Highly debatable. I've had great success developing highly dynamic websites using progressive enhancement and directive/web component like approach.

People often smirk when I mention progressive enhancement these days. But the same people often claim that something is "impossible" to do using PE, while it's not only possible, but downwright easy. This makes me think most of them never even tried this approach seriously.

My overall strategy is creating some crude "date model" of the application in pure HTML, then identifying additional behaviors I need to make it look/work the way I really want to. I implement each behavior as separate JS libraries. The libraries are configured by adding additional directives to my markup, so using and re-using them requires no coding per se.

You would be surprised how much you can accomplish this way. Moreover, it forces you to write highly reusable components that are easy to reuse.

CSS3 is a great help in this regard, because (in most cases) you do not have to specify look-and-feel of anything in the library itself. You can simply generate some additional markup that can be styled separately for every app.

This is so true. The greatest gift of the transactional model of HTTP applications, where you submit your action, to receive a page for your next step, was freeing application development out of the bind it was in: heavy client state with a myriad of small transactions triggered by events.

To put it another way, when you design transactional first, you actually design a very good approach to your business layer public interface. If you do that step right, you can do the next two with minimal effort:

1. An application API;

2. Client side javascript for improving the UI of common operations.

Single page applications often smell like the Windows Forms applications of old: A convoluted spaghetti of application states linked by insignificant events and event handlers, where the boundary between business logic and user interface is fuzzy or non-existent.

I'd like to see someone use progressive enhancement and create an app like google spreadsheets.

Probably because he really wants to build an SPA and believes that it provides the best experience for his users. Which might be true.

The notion that SPA automatically gives you better user experience is a fallacy. Better UI design gives you better user experience, and good UI design is possible using the classic approach to web development. As an added bonus, you get searchability for free and you don't have to move away from your existing server-side stack.

I used to think the same way, but trying out a non-SPA site really feels jarring now. The intermittent blank screen and the 2 second wait period makes for a shit user experience. I'm much more used to the fluid desktop-grade UI.

My only gripe with SPA was the initial load-time (looking at you Gmail), but with virtual-dom, being able to generate the html on the server gives you the best of both worlds.

You don't have to go SPA to avoid the page reload. AJAX works just fine with regular webpages as well, judiciously applied on the most latency-sensitive actions.

BTW, you're posting this on Hacker News, which is the ultimate in retro Web-1.0 technology. Heck, it even uses tables for layout.

SPAs use Ajax to sync data with the server, but the templates/assets are on the client already. In a regular webpage, Ajax would have to pull the templates for the new components as well.

I think this is what Gmail does, though it still takes forever for the initial load. Anyway, I can see this becoming a complicated mess very quickly, and find Ractive/React to be much simpler solutions.

As for HN, I doubt anyone comes to HN for the design. PG and YC's brand helped create a solid community with good content and good discussions, which is what keeps bringing us back. But let's call a spade a spade - the UI design here is a joke, even more so considering that its target demographic is the tech community.

Single page applications allow for more flexible UI design, and that flexibility allows for lots of potential improvements. Forcibly re-drawing the canvas during transitions is quite limiting, and I don't know any visual or interaction designers who couldn't do a better job without that artificial constraint.

Now, whether the benefits of getting rid of that constraint are worth the costs depends entirely on what you're building.

You do not have to re-draw the canvas during transitions. Believe it or not, it is possible to do AJAX declaratively and with progressive enhancement. My approach is to develop forms normally, then add a directive that intercepts them via AJAX, "cuts" certain pieces of the target page and "pastes" it into the current page. It is a very simple, generic and flexible approach. The markup looks like this:

  <form action="/something" submit-to="#x, #y"></form>
  <div id="x" />
  <div id="y" />

Normally, the only thing I need to add to go from non-AJAX to AJAX is submit-to="[CSS Selector Here]". Possibly, some IDs. Everything else works automatically. The library adds a certain attribute to the "pasted" parts, so I can add visual transitions via CSS3. I can use form's action URL to rewrite current URL via push state.