Live data from Hacker News

The JavaScript ecosystem is delightfully weird

fly.io

11–20 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#11

I wonder how much of this can be blamed on JS being a relatively gentle and forgiving codegen target.

I suspect that if some accidents of history hadn't left JS as the only language you can use to script a Web browser, it would have died off long ago.

I've been wondering about that lately. What is the rationale for making it necessary to run WASM binaries through JavaScript? Seems like a missed opportunity to not be able to just point a script element at a WASM blob, but I'm sure I'm overlooking something.

Re: The JavaScript ecosystem is delightfully weird

#12

I wonder how much of this can be blamed on JS being a relatively gentle and forgiving codegen target.

How is it a better codegen target than any other language? That's not intended with an argumentative tone- I'm genuinely curious as to what you mean.

Re: The JavaScript ecosystem is delightfully weird

#13
> deliberately misuses the JavaScript label syntax

Eh, deliberately repurposes. I don’t think “misuses” is the right word at all.

> abuse of the bundler

This also feels too strong a wording—though the fact that these are at least .js files (unlike .svelte files in the other case) makes the term “abuse” less unreasonable.

Re: The JavaScript ecosystem is delightfully weird

#14
> Nobody Writes JavaScript Any More

This is how "delightful" it is, and is the reason I'm waiting for it to die.

Every couple of years we decide on the 'no no, definitely this time we have it all figured out, trust us, just use X' "solution" to the problem of JavaScript. We have the definative 'this is how you do it', until the next one.

Re: The JavaScript ecosystem is delightfully weird

#15
post #7

Coffeescript was well before "tree shaking" (the JS ecosystem's way of spelling "dead code removal") and code splitting, both being relatively new things in the bundler world ("tree shaking" being introduced with rollup if memory serves). Then came Acorn, which gave way to a whole slew of JS transformation bits. It also didn't help that Node was fixed at 0.12 for years and years, and we had the IO.js fork until Node…

> "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.

Re: The JavaScript ecosystem is delightfully weird

#16
post #12

I wonder how much of this can be blamed on JS being a relatively gentle and forgiving codegen target.

How is it a better codegen target than any other language? That's not intended with an argumentative tone- I'm genuinely curious as to what you mean.

It's only a half-informed thought. I work on a project that compiles a domain specific language to C and C++. When I think about JavaScript as a codegen target, all I can see is all the problems I wouldn't have.

Re: The JavaScript ecosystem is delightfully weird

#17
post #9

So JS is delightful because we are still not actually writing JS, but stuff that looks like JS? Huh.

It's weird how JS is the only ecosystem entirely designed around the premise of avoiding direct contact with the language you're developing in at all costs. Like, even C programmers are willing to actually write C.

Rust has a far more powerful and widely used macro system then JS but I don’t think that means rust devs are trying to avoid writing rust at all costs

Re: The JavaScript ecosystem is delightfully weird

#19

I wonder how much of this can be blamed on JS being a relatively gentle and forgiving codegen target.

I suspect that if some accidents of history hadn't left JS as the only language you can use to script a Web browser, it would have died off long ago.

I want to disagree, but I think you are right. Java and Flash were the only alternatives to javascript that ever gained a foothold, and both of them were second class citizens. Circa 2001 I tried to use Java to interact with the DOM and ran into a browser bug that iirc took about a decade to fix. If the technology had ever been usable things might have turned out differently (or it might have turned out the same, who knows).

Re: The JavaScript ecosystem is delightfully weird

#20
post #7

Coffeescript was well before "tree shaking" (the JS ecosystem's way of spelling "dead code removal") and code splitting, both being relatively new things in the bundler world ("tree shaking" being introduced with rollup if memory serves). Then came Acorn, which gave way to a whole slew of JS transformation bits. It also didn't help that Node was fixed at 0.12 for years and years, and we had the IO.js fork until Node…

> "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 opt…

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

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

Post reply on HN