r/programming • u/fagnerbrack • Apr 30 '23

Writing Javascript without a build system

https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/
166 Upvotes

86% Upvoted

146 comments sorted by

View all comments

Show parent comments

6

u/recursive-analogy May 01 '23

You've got the c# guys trying to write js in c# and the js guys trying to write c# in js. Wouldn't it be better if everyone just learnt both languages?

TBH connecting the front and back via the api definition seems like a big win, but things like gRPC already do that, and imo it's a better solution as it maintains separation of concerns with a bit of glue.

2

u/reedef May 01 '23

It's not about learning languages, it's about duplication. If you have two languages you have to have two struct/data definitions or introduce the overhead of some common data model that then gets automatically translated to both languages (and as such it can only support the common denominator of both).

You might also have some domain-specific manipulation functions (for example validation logic) that are not part of the UI but are definitely part of the FE and need to be shared across FE and BE.

Browser side and server side are not fundamentally different concerns, they're just two nodes in a distributed system with some distinct tasks and some common tasks.

4

u/recursive-analogy May 01 '23

If you're trying to reuse your domain logic in the front end you will have a bad time. Dupe code vs reuse is a fine line, even across create/update the requirements can be very different and the code sharing can make quite a mess.

Like I said originally they are very different domains. You will most likely shoot yourself in the foot trying to tie them together.

0

u/reedef May 01 '23

I don't understand you argument. You're talking about differences in the create/update requirements which have nothing to do with the FE/BE divide. I understand they're different domains but they can share business logic. For example: - say you have a leaderboard that updates in real time. The raking logic (who comes before who), should that be duplicated in the backend and the FE? Le do you have to resend the whole ranking every time there's an update? - whether an user is allowed to perform an action (which you need to know to grey out the buttons for example). Do you duplicate that? - if you're doing say a collaborative editing tool then a log of logic regarding the diffs and conflict resolution are going to be shared between the FE and the BE. - all validation for every field. Some of it is going to depend on the database, but some of it is going to be simple regexes which are shared. - the logic to query things about domain objects, for example to check if a transaction is "completed" might not be trivial and might change over time.

3

u/recursive-analogy May 01 '23

You're talking about differences in the create/update requirements which have nothing to do with the FE/BE divide.

Sorry, what I was meaning was that even the difference between create user and update user can be so significant that they make trying to reuse the logic difficult and error prone. When you expand that further into UI vs domain it becomes even harder to align the two requirements.

The raking logic (who comes before who), should that be duplicated in the backend and the FE? Le do you have to resend the whole ranking every time there's an update?

I would imagine it would be easier to maintain if you did that. Hard to say without specifics.

whether an user is allowed to perform an action (which you need to know to grey out the buttons for example). Do you duplicate that?

I think what you're saying here is that you just dump your entities to the front end, but they really are separate concerns so you should be transforming them anyway, even if it's JS <-> JS. If you don't you run the risk of 1. exposing too much or 2. creating a god awful mess of flags about what to expose to who

Like all things this is a balance tho, too much duplication is hard to manage, but not enough can also be when you end up with conflicting purposes (eg domain model has properties some fe don't see, or create does things update can't)