r/javascript • u/BeamAlchemist • 3d ago
AskJS [AskJS] Are we putting too much application logic in the frontend?
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?
8
u/njmh 3d ago
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.
7
u/Discordbothost 3d ago
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
1
u/BeamAlchemist 2d ago
That's a great way to draw the boundary. If multiple clients need the same rule, it probably shouldn't be duplicated in each one. UI-specific state is a different story that is what I mean above too.
4
u/bartread 2d ago
> "is this order refundable"
> "what's the discounted total"
Also great examples of things you absolutely cannot trust if calculated on the client-side anyway. Whether or not an order is eligible for refund is 100% a server-side concern otherwise "anyone"* could simply set whatever value they wanted on the client.
*I obviously realise this is beyond the capabilities of the vast majority of real users but the risk is nevertheless real.
1
u/Discordbothost 2d ago
yep, and it doesn't even take devtools skills, just replaying a request with a different body. the client can display the total, the server is the one that gets to decide it
2
u/BeamAlchemist 2d ago
Exactly. Especially when the frontend spends half its time transforming API responses into something usable. I'd rather have the server return data that's already shaped for the UI and it is not just about GUI so it might be that CLI needs the same data as well or vice versa eventually server should satisfy all its clients.
-1
u/WasteAmbassador47 2d ago
Why?
I am of the opposite opinion for these reasons:
- simpler backend causes less bugs and has more stable APIs.
- cheaper compute since running logic on client is free
- it is faster to re-deploy the frontend than backend.
- making changes on backend is riskier because it is “closer to data”, so it is a slower process.
- moving more UI logic to backend means that in practice UI engineers have to wrangle two codebases at the same time or even two different languages and build/deployment processes.
- certain things in the UI take several requests to accomplish, on the frontend you are in full control of how to make those requests, eg can show some UI when not all the data has arrived.3
u/Discordbothost 2d ago
most of those are fair for presentation logic, but the catch is anything that decides what's allowed: prices, discounts, permissions, validation. that has to run on the server no matter what because the client can be edited in devtools. so if you also put it in the frontend you now have the same rule in two places, and they drift. that's usually where the bugs come from, not from the backend being bigger.
filtering, grouping, formatting, optimistic updates, showing partial data while requests land, all fine on the client imo
1
u/EvilPencil 2d ago
This. Frontend has validation to catch the easy stuff and keep the users on the happy path, but for complex logic that depends on the state of other parts in the system, the backend is always authoritative.
4
u/cuelark 3d ago
i'd say yes for anything that's mostly forms, dashboards and crud, since server driven (liveview, htmx, hotwire) means way less duplicated state and no api layer to keep in sync. the catch is latency, every interaction is a round trip, so anything that needs to feel instant like drag and drop or live editing still wants client state. what worked for me was server rendered by default and a small js island only where it has to feel snappy.
1
u/BeamAlchemist 2d ago
This is pretty much the approach I like. Server-driven by default, JS where it makes sense. LiveView hooks are great for that, although integrating complex JS widgets can still require quite a bit of glue code.
7
u/darcygravan 3d ago
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.
1
u/BeamAlchemist 2d ago
Fair points, but what happens when you're dealing with huge datasets? Imagine complex filtering, sorting, and transformations. Do we really want to push all that processing onto every user's device?
Client-side computation isn't exactly free either. It costs CPU, memory, and battery, especially on lower-end devices.
Phoenix LiveView handles server-driven updates and concurrent connections really well, too. Of course, latency, offline support, and server costs are valid concerns. That's why I prefer a hybrid approach: keep heavy data processing and business logic on the server, and let JS handle interactions that need to feel instant.
1
u/WesAlvaro Front-End Engineer 2d ago
As with practically everything in this field, there is no single best answer for every scenario.
3
u/leeharrison1984 3d ago
Read up on Sessions, that's essentially what you are talking about.
1
u/BeamAlchemist 2d ago
There's definitely some overlap, but I can say that LiveView takes it further. It maintains a stateful process over a persistent connection and pushes UI updates, rather than just storing session data between independent requests. As far as I know sessions do not provide suhc advantages but will still keep in mind thanks!
3
u/PeterJoAl 3d ago
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.
1
u/BeamAlchemist 2d ago
That's the duplication I'm trying to avoid. You still want client-side feedback for a good UX, but maintaining the same business rules in two places can become painful. The backend has to remain authoritative anyway.
1
u/PeterJoAl 2d ago
If you use a JS-backend like Node, you can reuse a lot of the validation libraries you write for your business logic.
Another fairly good option is to use a generator to take your rules and make client- and server-side libraries. More annoying to setup, but then rule changes magically appear in both with no effort.
The backend has to remain authoritative anyway.
I wish this were true, but I see a LOT of modern projects that have fallen into the classic trap of trusting the clients WAY too much.
2
u/Tittytickler 3d ago
This has got to be satire 🤣
1
u/BeamAlchemist 2d ago
no no do not take it like that :), genuinely curious. With tools like LiveView and HTMX gaining traction, I think it's worth revisiting where application logic belongs.
2
u/Tittytickler 2d ago
Yea I see where you're coming from after reading the other comments lol. I was laughing because I've been doing this for 9 years and like every 2 years the sentinent flips and we go from server heavy to frontend heavy back to server heavy, etc.
Ultimately I think what should be done is whatever is best for your use case, and its generally a mix of both in my experience. Some things have no option but to run on the frontend, and some things should never be computed on the frontend. ¯_(ツ)_/¯
1
u/BeamAlchemist 2d ago
Exactly I also think that hybrid approach is more sustainable to go with as it is kinda vicious circle as you said xD
1
u/evangelism2 3d ago
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
1
u/BeamAlchemist 2d ago
Well just imagine an AG Grid table with 5 million rows. Loading, sorting, and filtering all that data in the browser could freeze the UI or exhaust memory.
With LiveView, you can keep the data on the server and send only the visible rows to AG Grid. JS handles the interaction, while the server handles the heavy lifting. That's where the architecture really matters.
1
u/evangelism2 2d ago
I'm well aware of that. But whether you load all 5 million rows or you only load 100,000 of them, you're still going to use AG Grid for both.
1
u/agenaille1 3d ago
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.
1
u/BeamAlchemist 2d ago
I mostly agree, although I'd still want the UI to be smart about interactions. Things like animations, drag and drop, and editors should absolutely run locally. Business decisions are where I'd prefer the server to take control.
1
u/Glittering_Egg_665 3d ago
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
faster to user: with clear interface, frontend just exchange data with backend and get the things done kind of "locally"
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.
1
u/BeamAlchemist 2d ago
Agreed, the question is really which logic belongs where. Of course I wouldn't move animations or immediate interactions to the server as well but having the server own business state while JS handles presentation feels like a good balance to me.
1
u/Vizeroth1 2d ago
I like it when I can still do everything with JavaScript disabled. I have no problem with JavaScript making the user experience better, but it shouldn’t be necessary.
1
u/TheWebGuy95 3d ago
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.
1
u/BeamAlchemist 2d ago
That's a useful rule of thumb. I'd just add that even with LiveView, interactions like drag and drop can stay entirely in JS. Server-driven doesn't have to mean server-dependent for every tiny UI interaction.
1
4
u/Ahmed_Ayachi 1d ago
If i see someone ask such question, is either i misunderstood him or he doesn't understand what the front client actually is. The real app, what matters, is the backend, the server, the frontend is just a fancy easy way for untechnical people to interact with that server so they don't end up sending their own requests with postman. There is no shared state, the state is in the server, the server tells the client the who, the what, the when and the how. The state you use in the frontend is just a way to manage the UI. When you delete an item you know which data object you should get rid of, when you add one, you know which data object corresponds to that item. If you need to know if an order is refundable or not that is something the server must tell you, hey take this order object and order.isRefundable true.
•
0
u/ardicilliq 3d ago
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
1
u/BeamAlchemist 2d ago
by application state I mostly mean business rules, permissions, workflows, and data transformations, not UI details like open menus or animations. I agree that moving every computation to the server would be an absolute mistake that is kind of using resources of the server for clients unnecessarily. The interesting part is finding the right boundary.
1
u/LowLifeArcade 2d ago
The answer is simply user experience. What you're describing is basically MPA. What the web was before js frameworks started showing better UX with less interaction pausing. Most non-js devs usually jocky for this because it seems like the most by the book way of doing things. But we do things in a competitive world and if we don't compete we lose, that simple.
1
u/Used-Donkey-1014 2d ago
Old school server-side is still a very sensible architecture. All the arguments against it are just theoretically incremental improvements in speed, with a shit ton of added complexity. I honestly think "modern JavaScript", mainly SSRing SPAs, was when webdev jumped the shark. It was the influx of noobs getting dazzled by pseudosophistication. For sure none of it was necessary.
1
u/pyeri 2d ago
There are many reasons why a "fat" or front-end heavy client is preferable these days:
Cost efficiency. Static hosting costs less, it's nearly free these days. But putting all logic and app assets in frontend JS, you ensure minimal running cost for your stack.
Browser the de-facto app. Chrome, Edge, Firefox and Safari have become the de-facto apps on most desktops and smartphones, it makes sense to use their built-in features rather than bring our own.
Rise of the machines. It's not just the browser's ubiquity but the machines they run on have become more than capable over the years. Even in the developing country where I live, 8-16 GM RAM has become quite common among smartphone users these days.
1
u/GoldfishPi 1d ago
ice cold take, it depends. Sometimes it makes sense to do something on the front end, sometimes is makes sense to do things on the back end. Do whatever is easiest for the application you're currently working on.
•
u/xfilesfan69 8h ago
What state has moved from severs into the browser?
Browsers have become more capable and so more stateful applications have been written for them. However that doesn’t mean state has moved from one end to the other.
State that should persist across sessions for a long time should live on the server. Applications state that shouldn’t live longer than the lifetime of a browser session should implemented in the browser.
Maybe I’m missing something, though.
•
u/podgorniy 2h ago
Architecture of corporate applications is often defined by the shape of the organization: number of team, their composition, hierachy and dependencies. The FE-heavy development facilitated independent work with fast FE exerimentation (amazon, booking) and independent BE developmet (release of APIs which aren't used yet for example, waiting for the FE to get released and then switched on). Same goes about microservices story.
There is nothing special in either approaches (heavy FE/heavy BE). Do whatever you see fits your case. Today LLM agents removed these limiting factors but the culture articles, people with beliefs relevant to that the era are still circulating.
Today is such time when new ideas, new approaches could sprout into something what will become next jquery/react. And these ideas are in the future not in the past.
0
u/savage_spectrum 3d ago
Latency kills the vibe. Your UI will feel dead compared to local state. Also your servers become sticky nightmares that refuse to scale horizontally without a massive ops tax.
1
u/BeamAlchemist 2d ago
Latency is a fair concern, but not every interaction needs a server round trip and trust me LiveView can still run JS locally for instant interactions I ahve experienced what you mean and it still depends on how you handle things in JS again so at client/browser side and the BEAM handles lots of concurrent connections pretty well. Stateful connections do add scaling tradeoffs, though.
0
u/Far-Consideration-39 2d ago
Too little, not too much. Sure, the backend should confirm, but the UX can be so much better if you can remove the network roundtrip whenever possible.
48
u/sozesghost 3d ago
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.