Was a nightmare making extensions in the previous version. The documentation was very scattered/cluttered between different jupyterlab versions. Don’t think I’ll be coming back to it for 4.0.
Making extensions is really a lot about looking at their own packages in their repos and looking at the API docs, figuring things out from procedure names and sometimes useless comments, that merely rehash the procedure name as a phrase.
Additionally they often point you at their terrible discourse forum for asking questions. More often that not I don't see a good answer there either, when I merely search for one. I think their gitter channel has worked best for me so far, when they did not point me to that forum.
Typescript also helps a bit when compiling.
Sometimes I visit an old bookmark, that looked like part of official docs by the URL, but find it 404ing. Ultimately I agree, that good and accessible docs is not the project's strong side.
I guess I will have to figure some things out again soon when updating extensions to version 4.
I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.
Your experience probably differs from people who like TS. Personally I don't feel any hassle from using it and I couldn't even start listing all the benefits it offers. Even for very small personal projects, first thing I do is installing TS.
Not saying it's your case, but I noticed that a lot of people who hate TS like to use techniques and patterns that are usually considered bad practices, which often trigger errors in TS. Mutating an object to add a new property, mutating an array to add an element of a different type, processing apples and oranges in the same function without using generics or the correct union type, etc. Code works but TS doesn't like it and forces them to rewrite it properly and it feels like a hassle with no benefits.
I also noticed that lot of people who don't like TS think they need to type everything (every variable, every function's return... which is obviously inconvenient) instead of relying on types inference. There is usually very little to type in TS (compared to Java or C# for example). The two main things are the parameters of your named functions and your external data (i.e. the fetch responses). Almost everything else can be inferred.
I also observed that some people refuse to use VSCode (or any code editor with a good TS support). So they don't see any of the benefits while coding and think it's totally useless.
>Not saying it's your case, but I noticed that a lot of people who hate TS like to use techniques and patterns that are usually considered bad practices, which often trigger errors in TS. Mutating an object to add a new property, mutating an array to add an element of a different type, processing apples and oranges in the same function without using generics or the correct union type, etc. Code works but TS doesn't like it and forces them to rewrite it properly and it feels like a hassle with no benefits.
Not sure, people who like TS are usually for large corporate projects with OOP background. Most functional lispish type developer would be fine just using ES6 and above.
I feel the same, but when I complain I get blamed. Or someone chimes in with an illegible type/interface definition that solves my issue but is completely out of reach for all but language experts, which in other languages is not an issue.
Can you provide an example of something you'd see in common use that is 1) not provided by an existing library (such that you are consuming a complex type rather than writing it) and is 2) "out of reach for all but language experts"?
FWIW, when I first started getting into TypeScript from plain JS in 2019, I had a similar feeling. Part of it was that I was dealing with some object types of libraries I was using that were already quite complex. And, given all of the advancements in TS over the past few years, writing new types can be quite difficult - there is just a ton there. E.g. TypeScript's type language is famously turing complete.
That said, I absolutely love TypeScript, even just for small personal projects. The value I get from VSCode typeahead, and being able to look up the expected fields on, for example, parameters or return values of a function is invaluable, never mind its power in refactoring.
I guess I would recommend that, if in the beginning, you feel a bit overwhelmed by TS and can't yet see its value, just give it some time. At least, that's what happened to me.
I think that TypeScript, properly managed with things like zod or typebox, does an excellent job of giving me those benefits of types that I've come to expect while also having a really, really first-class development experience that reminds me (unsurprisingly?) of how actually-delightful using C# was in its heyday, with ReSharper and Visual Studio making it enjoyable. I genuinely don't feel any hassle around using it; the way that I can start with type signatures and then make the red squiggles go away is a really comfortable way to write code for me.
For me, I was out of the JavaScript cinematic universe for a long time (from about 2011 to 2018) and TypeScript was my entree back in. What got me deeply into it, and has kept me there, is not that it's better than JavaScript, but that, for my purposes, it's better than my at-the-time common languages: Ruby, Java, and C#. It gives me most of the linguistic flexibility that I'm used to with Ruby, while preventing me from dealing with the worst thing about it (Other People's Ruby being high on my list of terrible things). At the same time, it provides a level of "fall into the pit of success" structure around the type system that's superior to Java or C#, while not being as difficult to access as Rust can be.
(I like Rust, too! But the level of experience and skill necessary for somebody to be a "TypeScript operator" remains low, while letting those folks leverage really nice tooling built by folks like me who write TypeScript tools and libraries.)
I'm curious about what languages you're comparing it to. My other experience is with C# and Go, and I find Typescript's type system to be much more expressive and natural to work with.
It is truly bad to work with large Javascript projects without types. But I'm curious, what benefits of types do you feel you are missing in Typescript?
I do think it’s hard to break into initially — if you are approaching it from any other industry (such as what I did), it can take a few jobs to make the leap into a high paying career.
Edit: not trying to derail what you had said either, just a comment
Whenever I see articles like this one, I imagine this is the kind of PR that US colleges would use to deflect conversational topics they don’t want happening. Get people talking about “how do we get into college?” (with the assumption that college is where we want to be) instead of “why is the US college system broken?”
Not saying this is that, but just a thought and I’d be curious to see if this is a trend that continues.
I don’t really agree with this, if you’ve never noticed someone respond in the overly negative way to things you say as annoying and conversation-stopping, there is a good chance you don’t realize how other people perceive this. Sure, if you have close friends they can probably roll with the punches, but I bet they’d appreciate your conversation more if you disagreed to things in a positive way.
Maybe to give a more obvious example:
“Do you like to play any shooters”
“Nah, I think shooters are stupid.”
This halt’s the conversation and reads as “I think the thing you like is stupid, and also now I want you to respond to that.”
If the goal was to continue the conversation, the same feeling could have been expressed conversationally as…
“I’m not really a fan of shooters tbh, I’m more into puzzle games.”
This does 2 things — it expresses your disinterest in the topic presented without insulting your conversational partners preference and it follows up with an offer of similar topic that might be of interest to the other so that they could respond like…
“Oh, I haven’t seen any good puzzle games lately! You have any recommendations?”
I don’t really think there is an exception to this rule. The reason for this is that responding negatively should imply you find the others opinion unsavory:
“This driver is so terrible, they must be Asian.”
“That’s racist.”
The reason that the negative disagreement is used here is not to continue the conversation; rather, it’s to let the other person know that you think their opinion is wrong/bad. (I’m not saying this is a good way to go about this conversation either, I just think it’s more obvious what effect the negative disagreement has on conversation.)
> “I’m not really a fan of shooters tbh, I’m more into puzzle games.”
> “Oh, I haven’t seen any good puzzle games lately! You have any recommendations?”
This is not how a conversation goes. The typical response would be not to engage about puzzle games, but to tell you in blisteringly mind-numbing detail how great the shooter they're currently playing is and how they got out of a tight situation and blasted the opposition.
Because that's the conversation they want to have with you, and they won't be dissuaded.
That’s not how my conversations typically go. If they responded like that I would exit the conversation and not enter into conversations with them at a later date.
