[jpgvm]

If you are buying into JS/TS the very last thing you are getting is DX. I have never worked with such a low quality ecosystem ever before and I hope I won't have to endure it for too much longer.

If you want DX you are better off with JVM, Rust or something similarly well designed. Hell, Go has better DX than JS/TS and that is a pretty low bar.

Real build systems, real module systems (instead of like 3 competing incompatible ones) actual compilers instead of transpilation BS. Actually good linters and static analysis. Actually good IDEs. The list of things all of these platforms do better than the whole JS/TS nightmare just goes on and on.

What you are getting when you buy JS is isomorphic code with browsers. That is all. DX? Forget it.

[rwalle]

LOL

I have done front end development for hobby and professionally for over a decade. I can confirm that this guy does not understand the history, limitation and complexity of tooling around the ecosystem and is just here being uninformed and whining. Phrases like "real compiler" tell enough about people who mostly work in the back end that do not understand how the real world works for web.

Or let me ask this question: How would you change all this? Why would people find it better than the current status, and that proposal be universally adopted? And I am pretty sure you can't give a convincing answer. Because if it existed, people would have adopted it. Maybe you don't think this way, but there are a lot of smart people in this ecosystem and think about it a lot.

By the way, we have come a long way and are still much better than 2000s or early 2010s for many many reasons. I don't see any acknowledgement of that.

[jpgvm]

I'm not uniformed, I am aware better solutions don't currently exist for the frontend.

This however is a thread about using TS/JS on the backend as a web server and I think you will find all my arguments perfectly valid in that context.

Saying "Javascript tooling is better in 2022 than in 2000" is a useless statement even if true when saying "Javascript tooling is vastly inferior to JVM tooling" is also valid in 2022.

Just because it's better than it was doesn't make it good.

[TobyTheDog123]

> I can confirm that this guy does not understand the history, limitation and complexity of tooling

It sounds like he does, at least a little bit, because that's the problem he has with it?

>Phrases like "real compiler" tell enough about people who mostly work in the back end that do not understand how the real world works for web.

"How the real world works for the web" is the problem.

>How would you change all this?

WebAssembly/WASI is a pretty good start IMO: Having a compiled language with escape hatches to browser APIs is the ideal for me. Personally, the closest I've seen is Flutter's Skia/CanvasKit (which does use WASM, apparently). I'd certainly like to see applications of similar concepts in other languages/frameworks though.

[TobyTheDog123]

You're getting downvoted, but I absolutely agree that the ecosystem is a problem.

It's not the JS/TS language/syntax that is the problem per-se, but all the tooling that needs to exist around it for a decent DX.

NPM, Yarn, Babel, Webpack, TSC, ESLint, Prettier, even VSCode itself all contribute to an ecosystem that is a nightmare if you are trying to do anything outside of a handful of common scenarios

Tooling like Vite, Expo, CRA all try to reduce the headaches here, but at the end of the day just end up moving the headaches up an abstraction layer, and reduce the amount of supported scenarios.

That being said, there's not much support for using those languages outside of the ecosystem. Typescript is an incredible language, and if it was possible to transpile it to a language other than Javascript, that'd be ideal for me.

[jpgvm]

Yeah definitely. Typescript is passable, even has some decently cool stuff like discriminating unions which would be nice to have more widespread. The tooling however is just awful.

I'm trying to make it palatable with Bazel + rules_js/rules_ts and pnpm but even so still end up needing Babel and Webpack because browsers are a thing. This stack does make the build times somewhat more reasonable and actually manages to avoid too much wasted work locally/CI but boy does it take a lot of work to get done.

The time I'm investing in making a Typescript monorepo viable will pay off but only when compared to not implementing my changes and staying with TS, the comparison to simply not using the stack and using something better to solve our non-Typescript specific business problems would rather lopsided.

[TobyTheDog123]

My usual project stack is React Native (+React Native Web) to cover iOS/Android/Windows/Mac/Web all in one repo, with serverless functions (Workers/C@E/etc) on the API side in another, and with shared types between the two as a third.

However I have different business goals where I can actually take some time to choose a non-TS stack...

... but unfortunately with those kind of goals/restrictions the choices aren't really there, afaik.

On the client-side, you have Flutter, which is cool enough (No JS, everything in a canvas), but I'm not Dart's biggest fan, and there's no Dart WASM target yet to be able to write in one language for both (and share types).

On the server-side, most cloud companies only support Javascript + Rust + WASM, and WASM just isn't mature enough yet where it's not a total pain to work with (I think it'll get there at some point though)

So I'm left pretty much where you are, my last and only hope is a Typescript monorepo.

[lucasyvas]

You are free to think that - I personally don't think you give it enough credit, but if your general argument is that there's a best tool for the job and this isn't it, I would agree within the context of this topic: performance.

Deno is objectively a pretty nice package and does a better job than its JS predecessors of delivering on DX. But my fear is that JS is inherently fragmented and this will never be truly resolved. I personally wouldn't dissuade those from using it - you can still achieve great results. But it's not a poster child for how we should do things. That undertone bothers me a lot more than the runtimes themselves.

[endigma]

Agree with JS ecosystem being a dumpster fire, however you say "Go has better DX... and that is a pretty low bar.", What in the world do you mean? Go has in my opinion some of the best DX of any language to exist right now?

[jesse__]

Completely agree.

I use C and C++ on a day to day basis, which has an extremely bad rap in the DX department. Even coming from languages that, by and large, have very poor DX, I find the JS and TS ecosystems to be intolerable. The tooling is extremely slow, buggy, and often produces straight-up incorrect results.

[jpgvm]

I originally came from a C background where the tooling is essentially the worst in the business (embedded) so yeah, I definitely know what poor DX looks like lol.

For me I would pick that again over the current state of Typescript/Javascript tooling. Atleast I felt like I had some semblance of sanity even when cobling together piles of CMake.