[smoyer]

The arguments against the four language features in this article all boil down to it not being Javascript. If I wanted to write in Javascript, I'd use files with a .js extension. If you've picked Typescript, I don't think you should worry about whether your code is also valid Javascript "if you remove all the type information" (who's going to do that anyway.)

Unless you're a solo developer, what's more important it to agree on languages and conventions that apply to your team's projects. Once that's done, any change to the team's work process should be a conscious, measured decision.

Note that I also used CoffeeScript 10ish years ago and still consider it to be a superior experience to working in plain-old Javascript.

[rezonant]

While I agree with the general sentiment, there's a bit of pedantry for you here: Typescript itself removes all the type information when you compile, it's not about the developer doing that themselves outside the context of the compiler. But that is a moot point with regard to the suitability of the features as the article itself suggests-- TS doesn't break your enums during compilation, a suitable JS representation is emitted.

Occasionally I think I might want to use enums in a place but then find that other solutions like const collection objects or plain constants works fine enough for the purpose at hand. I don't think it's a problem if folks use enums though, it's really not a big deal.

[mhoad]

I continue to maintain that despite all the nice features from ES6 onwards working in straight JavaScript is psycho shit. It’s the NFTs of development.

I’m genuinely looking forward to the day where we have other viable options for the DOM. I see TypeScript at best as a temporary band aid because you’re still stuck in the god awful NPM ecosystem at the end of the day.

[rezonant]

I disagree with almost all of this, but I will say have you checked out Deno? It is in fact Typescript without the NPM ecosystem (amongst many other interesting aspects)

[mhoad]

Honestly, I’m more waiting for WASM garbage collection to officially land as a standard.

It won’t get me DOM level access but I can at least move a lot of my code there. I’m also quietly hopeful that canvas based rendering can make some huge improvements in the next few years so it doesn’t feel like Flash 2.0 but I’m ready to at least start thinking about letting go of the DOM as the thing I have to care about.

Until then I’m having a good time with Lit (lit.dev) for building web apps that need to be super snappy and “web feeling” which is still basically every customer facing thing.

But in a dream scenario I would way rather be writing apps in Flutter which was at least built from the ground up for building complex user interfaces in a sensible way, but that whole ecosystem is still in some very early days on the web and isn’t a good choice right now for most things, hoping that changes in a few years as they also seem to be targeting the WASM + Canvas path and the web as a platform isn’t there on that yet and neither are they.

[rezonant]

There are a few big problems with using Canvas for UI on the web. First and foremost is accessibility- there is no way for your app to convey the information screen readers are able to get from analyzing the DOM along with the ARIA metadata that you (should) put into your markup. Furthermore, users who have trouble using a mouse can use the keyboard on the web, and it usually works very well since the browser handles it and the browser has been battle tested. You would need to implement your own keyboard handling scheme (though I'm certain a ton of apps just wouldn't bother). What about scrolling with touch input? You would have to implement that too and good luck making it as smooth and performant as the system's own native scrolling (let alone making it use the appropriate rubber banding- iOS and Android have separate ways of doing this because Apple patented the original iOS rubber band scrolling)

Secondly, there is no way for automated agents to extract content from your user interface. This includes search engines, browser extensions, the browser itself, or your end users. I think that goes against what the web is, and I hope other devs agree. The mutability of HTML (and thus the DOM that represents it at runtime) is a strength, not a weakness

[mhoad]

This was my first reaction also and I think it’s understandable but having looked at proposed solutions to it as well it actually doesn’t seem like such a big deal.

I apologise if I get some minor details wrong here as I am doing this on a phone and recalling this from memory because I don’t have the time to grab the sources right now.

However… the short version of the plan to solve this that I seem to recall to this:

The Flutter team specifically seemed to indicate that they are already used to operating in non DOM environments where they have to support accessibility across Android, iOS, MacOS, Linux and Windows that doing it on web actually isn’t that big a deal as it first seems.

They already have all of the code in place that builds a full tree (like the DOM) which does a complete mapping between every element (widgets in Flutter lingo) on the canvas to their respective bits of accessibility info. They then just take that tree and hook it up to the respective accessibility APIs that each platform exposes.

At no point have they indicated that this looked like it was going to be a serious roadblock or challenge for them. I believe them and they have a history of this approach working elsewhere.

There is just too much money riding on this investment for them not to get accessibility 100% correct in a web native way.

From there if you are able to expose everything through accessibility APIs then you presumably also have everything you need as a search engine or an adblocker to actively read and modify that canvas. At this point the entire argument that it’s just an opaque set of pixels seems to vanish for me.

This is also AFAIK already a solved problem for them in other products where they are using canvas based rendering such as Google Earth and Google Docs.

I don’t have the details beyond that right now sorry but that passes the sniff test for me at least.

[rezonant]

> respective accessibility APIs that each platform exposes.

That's the problem, there isnt an accessibility API for the web, is there?

EDIT: At least not one that works without DOM

[smoyer]

Compiling Go to WASM is actually a viable way to write a SPA ... I've used it with material-components-web so you can certainly manipulate the DOM.