this post was submitted on 08 Sep 2023
546 points (94.2% liked)
Programmer Humor
19817 readers
66 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I haven't managed to break into the JS-adjacent ecosystem, but tooling around Typescript is definitely a major part of the problem:
At this point I'm seriously considering writing my own sanelanguage-to-JS transpiler or using some other one (maybe Haxe? but I'm not sure its object model allows full performance tweaking), because I've written literally dozens of other languages without this kind of pain.
WASM has its own problems (we shouldn't be quick to call asm.js obsolete ... also, C's object model is not what people think it is) but that's another story.
At this point, I'd be happy with some basic code reuse. Have a "generalized fibonacci" module taking 3 inputs, and call it 3 ways: from a web browser on the client side, as a web browser request to server (which is running nodejs), or as a nodejs command-line program. Transpiling one of the callers should not force the others to be transpiled, but if multiple of the callers need to be transpiled at once, it should not typecheck the library internals multiple times. I should also be able to choose whether to produce a "dynamic" library (which can be recompiled later without recompiling the dependencies) or a "static" one (only output a single merged file), and whether to minify.
I'm not sure the TS ecosystem is competent enough to deal with this.
This last part sounds nice in theory, but it's way outside the scope of what Typescript is intended to accomplish. I've been pursuing a similar goal on and off for 10+ years at this point, I even wrote an ORM for Backbone.js so I could use it on the server as well. Back then we called it Isomorphic Javascript, later on it got renamed to "universal javascript", nowadays I'm not sure.
But yeah, the problem is similar with any code, really... What you're often writing in software dev is just functions, but the infrastructure required to actually call said function is often not trivial. I agree it'd be nice to be able to have different "wrapper types" easily, but I'm afraid their usefulness would be limited beyond toy projects.