Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript is surprisingly ok for compilers

matklad.github.io

Post reply on HN
Print view View original

111–120 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#111

Post by hibbelig »

AgentME wrote: post #94
jillesvangurp wrote: post #45

Earlier quoted context omitted.

I've done a bit of typescript and kotlin-js. It always strikes me how close those two languages are. Yes there are lots of differences but they aren't that different and you can transition from one to the other pretty easily. I have my preferences (kotlin) but I can work with both. IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascrip…

Typescript is defined to run exactly as the equivalent Javascript you get when all the type declarations are stripped out of the source. There's no benefit in compiling it to WASM unless you had a WASM JS engine (or JS->WASM converter) that executed the JS faster than the browser's built-in JS engine (or created WASM binaries that were smaller than compressed minified JS, which seems extra unlikely when you'd have to…

Your parent suggested to make changes to TS so that TS is no longer compatible with JS (in the sense you described). Once that happens, compiling to WASM instead of transpiling to JS is a very valid design choice.

Re: TypeScript is surprisingly ok for compilers

#113

Post by andsoitis »

xvilka wrote: post #48
lmm wrote: post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.

> This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.

JavaScript and TypeScript are not "proper" languages?

Different languages are powerful in different use case dimensions (tradeoffs), and the typical client-side web programming has a very very strong UI angle, which many "more powerful" languages that I am going to guess you have in mind are less adept at.

Re: TypeScript is surprisingly ok for compilers

#115

Post by raxxorraxor »

austin-cheney wrote: post #66
baq wrote: post #17

Earlier quoted context omitted.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

I never ever use try/catch in my code. The only time its really necessary is to wrap JSON.parse on use of untrusted input. For everything else it just feels sloppy as through there is insufficient logic in place for handling primary conditions versus edge cases. Also, try/catch will never compile in the JIT.

For everything with the slightest bit of I/O it is quite practical if you have even the most trivial assumptions about its form.

Sure, you can check for everything. It often is more effective, but not prettier or easier to read and of course you also will miss cases.

Re: TypeScript is surprisingly ok for compilers

#116

Post by grumblingdev »

TypeScript is an incredible language in general.

The fact that Functions are Objects that can have properties/methods is supremely undervalued.

Are there other languages that do this so nicely? It's the perfect blend of OO and functional.

Programming is mostly about gradually figuring out the right design I find. JS/TS let's me evolve things naturally without big rewrites.

    function foo() {}
    function bar() {}
    function baz() {}
    const commands = [foo, bar, baz]
    // Run commands
    commands.forEach(x => x())

    foo.help = 'This does something'
    // Describe commands
    commands.forEach(x => console.log(x.help))

    // Add some state via closure.
    const config = {}
    function foo() { config.blah }

    // Add some state using partials.
    function _foo(config) { config.blah }
    const foo = foo.bind(null, config)
I can flexibly do what I need, without ever having to define a class like `Command`, which I probably don't even know what it should be yet.

This premature naming of things in OO creates so many dramas.

It avoids things like `VideoCompressor#compress()`, `VideoSplitter#split()`. You don't have to think: what state belongs in which class...you just call the function and pass it what it needs.

Re: TypeScript is surprisingly ok for compilers

#118

Post by jakubmazanec »

usrusr wrote: post #103
flohofwoe wrote: post #63

Earlier quoted context omitted.

"Modern" Javascript essentially is Typescript without the type hints (e.g. if you ignore the historical baggage, JS is actually a fairly decent language).

Yeah, having just jumped into ts after a long js hiatus since back when The Good Parts was still surprising, it's quite awesome to see how much of what I assumed to be "ts stuff" is actually just postdeluvian js. Makes ts more attractive, not less. I do wonder however of it was possible to identify parts of that language superset that are fully redundant (as in not even required for exotic edge cases) and let loose s…

You already can kinda do that using ESLint and rules like https://eslint.org/docs/latest/rules/no-restricted-syntax, https://eslint.org/docs/latest/rules/no-restricted-propertie... or https://eslint.org/docs/latest/rules/no-restricted-imports.

Re: TypeScript is surprisingly ok for compilers

#119

Post by afavour »

austin-cheney wrote: post #66
baq wrote: post #17

Earlier quoted context omitted.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

I never ever use try/catch in my code. The only time its really necessary is to wrap JSON.parse on use of untrusted input. For everything else it just feels sloppy as through there is insufficient logic in place for handling primary conditions versus edge cases. Also, try/catch will never compile in the JIT.

> Also, try/catch will never compile in the JIT

Changing the way you program to fit what a JS compiler does or doesn't do is a fool's errand, IMO. The performance benefits are likely to be minimal, confusion for anyone else who has to touch the codebase is high.

Re: TypeScript is surprisingly ok for compilers

#120

Post by airstrike »

andsoitis wrote: post #113
xvilka wrote: post #48

Earlier quoted context omitted.

This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.

> This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web. JavaScript and TypeScript are not "proper" languages? Different languages are powerful in different use case dimensions (tradeoffs), and the typical client-side web programming has a very very strong UI angle, which many "more p…

JavaScript's redeeming quality is that it is ubiquitous due to being used by browsers. I don't think anybody credibly claims it to be a language we would want to use if we were to redesign web programming from scratch today
Post reply on HN