It’s also just not actually true though. It’s not considered good practice to bundle your web components when publishing to npm for this exact reason. That’s something that should happen inside the final app itself where the components get used so you only have one instance of Lit for example if you are using that.
It would be cool if you could apply even the most basic reading comprehension here where it says there was zero change in team size and stop spreading nonsense.
That’s not actually correct I don’t know where you got that from. This is from this year and was built on top of a wider rewrite of their JS interop using new language features to make it essentially a zero cost abstraction.
Dart has had browser support and DOM APIs before but never had the same APIs you have in the web platform before.
I’m not sure what YOU are on about here. They are both well known gaps that make integrations a pain in the ass. Not sure if you’ve ONLY used React or never used React.
You seem kind of confused about what people are referring to here and I don’t know if it’s out of ignorance or partisanship but I mean using options that don’t have to reimplement entire core parts of the web platform that already exist but in JavaScript and in a way that doesn’t work with anything else.
I’m making the argument that would be a bad choice to make in 2022 but totally understand why it made sense a decade ago.
It’s lack of proper support for both the DOM and native browser events are both giant holes that immediately come to mind and have the unfortunate side effect of making React integrate with anything that wasn’t specifically designed for React a giant PITA.
Probably something like Lit.dev seems exceptionally well positioned to stay aligned with the platform and give the same developer experience and a much faster user experience.
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.
If you’re going to be working in a multi language code base I am with you. Handing people garbage looking generated or compiled code and saying work with this is going to require a solid set of well defined interfaces at a minimum and maybe like you said even giving up all of that and having to make one thing look like the other. All of what I said was under the assumption that you don’t need to think about JavaScript again.
Im making the argument that JavaScript is a target that we have all been collectively forced into due to the limitations of the web as a platform but short to medium term horizon that is changing where things like WASM are maturing and will let a lot of new options flourish (.NET folks seem to be probably leading this charge currently)
But just stopping to think about the implications of that kind of changing landscape and what’s coming, I don’t think aiming for 100% JS interop not just from a code perspective but it also the entire tooling and developer ecosystem perspective is going to be as important.
Again, I just think people are somewhat forced to at the moment because the web has always been a one language show. That wasn’t because JS was the best choice but rather a limitation of the platform itself which is already in the early stages of changing.
For Dart specifically I kind of get what you’re talking about I guess because it’s pretty commonly referred to as the best bits of JS and Java put together while ditching the worst parts of each so it’s clearly aimed at productivity for application sized code bases rather than something low level but again… that’s literally why they have a proper complication step because getting it down to something a lot more low level is exactly what a compiler is for. That doesn’t feel weird to me at all, that actually feels like an incredibly sensible choice.
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.
I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps.
I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get the same compilation optimisations that Google uses to run all of their multi billion dollar ad business? Cool, that’s enabled by default out of the box. [1]
The part where Dart on the web falls over for me is that they have shitty support right now for modern web APIs. They are building against some ancient version of Chrome’s WebIDL files so you can totally forget about things like web components for example.
So in that sense it doesn’t feel like a sensible choice in 2022 for basic web development which is a shame because it’s otherwise probably the best developer experience I’ve ever seen.
[1] I say this somewhat theoretically, I don’t know that Dart is in anyway an obvious thing to point to in terms of web performance from what I had seen casually. I think their goal there you can write huge business critical applications with stupidly large code bases and still get good performance. But nobody’s experience after using Google Ads is to talk about how snappy it was.
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.
I guess that’s the part where we differ. I can’t help but see an inevitable merging between the idea of a native app and a web app until they are possible to be one and the same.
So for me the browser is more of a rendering pipeline that can deliver DOM for pages and apps or something like canvas for “native apps”.
As I was saying above I totally share that fear of sending these opaque blobs of binary data down the wire that paint arbitrary pixels that I have no control over. That isn’t how “the web” works.
So you are going to need to find a way to think about accessibility APIs for example that aren’t tightly coupled to the DOM. Those things are already happening. Source maps are another important tool to maintain that slick view source experience.
But I think there is a reasonable case to be made that the browser should 100% be capable of running native apps so long as they are able to play nice with the web as a platform.
Note: I have to just explicitly make that distinction between pages and apps here. I don’t ever want to see this try and become the new normal for anything that would reasonably be considered “document based”. I think they can comfortably coexist each with their own specialities.