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?
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).
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.
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.