Hacker News Reader

Comment by doix | Hacker News Reader

There is also the "backend of frontend", for a lack of a better term. When you've got a complex webapp, you start managing a lot of state on the frontend. You basically end up with a second database that you keep in sync, possibly two.

I think it's pretty common nowadays to have indexdb to cache data, but also your state management framework (ngrx,redux,mobx,etc) which sits between indexdb and your rendering framework.

I am (unfortunately) a FE engineer nowadays but I write very little HTML/CSS. It's mostly wrangling FE state and making it "efficient", cache invalidation, optimistic updates that mimic BE operations, etc.

View on HN

Yep.

On top of that, the complexity of front end (for me, which is in a “real time” app) often comes down to providing a user experience that “feels good” while also accounting for the complexities of keeping things in sync with the backend(s). For example, I often want a user to be able to update a thing and I want that change to feel immediate, but if 1% of the time that errors out because of business logic reasons, I need to be able to undo the immediateness, restore the previous state, maybe reconcile the local state with the newer remote state, and then display the problem to the user.

Maybe I’m just doing things wrong but there’s just a lot of complexity related to that and I struggle compartmentalizing it in a maintainable way

It’s a pretty unconventional way to do it these days, but blow it all away and load the page fresh from the server.

Maintaining a consistent state is very difficult at the best of times. This obviously has implications for the backend, it needs to respond quickly and the page render in a decent time(minimal libraries).

It really depends. For a "regular" website or blog, I agree. I think people over use complicated web frameworks to just serve what amounts to a mostly static page.

But the approach just doesn't work for things like Slack, Figma, Google docs. When you're trying to create an experience that's somewhat similar to a native application on the web, you need to start worrying about local state.

Personally, to the degree that I ever distinguish between “web apps” and just normal sites, one of the distinguishing features of web apps for me is whether forcing a page reload on the majority of interactions would be unacceptably clunky to most users.

Provided page reloads are fast, I think far more sites would be completely fine with just being sites and not rich client apps.

Glad to see that BFF is not an outdated pattern. It makes sense.

Reply on news.ycombinator.com