Your points are pretty spot-on - another would be to alleviate the computational load on the client. Like you say in your post:
a lot of logic already works in the Frontend
This is true, but it requires shipping a bunch of JavaScript over the wire, and making your users' computers do the heavy lifting on their end. You can reduce bandwidth by cutting down the amount of javascript you're transmitting and reduce the computational needs of your client-side frontend by offloading a lot of that logic to your backend. This will let your application work for people with lower resource requirements, and potentially reduce your client-side attack surface.
As far as what a "frontend" is, I agree with your list. All of those are frontends for a user to interact with your application.
Developer Evangelist @ Square. I have a love/hate relationship with JavaScript. When I am not programming/gaming/reading, I know way more than I should about shipping and payments now.
Totally agree with Ben here. That's why I had tried to narrow my definition of a frontend to I/O since its really just the layer for interacting with humans.
Offloading computation from the client is a really great point, and is the exact reason something like SSR (server side rendering) exists, since not all clients might have the computational power to be performant enough to match expectations.
Student from Germany who fell in love with coding and the tech industry after pivoting from a traditional career in banking. Currently pursuing a Bachelor's in CompSci.
Let the server lift the heavy weight of complex logic seems like a nice solution! In school we tinkered around with PHP for serverside rendered HTML forms (for calculating Body Mass Index and stuff like that) and I never got the point of it since you're able to do the same stuff in the frontend with JS.
I think, slowly I'm getting the bigger picture behind all that! 😊
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your points are pretty spot-on - another would be to alleviate the computational load on the client. Like you say in your post:
This is true, but it requires shipping a bunch of JavaScript over the wire, and making your users' computers do the heavy lifting on their end. You can reduce bandwidth by cutting down the amount of javascript you're transmitting and reduce the computational needs of your client-side frontend by offloading a lot of that logic to your backend. This will let your application work for people with lower resource requirements, and potentially reduce your client-side attack surface.
As far as what a "frontend" is, I agree with your list. All of those are frontends for a user to interact with your application.
Totally agree with Ben here. That's why I had tried to narrow my definition of a frontend to I/O since its really just the layer for interacting with humans.
Offloading computation from the client is a really great point, and is the exact reason something like SSR (server side rendering) exists, since not all clients might have the computational power to be performant enough to match expectations.
Thanks a lot @deciduously and @mootrichard !
Let the server lift the heavy weight of complex logic seems like a nice solution! In school we tinkered around with PHP for serverside rendered HTML forms (for calculating Body Mass Index and stuff like that) and I never got the point of it since you're able to do the same stuff in the frontend with JS.
I think, slowly I'm getting the bigger picture behind all that! 😊