Introduction to HTML Components
blog.mecheye.net
blog.mecheye.net
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
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.
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.
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...
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:
import {Polymer} from 'pathToPolymer';
export class IconToggle extends Polymer.Element {
static get is() { return 'icon-toggle' }
observedAttributes() { return ['toggleIcon'] }
attributeChangedCallback(name, old, new) { if(name === 'toggleIcon') {...} }
connectedCallback() { super.connectedCallback(); this.addEventListener('pressed', this.onPressed.bind(this)); }
onPressed(evt) { this.pressed = !this.pressed; }
}
customElements.define(IconToggle.is, IconToggle);
[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
[2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
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:
<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>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.
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.
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)?
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL
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.
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. =)
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?
.
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.)
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.
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 ;-)
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.
All without the marketshare of the time, thankfully.