Re: [w3c/webcomponents] [templates] Ensure that template instantiation actually improves the platform (#704)

@Jamesernator 

> I have read it and your proposed solution is essentially still just a VDOM/tree-diff except generating a patch on the server-side instead of the client. 

My comment was 1031 words. Of them:

- 59 were quotes
- 107 were about an interesting server-side rendering approach

This leaves _865 words that don't mention any server rendering even once_. That sliver of respect? Yup, still waiting for it. This renders a full third of your "counterargument" invalid, as you are arguing against something you yourself concocted and has nothing to do with what I wrote.

> "horribly cumbersome" is highly subjective

It's not. If you increase code necessary to write something by nearly half, it's no longer subjective. Developer Experience shouldn't be just an empty combination of words void of meaning.

> Again there's an open issue which is specifically about the capabilities of the default processor. 

That open issue already has at least four parallel discussions going on, all showing the glaring problems with the proposal. Are we still sure this actually improves the platform? You know, like a simple cost-benefit analysis?

Funnily (or sadly) enough, Chrome's WIP on template instantiation links another [issue](https://github.com/w3c/webcomponents/issues/747) which has another four parallel discussions which show even more problems in the proposal.

> What do you consider to be "compatible in syntax and behaviour"?

Incompatible with the rest of the _platform_. Not third-party frameworks. Not third-party template syntaxes. *The platform* aka the browser.

>> that is both very limited in functionality (poorly specified/underspecified if and foreach as the only control structures) and unlimited in functionality (we can call functions in the host language)
> This doesn't seem to be so much an issue with template instantiation itself as a lack of concrete spec text.

I wonder if you read the issues you yourself link as thoroughly as you read my comments. The very issue you yourself [link](https://github.com/w3c/webcomponents/issues/682) already discusses limiting expressions inside `{{}}`, and I'm sure there are many others.

Ah. Wait. I've even provided examples of where they are limited and underspecified.

> I highly doubt that proper spec text won't be released before the feature is shipped.

So far it looks like the feature is already being implemented without any proper spec. Oh wait, *you yourself linked to this* and *you yourself said*, and I quote:

--- start quote ---

One final thing, the spec text in this repository is not necessarily up to date or what will be implemented in browsers. There's currently a WIP implementation in Chrome to implement template instantiation

--- end quote ---

So, there's some mythical spec that is up-to-date that someone probably knows about. But yeah, everyone will see it, don't worry, at one point. When there will be no chance to give any further input on it, right?

>> that requires a different parser
> Nope it doesn't

Yes, it does. Because the parser doesn't stop just at the curly braces. Which would be obvious if you cared to read the issues you yourself link. Mmmm... I don't know: for example, parsing just a subset of Javascript inside curly braces.

>> a different execution model
> I don't understand this you'll need to elaborate. But it seems to me that anything would be a "different execution model".

Quoting the issue you yourself linked :

--- start quote ---

 From what I can tell the proposal includes the following features:
 - Path searching with dots, so you can do {{x.y}}. (But not brackets, so you cannot do {{x["y"]}}.)
 - Fallback with ||. Doesn't appear to be in the formal spec.

--- end quote ---

And quoting another [issue](https://github.com/w3c/webcomponents/issues/688#issuecomment-341811409):

--- start quote ---

We wanted to support a very small subset of JavaScript without supporting arithmetic or any other kind of operators but || and . and possibly [~] in the default template processor.

--- end quote ---

The proposal is bravely inventing new problems, and just as bravely finds solutions to those problems, calls it improvement.

So nope. "Anything" wouldn't be a different execution model.

> This seems to be quite syntax opinionated but you haven't actually proposed a syntax alternative that you'd prefer.

I quite unequivocally said what I would prefer, and just as unequivocally described all the issues this would solve. Sliver of respect and all that.

> You shouldn't need .innerHTML for anything. Either use DOM for the cases when you actually truly arbitrary structures

Yah, no. Have *you* tried to use DOM to any degree? In any recent past? There's a reason people use anything *but* the DOM. 

Instead of solving this problem (which would obviate ~90% of the need for the template proposal in the first place), you keep pushing a marginal improvement at a significant cost.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/704#issuecomment-489970881