Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mhevery opened this issue Sep 29, 2015 · 15 comments
Closed

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

mhevery opened this issue Sep 29, 2015 · 15 comments
Labels
effort3: weeks feature Issue that requests a new feature
Milestone

Comments

@mhevery
Copy link
Contributor

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) Use camelCase instead of dash-case in HTML #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

@mhevery mhevery added feature Issue that requests a new feature P2: required effort3: weeks labels Sep 29, 2015
@vicb
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

@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
Copy link
Member

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
Copy link

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
Copy link
Contributor

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
Copy link
Member

@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
Copy link

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
Copy link

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
Copy link

@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.

@ronnross
Copy link

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
Copy link

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
Copy link

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 added a commit to vicb/angular that referenced this issue Nov 13, 2015
vicb added a commit to vicb/angular that referenced this issue Nov 13, 2015
vicb added a commit to vicb/angular that referenced this issue Nov 13, 2015
vicb added a commit to vicb/angular that referenced this issue Nov 14, 2015
@vicb vicb closed this as completed in a8edc1e Nov 16, 2015
vicb added a commit to vicb/angular that referenced this issue Nov 16, 2015
vicb added a commit to vicb/angular that referenced this issue Nov 18, 2015
vicb added a commit to vicb/angular that referenced this issue Nov 18, 2015
vicb added a commit that referenced this issue Nov 19, 2015
@xgqfrms-GitHub
Copy link

good job!

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
effort3: weeks feature Issue that requests a new feature
Projects
None yet
Development

No branches or pull requests