DEV Community

Discussion on: The Trouble with TypeScript

Collapse
 
trusktr profile image
Joe Pea • Edited

I'm really enjoying AssemblyScript too!

Collapse
 
mateiadrielrafael profile image
Matei Adriel

I tried assemblyScript a few weeks ago and it has lots of problems, it feels like a prototype and until it gets out of beta I dont think I'll give it another try

Thread Thread
 
trusktr profile image
Joe Pea

What problems did you have? The main problem I can think is that it works with only a subset of the features of TS/JS, but if we stick with those features then it works well. I've been porting Three.js to AssemblyScript over at github.com/infamous/glas and so far it's been pleasing to see the ported tests pass in AssemblyScript. THe most notable changes were, so far, that we needed to modify any APIs that used object literals to instead use strictly-typed objects generated from classes. This is actually improving the type safety of the code. :)

Thread Thread
 
mateiadrielrafael profile image
Matei Adriel

I cant remember exactly the problems I had, but basically I was just porting an entity component system when I started getting random crycptic erros for no reason (and yes, I only used the supported features)

Collapse
 
jwp profile image
John Peters • Edited

Joe, kind of funny really. Webassembly must throw Javascript purists crazy. Their infrastructure is crumbling daily. Typescript from the top, Wasm from underneath. I'm not a fan of Razor, but it's ahead on challenge.

Thread Thread
 
ryansolid profile image
Ryan Carniato

Perhaps. As mentioned I'm into benchmarking. And WASM just isn't faster for DOM operations. Solid's higher level abstraction still is faster than the fastest WASM vanilla optimized hand crafted routines in JS Frameworks Benchmark. When you add a higher level abstraction on WASM it gets slower still. I'm sure it will get there some day but I think the direction of using compilation like Solid or Svelte doesn't make anyone in the wider JS community feel threatened by WASM. It's another tool. I think its more interesting when JavaScript haters don't realize that the more they accept things like TypeScript and WASM they are just playing further into the same infrastructure that legitamizes JavaScript. At some point there will be something better and it probably won't look like anything that is there right now. And it won't be because of some Type vs UnTyped mentality will be about capability and expressitivity. That's why JavaScript is still here. In those terms it is incredible. I think things can be better. JS is far from perfect but it sort of accidentally hit this sweet spot that I don't think is immediately appreciatable.

Thread Thread
 
jwp profile image
John Peters

Today, I like Javascript. But in 1990-2005, I couldn't stand it. I was forced into it due to its ubiquitous utilization. If one works the Web. Javascript is paramount.

Thread Thread
 
trusktr profile image
Joe Pea

Yeah, until WebAssembly Interface Types are out and Wasm has direct access to DOM references, it will be hard to make Wasm faster than plain JS for DOM operations. But once Interface Types are out, and Wasm can work with DOM references directly rather than needing to do it via a JavaScript bridge, we might see optimized Wasm become faster.

When the day arrives that Wasm can access DOM directly, tools like Blazor (Wasm-based DOM manipulation in .NET), RSX (JSX-like expressions for manipulating DOM from within Rust compiled to Wasm), gccx (JSX for C++), and others, will be in a great position to take advantage of it and allow developers to truly select their favorite language for working with DOM and have great performance at the same time.

AssemblyScript is TypeScript syntax, which already supports JSX, so that's going to be neat once all the existing TypeScript DOM-typed APIs work directly in Wasm.

It is currently not possible for Wasm to win against JavaScript in DOM performance, but I believe that will change.