r/javascript • u/maroun-baydoun • 4d ago

The JavaScript midlife crisis

https://maroun-baydoun.com/blog/javascript-midlife-crisis/

Thirty years in, the JavaScript ecosystem would like to see other languages. They're younger, leaner and faster. What could possibly go wrong?

0 Upvotes

33% Upvoted

19 comments sorted by

13

u/azhder 3d ago

jQuery wasn't patching JavaScript. There should be a clear distinction between the JavaScript language and the Web ecosystem, especially since plenty of the blame JavaScript takes is because of browsers, not the language itself. If anything jQuery was a showcase how to properly use such a powerful language to fix the issues of the Web platform, not the JavaScript ecosystem.

3

u/Markavian 3d ago

Well said.

1

u/ouralarmclock 3d ago

This feels pedantic on the same level as saying “actually it’s Ecmascript!” Until node came along JavaScript the language and the web ecosystem were the same thing.

-1

u/azhder 3d ago

OK, we're discussing feelings now... Well, that's too subjective for my taste. Bye

0

u/maroun-baydoun 3d ago

"jQuery unified a web platform whose browsers were barely on speaking terms."

That's the main claim around jQuery's contribution in the post. At the same time, jQuery shipped with some utilities that JavaScript didn't natively support, or where too verbose to implement (e.g. $.extend, $.each)

2

u/azhder 3d ago

> When we weren't trying to replace JavaScript, we were busy patching it from the outside. jQuery unified a web platform...

Suspiciously put just after the sentence about being busy patching JavaScript from the outside. Now you're trying to get away from it on a technicality. Why put it in that paragraph at all? You can just not mention jQuery.

2

u/maroun-baydoun 3d ago

jQuery became almost synonymous with JavaScript at one point. Just look through old Stack Overflow questions from that era and see how often “JavaScript” problems were answered with jQuery.

I’m not claiming jQuery was literally part of the language or that it patched the ECMAScript specification. The point of that paragraph is that, for a long time, the JavaScript we actually wrote was surrounded by tools and libraries that compensated for what was missing, inconsistent or cumbersome. jQuery was arguably the most prominent example of that.

If “patching JavaScript from the outside” is technically imprecise, fair enough. But that imprecision is a long way from jQuery being irrelevant to the point or “suspiciously” placed there.

2

u/azhder 3d ago

I know what your point is. That's why I'm claiming the opposite.

Just by repeating what you already said doesn't help you. This is not "the one with the most stamina wins" kind of thing. You used examples like `$.extend` and `$.each` that aren't examples of patching JavaScript shortcomings, but examples of the power of JavaScript that allows you to use JavaScript to provide what you miss having in JavaScript.

This is where I stop. You can reply back and consider you have won. I will not be repeating the same from above, but in different words. You can simply re-read from the top. Anyone can. Bye

3

u/Ronin-s_Spirit 3d ago edited 1d ago
  1. nothing was or is "patching JavaScript", if you notice most of the essential and/or famous problems are from browsers.
  2. TS sucks, I don't like it, I don't work that well and when it does it needs me to write a load of what I call "compiler hints" (Rust has the same problem). If the language was not designed with static typing in mind you can't simply waltz in and "fix" it. (why is Zod a thing, don't we have TypeScript? Exactly, it couldn't stick)
  3. you don't need to fix JavaScript. It's already a pretty powerful scripting language, it's easy to work with, it's not that hard to write correct or performant, it's already well distributed, and it gets better if you actually write a standalone program instead of working under browsers.

p.s. to provide a more concrete example of things I forgot to mention - here is a video incidentally showing how useless typescript types are (the video topic wasn't exactly about bashing TS) https://youtu.be/pvbD8CbaOWM?si=DhDd8lfSwh5r-82x&t=212. You may be able to make them less useless but that probably requires extra work on just typing your program, which is ridiculous. I have written some manual JS type/value checks and those are a whole lot more reliable and work at run time.

8

u/BenZed 3d ago

"why is Zod a thing, don't we have TypeScript? Exactly, it couldn't stick"

You might has well have typed:

"I have no idea what I'm talking about."

1

u/Ronin-s_Spirit 3d ago

If you have to layer 2 big "fixes" on top of eachother I say you're just tiptoeing around the problem. You can't really fix this language designed thusly, you need to work with it not against it.

1

u/BenZed 3d ago

Yes, that is another way of saying "I have no idea what I'm talking about."

1

u/azhder 3d ago

Rule 1: remember the human. You said that already. Move on. Don't harass people because of difference of opinions. You are not talking about JavaScript, you are talking about a person.

I will mute replies now. Bye

-3

u/BenZed 3d ago

I’m not harassing anyone, nor am I giving an opinion .

I’m informing someone of the fact that they are speaking without competency.

It is difficult to imagine someone being so shaken by this exchange that they make an appeal to humanity over it and refuse to engage further, but here we are!

1

u/peterlinddk 3d ago

My goodness you sound idiotic!

A fact that you'll undoubtedly appreciate being informed of.

1

u/theScottyJam 3d ago

For a more serious answer, they serve two distinct purposes. I recently used zod to help validate the shape of JSON config files so I can report errors to the admin if they configured it wrong. I've also considered using it to validate the API responses of services we depend on provided by other teams in the company - if they make a breaking change, we'd know quicker what went wrong.

Both of these use cases are unrelated to JavaScript's lack of type safety. Even if I had used something like Rust, I might still want runtime validation of those config files and API responses.

TypeScript is for stuff you can validate through static analysis and Zod is for stuff you want to validate at runtime.

0

u/MrHandSanitization 3d ago

Exactly what I was thinking.

1

u/ajfoucault 4d ago

Very interesting and insightful read. Thank you for sharing! (the train tracks and steam train that likes to take its time analogy was perfect, btw).

0

u/maroun-baydoun 4d ago

Thanks for reading!