Hacker News Reader

Comment by have_faith | Hacker News Reader

Does anyone know if there is any effort to move jQuery development towards using TypeScript or something similar? For some reason I had assumed they probably already were.

View on HN

Some of jQuery APIs wouldn't be that easy to convert to TS internally, we'd have to have lots of casting and most likely file size would suffer and that's one thing we care a lot about in the jQuery team. Plus, that would be a barrier for some contributors.

The @types/jquery package is maintained quite well so TS users can consume a typed jQuery anyway.

So, no plans to switch to TypeScript (or to ES6+ with the exception for imports) for now.

Not to take anything away from your larger point, but TypeScript doesn't have not casting, it has type assertions. This matters because casting means "turn it into this type", which generates code. A type assertions only means "assume it's this type". It gets removed at compile time, plus any intermediate variables you might need to create to avoid the occasional type assertion monstrosity will be appropriately cleaned up by any minifier.

In short, I strongly doubt that the need for type assertions would meaningfully impact jQuery file size.

Thanks for the terminology fix. With lots of these assertions, especially in the form of `x as unknown as TheProperType` we wouldn't have to increase file size but that would nullify most of the TypeScript gains and would make the code more readable. If we wanted to make internal code more in line with what TypeScript expects, that would require code changes which I expect may increase the file size, though.

I haven't done any real testing on the jQuery code base but that's my experience working on some TypeScript projects.

Not everything can be handled by a minifier. Consider multiple accesses of `item.prop` where `prop` is optional. You can cache `item.prop` in a variable to avoid multiple checks but the minifier usually cannot revert it back to the previous form as it has to take into account the possibility that `item.prop` is a getter in which case such a replacement would potentially change semantics.

> Plus, that would be a barrier for some contributors

A good point considering the scope of jQuery and its user base. I don't know much about generating larger file sizes but the community contribution aspect isn't something I considered.

I might sound offensive but I would rather save the TypeScript ‘greenfield’ ecosystem from jQuery. And I used jQ a lot in the past but I think the glory days are gone.

It does not sound offensive, it sounds stupid.

That's fine, I'll take that my point stands still though.

People bashing on jquery for that "points" never understood why jquery is even here to stay for at least 2 more years.

I remember having to write a small TODO program for an interview. I generally don't do frontend too much and the time limit was really tight.

So I made a simple TODO in like 30min. Naturally part of this is my familiarity with jQuery, the other is, for a small application jQuery is really great. I had a nice UI in no time.

I do understand it and I’m sure it will stay. I just think it’s not a good practise to use it anymore.

actually it is, ES6 native js is too long to type, jQuery is so neat and short, I will continue use jQuery whenever it's fit

But that makes no sense, as there are excellent typings for jQuery that Typescript users can use without a barrier. The question was about the language used to develop jQuery, which in this case would not matter for the end-user (save for file-size).

Reply on news.ycombinator.com