Comment by nawitus | Hacker News Reader

Comment by nawitus | Hacker News Reader

Parent Full thread

"maybe your goal isn't to "sell" WebComponents, but to sell Polymer."

The goal of Web Components are to sell a interop layer that is supported by many (or even all) frameworks. It's not supposed to be a framework that has the best developing experience.

The Polymer API is better than the Web Components API. The Polymer API is more high level than the Web Components API. This is not by mistake, it's by design. The higher level the Web Components API is, the more difficult it is to use by a large number of wildly different frameworks.

"We complain because WebComponents API is horrendously bad, and that was a deliberate design choice."

I don't think it matters much to be honest, because developers should use frameworks, just like they are using frameworks at the moment.

"Here's code to create one single property with one single synced attribute. One. single. property/attribute pair. One."

You need a "synced attribute" only for some frameworks, not all. Also, your example is misleading, because the two last methods are only needed to be defined once, so if you want 2 synced properties, the total number of methods is 6, not 8.

"Bad developer experience."

Use a framework.

"If WebComponents had better APIs, there would be no need for Polymer, would there."

The risk is too high to use the Polymer API for the Web Componenets API. In addition, the more complex the API is, the more likely it is for the browsers not to implement the API. It's better to have a simple native API and provide different frameworks for a good user experience.

"Because in your mind WebComponents === Polymer."

Or maybe he thinks that frameworks should be used, as intended.

> The goal of Web Components are to sell a interop layer that is supported by many > Or maybe he thinks that frameworks should be used, as intended.

Translation: instead of providing a good DX we're going to sell Polymer

> The Polymer API is more high level than the Web Components API. This is not by mistake, it's by design.

Indeed. By crappy design with horrible developer experience

> The higher level the Web Components API is, the more difficult it is to use by a large number of wildly different frameworks.

Hmm... How about "let's reduce the need for and dependency on multiple frameworks"? When will that ever be a goal?

> You need a "synced attribute" only for some frameworks, not all.

Surprise, Polymer's API provides a possibility to define that.

> Also, your example is misleading, because the two last methods are only needed to be defined once, so if you want 2 synced properties, the total number of methods is 6, not 8.

Oh. Right. 6, not 8. I wonder if I ever complained about the number of methods required? Nope, what I complained about is the amount of tedious boilerplate you need to write to implement the most basic and common of things.

If I need 1 more synced property/attribute pair, I will need:

- 1 extra setter

- 1 extra getter

- 1 extra item in the attributes list

- 1 extra if clause in the callback.

>> "Bad developer experience." > Use a framework.

How about: platform provides a well-designed API that doesn't require a framework for the most basic and common functionality?

As an example:

- DOM APIs are horrible, and quickly devolve into tedious error-prone boilerplate

- jQuery API is amazing

- Does this mean that DOM APIs suddenly become developer friendly? Does this mean they are beyond any criticism?

Same with WCs

"Hmm... How about "let's reduce the need for and dependency on multiple frameworks"? When will that ever be a goal?"

That's not a realistic goal, because there's no common agreement on the framework API. If there were, every framework would have the same API already.

"Surprise, Polymer's API provides a possibility to define that."

Your point being?

"Oh. Right. 6, not 8. I wonder if I ever complained about the number of methods required? Nope, what I complained about is the amount of tedious boilerplate you need to write to implement the most basic and common of things."

You're not intellectually honest, so I will stop this discussion.

The moment I call you out twisting my words, you call me intellectually dishonest. Suit yourself. This entire discussion shows the actual intellectual dishonesty of people who defend WebComponents.

> Your point being

You, and others are completely entirely blind to the fact that:

- WebComponent API is horrible DX

- WebComponent API can be made better within the platform, without the need to rely on third-party frameworks.

However, if the goal is not to push WebComponents forward, but to sell Polymer to as many devs as possible, it’s not surprising.

Also:

>> "Bad developer experience." > Use a framework.

What is the point of WebComponents, exactly?

Let's quote from here:

--- start quote ---

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

--- end quote ---

They don't allow any of that, do they? Because, as you so eloquently put, "use a framework". As I'm already using a framework (there are dozens of them out there), what is the selling point of WCs exactly?

Oh, right. "Use Polymer", how can I ever forget.

"What is the point of WebComponents, exactly?"

My point differs from the opinion of someone else (not sure who you quoted).

" As I'm already using a framework (there are dozens of them out there), what is the selling point of WCs exactly?"

To provide interop between frameworks, so that we don't need to write the same components 10 times for each framework. We can just implmenet it once, and use a native API to use it from any framework.

"Oh, right. "Use Polymer", how can I ever forget."

There are and will be other frameworks which support the Web Components API.

Reply on news.ycombinator.com