Why was this written like this? It makes no sense. I’ll git blame it and ask them what’s going on. Oh it’s me…

I just peeked at the docs and right off the bat I don’t like how they have conflicting attributes like hx-get and hx-post. What happens if both are set at the same time? Why not just have hx-method?

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.

By the end of the meeting you have 10 more questions and no answers and more meetings to discuss the new questions

Thanks! This is a super helpful answer!

In that case you will love typescript. I’m not sure what other imperative languages have both type inference and structural typing.

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.

Yes, it’s still a transpiler, I’m not saying it isn’t, but what I mean is that it doesn’t add any functionally specific to the typescript language. There’s a transpiler for TS that doesn’t even do any type checking at all and just does the type stripping and back porting. But of course, that’s not why people use typescript. All the features that are actually important to typescript could be done through a linter instead. If type annotations were added to JavaScript you could get most of typescript’s features with linting rules and just handle back porting in a more standard way.

It can be overkill if you need something simple that doesn’t match next’s defaults, but if the default settings of next work for your use case I found the base project setup very simple to use.

Have you tried using an auto formatter? Let’s you write code however and fixes the structure automatically on save. It’s way easier for me to write curly braces then hit ctrl+s than have to select multiple lines manually and tab in and out. I feel the biggest gains I’ve made in productivity came after I learned to embrace tooling.

I was taught java my first semester. I certainly hope no schools teach dynamic languages in the first semester.

To be perfectly frank, I’ve only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.

deleted by creator

I view it more like a powered exoskeleton around a blob fish. IMO static typing is way more valuable than strong typing and I’d take static typing only over strong typing any day if I can only choose one.

I don’t see any practical use case for it as is as anyone wanting to use them would want the full TS feature set anyways, but I could see it being a good step forward for more meaningful features to be added in the future.

Curious if you’ve used next with react. React itself has a scope rendering design goal and leaves the rest of the app to the community, and next sets up all the stuff around it for you and I think they did a really great job with the defaults they close, and it’s still fully extendable.

Maybe I’m just too used to it, but with next.js static site generation I find react to also work really well for simple sites too. If you’re not dealing with state, react is basically just functions that return templated html. IMO it’s pretty sleek for static websites since tsx let’s you do basic templating with functions.

Best practices are pretty straight forward in the typescript community. Frankly I think all the serious professionals from the JavaScript community just went to TS so the people left over that didn’t migrate are well…

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.

Even if you do, you can still use most modern js features with transpilation.