3 ms·

IMO, the idea of trying to blur the line between client and server is a big mistake. I worked on WebSocket frameworks in the Node.js space so I was also tempted

IMO, the idea of trying to blur the line between client and server is a big mistake. I worked on WebSocket frameworks in the Node.js space so I was also tempted but I completely abandoned this approach years ago. Though with Node.js, I do often reuse utility functions between client and server, I reject any framework which tries to hide the separation. I demand to have complete understanding of where the code is executing and how. I need to know what is being executed, where and how. I also avoid technologies where the code I write is different from the code being executed. This is why I've been avoiding TypeScript. It performs code transformations which obfuscate my understanding of the logic which will be executed. With TS, the code I write is not the code which gets executed. This is scary to me. My code gets compiled into some messy junk-looking code and then that messy junk gets executed in ways I don't fully comprehend.

b_e_n_t_o_n 1y ago
You can use (ts 5.8 and above) a compiler flag `erasableSyntaxOnly` which enforces only TS features that can be dropped without modifying the underlying JavaScript. Unfortunately one of my favourite TS features, parameter properties, isn't erasable although it doesn't change runtime semantics.
mpoteat 1y ago
> I also avoid technologies where the code I write is different from the code being executed. Not to be snarky, but as opposed to writing assembly? Where do you draw the line if you don't allow TypeScript (which is, with limited exceptions, only type erasure unless you specifically request polyfill), but allow other forms of compilation? Would you define JVM bytecode or IR as messy-looking junk code? It's hard to see how a principled line could be drawn here.
- jongjong 1y ago
  If I had the mental capacity and time to write it in assembly, then that would be better. But then probably still not worth it due to added maintenance challenges. I guess it's really about mental capacity and time. The difference in the amount of value provided by a JS engine abstracting away from binary code vs TS transpiling to JavaScript is massive. The TS transpiler's value is extremely marginal by comparison, especially when considering the amount of trouble it brings. Also, I'm familiar enough with the V8 engine and other ECMAScript-compliant engines that I have a good sense of how my code is being executed on there. I don't have to worry about TypeScript dropping support for a specific configuration setting in tsconfig and then having to spend hours trying to figure out why my code isn't working anymore.

b_e_n_t_o_n 1y ago

You can use (ts 5.8 and above) a compiler flag `erasableSyntaxOnly` which enforces only TS features that can be dropped without modifying the underlying JavaScript. Unfortunately one of my favourite TS features, parameter properties, isn't erasable although it doesn't change runtime semantics.

mpoteat 1y ago

> I also avoid technologies where the code I write is different from the code being executed. Not to be snarky, but as opposed to writing assembly? Where do you draw the line if you don't allow TypeScript (which is, with limited exceptions, only type erasure unless you specifically request polyfill), but allow other forms of compilation? Would you define JVM bytecode or IR as messy-looking junk code? It's hard to see how a principled line could be drawn here.

jongjong 1y ago
If I had the mental capacity and time to write it in assembly, then that would be better. But then probably still not worth it due to added maintenance challenges. I guess it's really about mental capacity and time. The difference in the amount of value provided by a JS engine abstracting away from binary code vs TS transpiling to JavaScript is massive. The TS transpiler's value is extremely marginal by comparison, especially when considering the amount of trouble it brings. Also, I'm familiar enough with the V8 engine and other ECMAScript-compliant engines that I have a good sense of how my code is being executed on there. I don't have to worry about TypeScript dropping support for a specific configuration setting in tsconfig and then having to spend hours trying to figure out why my code isn't working anymore.