[news_to_me]

But... why? Doesn’t all this seem needlessly complex? How are users better served by adding complexity to the front end?

Certainly there are complex UIs that require sophisticated front ends, but you probably aren’t building one, even though you’ve convinced yourself it’s necessary.

[ervine]

Agreed that it's complex, but I think the "needlessly" part is up for debate. Considering we're all here on hacker news, we're all used to and just fine with the idea that if you want fresh data, you refresh the page. I agree with you that for 99% of websites, this is just fine.

But if the requirements are for less page refreshes and high interactivity with always-fresh data, then client side rendering with a client side cache and cache management become important. Like Apollo Client, or what have you. Does it add unbelievable amounts of complexity? Definitely. Is it needless? Depends on the goal.

I would argue it's easier than manually polling for new data, managing the cache by hand and ensuring that everywhere the data is needed has been updated, and updating the DOM as a response to that new data.

So to answer your question: when done right, the user is served by having the most up to date information displayed for them at all times, with the number of network requests for said data kept to a minimum.

Is it worth it? I don't personally think so in the big picture, but in my day to day having this complexity live on the client side gives us so much more control over the UX that it's necessary to build what is expected.

[hootbootscoot]

Apollo client? you mean where the Meteor Dev team suddenly leaped to when it dawned upon the world that Mongo as a primary-store and a bizarre architecture that let you walk away with exactly one artifact towards your inevitable rewrite? (moustache templates!) was probably not going to take-off in a big way. Awesome integration and polished docs etc. Mini-mongo and pub-sub with websockets always for everyone? mmmm it ran rather slowly... Put that at 30 degrees North North-West and integrate "what is good for a FAANG may bankrupt me and not provide foreign keys" lol.. Nothing against VC, but lets separate busy-work trends that mega-corps use in trench warfare of attrition (Google has more developers than you do.) from productivity tools. GraphQL? I'd probably Postgrest if I were a one-human front-end/SPA shop

[ervine]

I mentioned it as an example of one of the more popular solutions available. Yes, it's complicated and requires a deep understanding of what it's doing - and even then it has warts that you have to work around - but we're talking about situations this complexity is necessary for the desired UX.

Whether the user actually desires this experience is another question entirely...

[runawaybottle]

So, I’m going to fill you in on something. My snark level is at max this morning, so forgive me a bit if you can.

The desktop app is dead. There is only the web app. Remember all those complex desktop apps that existed? They are all web apps now, and what would have been a new desktop app will become a new web app.

The only other app game in town is mobile, and people still use web app technology to build that even.

Enjoy your UIs, because they ain’t going anywhere, ever. There is no more ‘why’ in this question.

[u678u]

Actually I'm thinking this is a good route, you can use a few simple standard backends (Firebase, Mongo) and all the work is just in one layer, the browser gui.

[pcthrowaway]

You need a server-side component to interact with MongoDB, it's not the same as Firebase