• 0 Posts
  • 125 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle

  • It will be questioned, but you have a good explanation. The tricky part is explaining it elegantly. Hiring managers kinda glance at resumes so you should add a sentence at the end explaining that you were let off due to internal company reasons. You should also try and get a letter from the company explaining that it wasn’t for performance reasons. Even better would be to get letters of recommendation from your coworkers and manager. Hopefully they’ll be extra nice to you due to your situation, but you need to be proactive about it.





  • My opinion is you should use it when it’s useful, but not when it’s unnecessary. Their main use case is when you need to couple the functionality of functions to a shared state, and it’s particularly useful when you have multiple interdependent functions that need to be tied to multiple codependent states.

    I find it relatively rare when I really need to use a class. Between first class functions and closures and modules and other features, I find JavaScript has a lot of tools to avoid needing classes. Classes add complexity so I only use them when the complexity they add is less than the complexity of the task they’re needed for.








  • Why would you not want to be using a rendering library? Your code is basically storing your application state in the dom which will turn into a horrible mess as soon as you reach any actual level of complexity. I know first hand. I’m traumatized from having to maintain large jquery code bases in the 00s. No serious professional writes code like this anymore.

    Also, your vanilla code isn’t modern. It should look more like this:

    document.querySelector("#element").classList.toggle("hidden")
    

    I could see not wanting to use a rendering library if you’re building a simple site on top of basic static HTML, but that’s not a serious discussion for industry professionals, and even still, jQuery is such a heavy dependency for saving some characters. If you find yourself using it so much you need the extra convenience then your site is already complicated enough that you should be using a rendering library with state management instead.





  • I feel like there’s no typescript drama, just JavaScript drama. Things are pretty happy in the TS community. I’ve been writing js code since it literally first came out. I’m definitely no js hater. In the early days js code bases quickly turned to spaghetti code, but I genuinely think the js community has done miracles turning what was essentially a super simplistic toy language into a seriously good production quality language. I’ve seen first hand how much work has gone into it, and while most of the js community has been great with embracing change for the better, there’s always been the niche of detractors against any change that adds complexity even when it makes coding safer and more productive.

    I’ve always had a love hate relationship with JavaScript, but with typescript it’s really been just straight up love. Pretty much all the trouble I have with typescript has been due to external libraries that use types lazily or incorrectly, and even then there are solutions to add safety to your own codebase. Sometimes I run into some trouble with the type system itself, but it’s pretty much always because I’m doing something really complicated that would be hard in any type system. I’ve been working with typescript for years now and my code bases are some of the most solid ones in my company. Typescript is really safe as long as you’re actually using it and not telling the compiler to ignore types through using any or making unsafe assertions.

    It makes no difference to me if other people prefer JavaScript. Any important js library will get ts support anyways through definitely typed, and if a library is so sloppy it can’t be typed well then it’s not a good library to use anyways. Having people proudly announce they only want to use JavaScript is also great for hiring. It easily tips me off on who not to hire.


  • I really don’t get how people can feel more productive in JavaScript. With typescript the code practically writes itself. Sometimes when refactoring I’ll change a functions input and output signature and just fix compiler errors until it stops complaining, and the code just works without me having to really even think about what the code is doing.

    Any time I’m forced to go back to js I feel like I’m going crazy trying to keep track of what’s in all the variables. With typescript I can use more powerful object structures without having to constantly double check where they came from.


  • The transpilation that typescript does doesn’t really have anything to do with typescript, it’s just there because typescript wants to support the latest ecmascript features, so transpilation is necessary for that, but technically you could simply strip out the type info and have another transpiler like babel handle the backwards compatibility. I think there are a few minor exceptions to that, like enums. There was even a proposal to add some typescript types to native JavaScript that would be ignored by the interpreter and just act as comments.


  • I’ve used JavaScript since its creation. I would describe typescript as JavaScript as it should have been. I’ve always actually liked JavaScript’s simplicity, but I’ve never liked its lack of type safety. At its core, JavaScript has a tiny conceptual footprint, and that’s actually pretty refreshing compared to other very complicated languages. But it was plagued with terrible implementations and the inherent messiness of dynamic typing. I’ve watched it evolve over the years and it’s improved beyond my greatest hopes. Between the advent of transpilation, tooling, and typescript, I’m very proud of where the language has gotten to. Having made websites in the 90s and 00s, I feel like people don’t realize how much work has gone into getting the ecosystem in a much better place.