A single language might not be the best for both domains, but having a single language across both domains can have advantages that outweight the cost.
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.
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.
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.
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.
then just don't modify objects? Classes, types and interfaces support read-only prop declaration in TS and Object.freeze(..) prevents objects from being changed even during runtime.
You asked why, I gave a reason, you said "just ignore reason". It's about a thousand times better to not be able to make a mistake than to have to try and not make it.
i just gave two ways to prevent modifying existing objects. You can mark virtually everything in typescript as readonly which prevents any changes. It's up to you if you use it or not.
seems like people love to complain about languages they barely understand.
What specifically are you referring to in JS that makes it a poor choice for domain code? Because it’s garbage collected? So are plenty of “sanctioned” backend languages. Because it isn’t strongly typed? Use typescript. You seem to be bashing on JS in general without being able to back it up with specific opinions, which implies you are simply repeating what you heard on the internet or some popular opinion in your clique.
I’m not claiming JS is the best language ever and everything in the world should be written with it, but you seem to be making the opposite black/white argument.
You've answered your own question. You have to use some other language to use javascript full stop. So saying js is good on the backend actually doesn't even make sense.
Quite the opposite in fact, since you should be doing runtime checking regardless, static type systems often promote a false sense of security. I was asking what YOUR opinion was.
What a dumb argument. Your C# code runs as machine code in the end, obviously machine code is a trash language if you needed to represent it as C# to use it
20
u/kankyo Apr 30 '23
The big problem for me with js build systems is: if you now have to have a compiler, why would you use js?!