After the "hump" you'll find yourself more productive I think. It's just like with Vim: after using it for a while you are faster than with regular editors at text manipulation. Every day I use text fields like the one I'm typing in right now, and can tell the difference in speed. There's some Chrome extensions like Wasavi that I maybe should try. But anyways, I've done some fairly huge refactors of code bases with TypeScript (in VS Code in particular with all the refactoring tools), and I can't imagine doing the same in plain JavaScript, let alone the refactors sometimes working first try! It's wonderful.
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
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. :)
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)
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.
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.
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.
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.
Yeah that's what I've been hoping for. I'm expecting the other shoe to drop for months now. And it sort of does. Like I feel fairly competent now with TypeScript. It's just the more I learn the more I'm impressed with how difficult the challenge that exists here. And while it's admirable and the community has been so helpful. There is always just the next thing.
I lived in the CoffeeScript world for a long time with no tooling after coming from C# where everything was autocompleted. It was less of a system shock than I expected. I've lived through both and they have their tradeoffs. The weird part for me is how TS is not C#. That strange ambiguity and incompleteness when approaching certain problems that are possible only because TS is JS.
Yeah, it is interesting how TypeScript is releasing some new type features -- that basically don't exist in any other typed language -- due to the efforts in making it possible to express JavaScript paradigms with types.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
After the "hump" you'll find yourself more productive I think. It's just like with Vim: after using it for a while you are faster than with regular editors at text manipulation. Every day I use text fields like the one I'm typing in right now, and can tell the difference in speed. There's some Chrome extensions like Wasavi that I maybe should try. But anyways, I've done some fairly huge refactors of code bases with TypeScript (in VS Code in particular with all the refactoring tools), and I can't imagine doing the same in plain JavaScript, let alone the refactors sometimes working first try! It's wonderful.
I'm really enjoying AssemblyScript too!
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
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. :)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)
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.
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.
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.
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.
Yeah that's what I've been hoping for. I'm expecting the other shoe to drop for months now. And it sort of does. Like I feel fairly competent now with TypeScript. It's just the more I learn the more I'm impressed with how difficult the challenge that exists here. And while it's admirable and the community has been so helpful. There is always just the next thing.
I lived in the CoffeeScript world for a long time with no tooling after coming from C# where everything was autocompleted. It was less of a system shock than I expected. I've lived through both and they have their tradeoffs. The weird part for me is how TS is not C#. That strange ambiguity and incompleteness when approaching certain problems that are possible only because TS is JS.
Yeah, it is interesting how TypeScript is releasing some new type features -- that basically don't exist in any other typed language -- due to the efforts in making it possible to express JavaScript paradigms with types.