vanilla javascript? what are you, fucking Amish?
TypeScript of course. The compiler often times catches mistakes in variable names, API methods, whatever. So it saves time by not having to run the whole application all the time. Also the input help is much better, when the editor knows sth is a string or a number, for example.
Honestly, as a mainly backend dev wanting to do more full stack, webdev is frustratingly intimidating. I keep trying to look up best practices but there's so little in the way of consensus. "Use JQuery, no use Vue! React is better, but also React is clunky and bad. Write pure js, no don't that's a waste of time, at least use typescript." It's all such a mess and I spend so long trying to figure out what to use. I'm trying to just pick something and stick with it, but I keep worrying that I'm not doing things the best way.
My issue with typescript... and, correct me if I'm wrong... is it doesn't exist without Javascript. Typescript needs to be compiled down into Javascript to be run. It has no stand alone interpreter (that I'm aware of) and definitely not one baked into web browsers or NodeJS (or adjacent) tools. In essence, Typescript is jank sitting on top of and trying to fix Javascript's uber jank, simultaneously fracturing the webdev space while not offering itself as a true competitive and independent language for said space.
That's my amateur two cents for what it's worth.
I think there's a positive coming from this competition, though. Apparently this infighting has re-lit the want for type annotations to be embedded in vanilla JS (ECMAScript proposal). I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.
You can get as close as it gets to this experience by using alternative runtimes such as Deno or Bun, which have native TS support (meaning you can just execute a .ts file without having to transpile it), but of course as soon as you have to write code for a browser you are back in the middle ages.
Typescript may have a million problems that make getting into it annoyingly hard and even seem pointless, but once it's settled in your project and used well... Damn is it fucking good.
And I'm saying that even though I had to disable intellisense and most of those advanced features because the project I work for is too large and typescript would easily use over 20GB of RAM and get my computer to freeze.
But if you're trying to use it like a traditional typed language, you'll only see the bad side of it and you'll certainly hate it.
I dunno, Typescript can be nice at times but it always feels like I'm bolting on something that doesn't belong on top.
I'll still use it for now. Not sure JSDoc is as adequate for an enterprise app for me. I know Svelte and stuff do, but I'll wait and see.
I learned typescript because so many authors are using it.
I think it's like jQuery. Learn it because you'll have to debug someone's code one day.
I’m not on Twitter, what’s happening?
I like TypeScript for its types and type-checking, but I also want to write JavaScript to avoid having a local build step, and having to wait for things to transpile/compile/etc when running locally. I have a pretty large project where I've gotten both worlds by just using JSDoc and only using TS for type-checking. VSCode still offers built-in type-checking with JSDocs and ofc the type-checking can also be run separately if needed.
When I write JS:
- It's because it has to run in a browser. (Why would I want to write JS that runs outside a browser? Rhetorical question. Don't answer that.)
- I use no JS dependencies. Zero. None. No jQuery. No React. No VUE. No Typescript. Nothing like that. (Unless you count as "JS dependencies" a) a minifier (but not one written in JS) or b) browser builtins.)
- I don't use any ECMA6 stuff. (Who asked for classes anyway?) Though to be fair, that's definitely at least partially because I have yet to even really look into what's available.
- I love callbacks and closures.
- I keep my global scope tidy, though I do store some things in the global scope. (Typically one or fewer global variables defined per JS file.)
- I don't use prototypes. Just because I've never found good uses for them.
I do believe there's a beautiful language living inside JS. It is quite pleasant to work with. But not the kind of thing I'd want to write "real software" in when there are alternatives like Go or even Python.
I am just a little "programmer" (if I can even call myself like that), and I'm using Typescript. Sure, it has it's own shortcomings, as everything, but it looks better than plain JS (at least in vscode)
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 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've always felt it doesn't solve the problem people think it's solving.
Javascript.
Because my exposure to Typescript is wading through over-engineered and bloated Angular front ends that could easily (and should) be thrown out and re-written in html/ js.
But also because I exclusively write simple shit that doesn't have a build step for the front end, because 90% of the stuff I make gains no benefit from needlessly overly complex front ends.
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,Classtype 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 haven't managed to break into the JS-adjacent ecosystem, but tooling around Typescript is definitely a major part of the problem:
- following a basic tutorial somehow ended up spending multiple seconds just to transpile and run "Hello, World!".
- there are at least 3 different ways of specifying the files and settings you want to use, and some of them will cause others to be ignored entirely, even though it looks like they should be used.
- embracing duck typing means many common type errors simply cannot be caught. Also that means dynamic type checks are impossible, even though JS itself supports them (admittedly with oddities, e.g. with string vs String).
- there are at least 3 incompatible ways to define and use a "module", and it's not clear what's actually useful or intended to be used, or what the outputs are supposed to be for different environments.
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.
I'm with the guy sitting at the table
I don't like blocated crap, so vanilla js es6 is the way
I’ll be downvoted again but I agree.
I’m idealistically/philosophically committed to a Purescript Halogen front end with a Haskell Servant backend, biatch. Maybe someday I’ll get WASM in there. One thing I will not do is use TS or JS.
well, I mostly create SPAs, with big projects a type system is a necessity...
All the stuff I write is personal tools anyways so I do the same. They're small anyways.
To be perfectly frank, I've only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.
I'm still using CommonJS and occasionally ESM, but I always get to integrate JSDoc for weak typing in IntelliSense. It's like getting the (almost) juiciest part from Typescript without committing to it
Keen to see how this one turns out. Maybe it'll light the fire under people's asses and we'll get native types in JS finally
