I'm slightly confused by the combination of "introduced in Internet Explorer 5.5" and "offers a powerful new way" being written in an article posted on August 28, 2017
FTA: cough OK, obviously it’s 2017 and Internet Explorer 5.5 isn’t relevant anymore. But if you’re a Web developer, this should have given you some pause for thought. The modern Web Components pillars: Templates, Custom Elements, Shadow DOM, and Imports, were all features originally in IE5, released in 1999.
haha, it really was too, no hint of sarcasm! Young'uns these days probably can't believe what a saviour Microsoft from the clusterfudge that Navigator represented back then.
They behaved like a native app, with control over their native chrome, and without any browser sandboxing: their JavaScript (JScript) or VBScript could use COM components to access to the file-system and other features, including loading other binaries in-process. File-system access was through Scripting.FileSystemObject, for example.
Some built-in Windows components were/are built as HTAs, like the previous versions of the Microsoft AntiMalware / Windows Defender UI.
I tried to use it for a project in 2013 but couldn't because HTAs are forced to run in Quirks-mode, so you can't use IE11's Edge mode, unfortunately.
Best of all: they ran while needing only a few megabytes of RAM. Compare with Electron-based apps and it makes me weep because this, right here, is evidence that a Web-View can be used as the basis for an application, using a platform that was available since 1998/1999, without it dragging my PC down.
I don't agree that Electron is simple. Electron runs a Node.js instance as a websever and application server in-proc, while also running Blink/WebKit for each frame instance. There's no consolidation going on, and I feel for a majority of Electron applications there's no need for the Node instance because all they're serving is an Angular app using the built-in `chrome.` APIs. What would be simple is if a script tag in a single HTML file could access the filesystem or Windows registry - but under Electron they can't.
I still use them - IE9 being the highest available engine is just as bad as you remember, but being able to quickly whip up a few-hundred KB app HR can all use off a network drive to automate tedious tasks like recurring data-driven document generation, with a decent React UI, is worth some of the pain.
You can still do this, and in OSX too using MacGap (or writing a tiny webview wrapper yourself). The main reasons this is not widely done are incomplete device APIs, no control over browser versions/features - app might break at any moment for different subsets of users, and the lack of cross-platform compatibility. Electron actually solves most of those pain points despite the heft.
Personally, I think there's an important lesson here, and its the same lesson that polymer is learning as it stumbles around trying to convince people to use it.
Most people don't actually derive much benefit from writing custom UI widget primitives.
Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful.
I don't have time to invest hours implementing `ImageDropDownSpinner` as a custom element. <select> is good enough for me, and heck, maybe I'll use some 3rd party widget if I need something special.
That's not why react, vue, angular, etc. are winning the mind share of 'how to build web apps'; building UI widget is far less interesting than the ability to decompose your UI into a custom hierarchy of re-usable self contained units of functionality, that only at the lowest level actually involve UI components, is extremely powerful.
They might look like custom widgets, but <PageFoo> isn't a UI widget, it's your entire application; that's the difference.
It's easy to say this was a revolutionary idea, before its time, and it would have flown today instead of vanished into obscurity... but I think it missed the mark; it didn't solve problems people were actually having.
...but to be fair, it's easy to look at 'Web Component' efforts (like Polymer...) and go... yeah, this seems very familiar...
I really tried with Polymer (for the last few months) but it was particularly verbose.
I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand.
Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening....
Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs...
So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer.
I do look forward to going back there though when 3.0 is available.
Angular is a front-end framework for general purpose. Polymer is the library specifically to facilitate Web Component development only. So I think you are comparing apple and orange here.
Both are basic front end frameworks. Polymer just happens to use a minor spec to encapsulate and expose, the smallest part of what it actually does.
Polymer of all the frameworks i've had to use has had the most breaking changes. That they're turning the ship for each and every major forcing you to rewrite the entire application is kind of ironic given that their motto is "use the platform" as if suggesting stability and standard behavior.
Polymer is not the standard, just another arbitrary driver (as in: their own syntax, their own structures, their own api) for a pretty harmless spec that sets out to solve issues we haven't faced for at least 5 years.
Big corps like Google tend to over-engineer stuff. It's the very reason why Vue.js is so kicking ass due to its low learning curse and progressive approach. Why can't we do the same for WC standards?
I think the problem is more or less that we're at a breaking point where it's getting quite obvious that we should move away from higher-up standards. The browser should worry about low-level interfaces only, high level abstractions should never be cast in any standard and that is exactly what the extensible web manifesto said.
WC break this in half again and all of the sudden they're again trying to shovel more UI stuff into the dom. What they're trying to fix hasn't been a problem for years. Their entire spec was thought out in a meeting room maybe 10 years ago, but almost nothing of it has relevance today. It would simply make it harder again and block applications from leaving the browser behind.
For my sins, I look after a Polymer 0.8 based site left to me by a Chrome enthusiast. It is starting to break in mysterious ways. Not looking forward to the upgrade path...
"Third party widgets" was the use case. The idea was to build a marketplace for frontend components, much like existed for Visual Basic, eg. the average web developer would buy/download BobsTreeView.htc and bind an XML file and that would be it.
The actual issue was that very few people was doing any serious frontend development back then. Netscape and IE had completely different DOMs and the environments were not super stable. But there was an attitude that frontend was for designers and "real programmers" were backend-only.
So the real programmer found a backend component for ASP.NET or GWT and wasn't interested in the frontend sausage.
(This article reminded me of the DHTML Dude column[1], and yeah some of us unreal programmers were doing this bleeding edge IE-specific front-end stuff for clients. Then we spent many years atoning for our sins. However, I think 90% of "IE-only" apps never used this stuff, they just had the wrong box model or some dopey ActiveX upload component or something.)
That frontend vs backend attitude exists to this day, although somewhat less so. To be fair, apps were basically just forms in the early days of the web with very little dynamic activity.
I think that people that disregard Polymer fail to understand that Web Components are already here.
They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them.
And they have to, because Chrome and Safari own the mobile web.
Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and utility classes to make writing components easier.
Web Components is what is making me finally get to love web development again.
If it is to make an application platform out of browsers, then give me a platform, not an application for doing hypertext documents that we try to bend for something else.
Chrome settings panel, the new You Tube, all new EA gaming portals are already using Web Components.
I look forward to have something like Blend for Web Components.
Well, I think mainly it's because Google is behind webcomponents.org. It has ZERO mentioning on x-tag and other competing frameworks. Ironically, it is called "webcomponents.org".
It's like visiting a store called "phone" that sells iPhone exclusively. Google has definitely got own its down agenda with the so-called standards in this regard.
Unsurprisingly, a searching "x-tag" on webcomponents.org returns pathetically two components.
While this is true, it's also true that x-tags and whatever else that's not Polymer is entirely irrelevant in the context of WebComponents.
There's only Polymer.
It's gotten so bad that even the main proponents of WebComponents (working for Google, of course) cannot build proper WebComponents (and no one can): https://www.youtube.com/watch?v=sK1ODp0nDbM
> main proponents of WebComponents cannot build proper WebComponents (and no one can):
I've a vested interest as I run the team that Rob is on, I feel like there is a lot being misconstrued here in this thread, x-tags is be on the list of supported resources on webcomponents.org. If there are only two elements on the list it's not because it's "polymer only" and run by the Chrome team. I've launched a couple of elements using plain JS and there are others on there too, it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem.
Rob didn't say no one can build proper web components, he was saying that to build great web components there is a lot of work that you have to do especially to make them accessible and good actors in the life-cycle of a page and that many of the spec authors hadn't seen them being built as a canonical reference set. Of course people can build proper web components, but it is on us to explain it clearly now that the browser support is mostly there.
> it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem.
That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that.
Rob did say something like "Polymer is the jQuery of WebComponents". And it's true.
One could argue that you can write your stuff in pure DOM APIs. Yet hardly enyone ever did that, because there was jQuery. All the handlebars and mustaches and other things of this world were largely irrelevant because of jQuery.
Now, jQuery solved a very pressing problem: it gave an easy, simple, extensible API that made working with the DOM a joy. It would be very nice if jQuery's approach was adopted by w3c, but that is really too much to ask for.
In 11 years since jQuery's original release w3c managed — barely! — to standardize on querySelector/querySelectorAll (already a much more cumbersome combination of APIs than jQuery's $).
Enter WebComponents. 6 years in development. Quite a few years of saying that they are the future. Let's do a reality check, shall we?
The APIs are horrible. None of the original promises are fulfilled. As Polymer 3 approaches someone suddenly starts asking "erm, guys, what are the best ways of creating WebComponents without Polymer".
- It turns out even people who implement the spec in the browser don't have reference components.
- It turns out the API is so bad, you have to use pseudocode in your presentation to sell people the idea[1].
- It turns out WebComponents are so effing great and can really be used to reimplement stuff in the browser, ... that you can't even implement a checkbox without reimplementing the checkbox label [2]
- It turns out people don't even know how WCs should work. Quote from [1]: "If we can generally agree on how Custom Elements should behave..."
- It turns out that actually implementing WCs in anything but Polymer is a royal pain in basically everywhere because w3c's goal was never to create a sane API for anything.
etc. etc. etc.
Therefore, forget selling people the idea of WebComponents. For all intents and purposes they do not exist. Only Polymer exists. Masochists can go and check out the underlying DOM APIs, of course.
I think web components are low level and non-opinionated to give you freedom of implementation for higher level things.
Thats what Polymer, Stencil, Svelte, SkateJS are for. Indeed WC API is not the nicest to work with to say the least, but thats not the problem, I write in python instead of Assembly, just user higher level stuff.
> Indeed WC API is not the nicest to work with to say the least, but thats not the problem
How is it not a problem?
> I write in python instead of Assembly, just user higher level stuff.
As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world
I wonder how far along iOS would get if all it provided for its UI libraries was just the UIView, and never anything else (no collection views, no table views, no content views etc.) That's exactly what w3c does, times and again.
It is low level API to be non-opinionated. Or at least it makes sense for me to make it like that. Same as web assembly, service worksers and others - that is a step in right direction IMO.
Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.
No API is non-opinionated. It's the opinion of its authors. And w3c's opinions invariably are to the detriment of developer experience.
For example, quote from [1]: "The things like property initializers for instances that were so nice in [a previous example] aren't here. And they've been stuck in committee for reasons that, frankly, just make me grumpy" (around 22:30 mark)
Around 12:50 mark: "What jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components". Let's look at WCs: ooops, all the infrastructure is still there, nothing is done to make it easier.
> And w3c's opinions invariably are to the detriment of developer experience.
Wow. Sorry, but I don't think you really know what you're talking about here. The Web Component specs are part of the HTML and DOM specs. Things like property initialization would fall under JavaScript and are already being addressed with JavaScript class fields with initializers. Spec authors don't go out of their way to make life hard on developers :/
It's the difference between AppCache and Service Worker.
AppCache is very easy to write, very easy to read, has a nice and simple API. It's just the wrong API, so it's functionally almost useless.
Service Worker's API is more complex because it has hooks for the user to efficiently express exactly what they need. It's less easy to write, and less easy to read, but it's flexible enough that basically every site on the web could make good use out of having a Service Worker.
Most people won't write against the Service Worker API directly, they'll use a library.
You might say that this is a flaw of the API, that it's too complex or verbose for most users to use directly, but I think there's another angle to it. There can be many libraries and those libraries can iterate quickly. There can be only so many specs, and those specs necessarily iterate slowly.
I don't understand what you're trying to say. I'll rephrase my position in longer form, because I think we're talking past each other.
High level APIs necessarily make a lot of assumptions of how the low level details should work. When successful, users can get 80% of the benefit of the ideal low level implementation for 20% of the effort.
For complex apps that 80/20 tradeoff isn't worth it, they would rather spend the extra effort to get maximum utility out of the API, even if it means mucking about with low level code.
(As a non-web example, consider filesystem APIs. Most apps use just a few filesystem APIs, they just want to read strings, write strings, and list files in directories. A few apps though, like databases, can get huge benefit over having finer grained control, and need lower-level filesystem APIs.)
App Cache is an example of trying to build the high level 80/20 solution first. It looked reasonable, but it failed in the details. You can't build a good low level API out of a high level one, but you can build high level APIs out of low level ones.
Service Worker and Web Components take the opposite track. They are lower level APIs, sufficient to make complex apps possible. Library code can come in and build on top to provide high level 80/20 solutions. Then, after looking at the libraries that people build and use, we can pave the cowpaths and standardize good high level APIs.
x-tag is mentioned on the WebComponents site--and it works with the same underlying technologies as Polymer: shadow dom, HTML imports, custom elements and templates: https://www.webcomponents.org/libraries
The main problem: when the framework makes the developer decide whether to pass attributes or properties to Custom Elements, it's mostly ok. The framework should also allow binding any events (which cna be named as onEvent, or on-event or...)
Frameworks that are trying to be clever and hide the complexities of DOM behind proper APIs, and that implement their own event systems suffer greatly because DOM APIs and WebComponent APIs are a pile of steaming crap.
> No one in their right mind would even think about writing and using WebComponents in vanilla JS.
Why not? I have written a complete widget toolkit [1] this way. With vanilla APIs the code is a bit more verbose and repetitive, but in turn you get more options for speed optimization and fine-tuning.
You get a small set of APIs that allow you to encapsulate, so what, encapsulation never was the problem. Now how do you bind, how does the UI react to store changes, how do you bring state managers into this, etc. We'd be in 2010 fighting the naked dom all over again.
As for optimization, vanilla won't be faster than a framework unless you write one from scratch. That means having a scheduler in place that orders dom read/writes, pooled events listening from a single source (the main document), a prioritizer that can cull, something that diffs state in order to render the minimal set of components, etc. Many don't realize the effort that goes into these libs to render as efficient as possible. Even if some stuff is baked into the browser, the field is moving so fast that we get higher benefits from community driven optimizations. And that is an understatement if you look at things like React Fiber.
They are not a solution in search of a problem. They have a very clear problem statement, it's hard to orchestrate reusable front-end code. React's problem statement is roughly the same, but react seeks to provide more structure and functionality to the foundation of web components. The WebComponent spec is just trying to formalise that foundation.
What React was, and is, is a library with a specific goal that solved a specific problem, and it's basically this: "Build encapsulated components that manage their own state, then compose them to make complex UIs."
No one really knows what WebComponents are, and what problems they solve. I know what Polymer is and what it attempts to solve though.
That is ridiculous. They've come from some impetus, derived by some individuals, and they obviously had a goal in mind. They are in a spec, they're being implemented into browsers, they're emulated or polyfilled by various JS libraries, and they're being used by individuals around the web.
> I know what Polymer is and what it attempts to solve though.
The WebComponents spec is admittedly lacking a full feature set to truly enable "Encapsulated Components" but with really not very much work ( https://bitbucket.org/polylab/polyblocks ) you can get pretty close.
I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right? But not everything needs to be a highly orchestrated complex UI, and in those circumstances I still want to be able to re-use my frontend code.
> That is ridiculous. They've come from some impetus, derived by some individuals, and they obviously had a goal in mind. They are in a spec, they're being implemented into browsers, they're emulated or polyfilled by various JS libraries, and they're being used by individuals around the web.
Yeah, yeah, yeah. Snake oil is also used by many people who say they know what they are doing.
- people who implement the spec in the browser don't even have reference components
- people who try to sell the vision of WebComponents have to use pseudocode in their presentations because the APIs are horrendous
- the very same people casually drop things like "if we could only agree on how webcomponents should behave"
etc. etc. etc.
> I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right?
Kinda. As someone else put it in the comment here: WebComponents are solving a problem no one has had for at least five years now. They are a solution in search of the problem. Worse still, they are entirely highjacked by Polymer.
I have no idea what the purpose of WebComponents is anymore. Any and all of their original goals [1] are either not there anymore or solved in much better ways than whatever specs have become.
Right now the narrative is "build reusable components that you can use anywhere regardless of library". We've been using jQuery components in our React projects for years, so the fuss is largely overrated.
And since the vast majority of components are extremely highly Polymer-specific, good luck figuring out how to work with their components, it's no better than figuring out how to hook up a jQuery component.
I wish people would stop saying "feature X is already here" when it is missing Edge and Firefox support. What projects are people working on where they can happily overlook the fact that something simply won't work in 2 out of 4 major browsers in use today?
Developer usability: the fact that they're largely analogous is literally why the implementations that stick to one language, taking advantage of new language features as they pop up, and abstract away all the bindings, win out over something like Polymer, which sticks to the separation of HTML, CSS, and JS.
React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a bare minimum of coding on their part. That is in stark contrast to Polymer, which requires devs to write out a lot of the logic that you simply get "for free" with React. Writing a pure JS class that "just works" just because it has the two words "extends Component" is a hugely winning benefit, for example.
Take something like https://codelabs.developers.google.com/codelabs/polymer-firs... - it certainly does the job, the code is clean, and the separation of concern follows the traditional HTML/CSS/JS model. But as a developer, what I see is an inefficient implementation that requires me to put loads of stuff in that should be taken care of for me: "Why would you need to say what my component 'is'? Tooling should see that already.". Also, all browsers already handle arbitrary properties, so "Why would you need say which properties can be used, except for schema enforcement". (if I say <div cats="yes"> then every browser already sets that attribute key:value correctly). And of course: "Why would you need to specify which events to listen to instead of just implementing the relevant function hook? Tooling should take care of the rest".
So what I _want_ to write as a developer who's used to efficient web-component-like libraries is something like:
import { register, Component } from 'polymer'
register('icon-toggle', class IconToggle extends Component {
onAttributeChange(attr) {
if (attr.name === 'toggleIcon') { ... }
}
onPressed(evt) {
this.pressed = !this.pressed;
}
});
And we're done, that should tell the library everything it needs to know.
It really is just a matter of "what lets me do the most while saying the least". Polymer requires me to write a book where React or Vue let me write a memo. Does it make it harder for a search engine to index my site? Sure. But that's what seo/og is for. Does it make it harder for a user to inspect-element? Sure, but that's their problem, not mine. Does it make it harder for someone else to learn how I did something if I don't host the code on github or something? Sure, but I am under no obligation to write code that, in production, is easy to debug and replicate.
So while Polymer is super strong for all of those, realistically: I only care at the academic level, because that's not where my time and efforts lie.
The reason you have to define what an element 'is' is for backwards-compat reasons. Additionally, the properties definition block is there simply for attribute -> property serialization so that you can set properties declaratively in the HTML as attributes. The property declaration is also used for tooling schema enforcement just as you suggested it should really be there for. You do not need a properties block at all since Polymer uses webcomponents, and as you said, elements can handle arbitrary attributes (and attributes set in JS with the exception of the data- attributes [1]).
In Polymer 2, you simply set the function hook just like you wanted. Polymer 3 which is essentially just a refactoring of Polymer 2 introduces JS Modules. An example would be:
This example, does not use the properties but the native attributeChangedCallback [2], it does not explicitly define properties and it can still set this.pressed, and you can easily add a 'cats' attribute if you want which can then be accessed via this.getAttribute('cats') like any other native element. Polymer is written so that all the code is executable in the browser even with the JSX-like template syntax [3]. But with the move to JS modules, a webpack configuration can easily add extra functionality like not even having to define the event listeners or the observed attributes.
As a dev, comparing technologies given that I've already used Vue and React, I still see lots of code that I've become accustomed to not needing to specify, making even Polymer 2 still feel clunky and bloated: there is still no reason for that "is()" or "observedAttributes()" (tooling should take care of that), and the fact that you manually need to initiate the super chain in connectedCallback instead of having a side call to a function with a name that indicates what it's actually for, with the chain taken care of by the super class (if your callback function has the word "callback" in it, that's already a wasted 8 characters that could have been used to actually name the function after what it does) still makes me go "this is silly, why would I go back to such a verbose technology?".
Polymer 2 looks better than polymer 1 for sure, but if I'm comparing what I need to write in React vs. Polymer 2, the former still beats out the latter in terms of low effort, high productivity.
And to be clear: the reason I think (and the numbers bear out that) React and Vue etc. beat out Polymer still is because they can do the same things as polymer: the on-page result is identical. Except React and Vue offer a better dev experience... provided you buy into the development model, of course. But this is also true for people who first start with Polymer: they have to buy into the idea that the classic web stack is the best solution to the problem of needing custom components.
And that reveals the major difference, in turn revealing another reason why Polymer is not as popular as one might hope: Polymer is a web presentation and interaction technology, whereas for instance React is a universal UI technology. They're not even remotely the same thing: the latter is effectively a superclass of the former. For example, as long as you call the functions that React tells you need to be used to effect UI updates, you will never have to think about "where this code runs". Web? Mobile? Desktop? Someone's GTK+ application on embedded hardware with JS support? It literally doesn't matter: call the functions, and it will work. The fact that the DOM is used in the browser is pretty much irrelevant to React - it's only relevant to devs who want to explicitly tie their UI to APIs that are only available in a browser. Polymer takes an approach that is diametrically opposite to this: it keeps things as "webby" as possible, making you write DOM, and only DOM, elements.
So that is another reason for the difference in dev experience: React has abstracted as much as possible so as to only expose what you need because it wouldn't be able to do its job as UI technology if it kept exposing platform-specific construct, whereas Polymer can keep things explicitly tied to the browser stack, and thus never got pushed to be as self-contained as possible, with as high a productivity:effort ratio.
(and whether that's a good or bad decision is irrelevant when discussing 'why is one of these more/less popular than the other', even if I certainly have opinions there. I'd love for React to be more webby, like polymer, but if it was, it would be much clunkier)
The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality.
It's much like JQuery. It was very much necessary when it came out in 2006. But then browsers got querySelectorAll, classList, uniform event handling, uniform dimensions, fetch, animations, transitions, data-attributes, and basically all the other functionality in JQuery.
The JQuery API is still more convenient in many cases, and several loyalists are still like "You'll pry JQuery out of my cold, dead fingers." But they build worse sites - for the same functionality, their sites are slower, take longer to load, and have more things that can go wrong. The market usually flushes such loyalists out eventually, and we may see a similar situation with React/Vue/Angular when components are standardized across browsers.
I don't think I've ever seen a Polymer-powered page of any substance use less than 132kb of JavaScript. File size is really not a good reason to choose web components, especially when you consider the things you need to do to actually work efficiently with web components once you have them.
>The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality.
If that's the big benefit, then it will be increasingly irrelevant (assuming its not already), including on the mobile space.
Especially since those 132K (for React, Angular, and the like) are not "basic platform functionality" but give tons of things that Web Components do not.
Custom elements is like an API of six methods `connectedCallback`, `disconnectedCallback`, attributeChangedCallback`, `adoptedCallback`, `attributes` and `register`. I don't see why this must nescessarily be compared with React or Vue any more than `appendChild` or `inserBefore` or any of the other DOM APIs. High level frameworks use the current DOM APIs now and they will surely use the new APIs in the future, but that doesn't mean that you have to use them, that's in fact the whole selling point of React and Vue.
You can use custom elements in React and you can even use React in custom elements, so they are not designed to be competing technologies. Quite the opposite.
If it just was fully styleable. Browsers really should implement better selection of customizable standard widgets. Currently it requires too many hacks to re-style the built-in input elements. Web components feel a bit overkill for most cases.
Most if not all major browsers let you style scrollbars, but the problem is that styling for built-in widgets is not standardized, i.e. it relies on vendor prefixes and worse, not all (sub) elements can be styled at all depending on browser. E.g. <select> has poor support for styling.
Or maybe designers should learn to respect the platform's widgets' look and feel, which the user is familiar with and has possibly customized according to their preferences and accessibility needs.
Hah! You're kidding, right? Custom styling or "skins" has been one of the main drivers of app development since the beginnings of time. I feel that we, puritans, should just give up and accept what the masses want.
Unfortunately the industry just doesn't work that way.
Accessibility is one reason why css-themeable native widgets would be a win for everyone, their look will match with the branding (customer happy) and behaviour will be consistent (end user happy), and standardization would make developers happy.
Why shouldn't your entire application be a widget? Sometimes it's nice to embed one application into another, multiple times. I find your reasoning here short-sighted, since there's often no clear point at which components should bottom out. You can always add another layer.
That "sometimes" quickly breaks down when your application starts to grow beyond trivial. Some things that are rather application-specific like routing and dependency management don't quite compose well in the widget model. Or at least, Polymer at the moment doesn't have proper solutions to quite some edge cases that you'll be running into.
I actually implemented React's UI Router in polymer, works the same as in Angular 1/2. The biggest issue with web components in general are problems with Shadow DOM support.
Which means you need to do elements without shadow components up to top level - that is indeed annoying and reduces the pros of components.
I think you've misunderstood my point; I don't think that at all.
I'm specifically criticising the focus polymer has on creating user interaction elements.
My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level <App/> component).
Actually - the process of creating both is exactly the same, I created components in angular, react and polymer. No difference IMO (apart implementation details).
* It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaScript itself, but it isn't.
* Bloated. You end up downloading several hundred kilobytes of JavaScript if your webapp uses more than a few different types of UI elements.
* Polymer components don't behave like native components. For example, you cannot swipe between tabs like a ViewPager does on Android. Implementing any kind of swipe-based feedback is hard, including pull-to-refresh. Back to native programming, I guess.
* For having so much marketing and PR and a camel-cased name "WebComponents", you would think it would be productized enough that it employ the appropriate native Android elements at least in Google Chrome on Android, and use the HTML5 substitutes on iOS and desktop. For example, you should replace the Polymer button with an actual styled Android button instead of a nested div hell. Chrome should have worked with the Polymer team on this. Not doing this has serious performance implications when you display thousands of items (e.g. lists of results, contact lists) each with their own nested div hell. Back to native programming, I guess.
* There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.
The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.
Honestly I never understand why they need to be so complicated. If you want people to use your product, why not make it easy to use it? This goes for developers too -- who should be spending their time coding their product, not dealing with how to install stuff.
There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.
Google's Flutter certainly creates apps (using mostly web technologies) that have the correct look and feel for Android and iOS from the same codebase.
> Most people don't actually derive much benefit from writing custom UI widget primitives.
Bingo. Most won't and shouldn't. There's a different between building casual widgets for personal vs for business production use. jQuery UI got some widely popular components such as Select2 and jqGrid, Datatables etc. They will never be developed by non-developers or business users. The tool should be really reserved for code crafters.
Imagining those crafters started creating tools with WP that are modular and self-cotained, work across whatever browsers threw at them.
It's really interesting to see these comments when I feel the struggle of not having this on a daily basis.
I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")
Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth.
Let's say you are working on a social network though. You'll need to display a "person widget" a bunch, in different contexts. Of course you want to have it be consistent throughout your app. Of course you want it to look the same. Of course you want encapsulation!
When you're writing a web app, your HTML isn't just layout but the entire interface. You're usually working with a huge team and need consistency. You want to be DRY.
If you have a style guide, you probably could benefit some from this. The proof is that things like JQuery UI exist, even if it's activated more through JS.
HTML is basically unreadable in so many cases because you can't encapsulate layout code into widgets. Having these tools lets you stay a bit sane when you need to build out a lot of workflows in a consistent manner.
> I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")
This is what Progress Web Application tries[0](PWA https://en.wikipedia.org/wiki/Progressive_web_app), a fairly new spec, attempts to bridge the gap. Basically a normally web page will virtually be indistinguishable from a web app.
Sure, certain concepts have been around and keep getting reimplemented but it's far too easy to confuse the old with the new.
One of the very real issues WebComponents solve is encapsulating the component functionality and styling away from everything else in a typical web page; you know, the basic separation of concerns stuff.
Certainly nothing that Microsoft proposed then has today's comparability and flexibility of today's offerings.
Microsoft didn't lack good ideas back then when they cared about the web; they were clueless about interoperability across devices and platforms. (IE for the Mac had a better but different rendering engine than IE for Windows did.) And because of their monopoly status then, they weren't to be trusted.
I also want to correct something the article mentioned, that Netscape was irrelevant back then due to Microsoft's cool features--not true. In fact, on any big project, developers had to essentially make two sites--one for Netscape users and one for IE users.
The "new" Microsoft it much better with getting their ideas out and working with other companies.
If you wanted to, with WebComponents you could easily use an x-PageFoo tag as a parent tag that orchestrates other child components. Your WebComponent is just a bunch of HTML, Javascript and CSS, it can really do what ever you want it to. It isn't a framework though, so to suggest that it doesn't provide as much as React is being a bit disingenuous, as it's not trying to. It's trying to formalise some of the foundations for things like react.
Smaller scale but for fun, in vanilla WebComponents (as implemented in Chrome) I put together a Slider that can then accept and consume child elements that add behaviour, like this:
<x-slider data-config="{autoplay:true}">
<img src="some.jpg" />
<img src="some.jpg" />
<x-slider-controls /> //Introduces left and right slider controls
<x-slider-dots /> //Introduces slider dots
</x-slider>
I was a little bit disappointed to see that the plan for Polymer 3.0 is to leverage ES modules to handle all the asset loading. Maybe their hand has been forced here since browser vendors refused to implement http imports but if Polymer requires a fair bit of Javascript to do anything interesting then its advantage over something like React becomes a bit less clear-cut, IMO.
Yeah, its definitely been forced, you can see it in the team's faces (https://www.youtube.com/watch?v=0N-ldg1IPn4&t=1766s). Its possible that the HTML Modules spec will hit browsers in the next year or so (the fact that the ES Modules spec does nothing when the resource mimetype isn't JS means it'll be very easy to extend), in which case Polymer 3.0 will have just been a crash course in tagged template literals.
From index page "Polymer is a JavaScript library that helps you create custom reusable HTML elements".
I'm using Polymer components same as as react's controller/view components. You don't need to reimplement custom select's or whatever. You can use exact patters as other frameworks use.
"Web developers" do not know how to program, but they only know how to do "copyAndPaste".
For this reason "the web" uses a shit technology.
It's ONLY this: in other areas there are no such problems
I am not sure it is not a coincidence that the same idea keeps resurfacing. I remember reading pretty early on that HTML/XML/XHTML would eventually lead to a world where "chemists would have their own tags to represent chemical formulas" and similarly each discipline would develop their own tag language. Browsers would just know how to render them!
People have tried to materialize this idea in multiple ways over time - HTC, microformats, web components etc. It should not be surprising that the solutions are similar. This isn't to say the first implementation was the best, and the others have just forgotten history. I am sure there are some pretty senior web developers around who remember their history, and were even part of it. If anything we should be optimistic that the new implementations have learned from the mistakes of the past.
I guess the rendering of custom XML documents was more supposed to be controlled by CSS via the processing instruction <?xml-stylesheet type="text/css" href="styles.css"?>. It's a little known fact that this was actually working in Mozilla/Firefox all this time, but not anymore I suspect.
Nice; I used these "back in the day" while at Google to implement the illusion of native SVG support in Internet Explorer 6-8; I used hidden Flash for the rendering and Microsoft Behaviors wrapping it all so that the fake SVG would look like it was part of the DOM for full JS scripting. Fun times. Check it out here: https://github.com/BradNeuberg/svgweb
To this day I'm absolutely flabbergasted that XHTML didn't win out. Well-formed XML documents, rather than a best-guess soup of broken HTML, was perfect. Absolutely perfect. I sat on the edge of my seat for 2-3 years waiting for the XHTML MIME type, with clients performing strict parsing, to become the new norm. It never happened. It's extremely sad if you think about it - we couldn't handle a world where developers had to conform to a very simple level of strictness. Imagine any backend language (C, Java, PHP, etc.) allowing you to get away with vomiting up garbage code with syntax errors, and having the compiler or interpreter best-guessing your program's logic. It's unfathomable! And yet, that is exactly what we have with HTML(5). Mind-boggling, to say the least.
Related aside: to this day, we still cannot write <script src="/main.js"/>. We must use <script src="/main.js"></script>. All because of a multi-decade old description of a CDATA element. Sigh.
The Web 2.0 movement, ditching XHTML and pushing HTML 5 instead was exactly when I went back to focusing in native applications, only doing Web when required to do so.
Web Components look to at least we can get some of those ideas back, instead of writing workarounds with HTML/CSS/JavaScript.
I know this is not a popular position here, but I like writing HTML directly (say, without markdown) and appreciate the optional tags and escapes. I can see a big opportunity may have been lost technically...
If you call web browser vendors mutinying against the W3C who was pushing XHTML 2 down their throats "politics", which lead to Apple, Mozilla and Opera creating the Web Hypertext Application Technology Working Group (WHATWG) and to HTML5--then I'm okay with the politics.
Yeah, I could close my tags and validate my code with the best of them back when XHTML was a thing--but that's no way to live. I'm glad WHATWG stepped in and literally saved the web from itself. OMG! XHTML 2 would have sucked so much!
The way I remember it, there was a guy called Hixie something that was in charge of standards implementation at Mozilla and made a terrific job at that. But then he got hired by Opera and saw that there was no point in competing with Gecko and so he started a FUD campaign called "XHTML considered harmful" to lower market standards. He bluffed you into believing that namespaces are far too complicated for the human mind to comprehend, when in reality XHTML hadn't caught on because the CMS systems were not up to date. He did a terrific job at that, so he got hired by Google to publish a competing specification that was actually based on the way that Internet Explorer 6 parses HTML4. He did at terrific job at that, so we are finally back where we started, with a standard that lives forever while IE6 is long gone, and Goggle can scavenge the specifications from this forgotten future for ideas they can present as original. Even Mozilla played along with the HTML5 scheme, it was like watching a nuclear superpower go down in a fist fight. How can you not call that politics?
As far I remember that time, I would say IE Components didn't succeeded, because at that time server side rendering was far more popular. I personally was doing sites in PHP and tried to avoid JS at all costs. Strange that today I'm doing exactly opposite.
I remember discovering these in the mid-2000s, and thinking along the same lines as the author: why hadn't they caught on and been standardised like XMLHttpRequest, etc. had been?
I think the reality is, Microsoft introduced these technologies at the tail-end of initial "dot com boom". Shortly afterward, most of the companies who might have built ambitious web apps using them went bust. Microsoft stopped investing in IE, and for quite a while afterwards, web development regressed to people building document and brochure-style sites. People were too busy trying to figure out complex CSS, and what `hasLayout` meant in IE to build component-based apps.
A few years later, web development crept out of the doldrums: JavaScript's reputation began to be rehabilitated, the term "AJAX" was coined, and companies like Google began building more ambitious web apps. But by now Firefox was the browser of choice for most developers, and had gained enough market share that you couldn't build IE-specific sites.
Mozilla teamed up with Opera and Apple, and later Google, to create what became HTML5, and that included reverse engineering and standardising a number of proprietary IE APIs. However, they chose to ignore element behaviours. Presumably because they had their own component technology, XBL, and wanted to make that the basis of web apps. And, since element behaviours never made it into Firefox, developers never started using them.
My guess is, had Firefox adopted them, they'd now be a standard part of the web platform, and we wouldn't have web components as they currently stand. There are a lot of similar "what ifs" in the history of the web. For example, what if Microsoft had adopted XBL? What if flexbox and grid had been implemented in early 2000s when they were originally designed, instead of fifteen years later? What if ES4 had been accepted and implemented? What if Cassowary had been built into CSS when it was proposed, instead of being ignored (and later used by Apple as the basis for auto layout)?
XBL 2.0 was doing well on the standard track and would have made that happen [1], but it died along with all the other technologies whose acronym starts with an X. Flexbox was by the way implemented in Mozilla back then, I used it all the time in XUL, but then that acronym also starts with an X [2].
A great early site back in the DHTML/component days where IE4 was really pushing things was WebFX [1]. This was back when IE was actually a good browser as Netscape was fading due to DHTML/early AJAX (which was the XMLHttpRequest object originally from Exchange Server). DHTML at the time was mostly easier in IE because it didn't draw a new DOM for each layer i.e. document.layers (Netscape) each layer was a new full DOM and document.all (IE) was one DOM.
"Why did IE5’s HTML Components never quite catch on? Despite what you might think, it’s not because of a lack of open standards"
Actually thats precisely why it never caught on. Source: I was front end developer at one of the big dotcoms ca 2000.
Also, its remarkable how many people skimmed this article, and didn't understand that the first part was from 1999. That really says a lot about people's expectations when it comes to Microsoft and web technology.
I think the main problem with IE technology was the way Microsoft pushed it down our throats. The tech wasn't necessarily bad, but when the giant corporation pushes new features while not respecting/implementing the existing standards very few people support their efforts.
So as a result 96% hated the IE and the other 4% were using other browsers. No wonder nobody wanted to use the newest Microsoft only features.
I was young in 1999 so not very experienced with technology but I really doubt people were hating on Microsoft back then. Sure, every company will have a hate camp but I doubt it was as spread as it was in the past few years.
Actually, it was much worse back then. Nowadays Apple Macs are affordable and alternative PC operating systems are quite usable too. In 1999 there was a usable but limited/old Win 95 and Win 98 which was crashing on a daily basis. So you can imagine how frustarating it was to work with such a machine.
> "Why did IE5’s HTML Components never quite catch on?"
because technology per se is just one of the variables that matter. For example, you are missing things like "timing", "marketing strategy" and a whole lot of other things. =)
These were widely used for at least one thing in practice: adding support for :hover pseudoclass on arbitrary elements (not just <a>) in IE6. https://peterned.home.xs4all.nl/csshover.html
Polymer will ditch 'html-import'(which is similar to the HTML component) as it is not widely implemented on browsers and such.
Polymer 3 will switch to ES6-loader and npm, probably one year away?
I spent quite some hours with Polymer, but finally give up for now, one reason is that I want Polymer 3 today, but it is not there yet, also big companies tends to make its stack for big players(look at Angular2).
I will use Vue.js for new projects at the moment, I read somewhere saying, Vue.js could be the next modern jQuery, and I kind of agree.
I think Web Components will have/already had the same fate.
To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen".
At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery.
We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done.
React/JSX got the good parts of it, and added even more useful things. If we could add the missing parts on top of that (like encapsulation from the external DOM), it would be perfect, and the rest of their horrible API/design can vanish.
And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed)
This goes into the bucket of scary, poorly thought out features that makes the web hard to secure. It's just like expression(), in that it allows code within a style take to result in script injection. CSS, due it's weird parsing behavior (data is not quoted, so it's hard to determine whether a token is data or code without a full CSS parse) is very hard to escape, and it's common to let user defined variables into CSS. Stuff like this is a nightmare for developers concerned about locking down their apps. And to the best of my knowledge, there's no way to disable it.
Fortunately, like expression, it's gone now in newer browsers, but this was not a proud moment for web security.
150 comments
[ 33.7 ms ] story [ 236 ms ] thread.
Typed on Firefox :)
It just wasn’t good enough to last 10 years without updates
(Or replacing some thing that Java or Flash had done for years.)
https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).a...
They behaved like a native app, with control over their native chrome, and without any browser sandboxing: their JavaScript (JScript) or VBScript could use COM components to access to the file-system and other features, including loading other binaries in-process. File-system access was through Scripting.FileSystemObject, for example.
Some built-in Windows components were/are built as HTAs, like the previous versions of the Microsoft AntiMalware / Windows Defender UI.
I tried to use it for a project in 2013 but couldn't because HTAs are forced to run in Quirks-mode, so you can't use IE11's Edge mode, unfortunately.
Best of all: they ran while needing only a few megabytes of RAM. Compare with Electron-based apps and it makes me weep because this, right here, is evidence that a Web-View can be used as the basis for an application, using a platform that was available since 1998/1999, without it dragging my PC down.
Most people don't actually derive much benefit from writing custom UI widget primitives.
Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful.
I don't have time to invest hours implementing `ImageDropDownSpinner` as a custom element. <select> is good enough for me, and heck, maybe I'll use some 3rd party widget if I need something special.
That's not why react, vue, angular, etc. are winning the mind share of 'how to build web apps'; building UI widget is far less interesting than the ability to decompose your UI into a custom hierarchy of re-usable self contained units of functionality, that only at the lowest level actually involve UI components, is extremely powerful.
They might look like custom widgets, but <PageFoo> isn't a UI widget, it's your entire application; that's the difference.
It's easy to say this was a revolutionary idea, before its time, and it would have flown today instead of vanished into obscurity... but I think it missed the mark; it didn't solve problems people were actually having.
...but to be fair, it's easy to look at 'Web Component' efforts (like Polymer...) and go... yeah, this seems very familiar...
I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand.
Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening....
Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs...
So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer.
I do look forward to going back there though when 3.0 is available.
Polymer of all the frameworks i've had to use has had the most breaking changes. That they're turning the ship for each and every major forcing you to rewrite the entire application is kind of ironic given that their motto is "use the platform" as if suggesting stability and standard behavior.
Polymer is not the standard, just another arbitrary driver (as in: their own syntax, their own structures, their own api) for a pretty harmless spec that sets out to solve issues we haven't faced for at least 5 years.
WC break this in half again and all of the sudden they're again trying to shovel more UI stuff into the dom. What they're trying to fix hasn't been a problem for years. Their entire spec was thought out in a meeting room maybe 10 years ago, but almost nothing of it has relevance today. It would simply make it harder again and block applications from leaving the browser behind.
The actual issue was that very few people was doing any serious frontend development back then. Netscape and IE had completely different DOMs and the environments were not super stable. But there was an attitude that frontend was for designers and "real programmers" were backend-only.
So the real programmer found a backend component for ASP.NET or GWT and wasn't interested in the frontend sausage.
(This article reminded me of the DHTML Dude column[1], and yeah some of us unreal programmers were doing this bleeding edge IE-specific front-end stuff for clients. Then we spent many years atoning for our sins. However, I think 90% of "IE-only" apps never used this stuff, they just had the wrong box model or some dopey ActiveX upload component or something.)
[1] https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).a...
I think jQuery's massive success was precisely because it was a simple and concise API on top of the verbose and confusing DOM API.
They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them.
And they have to, because Chrome and Safari own the mobile web.
Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and utility classes to make writing components easier.
Web Components is what is making me finally get to love web development again.
If it is to make an application platform out of browsers, then give me a platform, not an application for doing hypertext documents that we try to bend for something else.
Chrome settings panel, the new You Tube, all new EA gaming portals are already using Web Components.
I look forward to have something like Blend for Web Components.
https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s
EDIT: fixed a few grammar issues
No. Polymer is here. As Rob Dodson said, "Polymer is the jQuery of WebComponents".
No one in their right mind would even think about writing and using WebComponents in vanilla JS.
Hence we're coming back to the problem with WebComponents: they are a solution in search of a problem.
How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.
If you go to webcomponents.org, you'll see that the overwhelming majority of components there are Polymer components.
It's like visiting a store called "phone" that sells iPhone exclusively. Google has definitely got own its down agenda with the so-called standards in this regard.
Unsurprisingly, a searching "x-tag" on webcomponents.org returns pathetically two components.
Not really a fair analogy as anyone can submit elements to webcomponents.org: https://www.webcomponents.org/publish
https://www.webcomponents.org/resources
There's only Polymer.
It's gotten so bad that even the main proponents of WebComponents (working for Google, of course) cannot build proper WebComponents (and no one can): https://www.youtube.com/watch?v=sK1ODp0nDbM
I've a vested interest as I run the team that Rob is on, I feel like there is a lot being misconstrued here in this thread, x-tags is be on the list of supported resources on webcomponents.org. If there are only two elements on the list it's not because it's "polymer only" and run by the Chrome team. I've launched a couple of elements using plain JS and there are others on there too, it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem.
Rob didn't say no one can build proper web components, he was saying that to build great web components there is a lot of work that you have to do especially to make them accessible and good actors in the life-cycle of a page and that many of the spec authors hadn't seen them being built as a canonical reference set. Of course people can build proper web components, but it is on us to explain it clearly now that the browser support is mostly there.
That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that.
Rob did say something like "Polymer is the jQuery of WebComponents". And it's true.
One could argue that you can write your stuff in pure DOM APIs. Yet hardly enyone ever did that, because there was jQuery. All the handlebars and mustaches and other things of this world were largely irrelevant because of jQuery.
Now, jQuery solved a very pressing problem: it gave an easy, simple, extensible API that made working with the DOM a joy. It would be very nice if jQuery's approach was adopted by w3c, but that is really too much to ask for.
In 11 years since jQuery's original release w3c managed — barely! — to standardize on querySelector/querySelectorAll (already a much more cumbersome combination of APIs than jQuery's $).
Enter WebComponents. 6 years in development. Quite a few years of saying that they are the future. Let's do a reality check, shall we?
The APIs are horrible. None of the original promises are fulfilled. As Polymer 3 approaches someone suddenly starts asking "erm, guys, what are the best ways of creating WebComponents without Polymer".
- It turns out even people who implement the spec in the browser don't have reference components.
- It turns out the API is so bad, you have to use pseudocode in your presentation to sell people the idea[1].
- It turns out WebComponents are so effing great and can really be used to reimplement stuff in the browser, ... that you can't even implement a checkbox without reimplementing the checkbox label [2]
- It turns out people don't even know how WCs should work. Quote from [1]: "If we can generally agree on how Custom Elements should behave..."
- It turns out that actually implementing WCs in anything but Polymer is a royal pain in basically everywhere because w3c's goal was never to create a sane API for anything.
etc. etc. etc.
Therefore, forget selling people the idea of WebComponents. For all intents and purposes they do not exist. Only Polymer exists. Masochists can go and check out the underlying DOM APIs, of course.
[1] https://www.youtube.com/watch?v=sK1ODp0nDbM
[2] https://github.com/GoogleChrome/howto-components/issues/112
How is it not a problem?
> I write in python instead of Assembly, just user higher level stuff.
As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world
I wonder how far along iOS would get if all it provided for its UI libraries was just the UIView, and never anything else (no collection views, no table views, no content views etc.) That's exactly what w3c does, times and again.
Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.
No API is non-opinionated. It's the opinion of its authors. And w3c's opinions invariably are to the detriment of developer experience.
For example, quote from [1]: "The things like property initializers for instances that were so nice in [a previous example] aren't here. And they've been stuck in committee for reasons that, frankly, just make me grumpy" (around 22:30 mark)
[1]: https://www.youtube.com/watch?v=y-8Lmg5Gobw
Around 12:50 mark: "What jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components". Let's look at WCs: ooops, all the infrastructure is still there, nothing is done to make it easier.
Wow. Sorry, but I don't think you really know what you're talking about here. The Web Component specs are part of the HTML and DOM specs. Things like property initialization would fall under JavaScript and are already being addressed with JavaScript class fields with initializers. Spec authors don't go out of their way to make life hard on developers :/
It's the difference between AppCache and Service Worker.
AppCache is very easy to write, very easy to read, has a nice and simple API. It's just the wrong API, so it's functionally almost useless.
Service Worker's API is more complex because it has hooks for the user to efficiently express exactly what they need. It's less easy to write, and less easy to read, but it's flexible enough that basically every site on the web could make good use out of having a Service Worker.
Most people won't write against the Service Worker API directly, they'll use a library.
You might say that this is a flaw of the API, that it's too complex or verbose for most users to use directly, but I think there's another angle to it. There can be many libraries and those libraries can iterate quickly. There can be only so many specs, and those specs necessarily iterate slowly.
Namely: 'I don’t think we need a “Service Worker’s jQuery”. We need to use Vanilla AppCache code.'
Same goes for a ton of other things on the web platform. Replace "Service Worker" with "Web Components", and the sentence will still remain true.
High level APIs necessarily make a lot of assumptions of how the low level details should work. When successful, users can get 80% of the benefit of the ideal low level implementation for 20% of the effort.
For complex apps that 80/20 tradeoff isn't worth it, they would rather spend the extra effort to get maximum utility out of the API, even if it means mucking about with low level code.
(As a non-web example, consider filesystem APIs. Most apps use just a few filesystem APIs, they just want to read strings, write strings, and list files in directories. A few apps though, like databases, can get huge benefit over having finer grained control, and need lower-level filesystem APIs.)
App Cache is an example of trying to build the high level 80/20 solution first. It looked reasonable, but it failed in the details. You can't build a good low level API out of a high level one, but you can build high level APIs out of low level ones.
Service Worker and Web Components take the opposite track. They are lower level APIs, sufficient to make complex apps possible. Library code can come in and build on top to provide high level 80/20 solutions. Then, after looking at the libraries that people build and use, we can pave the cowpaths and standardize good high level APIs.
Yeah, that worked so nice with X-Windows...
The main problem: when the framework makes the developer decide whether to pass attributes or properties to Custom Elements, it's mostly ok. The framework should also allow binding any events (which cna be named as onEvent, or on-event or...)
Frameworks that are trying to be clever and hide the complexities of DOM behind proper APIs, and that implement their own event systems suffer greatly because DOM APIs and WebComponent APIs are a pile of steaming crap.
Also it is not helpful to call standards 'a pile of steaming crap' without backing that up with something substantive, examples/alternatives etc.
https://vuejs.org/v2/guide/components.html
Why not? I have written a complete widget toolkit [1] this way. With vanilla APIs the code is a bit more verbose and repetitive, but in turn you get more options for speed optimization and fine-tuning.
[1] https://github.com/jarek-foksa/xel
As for optimization, vanilla won't be faster than a framework unless you write one from scratch. That means having a scheduler in place that orders dom read/writes, pooled events listening from a single source (the main document), a prioritizer that can cull, something that diffs state in order to render the minimal set of components, etc. Many don't realize the effort that goes into these libs to render as efficient as possible. Even if some stuff is baked into the browser, the field is moving so fast that we get higher benefits from community driven optimizations. And that is an understatement if you look at things like React Fiber.
Exactly. Just the code for syncing attributes and properties is enough to never ever use vanilla JS for WCs
I'd love to see that problem statement written anywhere in any of the webcomponent-related specs or sites.
If it were true, they would not have such cumbersome APIs, for example.
On the contrary, WebComponents, as they turn out to be, realise next to none of their original goals: https://fronteers.nl/congres/2011/sessions/web-components-an...
> but react seeks to provide more structure and functionality to the foundation of web components.
React has nothing to do with web components. Until less than a year ago React team was set against WebComponents in any shape or form: https://docs.google.com/document/d/1QZxArgMwidgCrAbuSikcB2iB...
What React was, and is, is a library with a specific goal that solved a specific problem, and it's basically this: "Build encapsulated components that manage their own state, then compose them to make complex UIs."
No one really knows what WebComponents are, and what problems they solve. I know what Polymer is and what it attempts to solve though.
That is ridiculous. They've come from some impetus, derived by some individuals, and they obviously had a goal in mind. They are in a spec, they're being implemented into browsers, they're emulated or polyfilled by various JS libraries, and they're being used by individuals around the web.
> I know what Polymer is and what it attempts to solve though.
The WebComponents spec is admittedly lacking a full feature set to truly enable "Encapsulated Components" but with really not very much work ( https://bitbucket.org/polylab/polyblocks ) you can get pretty close.
I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right? But not everything needs to be a highly orchestrated complex UI, and in those circumstances I still want to be able to re-use my frontend code.
Yeah, yeah, yeah. Snake oil is also used by many people who say they know what they are doing.
And then you get presentations like this: https://www.youtube.com/watch?v=sK1ODp0nDbM where you learn that:
- people who implement the spec in the browser don't even have reference components
- people who try to sell the vision of WebComponents have to use pseudocode in their presentations because the APIs are horrendous
- the very same people casually drop things like "if we could only agree on how webcomponents should behave"
etc. etc. etc.
> I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right?
Kinda. As someone else put it in the comment here: WebComponents are solving a problem no one has had for at least five years now. They are a solution in search of the problem. Worse still, they are entirely highjacked by Polymer.
uh, this applies to Web Components too. In what way do you think they're different?
Right now the narrative is "build reusable components that you can use anywhere regardless of library". We've been using jQuery components in our React projects for years, so the fuss is largely overrated.
And since the vast majority of components are extremely highly Polymer-specific, good luck figuring out how to work with their components, it's no better than figuring out how to hook up a jQuery component.
[1] https://fronteers.nl/congres/2011/sessions/web-components-an...
https://meowni.ca/posts/web-components-with-otters/
XHTML was "already there" too.
>They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them.
With React, Vue etc going strong, I don't see them going anywhere even after that. They solve less problems in a messier way.
The component models are largely analogous. React and Vue could use custom elements if they chose to.
React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a bare minimum of coding on their part. That is in stark contrast to Polymer, which requires devs to write out a lot of the logic that you simply get "for free" with React. Writing a pure JS class that "just works" just because it has the two words "extends Component" is a hugely winning benefit, for example.
Take something like https://codelabs.developers.google.com/codelabs/polymer-firs... - it certainly does the job, the code is clean, and the separation of concern follows the traditional HTML/CSS/JS model. But as a developer, what I see is an inefficient implementation that requires me to put loads of stuff in that should be taken care of for me: "Why would you need to say what my component 'is'? Tooling should see that already.". Also, all browsers already handle arbitrary properties, so "Why would you need say which properties can be used, except for schema enforcement". (if I say <div cats="yes"> then every browser already sets that attribute key:value correctly). And of course: "Why would you need to specify which events to listen to instead of just implementing the relevant function hook? Tooling should take care of the rest".
So what I _want_ to write as a developer who's used to efficient web-component-like libraries is something like:
import { register, Component } from 'polymer' register('icon-toggle', class IconToggle extends Component { onAttributeChange(attr) { if (attr.name === 'toggleIcon') { ... } } onPressed(evt) { this.pressed = !this.pressed; } });
And we're done, that should tell the library everything it needs to know.
It really is just a matter of "what lets me do the most while saying the least". Polymer requires me to write a book where React or Vue let me write a memo. Does it make it harder for a search engine to index my site? Sure. But that's what seo/og is for. Does it make it harder for a user to inspect-element? Sure, but that's their problem, not mine. Does it make it harder for someone else to learn how I did something if I don't host the code on github or something? Sure, but I am under no obligation to write code that, in production, is easy to debug and replicate.
So while Polymer is super strong for all of those, realistically: I only care at the academic level, because that's not where my time and efforts lie.
https://www.polymer-project.org/2.0/start/first-element/step...
The reason you have to define what an element 'is' is for backwards-compat reasons. Additionally, the properties definition block is there simply for attribute -> property serialization so that you can set properties declaratively in the HTML as attributes. The property declaration is also used for tooling schema enforcement just as you suggested it should really be there for. You do not need a properties block at all since Polymer uses webcomponents, and as you said, elements can handle arbitrary attributes (and attributes set in JS with the exception of the data- attributes [1]).
In Polymer 2, you simply set the function hook just like you wanted. Polymer 3 which is essentially just a refactoring of Polymer 2 introduces JS Modules. An example would be:
This example, does not use the properties but the native attributeChangedCallback [2], it does not explicitly define properties and it can still set this.pressed, and you can easily add a 'cats' attribute if you want which can then be accessed via this.getAttribute('cats') like any other native element. Polymer is written so that all the code is executable in the browser even with the JSX-like template syntax [3]. But with the move to JS modules, a webpack configuration can easily add extra functionality like not even having to define the event listeners or the observed attributes.[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
[2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
[3] https://www.youtube.com/watch?v=ruql541T7gc
Polymer 2 looks better than polymer 1 for sure, but if I'm comparing what I need to write in React vs. Polymer 2, the former still beats out the latter in terms of low effort, high productivity.
And to be clear: the reason I think (and the numbers bear out that) React and Vue etc. beat out Polymer still is because they can do the same things as polymer: the on-page result is identical. Except React and Vue offer a better dev experience... provided you buy into the development model, of course. But this is also true for people who first start with Polymer: they have to buy into the idea that the classic web stack is the best solution to the problem of needing custom components.
And that reveals the major difference, in turn revealing another reason why Polymer is not as popular as one might hope: Polymer is a web presentation and interaction technology, whereas for instance React is a universal UI technology. They're not even remotely the same thing: the latter is effectively a superclass of the former. For example, as long as you call the functions that React tells you need to be used to effect UI updates, you will never have to think about "where this code runs". Web? Mobile? Desktop? Someone's GTK+ application on embedded hardware with JS support? It literally doesn't matter: call the functions, and it will work. The fact that the DOM is used in the browser is pretty much irrelevant to React - it's only relevant to devs who want to explicitly tie their UI to APIs that are only available in a browser. Polymer takes an approach that is diametrically opposite to this: it keeps things as "webby" as possible, making you write DOM, and only DOM, elements.
So that is another reason for the difference in dev experience: React has abstracted as much as possible so as to only expose what you need because it wouldn't be able to do its job as UI technology if it kept exposing platform-specific construct, whereas Polymer can keep things explicitly tied to the browser stack, and thus never got pushed to be as self-contained as possible, with as high a productivity:effort ratio.
(and whether that's a good or bad decision is irrelevant when discussing 'why is one of these more/less popular than the other', even if I certainly have opinions there. I'd love for React to be more webby, like polymer, but if it was, it would be much clunkier)
It's much like JQuery. It was very much necessary when it came out in 2006. But then browsers got querySelectorAll, classList, uniform event handling, uniform dimensions, fetch, animations, transitions, data-attributes, and basically all the other functionality in JQuery.
The JQuery API is still more convenient in many cases, and several loyalists are still like "You'll pry JQuery out of my cold, dead fingers." But they build worse sites - for the same functionality, their sites are slower, take longer to load, and have more things that can go wrong. The market usually flushes such loyalists out eventually, and we may see a similar situation with React/Vue/Angular when components are standardized across browsers.
If that's the big benefit, then it will be increasingly irrelevant (assuming its not already), including on the mobile space.
Especially since those 132K (for React, Angular, and the like) are not "basic platform functionality" but give tons of things that Web Components do not.
I would like to see sources supporting these claims, please.
You can use custom elements in React and you can even use React in custom elements, so they are not designed to be competing technologies. Quite the opposite.
If it just was fully styleable. Browsers really should implement better selection of customizable standard widgets. Currently it requires too many hacks to re-style the built-in input elements. Web components feel a bit overkill for most cases.
Accessibility is one reason why css-themeable native widgets would be a win for everyone, their look will match with the branding (customer happy) and behaviour will be consistent (end user happy), and standardization would make developers happy.
I'm specifically criticising the focus polymer has on creating user interaction elements.
My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level <App/> component).
For comparison, read:
https://www.polymer-project.org/2.0/start/
'build custom ui widgets' <-- wrong, this isn't a problem most people have.
vs.
https://vuejs.org/v2/guide/#Composing-with-Components
'build your application from components' <-- right.
* It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaScript itself, but it isn't.
* Bloated. You end up downloading several hundred kilobytes of JavaScript if your webapp uses more than a few different types of UI elements.
* Polymer components don't behave like native components. For example, you cannot swipe between tabs like a ViewPager does on Android. Implementing any kind of swipe-based feedback is hard, including pull-to-refresh. Back to native programming, I guess.
* For having so much marketing and PR and a camel-cased name "WebComponents", you would think it would be productized enough that it employ the appropriate native Android elements at least in Google Chrome on Android, and use the HTML5 substitutes on iOS and desktop. For example, you should replace the Polymer button with an actual styled Android button instead of a nested div hell. Chrome should have worked with the Polymer team on this. Not doing this has serious performance implications when you display thousands of items (e.g. lists of results, contact lists) each with their own nested div hell. Back to native programming, I guess.
* There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.
A quick CDN get-started would be convenient I agree. There is Polymer-CDN for demos/code-pens: https://github.com/download/polymer-cdn
The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.
Half the things I've ever installed were far more complicated than that.
Google's Flutter certainly creates apps (using mostly web technologies) that have the correct look and feel for Android and iOS from the same codebase.
Keynote: Flutter (Dart Developer Summit 2016)»https://www.youtube.com/watch?v=Mx-AllVZ1VY
Bingo. Most won't and shouldn't. There's a different between building casual widgets for personal vs for business production use. jQuery UI got some widely popular components such as Select2 and jqGrid, Datatables etc. They will never be developed by non-developers or business users. The tool should be really reserved for code crafters.
Imagining those crafters started creating tools with WP that are modular and self-cotained, work across whatever browsers threw at them.
I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")
Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth.
Let's say you are working on a social network though. You'll need to display a "person widget" a bunch, in different contexts. Of course you want to have it be consistent throughout your app. Of course you want it to look the same. Of course you want encapsulation!
When you're writing a web app, your HTML isn't just layout but the entire interface. You're usually working with a huge team and need consistency. You want to be DRY.
If you have a style guide, you probably could benefit some from this. The proof is that things like JQuery UI exist, even if it's activated more through JS.
HTML is basically unreadable in so many cases because you can't encapsulate layout code into widgets. Having these tools lets you stay a bit sane when you need to build out a lot of workflows in a consistent manner.
This is what Progress Web Application tries[0](PWA https://en.wikipedia.org/wiki/Progressive_web_app), a fairly new spec, attempts to bridge the gap. Basically a normally web page will virtually be indistinguishable from a web app.
One of the very real issues WebComponents solve is encapsulating the component functionality and styling away from everything else in a typical web page; you know, the basic separation of concerns stuff.
Certainly nothing that Microsoft proposed then has today's comparability and flexibility of today's offerings.
Microsoft didn't lack good ideas back then when they cared about the web; they were clueless about interoperability across devices and platforms. (IE for the Mac had a better but different rendering engine than IE for Windows did.) And because of their monopoly status then, they weren't to be trusted.
I also want to correct something the article mentioned, that Netscape was irrelevant back then due to Microsoft's cool features--not true. In fact, on any big project, developers had to essentially make two sites--one for Netscape users and one for IE users.
The "new" Microsoft it much better with getting their ideas out and working with other companies.
Smaller scale but for fun, in vanilla WebComponents (as implemented in Chrome) I put together a Slider that can then accept and consume child elements that add behaviour, like this:
People have tried to materialize this idea in multiple ways over time - HTC, microformats, web components etc. It should not be surprising that the solutions are similar. This isn't to say the first implementation was the best, and the others have just forgotten history. I am sure there are some pretty senior web developers around who remember their history, and were even part of it. If anything we should be optimistic that the new implementations have learned from the mistakes of the past.
They wouldn't "just know," there were supposed to be DTDs published that would tell the browser how to render that specific kind of markup.
why didn't we stick to xml and use a language to transform it into ui.
with fast internet raster images shouldn't be a big issue.
and all the browser does is send the window size and cursor position.
Related aside: to this day, we still cannot write <script src="/main.js"/>. We must use <script src="/main.js"></script>. All because of a multi-decade old description of a CDATA element. Sigh.
Web Components look to at least we can get some of those ideas back, instead of writing workarounds with HTML/CSS/JavaScript.
Yeah, I could close my tags and validate my code with the best of them back when XHTML was a thing--but that's no way to live. I'm glad WHATWG stepped in and literally saved the web from itself. OMG! XHTML 2 would have sucked so much!
why/how? because you'd have to close your tags and validate your code?
All without the marketshare of the time, thankfully.
I think the reality is, Microsoft introduced these technologies at the tail-end of initial "dot com boom". Shortly afterward, most of the companies who might have built ambitious web apps using them went bust. Microsoft stopped investing in IE, and for quite a while afterwards, web development regressed to people building document and brochure-style sites. People were too busy trying to figure out complex CSS, and what `hasLayout` meant in IE to build component-based apps.
A few years later, web development crept out of the doldrums: JavaScript's reputation began to be rehabilitated, the term "AJAX" was coined, and companies like Google began building more ambitious web apps. But by now Firefox was the browser of choice for most developers, and had gained enough market share that you couldn't build IE-specific sites.
Mozilla teamed up with Opera and Apple, and later Google, to create what became HTML5, and that included reverse engineering and standardising a number of proprietary IE APIs. However, they chose to ignore element behaviours. Presumably because they had their own component technology, XBL, and wanted to make that the basis of web apps. And, since element behaviours never made it into Firefox, developers never started using them.
My guess is, had Firefox adopted them, they'd now be a standard part of the web platform, and we wouldn't have web components as they currently stand. There are a lot of similar "what ifs" in the history of the web. For example, what if Microsoft had adopted XBL? What if flexbox and grid had been implemented in early 2000s when they were originally designed, instead of fifteen years later? What if ES4 had been accepted and implemented? What if Cassowary had been built into CSS when it was proposed, instead of being ignored (and later used by Apple as the basis for auto layout)?
[1] https://www.w3.org/TR/xbl
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL
[1] http://webfx.eae.net/
Actually thats precisely why it never caught on. Source: I was front end developer at one of the big dotcoms ca 2000.
Also, its remarkable how many people skimmed this article, and didn't understand that the first part was from 1999. That really says a lot about people's expectations when it comes to Microsoft and web technology.
Any other reference article for web designing.
So as a result 96% hated the IE and the other 4% were using other browsers. No wonder nobody wanted to use the newest Microsoft only features.
Furthermore, microsoft was fighting open source software which didn't make them more popular: https://en.wikipedia.org/wiki/Halloween_documents
Compared to those times the data collection on modern Win 10 systems and forced updates are small sins ;-)
because technology per se is just one of the variables that matter. For example, you are missing things like "timing", "marketing strategy" and a whole lot of other things. =)
Polymer 3 will switch to ES6-loader and npm, probably one year away?
I spent quite some hours with Polymer, but finally give up for now, one reason is that I want Polymer 3 today, but it is not there yet, also big companies tends to make its stack for big players(look at Angular2).
I will use Vue.js for new projects at the moment, I read somewhere saying, Vue.js could be the next modern jQuery, and I kind of agree.
To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen".
At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery.
We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done.
React/JSX got the good parts of it, and added even more useful things. If we could add the missing parts on top of that (like encapsulation from the external DOM), it would be perfect, and the rest of their horrible API/design can vanish.
And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed)
And see also http://ishoudinireadyyet.com/
That's browser adoption. XHTML was also adopted by all browsers.
I'm talking about developer adoption.
Fortunately, like expression, it's gone now in newer browsers, but this was not a proud moment for web security.