Dev it all

As most people have seen or heard in the web community. A new proposal for adding types of JS has been submitted. It’s looking like it will be following a subset of Typescript, adding “comments” that will be used by tools like VS Code.

I think it’s a pretty neat idea. The main issue with adding types to JS directly at this stage is backward compatibility. “Don’t break the web” they cry! This makes sense, it would be a massive shift from the current dynamic paradigm and it would cause there to be major work needed to update current packages.

Adding them in as a form of comment makes perfect sense! Let me just clarify, they aren’t comments as you would usually know them. You can already achieve typed JS in a way using JSDoc like so:

/**
 * @param {string} str
 * @return {string} 
 */
function doThing(str) {
  return str;
}

The proposal is pushing the idea of using TS syntax as comments. So for the equivalent with the new proposal:

function doThing(str: string): string {
  return str;
}

It looks a lot like Typescript and I like that. Since I’ve started using Typescript and seeing the benefits of it in projects that do grow in size and have crossover between helpers, stores and the likes. It shows its worth.

Using types

These “comments” would be understood by a linter, editor or some other tooling to provide IntelliSense to developers, along with type errors and more. The engine that runs the JS, in the end, would not read these bits of syntactical sugar (to me it is just sugar for JSDoc at this point) and proceed with the execution.

No broken web. Wahoo!

This is cool and does remove a build step that can take a while, especially in larger applications. Personally, though, I’d like to go further with it.

Other tools handle type checking akin to Typescript. The main one I want to bring up in comparison here though is Hegel. I only heard about this from doing a bit of research into this topic and while it does fall short of Typescript in some ways, it does have its advantages as well.

Actual strict typing is cool. I’ve seen code that has any dotted around without a care and no intention of being returned too and that’s crappy. Hegel prevents that, there is no any type and you have to be mindful about your types as you go.

Due to this, the type inference in Hegel is a lot better than Typescript and you won’t run into as many edge cases where you do get a runtime error without meaning too.

The aim

The whole point of adding types to JS in some way was to prevent errors that should have been perceived earlier.

The proposal will do that, but it all comes down to how standardised the implementation of it is when it comes to the linter or other tooling you use. If I’d known about Hegel before going down the Typescript hole I probably would have picked that up instead. Particularly on newer projects.

If this syntax is handled poorly then we’re still going to have problems and we’re still going to encounter a situation where we need something more robust and we end up adding tooling that may, in the end, require a build step.

It’s too early to tell how this will all go. We are going to have to wait. For now, I think we’re in a pretty good spot with how our tooling works. There are ways to make sure you’re not getting swamped with transpilation.

Consider your build tools. If you have the time and opportunity consider switching to using something like swc or esbuild. Both show decent results for speeding up Typescript transpilation and if you want to go even further you could try configuring other tools like Bazel.

Test things out people. Do your speed comparisons. We all like how we can just drop Vite into a project and go. Just make sure you’re using the best tool for the job.

You wouldn’t try and use Angular for an IoT project, would you?

No really would you? Does that work? Seems like a bad idea to me.