At some point, JavaScript got good | Hacker News Reader

At some point, JavaScript got good

jonbeebe.net

27 pointsjonbeebe21 comments

Better than before is not necessarily good. There are still lots of warts and gotchas.

In that regard JavaScript is a lot like C++. You can write pretty good C++ if you know what you are doing but the old ways are still possible and haunt you in legacy code.

That's a pretty apt comparison I'd say.

However, with JavaScript you have to avoid the old/outdated language constructs, and some warts need to remain, since browsers still need to support old websites. Perhaps in the future we can specify "ECMAScript version" (similar to perl) so old stuff can be thrown away and the VM can optimize without having to worry as much about backwards compatibility.

This is something I have always found interesting. Most people cannot write JavaScript but think they can because the syntax looks familiar and then complain when the result is shit.

There is some hidden assumption this language should reflect some other language a given programmer is formerly trained in and then disappointed when JavaScript is not their favorite pet language. Further interesting is that there is no interest or investment in formal training in JavaScript, just assumptions and failed dreams.

In that spirit when people say getting good I usually take that to mean looking more like Java, C#, or whatever.

You bring up a good point, but as you know, there's a certain amount of intuitive knowledge that gets carried over when learning another programming language (which is why it's much easier to learn additional languages than it was the first one you spent a considerable amount of time with). The problem is, JavaScript does look a whole lot like the languages you mention, it's just that some things behave vastly differently (ie. function scoped variables, behavior of double equals, etc.), which is what causes the confusion and sometimes you don't learn about these things until they bite you at some point.

Adding to this, the last few occasions I have been told that js sucks has either been about some browser security mechanisms (think cors and iframe sandboxing) and red-green async functions.

Block scoping has been -huge- for me.

ES6 'let' has very similar semantics to perl's 'my' and the absence of an equivalent elsewhere has always made me feel like I was missing a limb.

There's currently a proposal (which I think looks likely to succeed) to add a 'do BLOCK' syntax to ES6 as well, which is (now I get sane scoping) the top perl feature I miss All The Time when writing JS, and I can't wait.

(in the cases of both ruby and python the function scoping seems to be a deliberate choice rather than an omission and I just Do Not Understand how it doesn't bother people more)

I didn't know about the do BLOCK syntax that's (possibly) coming, that's interesting, thanks for bringing that up.

Regarding your last comment about Ruby and Python. I've been thinking about this for a while and I think a lot of the hate people have towards JavaScript is due to the fact that (being the only "official" web language) lots of people were forced to use it without any other choice, which adds a lot of resentment.

On the other hand, Ruby and Python are deliberate choices of which there are many options. People who choose to use it love it, and people who don't can move onto something else. It's not the same with JavaScript. If you want (or need) to do frontend development, you had to use JavaScript.

I observed this with Lua community in the past. I hardly ever see anything negative about it, but it has its own oddities (such as 1-based indexing, global by default variables) and is in a lot of ways similar to JavaScript being a prototype-based language (the only other one that I know of actually).

I am honestly drooling for it,

    my $thing = do {
      my $intermediate_1 = foo(...);
      my $intermediate_2 = bar($intermediate_1, ...);
      baz($intermediate_2);
    };

type code is something I use quite a lot to be able to name the intermediates while keeping them from escaping into the containing scope. So

    let thing = do {
      let intermediate_1 = foo(...);
      let intermediate_2 = bar(intermediate_1, ...);
      baz(intermediate_2);
    };

is going to make me a very happy camper.

My other major irritation these days is that 'let' is a statement in JS, whereas 'my' is an expression in perl, and I'm very used to writing

    if (my $token = $user->admin_token) {
      ...
    }

and similar constructs. In JS currently I have to write

    let token;
    if (token = user.admin_token()) {
      ...
    }

(and wrap that entire construct in its own block if I don't want the 'token' variable to continue to exist afterwards, which generally I don't)

The javascript-viable version of that is probably to have a special cased 'if let' just like 'for let' was added already.

I'm unaware of a proposal for that - yet.

Though the 'match' proposal currently in flight IIRC assumes 'do BLOCK' is available, and that will probably give me something sufficient to stop grumbling about that one.

(learning lisp, then applying the same "lexically scope as tight as possible" aesthetic I developed there to my perl code, then trying to use ... pretty much anything else ... has been an irritating experience on occasion ;)

I got less of a "Javascript got good", and more of a "Javascript got less unbearably bad" from this article. It is still a travesty that Javascript. alone is the language of the web (sans transpilation).

It is no longer. WebAssembly is now - with reference types and GC - fully usable.

Not really; DOM API still absent, calling between modules has high overhead, etc.

It's close though.

Reducing module to module call overhead is important for being able to split larger WASM applications without needing to do so by performance boundary rather than logical or other optimised boundary calc. Doing this properly probably means a proper dynamic linking approach or something but I'm no expert.

DOM API is self explanatory. The whole point of the web is the unified presentation layer but being forced to talk to it via a bridge sucks. Once it's done then WASM/DOM becomes GTK on steroids.

I read the entire article based on the misconception that the title was "At some point, JavaScript not good", which I thought was an amusing title, and also a pithy way to express what I've felt for a long time. So I read and read, expecting to get to the part where the author explains why JavaScript is not good at some point. But it never came.

I spent four years building an in-browser digital ad auction manager in JavaScript that truly bent my mind and that also delivered millions of dollars in ad revenue. You would think I would come away from that experience thinking "I know JavaScript", but I instead I came away thinking "That was hell, I never want to work in JavaScript again".

I worked on that project over the time period when ES6 was introduced and also later transitioned everything to TypeScript. I agree that things got better, but I still think that JavaScript is pathetic.

The problem is that once you spend any reasonable amount of time with something that doesn't suck it becomes hard to look at JS/TS the same way. The warts feel so much worse when you know it doesn't need to be that way.

Oh yes -- 100%.

Why would anyone use JavaScript when there are web stacks that JavaScript-free? You can use Flutter on the front end (people rave about how nice it is to program in Dart and Flutter) and there are also options like Elixir/Phoenix/LiveView and HTMX, which allow you to build modern web apps without messing with JavaScript.

I can't stand the fact that every other tech startup is using Node on the backend.

Everything can be so much simpler and better and nicer, but it is not.

Joining as a lead engineer in a startup, everything we do on the web will be Elixir. After three stints with Next.js “backends” at previous places I have vowed to myself to never use it or take a job where they use it ever again.

Literally 3 months back I would have disagreed with this article. Since that time I’ve been working on contract for a startup coding their backend from scratch in Typescript. The CTO/advisor insisted on nodejs because that’s what he’s familiar with. When I started I didn’t know quite enough about modern Javascript, didn’t know anything about Typescript, about mongoose or deploying and scaling node apps on the cloud. About the only thing in my favour was that this is still a C style language with familiar syntax.

I decided to go with Nestjs since it sets up somethings for you out of the gate. I’m still not fully happy with that decision, but it is what it is. Btw, I don’t even know how to write tests for any of the code I wrote. I’m still figuring that out. We just needed quick and dirty code that we can test in real world. But we’re happy with this, admittedly shitty, backend for now while we have been testing it with our initial audience.

So now I’m leaving heavily on the author’s side that the modern JS ecosystem and the language itself is pretty good. It still requires quite a bit of sophistication to understand what is going on, but it isn’t a nightmare inducing mess that popular programming culture makes it out to be.

I don’t think a complete newbie would have been able to do what I’ve done over that last few months. You still need to check a lot of your expectations of the language and be careful. But quite a lot about this ecosystem and the tooling available is undeniably impressive.

I would just advise people not to fall for the “backend elitist” mentality that is so prevalent in the discourse and actually try things out for themselves.

If Javascript is good, explain String.splice.

I'm not entirely sure what you're getting at (perhaps the fact that it mutates the original string, similar to `Array.prototype.splice()`) ... but I can say it's never gotten in my way.

I started using kotlin-js a few years ago. That was after using typescript in a project. Unlike typescript, kotlin-js is very unapologetically Kotlin first. It has some facilities to enable interfacing with javascript libraries (mainly the dynamic keyword) but mostly it's just Kotlin. Which means things like refactoring works. The compiler stops you from deploying broken code. And it's a nice language that is well suited for frontend development as demonstrated by its popularity on Android (and increasingly IOS via compose IOS).

I come from a Java background and have mostly done server side until a eight years ago when being in charge of a startup meant I could not be picky about what I did and had to be able to do all of it (web, server, devops, etc.). That started with me inheriting a javascript code base. As javascript codebases go, it wasn't horrible but still pretty mediocre compared to what I was used to. No tests, obviously. And a lot of very verbose gibberish dealing with promises and what not.

I took the opportunity to learn typescript and migrated quite a bit of javascript code to that. I like typescript; it's great. But it is a bit of a compromise in that all javascript is valid typescript. Meaning, you inherit all the ugliness and weirdness with typescript and you need to be careful with how you use it. But it's a fine language and having a decent static type checker just wipes out whole categories of bugs that I don't need in my life. I found plenty of those migrating the Javascript code. Or rather the compiler did. I just fixed them as it found them. Cheap success IMHO. The downside of migrating javascript code is that a lot of it is still javascript and you end up either replacing a lot of its ugliness or not touching it until you have to because, for example, it's obviously broken or not right.

Fast forward a few years and another startup and I had a frontend developer whose only experience was Kotlin on Android. And I needed a webapp in a hurry and had no budget for bringing in re-enforcements. I considered doing react and typescript and training the person up. But instead, we evaluated using kotlin-js. Much to my surprise, this was actually pretty good. I had been using Kotlin server side for a few years and it obviously worked well on Android. But kotlin-js on the web felt risky. Yet a few weeks in we were getting kind of productive. We had integrated a few javascript libraries, picked a ui framework (fritz2) and my frontend developer was getting quite productive with it.

That was three years ago. That app still exists. As a technology choice it's been great. It was definitely a wild ride though in terms of being an early adopter. We were dealing with a rapidly evolving library ecosystem (kotlin multi platform), compiler bugs, a complete compiler rewrite in several steps (2.0 RC2 was released a few days ago), and a lot of other things. However, life is pretty good doing kotlin-js these days. If you want a break from typescript, it's well worth checking out. It would probably be considered cutting edge or risky in a lot of places. But it definitely worked well for us.

Considering how much I like TypeScript, kotlin-js sounds tempting based on your comment, but unfortunately it's a no-go for me the because I use React heavily, and the solutions I've seen for that look less ideal (for me) than using JSX.

Kotlin has internal DSLs. They are a quite nice alternative to JSX. Easier to refactor, auto complete, etc.

You can use react with kotlin-js btw. Lots of people do this.

Reply on news.ycombinator.com