Comment by gavinray | Hacker News Reader

Comment by gavinray | Hacker News Reader

Parent Full thread

I don't know that necessarily correct.

Previous startup I was at had a stack like this:

- Frontend: Vue + Typescript

- Android/iOS App: Vue (NativeScript/Capacitor) + Typescript

- Backend: Node + Typescript

- Database: Postgres

- Deployment: Everything in Docker containers

I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you get Javascript/Typescript on the backend as well, so the entire stack is just JS/TS the whole way through with a single UI/design language.

It was really easy to hire developers this way and the transferable skills were high.

However you look at it, this is sort of the deal with JS these days. From a productivity and development velocity perspective, it's really difficult to rationalize using other technologies when you can just holistically build your entire stack in one JS/TS UI framework for the clients (or Flutter, nowadays) and then JS/TS on the backend too.

This is why I'm mentally shoehorned into using Typescript for everything. I enjoy it a lot, but there are other languages I enjoy too, it just doesn't make as much sense to throw them in the mix because then you've increased technical complexity and made it that much more difficult to source talent.

I just built a frontend and backend with TS following this same logic. I'm super happy with TS for the frontend, but I regret picking it for the backend and am considering rewriting the backend in Clojure while it's still early.

My reasons are:

- I don't need to share type definitions between the frontend and backend; the frontend can generate TS type defs using GraphQL introspection regardless of which language the backend is implemented in.

- The backend is doing a lot of data manipulation, which TS is not very good at. For example, there's no built-in group-by function, and group keys must be primitives since TS doesn't have value equality for objects or arrays.

- Static typing doesn't help much with setting up GraphQL resolvers correctly, and overall feels much less useful than on the frontend where it's absolutely stellar to type check all GraphQL queries, React calls, 3rd party component props, and so on.

- I miss clojure.spec for validating calls to external services.

Plus a few more situational reasons:

- I work in a team that's already familiar with Clojure. I don't think it's a huge barrier to hiring either; I didn't know Clojure before I joined, they just recommended me a book.

- I personally don't find that using the same language everywhere helps much in reducing context switching costs. Using different languages actually feels more engaging, especially when one is as pleasant as Clojure.

Put all these together and I'm seeing real benefits in using different languages.

It'll depend on what you're building, but there's some value in rendering React on our backend. For example, we render documents (HTML => PDF) and emails with the same React components we use for our frontend to keep styling consistent. There are also some utils we use (in similar contexts) on both sides largely for things like string formatting or annoying math. Not a ton of stuff, but it's nice to have one bulletproof util to format phone numbers in every context. Another one is payment fee calculation[0], so we can guarantee the user sees the same number they'll be charged.

I think the more powerful benefits are definitely hiring and having a team that can work on both sides (and in that regard I think your points are perfectly reasonable), but there are definitely some more direct benefits in our case.

[0]https://support.stripe.com/questions/passing-the-stripe-fee-...

I wasn't very clear with my earlier description; the frontend is a SPA served by Node.js, while the backend is a completely separate GraphQL API service which I'm considering to rewrite in Clojure.

So the frontend can actually do SSR to render PDFs or emails. However, it would definitely be much harder to to ensure that any phone formatting or fee calculation done directly in the user's browser matches what the API returns. So yeah, definite benefits in sharing a language there. Thanks for the examples!

Makes sense! We have the same setup. FWIW, it's nice to do the React rendering on the backend because it's a bit easier to pass values to those templates directly (as opposed to using URL params or something). We render the React to a string there, then just pass that HTML string to a Browserless[0] instance.

Certainly not a showstopper though, passing a URI is easy enough!

[0]https://docs.browserless.io/docs/pdf.html

Have you tried Ramda for the data manipulation functions you miss from Clojure? It used to not work very well with Typescript (lots of inference issues), but now it's gotten quite good.

You can use something like https://github.com/vriad/zod to get both runtime validation and static types (via inference) at the same time. The downside is defining your types in a DSL instead of plain TS, but I think it's worth it for the runtime validation.

It probably depends on your project, but I find type checking to be at least as crucial on the backend as the frontend (probably moreso), and being able to share types/have editor auto-complete across the whole stack is a godsend. While node isn't my favorite backend environment, it's not too bad (async/await are fantastic for io), and code sharing/type sharing makes it the most productive choice overall imho, all things considered.

Clojure's a lot of fun though, and it has taught me a lot, so I do see where you're coming from!

take a look at elixir/phoenix if you're considering a rewrite. The Absinthe library is excellent and well documented. I'm using it for my startup and the app is speedy as hell on minimal hardware.

> Static typing doesn't help much with setting up GraphQL resolvers correctly, and overall feels much less useful than on the frontend where it's absolutely stellar to type check all GraphQL queries, React calls, 3rd party component props, and so on.

We found @nexus/schema to be excellent for this particular problem, but only after you set it up correctly to feed in type information via its typegenAutoconfig options.

I agree it is less frequently helpful at catching type errors, but the errors it does catch tend to be more important to get correct than the frontend errors!

You basically have arrived where lisp was some decades ago. Logical next steps are to write the OS and the editor and the VCS in JavaScript.

However, at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extensions. Then you learn that your precious stack is just a GCC upgrade away from not building anymore. And noone in your company even remembers what that is, a C++ compiler flag.

Well, in my experience you cache those dependencies via something like jfrog. That helps. But yeah, dependencies require maintenance.

If a NPM package requires a C++ compiler, I ignore it and move on.

V8 (and other Javascript JIT compilers) are written in C++. Whenever you think you run Javascript code, what you are actually running is C++ code that will emulate and compile your Javascript into machine code, update the DOM with C++ code, access sockets using C/C++ code etc. all running on an OS written in C/C++. Your code is a very small percentage of the code that runs "your" application. C/C++ runs the world. Including Javascript, Python, Java etc.

I do trust the C++ of V8 and NodeJS because it's used by many and well tested in the field.

I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.

Whether you end up with a hellish dependency tree is more up to the developer than the language. I’d say the only reason this is more common in node projects than it is in other languages is because dependency management in other languages is more tedious, so the barrier for introducing new dependencies is higher.

All of my node projects have had rather tidy dependency trees. It’s also been quite easy for me to use popular packages. If something breaks and hundreds of thousands of devs are impacted by it, it’s going to get fixed pretty quick. Which has been my experience in the rare occasions that in of my dependencies has broken, it’s been fixed before it even had a chance to impact me.

Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib

I'm currently learning Go and it's at the other end of the spectrum. Most of my apps have only one to three dependencies and one is usually a database driver. It's a really good feeling when there is something missing from the standard library and you questioning yourself that you really need that thing.

> Trust me, its the lack of standard library.

It's almost certainly not, as R has plenty of batteries, and young nitwits in the Hadleyverse are writing preposterous node-like dependency graphs. It's fashion, and it should be curb-stomped.

To be fair though, there isn't as much good introductory resources on base R, that aren't very discipline specific.

I do completely agree otherwise, but those people will learn through bitter, bitter experience that those dependencies will break over time and will see the light that is base R.

I don't see how R of all languages is a useful counterexample.

It's as far a way from a general-purpose language as it can get while technically still being one, in both scope and intended use/audience.

It's a useful counterexample because the problem didn't exist for the 20 years before legions of nodejs bros descended upon it and bestowed upon us the mess of hot garbage it is today. At this point, there is an entire half of the ecosystem which is unusable unless you drink the 400 dependency kool aide.

Totally agree, I'm currently learning Elixir and it has been such a delight to work with compared to Javascript. I'm writing a simple static site generator and I've not used any external libraries yet, because everything I've wanted to do thus far has been easy to build with the functions included in the standard library.

Choose “proven” technology, or “boring” tech as the original article calls it, applies here too. Popular libraries that are embedded in multiple language runtimes are written in C. SQLite comes to mind. Choose boring dependencies written with boring integration interfaces.

> at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extension

This is a big selling point of the most boring languages of all, Java and C#. Performance is close enough to C, and FFI is painful enough, that its rare to see any native code in a project. Other languages that are slower or have better FFI have a much bigger risk of bitrot if you're going to keep a backend around for decades.

Where I work we deploy the exact same pre-built artifact to our Mac dev machines, Linux servers, and Windows QA guys. With Go, Python, JS, Ruby, etc we would have to have it built specifically for the platform. They all use enough native libraries that you can't share a zip file. And its a huge pain to cross-compile for anything except Linux.

There's languages better than TS/JS for back-ends. I don't mind Typescript but I only use it because some flavor of JS is mandatory these days.

The non existent standard library and pretty nutty dependency management makes JS a bad choice for back-ends. There was a article a few days ago on how Deno is aiming to fix most of this and other issues, but I wouldn't use it for a couple years.

Back ends tend to stick around far long than front ends. Every company I've worked at is still running their original back ends, some decades old. Front ends are easier to replace because it tends to be just UI stuff, not a lot of business logic. I apt to take a lot less risk on the backend. It's probably going to be around forever and customers don't have to see how crusty it is :)

Seconding this. I have the same experience.

Reply on news.ycombinator.com