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.
javascript but more for philosophical reasons. when projects use typescript they always get focused on writing more scripts rather than optimizing HTML/CSS. Too many times I've seen overly complex scripts trying to solve what a properly arranged div and css tag have already solved.
I've been dealing with this at my job because a layout library was deprecated and is used throughout our codebase instead of proper css. Came to learn that my whole team doesn't like/know css, so they used this library that used angular directives in the html instead. We had multiple giant scripts for arranging elements in a grid that changed based on screen width
If js docs are a good working replacement then I can understand wanting to avoid all the annoying issues with typescript. I haven't used it before but it seems less flexible and more verbose, what's other people's experience with it? I'd have to check it out myself but for the moment typescript makes JavaScript a little more bearable.
I wasn't sure if this meme worked until I saw what he was eating
I've been writing my own render framework and component library for about a year now.
One thing I enjoy most about it is that the types are automatically inferred. There's a lot of Typescript wrangling going on, and it gets really deep into what TS is capable of and barely capable of (polymorphic this, dynamic return types based on input, Class type reconstruction, mixins that influence both static and instance properties, event listeners based on event name, typed property watchers based on property name).
It's all written in JavaScript with "JSDocs". It's not really JSDocs because there's a lot of recursion that's not possible with regular JSDocs. It's TS type information slipped into JSDoc comments.
Ridiculously complex core Class
But that is to setup the ability to tap into inferred types. The actual code that's written (eg: components) is fully typed check with little or no type declaration.
Declarative-style component with almost no explicit typing
The reality is, no complex piece of code should be written without some form of type checking. TS isn't perfect and if there were something better, I'd move. Alliances are stupid. There are problems with some things that have not been, and likely will never be, fixed. But what type-checkers should do best is infer types dynamically.
The result means all my code today just runs in the browser. I don't have to wrangle builders or compilers (bye Webpack!). At most, I use just esbuild to minify, though it's an optional step, not a mandatory one. If I want to mess around on Codepen with my library, I can refer to a git commit directly and load the file. I don't need npm to package and release. (CodePen Sample)
"In own my lane"
I prefer JavaScript personally, but it's time to acknowledge that TypeScript has won. If you want to contribute and succeed as a developer in the JS ecosystem, you need to learn TS, like it or not.
I'm on the side of NoScript.
From a privacy and security standpoint, both are evil and need to die.
You can minimize the attack surface with certain fingerprinting resistance settings at least.
I personally don't see why easy interactivity would be inherently a bad thing, plenty of apps that you would have to install directly on your system can instead stay isolated in your browser and never have access to anything else outside of it, particularly useful for proprietary web apps that we're forced to use, those same apps that go as far as to beg you to install their native counterpart on your PC, which is clearly an attempt at data harvesting and increasing user retention. Also useful for simple stuff you need once in a while and it would never make much sense to have installed
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.