upvote

points

by philipwhiuk10 hours ago |
comments
upvoteby vips7L4 hours ago|
next
[-]
KotlinJs and ClojureJs too. You always end up having to write wrappers or dealing with problems that would just work if you just used normal js/ts.
reply
upvoteby gleenn2 hours ago|
parent|
[-]
Clojurescript not ClojureJs, and Typescript doesn't run in the browser, it has the exact same issues/limitations: it must be compiled to JavaScript first.
reply
upvoteby warpech2 hours ago|
parent|
[-]
Compiling TypeScript is just stripping out types
reply
upvoteby Stratoscope1 hours ago|
parent|
[-]
That is true only if you confine your TS code to be pure JS plus type annotations.

There are TS constructs that require compilation into equivalent JS, such as enums and namespaces.

reply
upvoteby hermanradtke1 hours ago|
parent|
next
[-]
Are there any other?

Namespaces are heavily discouraged. Some teams still use enigma but most people in the know us unions of strings.

I know the TS team regrets enums and I have not seen any plans for adding additional keywords that break type stripping.

reply
upvoteby Stratoscope3 minutes ago|
parent|
[-]
The other one I read about was parameter properties in constructors.

And thank you for the correction! It was quite a few years ago that I used TypeScript, and I think the landscape was different then.

Making things even fuzzier in my mind, this was an Angular project, and it was hard to keep track of what was Angular and what was TypeScript.

It sounds like people these days actively avoid the parts of TypeScript that require translation into different JS code.

reply
upvoteby p_l1 hours ago|
parent|
prev|
next
[-]
"fortunately" we can load swc compiled to wasm to deal with that.
reply
upvoteby igl1 hours ago|
parent|
prev|
[-]
absolutely nobody used those outside of a language demo. We also got --erasableSyntaxOnly last year to remove them from the language. The TS team considers them “mistakes“ for a really long time now
reply
upvoteby nobleach8 hours ago|
prev|
next
[-]
Yup, and Clojure/ClojureScript!
reply
upvoteby lbourdages9 hours ago|
prev|
next
[-]
Couldn't WASM solve that problem once and for all? Is there some limitation that WASM has that JS doesn't?

Disclaimer: I am very inexperienced at front-end development.

reply
upvoteby danielheath9 hours ago|
parent|
next
[-]
> Is there some limitation that WASM has that JS doesn't?

You need a JS trampoline to call your WASM and make browser primitives available to it, and IIRC calls into browser code incur some extra overhead, but those are pretty manageable.

Additionally: for high level languages, source code is _much_ smaller than compiled binaries. If your initial needs are simple, your users are likely downloading more than 10x as much code.

reply
upvoteby applfanboysbgon7 hours ago|
parent|
prev|
[-]
WASM does not (yet) have access to the DOM or web APIs, meaning every direct interaction with the browser must first go through JS interop anyways, with a resulting performance penalty. There are proposals, and maybe we'll see it happen by 2035, but as of now WASM is best suited for heavier workloads where the edge in application performance outweighs the cost of JS interop with the browser rather than being a universal solution.
reply
upvoteby raphinou9 hours ago|
prev|
[-]
Such attempts are quite common. Some I remember:

https://ocsigen.org/ in Ocaml too

https://websharper.com/ for fsharp and csharp. Really good when I used in in fsharp

Maybe https://melange.re/v7.0.1/ too? (Not sure)

reply
upvoteby vintermann8 hours ago|
parent|
[-]
I took this as a joke in reference to the popularity of JavaScript on the backend for the last two decades.
reply
upvoteby reactordev8 hours ago|
parent|
[-]
that's because most people's intro to CS was how to build a webpage.
reply
upvoteby zero_bias2 hours ago|
parent|
[-]
Modern web development is more like computer alchemy
reply