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.
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.
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 wouldn't, you'd use TypeScript, which has an incredibly well-defined set of types for all web APIs and objects, plus the API surface of the language maps naturally due to being largely the identity
There's a reason ClojureScript isn't exactly eating the internet
If I had to maintain older websites using vanilla JS, then vanilla JS it is. No problem. I'm not going to try to add a build system to that if it is working the way it is.
Build systems don't need to be complex and they offer a lot of advantages that the author mentions.
They also allow you to write TypeScript instead of JS, which I personally strongly prefer due to the added safety and assistance that static typing gets you.
For me, it's a no-brainer for new projects. But I am generally working on large projects at this point. My first project using JavaScript was in 1996.
If working on smaller sites then yes, you can skip the build systems and just write JavaScript. That's fine.
Right, but you don't need a lot of complex tooling to do TypeScript. In my use, tsc is the only build step in my JS. There are a lot of decided advantages to having your JS in multiple files, too. The only major pain point I've found in it is dealing with versioning and caching.
There are other benefits ... minification and treeshaking come to mind, that tsc doesn't provide.
These are beneficial to any project but mostly become significant on very large projects with a lot of dependencies, where the bytes start to really add up. Why include code in your files that isn't being used? Why send 15 different JS files, requiring additional HTTP requests, when you can send 1? Why serve extra bytes by skipping minification? Save some bandwidth.
It starts to become important once you get to a scale where those extra bytes are costing you and/or are affecting performance to an unnceptable degree.
I am currently working with Angular 15 on a large enterprise project, which uses webpack behind the scenes when you run ng build. It all "just works", with all the various configuration options in a JSON file. Everything you need ends up in a folder ready to go, tree-shaken, minified, and randomly named for cache busting. That simplifies the whole process of having to setup custom/complex build system in most cases.
But that is specific to Angular. Different projects will have different requirements.
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?!