Hacker News Reader

Comment by save_ferris | Hacker News Reader

This. So much this.

My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful.

Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well.

Since the announcement, our productivity has diminished dramatically since so much of our time is now focused on re-working functionality that already exists into an SPA, and it's completely unnecessary. Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks, and we're definitely going to make mistakes along the way that we weren't making before.

It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients, when 99.9% of our clients have no idea what an SPA is. And the amount of money being spent on turning already-working apps into SPAs is astronomical.

View on HN

Wow... that is just insane.

I've been working alone for so long I've not had to deal with anything like that for years, but I'll offer this...

Doesn't matter, so don't let it matter to you.

When I worked for others I'd offer my opinion and advice and when it was ignored I'd do it their way every step of the way because it really does not matter. You get paid the same either way.

I'll add that because it didn't matter to me I ended up getting to work on some pretty cool stuff. Everyone knew I wouldn't whine about changing directions or being taken off a project and jumping on whatever they wanted so I was almost always the 1st choice to work on something new.

When that happened I was often able to influence the direction of the work.

Yes. This... yes.

All you can do as a professional, with experience, is offer up an argument and attempt to make it convincing enough to compel people to do things your way. If they reject your option, defend only once, and no more. After that, simply step back and work with whatever technologies are decided upon.

You can also attempt to work the social networking game and play (internal) politics. If you do these successfully you're more likely to get your ideas heard and implemented. I find this tiresome.

Ultimately if I'm being polite, professional and basing my arguments on facts and evidence, and they're being rejected, I'm not expelling any more energy on this front. Move on. Work on and with what's decided and have fun doing it.

> work with whatever technologies are decided upon.

It may sound great when you learn something new, but when you worked with a technology and you know its deprecated crap - as a professional - you should also consider your own career..

Work on crap nobody uses for 5 years and you are so handicapped by that you "will" find a new job, but rather not a good one.

Not everyone can spend hours at home to keep up with the industry.

That's true, but not really the same thing.

I was looking for work once and went to place that made wheelchair lifts for vans and buses. There was a miscommunication about what they were hiring for and when I got there they took me out to a drill press with a stack of thousands of parts on carts that needed a hole drilled in them.

I politely declined the position.

> My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful.

This doesn't seem like a problem of "MVC vs SPA".

The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for example. You'd experience the same pain.

The story of rewriting Netscape comes to mind and a few others. Point being, not much value in rewriting something that works in different language.

You overlooked this part:

> Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks

You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)

Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.

There was indeed a moment few years ago when front-end frameworks/libs were changing at warp speed, but last year or so I think the situation crystalized a lot. You now have React and Vue as major players and Angular competing for the 3rd place against some fresh libs... and I don't see that changing anytime soon.

yeah, you have React, but which of the 30 fashionable state-management libraries are you using? Typescript or Flow? What version of JS syntax? What compiler what minifier? oh hey, half of these just stopped being maintained without warning

Every year this is said like burning man is dead.

I predict a bigger react ecosystem. The slide of vue but the raise of the Quasar framework for apps. The rise of Angular once again.

I have always felt as angular was the second major player and vue the one in the 3rd place.

It's possible, especially if you look primarily at the enterprise market. From where I stand (startups, SMEs) it seems like a lot of people moved from Angular 1.x directly to Vue, skipping Angular 2+ versions. I haven't been offered any Angular projects in about 2 years, while React and Vue are really popular. But it's just my perspective, global situation might be different.

This has also been my experience. Enterprise systems really went all-in on Angular 1 for some reason (I personally suspect because it bridges reactive and MVC), and when it was time to move to a fully-reactive front-end framework, in my opinion Vue and Angular 1 are similar to each other in a way that React is not similar in relation to either of them or Angular 2+.

I still can't quite put my finger on why Angular 1 and Vue rhyme, though. It's common wisdom that "If you know Angular, you'll pick up Vue quickly", and it seems to be true, but nobody has ever explained to me why. Is it the state management? Reliance on viewmodels? How they're more complete systems out of the box and can be reasoned about holistically? Help a girl out, HN.

Not only that but you have to reinvent SSR with front end frameworks. Why do something simple when you can make it 10x as hard but ultimately end up with the same result.

I mean, I think these SSR front-end frameworks are a pile of crap, not worth the added complexity, and I hate using them; but it's pretty clearly not the same result. The problem they're solving is not "render on the server side", it's "render on the server side for the initial load then inject a fully functioning SPA for subsequent loads".

I'd rephrase: Front-end frameworks have been progressing through an iterative process, browsers are adopting standards that make them more consistent, and the tooling have been advancing at a rapid rate.

FE is a vibrant ecosystem and the tooling, in my opinion, is some of the best I have worked with as a SE.

Not at all, people moves between libraries of the same framework, they will likely refactor jQuery mess into a framework, but it's unlikely for a team to move from React to Vue or Angular (and vice versa).

you don't have to follow every trend. stick to one framework until it is no longer suitable. since 2012 i have learned to work with exactly two frameworks. i started with angular 1, and switched to aurelia when angular 1 was no longer viable. i'll stick with aurelia until it has run its course.

Yes, but front-end developers are much more fungible as well.

Not if you've built your product around a front-end framework that's gone out of style.

Remote workers are good for this scenario. My current employer is maintaining an outdated backbone.js app, thankfully I'm not on that team.

We have one guy in the office responsible for all of it, as warm bodies with backbone experience are impossible to find. However, should we decide to employ remote workers, we can easily find developers with backbone.js experience from Romania, Lithuania, India, and Pakistan who would work for a pittance and be grateful for the opportunity.

Also, on the majority of SPA frameworks you have the notion of components which makes making the UI a lot simpler than with traditional SSR abstractions (templating and partials are not sufficient).

Or your backend template engine is weak. In Elixir, EEx used in Phoenix, every template is a function. It's not supper good, but it's component (I hate term "component" and prefer "function")

But a component is a function that satisfies certain properties, why would you prefer to not to be precise in your communication? Do you call squares rectangles because you hate the term "squares"?

In my example, it's very precise that a template _is_ definitely a function. And conceptually I still think of it as function.

For your example I'd call it "squares" not because I don't hate it, but I don't think squares has something to do with "component"

The complexities of back-end frameworks are far less than the complexities of front-end frameworks in my experience and observation (in particular because the latter tend to needlessly reinvent half of a web browser). Additionally, the back-end complexities still exist when using front-end frameworks (unless you don't actually have a back-end, of course).

"You simply trade back-end frameworks complexities for the front-end framework complexities"

Not necessarily, you can have simple and modular front-ends while also having less complex back-end frameworks. The question is between SPA and non-SPA web applications, not between SPA and JSP/PHP.

Is there any possibility that the added complexity is a symptom of the framework in use and not a general problem with ALL frameworks? I know I've experienced many projects and found server side rendering more complex then client side when using frameworks like Ember.js.

I'm a front-end engineer, but I'd agree that SPAs are always more complicated than a pure SSR solution: You're inherently doing more. You're probably already tracking state somewhere on the backend (e.g. in a database). An SPA means you now have to track state on the front-end too.

There are benefits and things you can do with an SPA that you can't do with pure SSR, but they _do_ come at a cost. TANSTAAFL.

TANSTAAFL stands for: There ain't no such thing as a free lunch

But I agree, that seems to be my impression. Single Page Apps allow higher quality User Interfaces (if done right), though they do require more work.

It's a symptom of the SPA architecture. Since you give up a lot of basic functionality by not using multiple pages, that same functionality has to be reinvented.

That's pretty debatable. I've worked on some gnarly SSR architectures and making changes to the front end almost always involves refactoring some of the backend as well.

But this claim is simply wrong in a large percentage of cases (at least among the “web application” projects I have seen firsthand).

Yeah, I don't buy that. React and Vue are dead simple.

React and Vue are dead simple.

But if the comparison is with more traditional SSR sites, React and Vue are also not doing everything the back-end was doing before.

When you talk about React and Vue it should mean React ecosystem or Vue ecosystem, not view layer. Then noting is simple.

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all.

Compared to client side rendering discrete web requests with minimal templates; you usually get much better separation of logic, view, and code than the typical serverside solution.

There is a happy medium where server side services are encapsulated to separate concerns in a similar manner, but it rarely happens, even with competent, experienced, well intentioned teams.

SPA doesn’t guarantee good separation of concerns though. I have seen many a horrible SPA in my day that had all the business logic in the client side JS and zero validation server side. Server basically a very thin wrapper around the database.

I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.

Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.

My experience is the opposite. The interface created in such a situation is the worst of both worlds.

This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.

I'm not sure I buy this. I recently worked on a project where we had one .net core developer, a dev ops guy, and me doing the client SPA. We were all able to focus on our core competencies and turn around the project incredibly quickly. I would argue that you can get away with the same team size split between front and back end and possibly end up with a more efficient allocation of resources.

Perhaps, but if both teams are half the size, specialised and deliver faster, it’s a win.

That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.

Two teams sharing an interface means one team will block the other most of the time if a new feature always requires changes in the interface and implementation on both sides. Doesn't matter if individual development speed increases, overall project speed will suffer greatly.

That's a hell of a generalisation, and it falls down pretty fast when you move beyond CRUD apps. You can easily end up with entire teams whose role is just to babysit Elasticsearch.

No, it doesn’t.

Regardless of the backend stack, if you maintain both the front end and the backend, it is categorically less effort to only maintain the backend (ie. just run an API).

Half as much effort? 3/4? I don’t know, maybe your UI is a man autogenerated swagger frontend and it’s (43/50) as much effort.

It depends... but it is always less effort not maintaining an external user facing UI.

I think the counterpoint to this would be Google Search. The core product is incredibly simple from a frontend perspective, but the backend is world-class engineering.

I think making information usable is hard. This means that the burden of the development falls on whatever is making the information useful. If you simply can query an API and get stuff back that's valuable because the data is already processed, UI is pretty easy (aka Google). If your backend is returning raw data that needs to be organized and displayed, and users need to be guided through complex processes that are just simple CRUD operations server side, you have a much harder UX/UI challenge. Most things fall somewhere in the middle.

Well, what does your API actually do? If you're e.g. Heroku, your front end does almost nothing in comparison to the rest of your product. Why would running the backend of a globally distributed infrastructure-as-a-service company be easier than maintaining the front end?

I'd argue more than double considering all the things a good SSR gives you reliably for free.

This is a load of nonsense.

If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA.

Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.

>Plus you've got the extra layer of an API to maintain too

On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.

Possibly, though your perfect API design may differ significantly from your perfect site structure. It feels reasonable to consider both and see it as a positive if the use cases work.

Nonsense. People have been doing that for years before the single-page hype. The servers generating HTML contents use the API as their own backend and you have better layering.

Are you sure about that? Today I think this is a good model, but I haven't seen it in the wild before.

This is also the main argument that keeps me on the side of SPA for our own project, at the moment. Our product is a specialized database with a fancy GUI on top, but we have customers that only use the database through its API; by using it ourselves for our frontends we make sure everything is doable that way.

The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...

I definitely view being forced to build a sane API as one of the perks of a SPA. Having worked on some PHP pages with SQL queries, HTML, CSS, & JS all in a single file you would be surprised how people fail to separate concerns when they aren't forced to.

How would you make it "even more complicated, and more likely to spaghettifi" to maintain an API than having to maintain a rich UI. Now that's a load of nonsense, or at least very misguided hyperbole.

It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them.

But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together.

With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.

IMO it's one of the long-term failures of web architecture for CRUD that there isn't a unified solution for this; not only should they be the same team but they should be in the same repo, quite possibly in the same language, and the number of places a field has to be defined should be as small as possible. Let the machine sort out separation of concerns and what code goes where. Learn something from dBase and FoxPro.

Apologies if I misunderstood you, but isn't all of that criteria met by a Node/GraphQL/React app?

1. One language - JavaScript

2. One repo - containing a Node backend, also builds/serves a front end bundle (alternatively use Next.js/etc if SSR is your thing)

3. Use GraphQL schemas to handle your API(s) and consume the minimum necessary data on the client, reduce redundant field declarations

One language, one repo, easy & consistent API production/consumption, no?

I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose.

Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions).

The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong.

I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.

The real issue here was that someone forced a bunch of developers to rewrite their entire product in a stack they don’t know, against their will.

Hi, I'm a Redux maintainer. Any specific concerns that I can help with?

You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:

https://redux-starter-kit.js.org

After having some pretty extensive (heated) debates about the merits of redux here on HN, I've come to the opinion that the love/hate for redux is a consequence of the departure from MVC architectures that more experienced developers are accustomed to. There are decades of best practices built up around scaling object oriented MVC architectures, but react and redux come from a completely different school of programming where trying to apply traditional inheritance patterns is impossible and can mortally wound a project.

There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary:

> Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might have a Health component, a GroundBasedMovement component and a ZombieAi component added to an entity named ZombieEnemy. This eliminates ambiguity issues encountered in an inheritance-based design (should the root be Actor <- DamageableActor or Damageable <- Actor? Should items be implemented twice as PickupActors or DamageablePickupActors?). At the same time, components can be freely combined: a damageable inventory item? add the Collectable and Health components to an entity.

It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile.

[0]: http://entity-systems.wikidot.com/

i love redux - surface area for bugs is reduced so much compared to the past. thanks!

> I would note that generally server side templating is often a mish mash of business logic

If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...

TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less.

It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want.

We seem to only want developers with this skill, but then force them to rewrite stuff often enough so that no actual long-term gains can be realized from their expertise.

> TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less.

I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner.

Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some new feature to land a new customer or appease a current one (a not-too-different scenario happened to me once.)

Priorities change all the time, and quality code grants the flexibility to adapt to changing priorities.

Unknown: when random CEO idea occurs

Known: we’re definitely rewriting it in two years regardless of this CEO feature

The feature probably isn’t that complicated anyway

Maybe if you want code quality, stop rewriting so much shit because there’s some new hotness. Probably helps to not have so much new hotness too.

So I could see an issue with someone writing business logic in a view and then someone else rewriting that business logic somewhere else slightly differently.

But I've seen the same thing happen in the SPA. Where one person calculates some value in an API method, another doesn't know about it and calculates it again slightly differently in a different method leading to app inconsistencies. And SPA's make it worse not better because it sometimes forces you to write a piece of domain logic twice, once for the browser and once serverside.

I honestly don't know what's wrong with accessing query strings or session information. But I think maybe the reason you've seen template code using global state is because the template code was just written earlier back before that information had really soaked into the entire development community.

I could make the reverse argument: bad frontend programmers who dont use the facilities available to separate concerns create unmaintainable spaghetti when good backend programmers who separate concerns properly produce beautiful maintainable code.

The key being bad programmers dont isolate concerns and good ones do.

This separation of concerns is also good if you have both a web app and native mobile app. The server side ideally puts forth an API useful for both;

Our controllers use APIs. This was common before SPAs became all the rage.

Indeed, that's true. While I'm not saying they're good for everything, one thing I like about SPAs is that the server can just serve up an API that is usable by both web and mobile clients. No duplication of templating/view logic between server and client as often happens when the server is serving up HTML.

One reason the SSR mess is so easy to walk into is that everyone knows it's a reasonable amount of refactoring to get out of later. The cleanup of an SSR app lacks the deployment headaches of SPAs (doubly so with the service worker layer).

These problems appear largely academic to me.

Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications.

MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic.

Clean separation of frontend SPA and backend API made both sides simpler and more robust.

I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.

I turned around an SPA fast because I'm only a backend developer. I wrote API endpoints only and contracted a friend to write the frontend, delivering a swaggerspec and vague ideas of what I wanted. Completed the thing in like four design meetings and one touch-up meeting. Couldn't be happier.

> I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.

In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.

Hah. I just finished a huge refactor of an application where the back end developers "dramatically simplified" the business logic and architecture. What they meant is they removed all of the business logic from the back end so the client could do it instead. You might be able to tell I'm still a little bitter about that.

> In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience.

The key is to design the DTOs (which API endpoints are based on) starting from the API consumer perspective. Business logic on backend is responsible to deal with mapping of DTOs to the domain models and in turn to data access layer models.

This results in most DTOs being "flat" and easy to consume by client.

This where technology like graphql can really shine.

You can do that separation either way. People working on state sync and actual apis should be different anyway (unless your team is small).

I'm not convinced. We were using MVC for years and tried different approaches, but the API code is incomparably cleaner when it doesn't deal with client concerns.

> Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications.

It sound as though the application was a suitable candidate for an SPA and should have been developed as one to begin with?

It was not one application. Since we moved to SPA we have started multiple new applications having very different use cases.

Eh. The problems you talk about have little to do with SPAs in general, and have more to do with "rewriting things from A to B". If you had started out with SPAs first and wanted to un-SPA everything, you'd be making the same comments. The issues you mentioned aren't intrinsic to SPAs, they're intrinsic in redoing things.

You're right, but it's also intrinsic to the senselessly shifting paradigm/bandwagon-jumping around SPAs. It's not just that redoing things is a problem, but that the motivation behind the rehaul is poorly conceived.

I think that's how the cookie crumbles, unfortunately. Most companies want to be on the biggest bandwagon to ensure they have a steady supply of fresh, young employees. Few companies want to rely on niche software that only a few people know how to work with. As long as younger people keep jumping onto new trends, companies will continue to follow.

I'd love to hear some trench stories where these kinds of initiatives to increase the complexity of (what appear to be core) business tools were met with what I'll call a "simplicity advocate," who carried the day and the complexity was tempered, if not rejected.

Anytime you rewrite 12 existing, working web apps in something new it is going to be a huge pain. The only sane way to approach this is the strangler pattern, picking one page/view in one app to rewrite, then another, hooking them up with some kind of client-side router, and slowly letting the SPA consume the old SSR pages. That way you can measure the cost/benefit of each page before deciding it should be added into the SPA.

I have had to do this approach before - I hate it so much.

Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation.

We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it.

While I'm not proposing a complete rewrite into SPA, due to - migration requires a lot of effort, huge risk for missing functionality, errors etc.

The biggest problem with the product is - app posts back the entire page, which most of the times is huge, even if we changed just one field. The viewstate is enormous. My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it.

This approach is also described in MS's silk project - https://www.microsoft.com/en-us/download/details.aspx?id=272...

> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it

If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever).

I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders.

You can find an example of this technique here[0]

[0] https://github.com/jbogard/ContosoUniversityDotNetCore

I recall one of the more frustrating clients at my old firm. The client was hoping to build a competitor to a fancy all-AJAX industry-specific backoffice application (written by a team of dozens and with a coffee budget alone three times our dev budget) Since they were domain experts, but sort of scatterbrained (oh, we need undisclosed requirement xyz" 3 months into development), we were building it in phases to make sure we could cover their functional needs. It was a rule-based system for validating and analyzing user-provided data, where they'd be responsible for maintaining the rules via an admin backend. It was your typical PHP based request/response lifecycle.

They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?"

So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves.

Recently, I saw Turbolinks [0] which looks like the same concept with way more panache.

[0] https://github.com/turbolinks/turbolinks