Use our own parser for HTML (instead of browser) #4417

Closed
mhevery opened this Issue Sep 29, 2015 · 13 comments

Projects

None yet

10 participants

@mhevery
Member
mhevery commented Sep 29, 2015

Advantages:

  • We could use it in WebWorker, Server side, or with native renderers.
  • Proper camel casing. (We can get rid of inner-html vs innerHTML) #4923
  • Errors have proper line numbers.
  • We can rely on attribute order (not sure if it would be relevant)
  • We could support self closing tags <name /> for custom elements
  • No need to ship parser when doing offline compilation.

/cc: @pkozlowski-opensource, @gdi2290, @tbosch

@vicb
Member
vicb commented Sep 29, 2015

Couldn't we rely on parse5 here ? (AFAIR it also supports line numbers)

I'm not sure if I like your "proper camel casing" point: I think we should conform to what HTML is and don't try to re-invent the wheel.

@vicb
Member
vicb commented Sep 30, 2015

To give more details on why I'm not keen on this idea:

  • I can not really remember of any techno aimed at improving the standard (coffe script, dart, ...) being very successful and widely adopted,
  • Having our own parser would Make it easy & tempting to deviate from HTML. IMO this could only increase fragmentation & frighten users,
  • do we really want to maintain a parser as part of Angular (for ref parse5 is ~4000LOC) ?
@alexpods
Member

@vicb Angular2 has already deviated from HTML. Please, don't pretend that [prop]="expr", (event)="expr", *ng-for="#value of values", <div #element> are valid HTML syntax. And it has already frighten some users. The way I see it, the need to remember dash-case/camelCase conversion and its special cases are terrible user experience. It will been frightening users even more.

@pkozlowski-opensource

I'm not sure if I like your "proper camel casing" point: I think we should conform to what HTML is and don't try to re-invent the wheel.

@vicb looking at the current user experience / feedback there are toons of people that bump into this issue. I all for following standards, but I'm also for given users' a tool that works according to their expectation.

I'm not saying that we should do one or another - I can totally live with the current system since I understand it now. But yeh, we've got trade-offs to make here.

do we really want to maintain a parser as part of Angular (for ref parse5 is ~4000LOC) ?

My understanding was that we sort of do this already for the server-side compilation. I wouldn't even raise this case if not the fact that we need to parse templates on the server-side anyway. On top of this having the same parser on both sides would allow us to remove parser / compiler from the framework's runtime.

All in all what I'm saying here is not "we need to absolutely do it" but rather "there are serious advantages of this approach so let's consider it seriously"

@kasperpeulen

I would love this. If you are going to set a javascript property, I feel like I should use the javascript name, not some html enforced name.

About the html standards argument. It doesn't feel like the angular2 project is much into standards anyway. I mean writing the code base in Typescript. Supporting Dart. Also the [value], (click) #input notation.

Some people will not like this. But is that a problem? I think that polymer is an excellent project if you prefer using (upcoming) web standards.

@vicb
Member
vicb commented Sep 30, 2015

@alexpods

don't pretend that [prop]="expr", (event)="expr", *ng-for="#value of values", <div #element> are valid HTML syntax

They all are valid HTML syntax.

@pkozlowski-opensource

My understanding was that we sort of do this already for the server-side compilation

AFAIU we use parse5 to parse templates on the server side.

On top of this having the same parser on both sides would allow us to remove parser / compiler from the framework's runtime.

As of today, we use the browser built-in parser so we already do not need to embed any kind of parser in the runtime. The situation would be even regarding the runtime footprint.

All in all what I'm saying here is not "we need to absolutely do it" but rather "there are serious advantages of this approach so let's consider it seriously"

I fully agree here. We should consider it and carefully weigh the pros & cons before we jump into this or discard the idea. @mhevery only listed advantages in his original message (some of which are disputable IMO) but I think we should consider both up & down sides.

The only 2 benefits I see in implementing our own non-HTML compliant parser are:

  • Proper camel casing. (We can get rid of inner-html vs innerHTML)
  • We could support self closing tags for custom elements

@kasperpeulen

It doesn't feel like the angular2 project is much into standards anyway. I mean writing the code base in Typescript. Supporting Dart.

Typescript is mostly ES6 + some proposals from ES7 + types so it is close enough to the standard plus it transpiles to ES6/ES5 so the user do not have to be exposed to TS if they prefer not to.

WRT Dart, I would say that 95+% of the code base is TS only, I don't see an issue here - and once again this is transparent to JS/TS developers.

@pkozlowski-opensource

@vicb IMO there are more benefits that just camel-casing and self-closing tags:

  • Errors have proper line numbers <- this would be huge wine. Especially that we can detect more pbs (ex.: funky auto-corrections done to HTML by browsers)
  • From what I understand we would have still some runtime code-size gains - we should measure.
  • Not having several versions of a parser would be good (only one code path means that we've got only one set of bugs to fix)

Anyway, to be discussed / measured / decided upon.

@martinmcwhorter

I am wondering if any of the new TypeScript tsx/jsx features in TS 1.6 could be leveraged with an Angular2 parser in order to allow type safe templates?

@inikulin
inikulin commented Oct 1, 2015

@vicb

AFAIR it also supports line numbers

Correct. v2.0 will come up with line/col support as well.

@kasperpeulen

@vicb I think I didn't word myself clearly. I didn't meant to say I see dart support as an issue. I love dart.

As an outsider, it looks like the philosophy of angular2 is more in sense of, "no problem to go a bit off standards, if it gives big gains". Actively recommending typescript, supporting dart. I like that way of thinking. It feels like this proposal is in the same line.

Where polymer seem to have more the philosophy, only use web standards, and if those web standards are not good enough, we should try to push the standards to improve. Some people may prefer that. Not sure if angular2 should try to fish in this water, if there is already a big google ship fishing there.

@tbosch tbosch self-assigned this Oct 26, 2015
@mhevery mhevery modified the milestone: Beta Oct 27, 2015
@mhevery mhevery removed the hotlist: beta label Oct 27, 2015
@ronnross
ronnross commented Nov 5, 2015

Personally I am totally for this. What about even using PascalCase for elements? Here is my reasoning. We already are naming our classes using
PascalCase MyComponent. When we import the component it looks like import MyComponent from './MyComponent'.
We also inject it using PascalCase directives: [MyComponent]. Then when we use it inside of our template we shocking
now refer to it like <ns-my-component />. To me this seems a bit jarring and not as clear as simply using
<MyComponent />. I feel another benefit is that it becomes really easy to quickly pick out which are custom
element.

<section>
  <div>
    <MyComponent />
  </div>
</section>

Not to mention how nice it would be if one happens to rename their component. Then one could find and
replace all instances of the component name, instead of first updating all instances of MyComponent and then ns-my-component.
Also it seems one would no longer even need the selector: '' inside of the component decorator therefore simplifying
the boilerplate needed to define a component.

@martinmcwhorter

If we used PascalCase component element names and get rid of the selector don't we lose component directives that are bound to the view as attributes?

@timkindberg

I'm with @ronnross on keeping names consistent and potentially ditching the selector property (keeping it optional in case you want a different name than your class).

Directives would probably need to remain lowercase dashed, but if there wasn't a restriction you could technically set your selector to selector: '[MyDirective]' if you had a preference for it, e.g.:

<div MyDirective="stuff"></div>

We could make a Component's default selector '${ComponentClassName}' and a Directive's default selector '[${DirectiveClassName}]'.

@vicb vicb added a commit to vicb/angular that referenced this issue Nov 13, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
8e4ed99
@vicb vicb added a commit to vicb/angular that referenced this issue Nov 13, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
92f4b08
@vicb vicb added a commit to vicb/angular that referenced this issue Nov 13, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
61ac285
@vicb vicb added a commit to vicb/angular that referenced this issue Nov 14, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
411663b
@vicb vicb added a commit that closed this issue Nov 16, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417

Closes #5264
a8edc1e
@vicb vicb closed this in a8edc1e Nov 16, 2015
@vicb vicb added a commit to vicb/angular that referenced this issue Nov 16, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
4d6da64
@vicb vicb added a commit to vicb/angular that referenced this issue Nov 18, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
b68b3db
@vicb vicb added a commit to vicb/angular that referenced this issue Nov 18, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
4c4cace
@vicb vicb added a commit that referenced this issue Nov 19, 2015
@vicb vicb feat(Compiler): case sensitive html parser
close #4417
Closes #5264
36a423f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment