111–120 of 151 posts
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.
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 im…
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…
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.
Earlier quoted context omitted.
> 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 th…
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.
Yeah, that worked so nice with X-Windows...
Earlier quoted context omitted.
I was a big fan of XHTML and all related XML Components, but then politics won.
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 stepp…
why/how? because you'd have to close your tags and validate your code?
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 im…
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.
Earlier quoted context omitted.
It was a truly great release.
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. . Typed on Firefox :)
It just wasn’t good enough to last 10 years without updates
Earlier quoted context omitted.
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…
> I think that people that disregard Polymer fail to understand that Web Components are already here. 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.
Earlier quoted context omitted.
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.
> They have a very clear problem statement, it's hard to orchestrate reusable front-end code. 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/we…
uh, this applies to Web Components too. In what way do you think they're different?
Earlier quoted context omitted.
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.
> It is low level API to be non-opinionated. 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…
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 :/