Hacker News Reader

> As a maintainer of several large JS packages, and being so dreadfully burnt out on JS, there are other words I'd use to describe the whole thing than "delightful".

My first project that used JS was in 1996, so I've been along the ride every step of the way. Up until today where I am working with all of this on an Angular 15 enterprise project.

I actually would describe it as delightful, compared to what it was like only a short 10 years ago. 1996-ES6 was painful.

I understand your pain as maintainer and am also burnt out on ... um ... 27 years of JavaScript. Yikes.

But now it can just be written in TypeScript and I'll let the transpilers and other tools handle the details.

It is so much better.

The thing about JS is that it was always terrible 5-10 years ago, and is always "actually good now".

[EDIT] Though I actually agree that it's nearly-tolerable now that we have TypeScript and async/await to force what always should have been the default behavior.

Not sure what language you were coding in but I remember actively hating it 5-10 years ago and definitely didn't think "it's actually good now". It was always getting better of course, but even these days there's lots of problems that would prevent me from saying "it's actually good now".

The Web APIs are pretty lacking:

* WebUSB has only been available for a couple of years

* WebGPU is only now becoming a thing despite the aborted attempt that was WebGL

* Raw TCP/UDP sockets are still experimental

* WASM is still struggling to solve the scaling challenges to make it possible to make available a large portion of existing software as libraries for JS to interop with without overhead.

* WebCrypto doesn't have streaming hash support & fails to standardize protocols that are relatively popular (e.g. ED25519)

From a language level, there's all sorts of footguns/edges that can't be fixed due to back compat and the language is both slow in adopting good features but also fast to adopt features that don't work too well or just plain annoyances when switching between langauges (e.g. did any/all really have to be unique and called some/every?).

The ecosystem also has large annoying challenges with TypeScript being super slow to type check even small projects, a mess of bundlers to pick from (most of which are ass slow except for ESBuild and maybe SWC), linters (only really ESLint in the game which is slow for TS), formatters (prettier which is slow but thankfully there's now dprint), ES/CJS bifurcation that's a nightmare to manage, tooling that only works with very specific combinations of things, etc etc etc.

You can usually build something passably if you know what you're doing but it's a mess for someone new entering the field and even after having spent some time in it I'm finding myself futzing with project settings quite a bit to accomplish some slightly off the beaten path combination of tools.

I mean that at any time it was extremely common to see something like "well yes it was bad [amount of time ago], but now it's actually good!"

Before long that "actually good" is lumped in with the time when it was bad... but now, of course, it's actually good!

If something continuously improves then you'll always have people saying that as it crosses their personal threshold of "good". That doesn't mean they're wrong or that there is any contradiction. If you ask the same person what year javascript became good, their answer is not likely to change much over time.

The thing about JavaScript is lots of people are touching it and are innovating both in how to use it, and for language features.

It's always getting better, and always has opportunities to get better

If other tools handling the details just works for you, thats pretty amazing (and kinda surprising). Last time I was working on JS tooling there was a smorgesboard of various choices and it looked like most are opinionated just enough to not work with each other.

I've been at it since DHTML as well. I miss ES5. It should have ended there.

I feel like this is a normal thing for any language that becomes this ubiquitous. Python, C++ , Haskell, Java don't run in the browser the way JavaScript does. They don't have the same requirements that the JavaScript ecosystem does.

> "tree shaking" (the JS ecosystem's way of spelling "dead code removal")

I’m not altogether against giving it a different name. It’s very limited compared to what proper ahead-of-time compilers manage. I’d really like to see some actual effort put into partial evaluation and symbolic-execution-guided code simplification and dead code removal. Google tried something a little like it in Closure Compiler’s advanced optimisations mode, many years ago, but hasn’t really kept it up; and Facebook tried some five years ago with Prepack, but quickly gave up on it for unclear reasons.

Qwik is interesting here, very just-in-time with running JS on the client side.

https://qwik.builder.io/docs/concepts/resumable/

Qwik is basically more granular code splitting combined with a smart loader. We were already doing this ten years ago, just manually without a compiler.

> Coffeescript was well before "tree shaking"

From my quick research, it looks like the initial release of google's closure compiler, which had some amount of tree shaking, predates Coffeescript by about a month.

Joyent. Loved their free cloud server plans before until it was accquired by Samsung. It was also at that time I started looking at NodeJS, which is one of the side project from their software engineer for their SmartOS based on Solaris amirite?

But anyhow, boy oh boy, look at what we have today.

So, what language/ecosystem do you prefer nowadays if you were free to choose?

For web apps is just Javascript. And since you are forced to use it, why not run it on the server too and use less programing languages? Not a fan, but it is what it is.

I firmly believe Rust is the future.

I wouldn't say bundling started with babel... but was predated by browserify and other bundlers... oh the days of gulp/grunt and browserify...

What do you think about Deno?

Not a fan, for one reason in particular: they allow URL imports[0]. It's a massive uptime and security flaw in my opinion that was added because someone asked for it. It's been asked for on the Node repository as well where it's received mixed feedback (namely, negative feedback from several core contributors) due to it being, well... a dumb idea.

I've never seen the need for Deno. Every library I've written that has more than a few hundred users has inevitably been spammed about "Deno support when?" which also turned me off from it.

[0] https://deno.com/manual@v1.0.0/linking_to_external_code

They have ways to lock, bundle & version those in the faq you linked, so it doesn't seem to be a problem. I wonder if people have the same complaints about golang

Locking, bundling and versioning do not solve availability.

I'm not sure what you mean the versioning & bundling both ensure you have the right version in your local repository if desired. Of course the upstream source can go down but that isn't really different from any other package manager.