Who cares what OS the AWS machines are running? I can’t touch it, it’s completely inaccessible for me and other clients. I can only touch the services which AWS provides. I wouldn’t know the difference if it was running windows, since the OS is completely transparent, basically a hidden implementation detail.

You keep making the assumption that AWS == EC2, meanwhile it is just one of many services AWS provides.

Abstracting away is costly. You can target only the lowest common denominator. The abstractions are going to leak. It’s like the criticism of ORMs, only worse since SQL is at least standardized.

So far they didn’t complain. My manager is all praise too ;-) It’s kinda weird that I’m supposed to be the asshole for not being hateful of a technology. But you the hater are the nice guy?

The things is, I don’t diss on technologies without arguments. I’ve grown to recognize that they are tools, not a subject of passion, at least in a professional context.

Sure, but part of the claim was “without any compilation”. But bun/deno do compile TS into JS.

Lol, so angry :-D jQuery hating must be a real passion for ya.

Just fluff, no real arguments, ok.

Your code reads like it’s from 1992 mainly

Lol. You write a lot of text to mask the fact there’s no good reason why getElementById should be bad. It’s the same groupthink as with the jQuery, you’re told it’s bad, so you just follow the crowd.

jQuery was created as a way to account for browser support challenges

That was one of the reasons. The other was that DOM API was and still is crap. There were many such libraries to abstract away browser differences back in late 00s (Dojo, script.aculo.us, Prototype.js, MooTools), and the main reason jQuery “won” was that it provided the nicest API.

Which is why I think it’s opinionated in a bad way to arbitrarily pick one of them as the defacto.

You’re missing the fact that jQuery does not prevent you from hiding the element in other ways. It’s just optimizing for the most common case, which is one of the principles of good API.

What you’re missing is that the hidden class can contain anything you want. Animations or whatever else.

Sure, and when I just want to … hide it, without any animations? Then this hidden class is boilerplate only.

Why would you not want to be using a rendering library?

Because it’s just not very useful in some contexts. I’ve seen web extensions which mostly query the current page, and it doesn’t render much or even anything.

Not all pages are SPAs either. Many apps are the old request-response with some dynamic behavior sprinkled on top. jQuery covers that well.

This model is also quite compatible with the rising HTMX where the state/rendering is driven from backend and you just insert few dynamic pieces with JS.

document.querySelector(“#element”).classList.toggle(“hidden”)

There’s no difference between document.querySelector("#element") and document.getElementById("element"), they’re both same level clunky.

Also, what you wrote is not functionally identical. $el.show() is idempotent, the el.toggle("hidden") is not (as the name suggests, it toggles a class). It also needs an extra boilerplate class.

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

There are plenty of non-professionals doing web stuff and I think it’s great!

jQuery is such a heavy dependency for saving some characters

jQuery is 24 KiBs (minified, gzipped), that’s a good price for the egonomics it provides. If you’re constrained, there are API-compatible alternatives like cash which go down to 6KiBs.

There are multiple ways to hide an element yet they standardized on one that often wouldn’t work.

It’s the most common one. And it’s not like you can’t hide the element with some other mechanism with jQuery.

Also you’re using an ancient method getElementById…

And? What’s the difference from document.querySelector() when querying for ID?

So what is the right way to do that in modern js?

What is the right way is context dependent. I don’t see how having extra .hidden { display: none; } boilerplate is somehow modern or superior.

Python is for some reason darling of many, sometimes it has almost religious connotations. Meanwhile differences from e.g. PHP are mostly superficial and each has their strengths and weaknesses.

Bourne shell is orders of magnitude worse clusterf*ck than JavaScript, yet it’s rarely criticized.

Rust rarely gets criticized which isn’t necessarily a problem, since it’s IMHO a good language for its intended use case. But people tend to recommend it for things where the trade offs come out negative. (apps not needing max. performance)

In general I wouldn’t follow the trends on social media, it’s all a huge groupthink, mostly focusing on (easily avoidable) warts, and ignoring strengths.

Yes, the features are there. Just the API is still horrible.

As an example, make a hidden element visible (extremely common imperative operation).

jQuery:

$("#element").show();

Native JavaScript:

document.getElementById("element").style.display = '';

I hope you’d agree that the native JS is certainly not an example of good API.

It’s still the best API for imperative access to DOM.

Unpopular opinion: I hope it’s going to be a flop (apart from the few use cases where it does make sense). The limitation of having just JavaScript ensures level of interoperability which is IMHO one of the big advantages of web as an application platform. If WASM becomes successful, it will fragment the web.

That’s not true, deno compiles TypeScript to JavaScript, it just does it transparently. The code still runs on v8.

I agree. Rust has advantages, but none of them outweighs the negatives (complexity, difficult to find devs) for this particular use case.

I also agree that JVM would be a good platform. It’s both performant enough and simple/conventional enough.

has documentation which says it is meant only to be used for logging / debugging

No, it’s not a breaking change IMO. The method contract (the “debug” name, the comment) heavily implies the output may change and should not be relied upon.