Comment by liampulles

Ok sure, here are my thoughts.

This is obvious but it needs to be said: Backend languages are designed for backend work, and frontend languages for frontend work. Where this becomes a real pain point is where the design goals of the language run counter, and probably the chief one is around modelling business rules.

It is the job of the backend to constrain itself down into fitting the business rules and nothing else, and backend languages aid this by allowing one to model well-defined types and put defensive guards and deal with bad behaviour in a number of ways (e.g. there is often a distinction between a runtime error and non-runtime errors).

It is the job of the frontend (or at least, what my ideal frontend would be) to have good UX and to delegate to the backend for business rules. Indeed in my ideal, the backend would dictate the HTML content to the greatest degree possible. The coding that is needed on the frontend is for DOM manipulation to add some dynamic feel to the UI, and avoid full page reloads for small adjustments. A dynamically typed scripting language (e.g. Javascript) is good for this, because it is quick to hack and tweak an experimental view, review it with users, adjust, and repeat (which is at least how I go about getting the UX good enough).

Using a typed backend language on the frontend would get in the way of me just hacking the view, which is the appropriate mode of programming for a dumb client (dumb client being my ideal).

Also, and where it does tie in with my original comment, is that I do think using a backend language on the frontend invites putting business rules in the UI code. I think that because I've been on projects where that has happened, and I understand the instinct- why pivot from my frontend coding and go and figure out what I need to modify on the backend to code a feature when it is seemingly easy for me to model it on the frontend just as well? Infact, why not put all the logic in the frontend and let the backend be a dumb CRUD REST API/a GraphQL layer above the DB?

Conversely, if it is not easy to do much beyond DOM manipulation on the frontend (because the language and setup don't make it easy), and I am forced to modify the business rules in the backend, then fantastic.

solumunus 6 days ago

Yes, I don’t understand your issue with using “back end languages” in the front end.

Reply View 1 reply

liampulles 6 days ago

Ok sure, here are my thoughts.
This is obvious but it needs to be said: Backend languages are designed for backend work, and frontend languages for frontend work. Where this becomes a real pain point is where the design goals of the language run counter, and probably the chief one is around modelling business rules.
It is the job of the backend to constrain itself down into fitting the business rules and nothing else, and backend languages aid this by allowing one to model well-defined types and put defensive guards and deal with bad behaviour in a number of ways (e.g. there is often a distinction between a runtime error and non-runtime errors).
It is the job of the frontend (or at least, what my ideal frontend would be) to have good UX and to delegate to the backend for business rules. Indeed in my ideal, the backend would dictate the HTML content to the greatest degree possible. The coding that is needed on the frontend is for DOM manipulation to add some dynamic feel to the UI, and avoid full page reloads for small adjustments. A dynamically typed scripting language (e.g. Javascript) is good for this, because it is quick to hack and tweak an experimental view, review it with users, adjust, and repeat (which is at least how I go about getting the UX good enough).
Using a typed backend language on the frontend would get in the way of me just hacking the view, which is the appropriate mode of programming for a dumb client (dumb client being my ideal).
Also, and where it does tie in with my original comment, is that I do think using a backend language on the frontend invites putting business rules in the UI code. I think that because I've been on projects where that has happened, and I understand the instinct- why pivot from my frontend coding and go and figure out what I need to modify on the backend to code a feature when it is seemingly easy for me to model it on the frontend just as well? Infact, why not put all the logic in the frontend and let the backend be a dumb CRUD REST API/a GraphQL layer above the DB?
Conversely, if it is not easy to do much beyond DOM manipulation on the frontend (because the language and setup don't make it easy), and I am forced to modify the business rules in the backend, then fantastic.

Reply View | 0 replies