Support Web Components v1

[donny-dont]

The dart:html library should deprecate the current v0 specifications of Custom Elements and Shadow DOM and move to using v1 of both specifications.

[donny-dont]

DDC related issue #27311

[donny-dont]

@floitschG anything to follow for this? Chrome 54 shipped and comes with the v1 specs enabled.

[kevmoo]

@donny-dont there are a LOT of things we need to fixup in dart:html – we're holding off until DDC is locked and loaded. It'll be much easier to get everything working when our dev story is 100% javascript.

[kulshekhar]

when our dev story is 100% javascript

I'm not sure I understand this. Could you please add some more info. Is it JS compatibility you're referring to or the possible inclusion of javascript specific tools in the build step, along with DDC?

[zoechi]

@kulshekhar the problem is the Dart VM in Dartium where during development some Dart code is directly executed by the Dart VM but other stuff runs in JS land.
With Bazel and DDC they are working on building a developer story with fast edit-reload cycles with standard Chrome (without a Dart VM being involved) to simplify interop between the Dart code (transpiled to JS) and the native JS world.

[kulshekhar]

Thanks @zoechi

That makes sense now 😅

[eukreign]

Any updates on this, we're in 2017 now :-D

[matanlurey]

I imagine there won't be any progress on this until Dart 2.0 rolls out completely removing Dartium.

I'd check back in a few more months, or use JS interop to "build your own":
https://pub.dartlang.org/packages/html5

[eukreign]

Who's still following this issue in 2018? Sorry, couldn't resist. Maybe 2018 will be the year Dart finally gets Web Components v1!

[kevmoo]

We're in the process of updating our dart:html APIs – https://dart-review.googlesource.com/c/sdk/+/24501

That roll – and getting rid of Dartium – should make it easier to support the latest Browser features.

Having said that, our primary framework – AngularDart – is not using WebComponent features, so it's not a big priority for us.

My suggestion: once we've updated dart:html and friends, let us know specific APIs that are missing/broken

[elmcrest]

That's really sad.
In my mind a serious "community centered" effort should kind of use and depend on different independent blocks. to make the idea more clear, AngularDart for sure needs some stuff handling DOM and it seems sane to me to use something like dart:html as a basis.
so, every work from google would be contributed back to the basis and others building on top of this basis would automatically benefit - somehow like the whole OpenSource-Idea, no? ;)

currently Dart is more like: "You want to do web? Sure, use AngularDart." (Hint: AngularDart != "the web")

that said, I'm not the guy who can actually judge what you're doing and why - just saying this from a rather distant and abstract point of view and trying to support Dartlang itself against common attacks. (you know those.... "meh, google is going to throw it away anyways..." etc.)

Maybe I should add, that webComponents are the reason why our app is only running on Chrome...

[matanlurey]

@elmcrest Hi Marius.

I realize and understand you are disappointed. I'm one of the TLs of AngularDart, and let me make it clear I think web components are awesome, and would love Dart to support them well. The primary take away here is well though, and that will take a little bit of effort, because the current HTML libraries and browser bindings aren't well suited for this.

We could probably get some hacky support quicker, but it won't be something useful to most customers. It's something we'd like to revisit after Dart2 launches, but until then - again to be very honest - it's just not a priority. We care, but we have limited time and resources, and have to use them efficiently, like I'm sure you do on your project(s) and company.

FWIW, most popular web frameworks are not utilizing web components today:

• React
• Vue
• Angular (JS/TS/Dart)

... so it's not clear web components is the "killer" feature for most people.

Thanks for your patience!

[eukreign]

The entire point of Web Components is that it's a "framework" that is built-in to browsers. You can just use it, without any extra libs or 3rd party frameworks.

AngularDart emulates many features of Web Components, why does it do that instead of just using Web Components directly?

[matanlurey]

@eukreign:

The entire point of Web Components is that it's a "framework" that is built-in to browsers

Well, sort of. It has yet to be supported in Microsoft Edge, for example, which is quite a large market segment still, and the polyfill performs quite badly. So until it works everywhere, it's not free.

AngularDart emulates many features of Web Components, why does it do that instead of just using Web Components directly

AngularDart (and JS/TS, and React, and Vue, and Ember) all were created before web components were a thing. A lot of these framework authors have evaluated web components and found them severely lacking. Here is one of the leads of React, arguably the most popular framework today:

We’re not going to use it at all at Facebook. We’re not going to build React on it because there’s a strong model difference – imperative in Web Components to declarative in React. Web Components doesn’t have an idiomatic way to define things like where events go. How do you pass data when everything is a string? We see it more as an interop layer that lets various frameworks talk to each other.

In talking to the Atom team, this doesn’t solve different framework idioms as it doesn’t have an opinion on how they relate.

Again, it's not that support will never be offered, but it's unlikely to happen in any immediate time frame. There are other APIs that are more useful for our users, like web workers, service workers, and more right now.

From a personal perspective (not the Dart team's), I'd use JavaScript or TypeScript if I was highly interested in web components - its much better suited for this lightweight model than Dart is (more suited for larger web applications, not scripts/standalone components/buttons).

Thanks for understanding!

[eukreign]

This post has been deleted for violating the code of conduct.

[elmcrest]

I also disagree to prefer typescript over dart for little snippets. The undefined, NaN, 0, false, null, whatever hell is one point, imports and package management still another...
Dart can really shine even for small snippets and if your build system is already setup anyway, why wouldn‘t I want to use dart for everything?
One truth tends to get hidden/ignored more and more these days: Javascript sucks! ;)

[matanlurey]

I'm locking this conversation for now since it's getting non-productive. This is something that is interesting to us, but it's not on the immediate roadmap at this time. Thanks for the feedback.

[kevmoo]

We don't plan to support this API in the short term. None of our core users require it and would involve substantial effort to implement it correctly.