The code of the editor is in JavaScript and not in TypeScript. Which makes me wonder how hard it goes in terms of regressions when the codebase becomes progressively larger.
I love vanilla JavaScript, but I always try to switch to TypeScript if the codebase becomes larger than 100-200 lines of code. Or otherwise I may regret, and I know it too well from previous experiences.
Using JavaScript in 2023 is a code smell. You get a massive bug catcher for free with TypeScript, and that's only the most superficial benefit.
When I hire devs, I don't care much about their previous stack experience, but if they've actively chosen JS over TS, it tells me their philosophy/priorities are completely backward.
> You get a massive bug catcher for free with TypeScript...it tells me their philosophy/priorities are completely backward.
This is a superficial take. TypeScript is not free. You are adding a compilation step that takes time, slowing down feedback in certain workflows, as well as a rather large dependency. It certainly can be worth asking why they chose JS given some of your perceived benefits of TS but not using it doesn't mean that their philosophy is backwards.
I've been using TypeScript in server-side, client-side, and hybrid projects for 8 years. Since then, I've inherited JS projects and felt like I was being forced to use a rock when I was used to having hammers. My take isn't superficial.
> You are adding a compilation step that takes time
The entire project is compiled only when testing or deploying. As far as testing goes, having static types dramatically reduces the number of times you have to run a program before shipping it. The net is that there's less time waiting for builds, not more.
And anyway, most projects compile in 2 seconds or less. There is a huge net time saving no matter how you look at it.
> slowing down feedback in certain workflows
This is incredibly vague. Which workflows? And why does it matter in those workflows?
The majority of feedback given by TypeScript is during the editing process, and that feedback is instantaneous because it comes from the language server and doesn't require recompiling.
> a rather large dependency
No. It's a dev dependency and doesn't ship with your code. You have to install it locally at some point, so I guess if a few MB of space is important to you, it's a problem. Otherwise it isn't.
I agree 1000%. I am baffled by people still saying that the cost of TypeScript is not worth it. 1 unit of effort in setup at the start of a project for 1000 units of effort saved every day through lack of bugs, structural integrity, extensibility, intellisense help, and so much more.
Just a headsup, these days the typescript tooling is actually ergonomic with esbuild and vite. If you still use javascript and know about this tooling, I am very curious why you would choose to do so, because esbuild will literally compile AND bundle all your js before you can say "compilation".
What if you're not building a browser app. For a server side, NodeJS app? Sure, you can add a build step on the back end, but that's not free, as it comes with setup, having to run a transpiler before your code.
Also, using esbuild to transpile your TS will not actually check the types. It just transforms it back to JS. For typescript, you really need the official library which is slow and bloated.
Yes you need an extra build step, but really I cannot overstate how simple this step is. There is no webpack config hell, there is no giant dependency chain, there is no long wait for anything, there is no magic file globs and mimetypes. In 10-100ms, esbuild (a single small dependency) will take 3 command line arguments, grab all your linked TS from a single TS entrypoint file, and spit out a single (possibly minified) js file that you can immediately invoke with node. Instead of node bla.js, you do esbuild && node bla.js, you don't care what happens inside.
Indeed it will not check your types, but as stated elsewhere your IDE can do this for you. This is actually beautiful because it allows you to get correctness feedback on your code but your code will never fail to run due to arbitrary type complaints. If you later feel like you want the full correctness of TS, maybe during CI/CD, you can run the slower compiler and get a gatekeeper telling you if you are doing something fishy.
> What if you're not building a browser app. For a server side, NodeJS app? Sure, you can add a build step on the back end, but that's not free, as it comes with setup, having to run a transpiler before your code.
It is free if your IDE uses the TypeScript language server and gives you errors integrated with your code editor. You don't have to transpile if you don't want to. You can, as you said, just use esbuild to strip away the type information.
> For typescript, you really need the official library which is slow and bloated.
See above. You absolutely don't. And it's not slow or bloated at all. It has incremental builds, which are essentially instantaneous after the initial build.
IMO every JS engine should just consume typescript (without type checking). AFAIK TypeScript is designed to be easily consumed by JS engines. It's a pity that V8 ignores that property.
I don't think it does, it comes with a TS compiler built-in, and "can run TS" by compiling said TS to JS and evaluating that. Deno is still using V8, so unless Deno has changed recently, it does not "consume TS" and no mainstream JS engine does.
As a user, I don't care how Deno works under the hood. All that matters is that I don't have my own build step.
There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept, and it's against the philosophy of the project. TypeScript is metadata for devs.
> As a user, I don't care how Deno works under the hood. All that matters is that I don't have my own build step.
That's fine, doesn't make the truth any different that it doesn't actually read TS without compiling it, as parent said.
> There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept [...] TypeScript is metadata for devs
It does make sense to have a runtime for TypeScript directly. There is bunch of optimizations that can only happen after the runtime understands the type of the values, and if you keep switching the type of the variable value it'll be able to do less of those optimizations.
So you could probably end up skipping a lot of inference if the types gets shipped to the runtime as well as the rest of the source, vs just the source.
Needing constant, instant recompilation is itself a smell that indicates either a lack of confidence in the usage patterns of the apis you are depending on (types help with this), or an immature understanding of the tech stack in general.
There are no code smells in personal projects, but this isn't one anyway. Every text editor I've ever used has had a single button inside that editor to change the code in the editor to what you just typed in. For an author who has written a blog post on how they eschew unit tests, this is probably the most important feature for one.
A one sentence comment about how the author is bad at programming says more about you than the author. People have been writing text editors like that for decades. They aren't bad programmers.
I think that switching at some point from JS to TS is a great way to find a lot of bugs and edge cases in established functionality that already works well enough.
I think starting in JS and then migrating to TS is a very good strategy that lets you develop fast but once you figure what you needed to wrtie let's you get additional assurances and conveniences about what you wrote.
I don't think any of this stuff really matters for 1 person projects. The goal isn't to have multiple developers adding features in parallel with each other, so if the author understands it, it's more than likely OK. I wouldn't pick that language, but they wrote Roller Coaster Tycoon in pure assembly and wrote Emacs in Lisp 40 years ago (and we're still using the code today), so this likely won't be a project-killing decision.
I would take Emacs Lisp over Typescript any day, but that's just me.
I love vanilla JavaScript, but I always try to switch to TypeScript if the codebase becomes larger than 100-200 lines of code. Or otherwise I may regret, and I know it too well from previous experiences.