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.

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.

That’s misleading at best and most likely just false, and it’s worrying it’s so upvoted.

There’s no historical record explaining why this was designed this way, but we can infer some things. HTTP is very unlikely a factor, XHR / AJAX has been added years after the .sort() function. Additionally, it doesn’t make sense in the context that other comparisons are not string-wise (sort()/quicksort is basically a series of comparisons).

The trouble with JS arrays is that they can contain any values - e.g. [false, undefined, 1567, 10, "Hello world", { x: 1 }]. How do you sort those? There must be one function to compare every combination of value, but how do you compare booleans and objects?

There’s no such function which would provide reasonable results. In that context, doing .toString() and then string-wise comparison/sorting doesn’t seem that crazy - every object has .toString(), it will compute something, and often it will work well enough.

There could be some additional smartness - if the array contains numbers only, it could choose to use a number-wise comparison function. But that would require a) extra implementation complexity (JS was famously designed in short time) and b) reduced performance - since JS runtime doesn’t know what type of values are present in the array, it would have to scan the whole array before starting the sort. But I guess the a) was the decisive factor in the beginning and backwards compatibility prevented improving the function later.

I’m in a golden cage where my job earns about twice or more of what a large majority of remote jobs offer (available where I am, which is Europe).

I guess I could get very lucky and find a great paying remote job, but I feel like I could lose in the end.

People still want the money, tho. It’s the main reason I’m staying in my no-remote job.

RabbitMQ is more expensive on AWS than e.g. SNS/SQS. It’s not a coincidence, you’re trading lock-in for a cheaper price.

The increased complexity comes from the fact you will need some components which exist in either managed, but vendor lock-in form, or you need to spin them up / managed yourself.

Being cloud-agnostic also means additional cost/complexity.

Sometimes the only way to win the game is by not playing it.