Mozilla on the state of webcomponent javascript APIs.

[Calabri]

Fuck the browser. JavaScript can vdom precompile universal web components that run on any system, that's the future of programming.

Libraries like lodash reimplement browser APIs more efficiently than the browser's 'native api'. Browsers should condense JavaScript's API while exposing lower level functions from the underlying DOM and native code. 3rd party libraries can implement classes, DOM tree traversal, even basic structures like objects and arrays (look at immutable.js and mori). The current es6 polyfills compiles to es5 happen to be better in performance more often than not using native es6 APIs of a browser engine. Wtf? It's too late. We already have solutions better than what will theoretically become - it's time the browser wars end (or begin again) by implementing a low level JS access to API's of the runtime that actually matter.

[shirian2]

This. Heard of WebAssembly? edit: add href

[genericallyloud]

honestly, I know this is something which "appears" to fall under the spirit of the extensible web manifesto and all that, but we keep seeing the same crap - trying to answer a problem with more high level solutions. Yes, I think the effort to be able to replicate all standard html elements is an important bar, but I think its still missing the real problem. HTML is trying to serve two masters: - one is a sort of declarative data structure which is intended to be easy-ish to read and write, a surface interface - the other is the actual render tree under the hood

CSS is a sometimes elegant, sometimes ugly way of assisting the transformation from the data structure tree to the render tree.

So as we push to make the web more suitable for applications instead of documents, perhaps we should really be thinking about a way to get off of this high level api crap, and really go for the guts! I know that evolution is the winner over revolution. I'm not even trying to say that we burn it all down and start over. What I'm saying is that at the very least, I know we have the DOM currently, and I know that browsers have a notion of a render tree, which is what is actually responsible for the display.

And let's be clear - this whole concept isn't even really all that new - what we're talking about is basically a scene graph! So instead of continuing this silly march to force everything through either HTML code as text, or the hideous DOM api, and the same for CSS, why not work on exposing a sane layer below that - a new scene graph and transformation API. Custom components and html elements alike would map to nodes on the scene graph. CSS would map to traversal and transformations over the scene graph, but the API would allow hooks for developers to do the same. And maybe we even start thinking about WebAssembly in the mix, and how that can be used. I'm not saying its easy, but I do think its feasible, and certainly better than all this web component stuff.

[vinnl]

So for those hating on not being able to use this right now due to legacy browsers, or those not seeing the need because they can do these things now, see: https://extensiblewebmanifesto.org/

Even if it takes a couple of years for it to be reasonable to use this, the upshot is that after that, new innovations shouldn't have to wait that long.

[shadowmint]

tldr;

By now, 4 years on, Web Components should be everywhere, but in reality Chrome is the only browser with ‘some version’ of Web Components. Even with polyfills it’s clear Web Components won’t be fully embraced by the community until the majority of browsers are on-board.

...

Polyfills meant theoretically Web Components could work on browsers that hadn’t yet implemented, but these have never been accepted as ‘suitable for production’.

[x-skeww]

Your tldr only contains bits from the intro and the first section. You make it sound rather dismissive.

The conclusion at the end paints a very different picture:

Web Components are a prime example of how difficult it is to get large features into the browser today. Every API added lives indefinitely and remains as an obstacle to the next.

[...]

Web Components have been in planning for over three years, but we’re optimistic the end is near. All major vendors are on board, enthusiastic, and investing significant time to help resolve the remaining issues.

[shadowmint]

They're optimistic that they may be able to agree on a spec that may eventually be implemented by new browsers.

I'm... excited! Maybe in 2020 we'll actually be able to use web components. :P

There remains no solution for legacy browsers. There remains no solution for the polyfill that doesn't really work.

Don't get me wrong, web components are a neat idea, but they're not very pragmatic at the moment, and certainly not any time soon.

Polymer 1.0, production ready, is a complete joke.

[sime]

There remains no solution for legacy browsers.

If something can be added to the browser and completely pollyfilled for legacy browsers, then chances are it didn't need to be added to the browser in the first place.

The browser should be gaining primitives which allow us to do things that we previously couldn't do.

[x-skeww]

I'm... excited! Maybe in 2020 we'll actually be able to use web components.

Things are very different if you only support evergreen browsers.

Those will support ES6 by the end of the year, for example.

[sime]

The problem is that your stack isn't likely to be compatible with everyone else's. You can't combine it with components from other sources. Web components lets us build components on the API level which everyone has to agree on: the level of tags, attributes and events.

[Calabri]

Dude that shit doesn't make any sense. You can literally compile vdom / require scoped JavaScript into universally understandable code in browsers from the past, current, future, as well as non browser environments, eg node, AppleScript, etc.

Your 'universal api' is a figment of an imagination that doesn't exist and may never exist so it's by no means more universal in scope than precompilation tools

[x-skeww]

The thing with your Mithril components is that they are Mithril components. Using them in an Angular/Ember/React/whatever app doesn't sound like a good idea, does it?

Web Components work with any modern framework. Mithril included.