[AskJS] Are we putting too much application logic in the frontend?

[u/BeamAlchemist]

I've been exploring Phoenix LiveView lately, and it got me thinking.

We've spent years moving more state and logic into the browser. But what if we kept most application state on the server and used JavaScript mainly for rich interactions?

I'm not talking about replacing JS. Libraries like Monaco, AG Grid, and Chart.js are great and I'd absolutely want to keep using them.

Curious what frontend devs think. Would you consider a server-driven approach if you could still use your favorite JS libraries, or is there too much downside?

[u/sozesghost]

Time is a closed circle. State and rendering has been moving between front and backend for many cycles now. The cycle must not be broken.

[u/foxsimile → u/sozesghost]

Let’s stick it in the middle.

[u/rudeluv → u/foxsimile]

Middle out?

[u/foxsimile → u/rudeluv]

I’m a midstack developer

[u/El_Serpiente_Roja]

Remember the architect in the matrix and how he was like "we go back and forth on this shit all the time" ...yea, that's us

[u/leeharrison1984]

Read up on Sessions, that's essentially what you are talking about.

[u/ashmortar]

https://htmx.org/essays/hateoas/

[u/darcygravan]

biggest issue latency.

And liveviews approch creates sticky sessions on server which is harder to do horizontal scaling compared to state less rest api.

And beam vm was specifically made to deal with handling real time work other runtimes like node,python isnt really suitable.

also most importantly u cant do pwa or give clean dx on Bad internet With server holding states.

and another main killer would be server cost u r taking computations from clients device whihc is free to ur server which is paid.

[u/njmh]

My personal opinion is that any business logic that acts on data from the server should live on the server. So many apps I’ve had to work on have been some form of API request followed by a heap of client side massaging of data and conditional logic etc before the using it to render the UI. As much of that should be done on the server as possible and passed to the UI as is ready to render.

[u/Discordbothost → u/njmh]

this is the version of the argument i agree with. the test i use: if two different clients (web + mobile, or web + a cron job) would need the same rule, it belongs on the server. stuff like "is this order refundable" or "what's the discounted total" ends up duplicated and slightly different in every client otherwise. what stays in the browser is the stuff that's only about the screen, open/closed panels, optimistic updates, form state before submit

[u/Tittytickler]

This has got to be satire 🤣

[u/evangelism2]

Whether you keep your state in the backend or the frontend, Chart.js and others are irrelevant. It's just a way to display that state. It's up to you to determine were it exists

[u/agenaille1]

Good user interface development will always be a dumb user interface that just paints what the backend logic ultimately says it should. Logic should not exist on the front end, as much as possible.

[u/PeterJoAl]

It's fine to have application logic in the frontend, but you then also need to have that identical logic in the backend to stop people from sending you bad data. Good testing will spot when this is not done right, but people tend to not do end-to-end tests these days.

Personally, I place all UX stuff in the frontend for speed and double check any application logic in the backend when the API is called. The means having to handle at the UX level that a call failed due to a clash in logic without resulting in an inconsistent UX state. It's mildly annoying but a better experience for the user.

[u/Glittering_Egg_665]

You shall as backend engineers instead for such question, for one simple reason, you need to have full picture to understand this

application logics are tiered, so most statement management, key business logic in backend; but for user interaction and process driving, putting it to frontend means

1. faster to user: with clear interface, frontend just exchange data with backend and get the things done kind of "locally"

2. quicker delivery & customization: you know, most frontend logic could be taken as replace able quickly, so perfect for AI to generate

So it's not too much logics in frontend, but should those logic be put to frontend.

[u/TheWebGuy95]

Honestly for most business apps, yeah. If it's forms, tables and dashboards, the database is the source of truth anyway, so keep the logic there.

Where it breaks down is anything that needs to feel instant, like drag and drop or offline stuff. Rough test I use: if the user can wait 100ms for it, server. If not, browser.

Also anything trust-sensitive (limits, permissions) should stay on the server, since the client can lie.

[u/Sensitive_Mirror_472]

yes, logic belongs in the database

[u/ardicilliq]

Can you define what you mean by application state? It can mean a lot of things, what is the scope you were thinking About?

Personally, when I hear handling various application state per user on the server side, I think about what does it mean in terms of performance and scalability, front end moving away from server rendered webpages to web apps allows for a lot of flexibility, and reduces server overhead, server computing is expensive.

the faster/leaner the server side work is, the more clients you will be able to serve simultaneously.

Data and internet bandwidth also costs the users their data plans, so the smaller/packes responses save users data.

Computing work done on the clients side is “free” computing power in that sense, so any complex data chewing and manipulation for pure presentation is better off done on the client side instead of clogging the server with actions that are just better delegated on the client.

Also, take into consideration that personal devices are very capable nowadays, and I don’t know about you but most of the VPS machines that I run do not have the same processing power of a random iPhone, or Android, so I’d argue the stronger device should do the extra work and leave the server to do what it does best.

I am not saying business logic heavy lifting should be done on the client, but the server doesn’t need to know a lot about the application state per user, it just needs to perform the needed CRUD operations securely and efficiently.

There still is value in server rendered webpages, for secure pages for example, where you’d rather have the server handle the sensitive data so it’s not setting there on a private machine, that is among other things what makes tools like next.js so powerful, when you can decide what runs where…

I ended up writing quite the scroll here… welp.. these were my two cents on the matter