Comment by untog | Hacker News Reader

Comment by untog | Hacker News Reader

Parent Full thread

I absolutely agree on TypeScript, I love that it's opinionated and simply versioned. Every time I have to step back into a codebase that uses Babel and X number of different plugins it just tires me. Typescript is just Typescript, and the compiler works fantastically well.

> Better still, a lot of these languages are coming to the browser (via WASM or transpilation)

I think this has always been a concern - CoffeeScript had its moment in the sun, then the good parts got merged into JS and it died out. We'll see if that happens again.

WASM concerns me, though, because of the utility you outline, which doesn't actually serve the end-user in any way shape, or form. Much like we're seeing tiny webapps made with React (and requiring browsers to download and parse the accompanying runtime), I worry we're going to see sites using e.g. Kotlin in WASM simply because that's the developer preference, totally ignoring the fact that it means every user is going to have to download a Kotlin runtime and garbage collector despite there being a perfectly good JavaScript one sitting right there.

> CoffeeScript had its moment in the sun, then the good parts got merged into JS

No. Some good parts have been merged, but so many good parts will never get to ESxx or Typescript. Most dev's just don't see it because they do not know Coffeescript well enough. Compared to Coffeescript, Babel is a total mess with all it's options/plugs config etc..

I rarely have type issues in JS, Python or Coffescript. I do have type issues in Typescript though. I fix that with 'any', just like my collegues. A Typescript codebase is about 2x bigger than a Coffeescript codebase, that means about 2 times more chance for bugs. But it's totally amazing to see the Typescript proponents considering the language to be a godsend. I moved from C/C++ to Javascript to get rid of static typing, it's part of my love for JS, but now that joy is being destroyed by static type enthusiasts.

I've never worked in a pretty Typescript codebase ever, same with JS, so many bad constructs, bad naming, bad architecture, etc, etc.. IMAO the real problems with codebases cannot be fixed with Typescript, the problems are way too big and complex for that.

I still don't understand why JS dev's that crave for types don't do Elm or Purescript instead of Typescript.

> A Typescript codebase is about 2x bigger than a Coffeescript codebase, that means about 2 times more chance for bugs

That's pretty obviously not true. If that extra code is adding type annotations then it is removing potential bugs because the code won't compile if you accidentally combine incompatible types.

All these issues are being worked on. If you use kotlin-js, the output is javascript. There are no GC issues, you use the javascript GC.

WASM is currently indeed bottlenecked on the lack of GC. This is being worked on. I expect a lot of progress over the next two years that will gradually remove most of the obstacles on this and other fronts. None of these are fundamental issues; it's just a matter of things not being perfect yet. Despite this, there's already a lot of early adoption. But I agree that Kotlin on WASM is short term not ideal. In the same way C#/Blazor currently only makes sense for enterprise application where download size is less of a concern. Rust does not really need GC, which is why is a popular language for this already.

As far as bloat is concerned; react is actually pretty horrible. I've seen simple react applications go over 1 MB for no good reason. I'd say the react ecosystem is actually a main driver for people wanting to have some alternatives. I actually prefer more lean approaches. Vue.js seems nice and I'm aware of a few nice lightweight dom abstractions (e.g. redom is nice).

I'd recommend taking a look at Svelte as well, it compiles down to "raw" JavaScript with very little client-side bloat.

Reply on news.ycombinator.com