JSX is nice, but requires transpilation as JSX can’t be used by browsers directly. And as soon as you need a transpilation step you’ve opened yourself up to npm-hell with Babel, Uglify, Rollup/WebPack, etc - at which point people ask themselves why they’re even using JavsScript instead of TypeScript or going all-in on WASM.

Those tools do useful things. Forbidding developers to use arrow function syntax because you need to support IE11 isn't a winning formula.

Microsoft doesn't support IE11 anymore. You're probably safe to write modern JS unless you're in a very, very narrow niche.

That's not true https://docs.microsoft.com/en-us/lifecycle/faq/internet-expl...

And plenty of enterprises are still using it.

> And plenty of enterprises are still using it.

...but only as a back-up browser for those legacy internal web-applications. I’m sure all of them still install Chrome (or Chromium-Edge) for daily-browsing.

We sell into the NHS, and we still have high numbers of users on IE11 (and it's in our contract to support it). Chrome is definitely on the increase though.

Forbidding your developers from using arrow-functions such that you don’t need a JS build process can be justified.

Maybe a stupid question, but what kind of projects are ones where you don't need or want a build process?

Simple projects!

Projects where the client isn’t programmer-savvy and wants to make changes themselves and immediately upload them over FTP. Sites like self-hosted WordPress or hand-maintained static websites.

> Simple projects!

WP sites are far from simple. Maybe WordPress.com but definitely not the self host option. Not if you want anything other than a vanilla install.

> the client isn’t programmer-savvy > wants to make changes themselves and immediately upload them over FTP.

Why would you want a client who isn't savvy to make changes themself? Advocating for cowboy coding for end users is trolling... unless you're upselling a support package!? They can tweak things in the admin but I'd think long and hard before giving said client access to server files. Not to mention how easily end users mess things up by changing admin settings.

Having worked with such clients for 2 years, I gave up because at some point, the support burden was just too much!

> JSX is nice, but requires transpilation as JSX can’t be used by browsers directly. And as soon as you need a transpilation step you’ve opened yourself up to npm-hell with Babel, Uglify, Rollup/WebPack, etc - at which point people ask themselves why they’re even using JavsScript instead of TypeScript

React is fine with TypeScript, too.

“If you are using React, you might as well also use TypeScript instead of just JS” may be true, but I don’t see how its a problem.

The jump from javascript to typescript is trivial compared to the jump to some sort of framework built on wasm.

Nothing. It's a great innovation in web development and UI declaration to be more precise. I was skeptical for a while, but when started writing it it became natural real fast.

It's not part of Javascript, so you'll always need Babel (or similar transpiler) as a dependency and some kind of build step.

It's additional complexity when you could have solved the same issue by using better design on the API level.

Typescript transpiles JSX, which doesn't disprove your point at all, but it's worth mentioning.

I don't intend to ever write un-typed, naked javascript again if I don't have to.

Even scripting, ts-node is perfect for it.

And as far as complexity - I find typescript to be far better than webpack/babel in configuration and UX.