I was talking to my manager the other day, discussing the languages we are using at $dayjob. He kind of offhandedly said that he thinks TypeScript is a temporary fad and soon everything will go back to using JavaScript. He doesn’t like that it’s made by Microsoft either.
I’m not a frontend developer so I don’t really know, but my general impression is that everything is moving more and more towards TypeScript, not away from it. But maybe I’m wrong?
Does anyone who actually works with TypeScript have any impression about this?
I believe both are true… and I also develop a LOT in Angular (with TypeScript).
TypeScript is great but the thing is that if you look at the history of TypeScript and JS/ECMAScript you’ll find out that TypeScript sometimes is the testing ground for the future features of ECMAScript - pretty much like what happens with Sass and CSS that how even has nesting and scopes.
The issue with TypeScript/Sass etc. is that it requires a compiler and that’s totally obnoxious and completely defeats the point of having interpreted code on browsers. Depending on the project it might be better to go for TypeScript + Angular/React or other compiled solution or simply something vanilla with jQuery or the Vue runtime (no compilation) and other libraries.
If TypeScript ever goes away the underlaying features that make it great will be implemented in ECMAScript in the same way that we got modules, classes etc. and I really hope it happens. Less compilation usually equals code more maintainable in the long run because you won’t require hundreds of dependencies (that will eventually break) to get it to compile.
They have an explicit policy to only include features that are stage 3 already (i.e. that are pretty much certain to land in the language as-is). The only times they’ve diverged from this is long in the past (I think
enumis the main remnant of that, for which I’d recommend using unions of literal string types instead), andexperimentalDecoratorsunder pressure from Angular - which has always been behind a flag explicitly named experimental.So I really wouldn’t worry too much about that.
Oh I’m not worried, at all.
Shouldn’t WebAssembly be a solution to this? I.e. so you don’t have to interpret code but rather run the wasm binary (which is kinda interpretation as well but you get what I mean).
I love seeing webassembly getting traction because it enable cool stuff never thought possible before running in web browsers. But webassembly is a blackbox that can’t be tinkered with by end users. I dread the day webassembly become so widely used that average websites run under webassembly because that would be the end of blocking ads or tweaking websites behavior with greasemonkey scripts.
I don’t think adblockers rely on interpreting JavaScript, I think they would still work even if a site used WebAssembly.
Source: I can assure you every single ad-funded website would be doing this if that was the case.
ublock origin won’t help you blocking the ad elements if the entire website ui is rendered in a canvas (already starting to happen thanks to some frameworks like flutter) and can’t block the ad logic if it bundled in the wasm along with the rest of the app. It might still able to block the requests, but they’re starting to serve the ads from the same domain that serves the website so it can’t be blocked without breaking the website itself, and might begin to serve those over websocket so adblockers can’t block it by url path. With javascript, an ad blocker might still be able to monkey patch the ad logic on runtime to break it, but with black box like wasm I’m not sure if such thing is possible.
Once tooling and frameworks make it easier for average webdevs to use webasm, I’m sure ad companies will begin to offer it in their ads sdk. Thankfully most websites with ads are still care about SEO so at the very least we can be sure it won’t happen anytime soon, unless something changes in how google works that could enable this.
That sounds like an accessibility nightmare.
Have you tried not being disabled?
Flutter devs actually defended this approach, saying the web in general is moving to this direction. I think they’ve mellowed out somewhat and released html renderer support, though it’s still default to canvas for desktop web browsers.
That’s not a solution, it is the exact opposite - adding even more compilation and complexity to things. The ideia is to move away from compiled stuff as much as possible. WebAssembly makes sense for very complex and low level stuff that you can’t run interpreted with reasonable performance.
Less compilation usually equals code more maintainable in the long run. Think about it: if you don’t need a compiler and the hundreds of dependencies that will eventually break things will last way more time. Websites from the 90’s still work fine on modern browsers and you can update them easily while compiled stuff is game over once you lose the ability to install run said compiler and related dependencies.
You can have hundreds of dependencies whether you use a compiled or interpreted language, that really has nothing to do with that.
Also compilation has lots of benefits, including being able to do lots of static analysis to find bugs. I definitely don’t agree that we should move away from compilation in general or WebAssembly specifically. WebAssembly doesn’t have to be only used for low level stuff, you can write your code in a high level language and compile to WebAssembly just fine.