6 ms·

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

by junon 3y ago

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 was released by Joyent for OSS community members to take over. That caused more issues to boot. Also the whole bundling fiasco started with Babel, which wasn't a bundler at all and instead started as a means to provide polyfills for supporting "old browsers" (really, IE). From that whole thing came the concept of "evergreen browsers" which is a term that has largely fallen out of the common vocabulary with the rise of Edge. Now we have "anything is a valid feature request" TC-39, and "it's really just Google at this point" browsers dictating how the web works. It's a nightmare. 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".

chrismorgan 3y ago
> "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.
- rektide 3y ago
  Qwik is interesting here, very just-in-time with running JS on the client side. https://qwik.builder.io/docs/concepts/resumable/ https://qwik.builder.io/docs/concepts/resumable/
  - ricardobeat 3y ago
    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.
EMM_386 3y ago
> 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.
- yamtaddle 3y ago
  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.
  - 8note 3y ago
    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
    - PointyFluff 3y ago
      [dead]
  - vlovich123 3y ago
    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.
WA 3y ago
So, what language/ecosystem do you prefer nowadays if you were free to choose?
- junon 3y ago
  I firmly believe Rust is the future.
- Scarbutt 3y ago
  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.
polishdude20 3y ago
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.
nextaccountic 3y ago
What do you think about Deno?
- junon 3y ago
  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 https://deno.com/manual@v1.0.0/linking_to_external_code
  - f_devd 3y ago
    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
    - junon 3y ago
      Locking, bundling and versioning do not solve availability.
      - f_devd 3y ago
        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.
stevefan1999 3y ago
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.
thayne 3y ago
> 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.
aigoochamna 3y ago
I wouldn't say bundling started with babel... but was predated by browserify and other bundlers... oh the days of gulp/grunt and browserify...

by junon 3y ago

chrismorgan 3y ago

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

rektide 3y ago
Qwik is interesting here, very just-in-time with running JS on the client side. https://qwik.builder.io/docs/concepts/resumable/ https://qwik.builder.io/docs/concepts/resumable/
- ricardobeat 3y ago
  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.

EMM_386 3y ago

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

yamtaddle 3y ago
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.
- 8note 3y ago
  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
  - PointyFluff 3y ago
    [dead]
- vlovich123 3y ago
  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.

WA 3y ago

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

junon 3y ago
I firmly believe Rust is the future.
Scarbutt 3y ago
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.

polishdude20 3y ago

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.

nextaccountic 3y ago

What do you think about Deno?

junon 3y ago
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 https://deno.com/manual@v1.0.0/linking_to_external_code
- f_devd 3y ago
  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
  - junon 3y ago
    Locking, bundling and versioning do not solve availability.
    - f_devd 3y ago
      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.

stevefan1999 3y ago

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.

thayne 3y ago

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

aigoochamna 3y ago

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