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

Confusing error message when not closing an element #56

Open
DavidBruant opened this issue Dec 28, 2018 · 4 comments
Open

Confusing error message when not closing an element #56

DavidBruant opened this issue Dec 28, 2018 · 4 comments
Labels
debugging enhancement New feature or request proposal question Further information is requested

Comments

@DavidBruant
Copy link

Example code:

import htm from "htm"

const e = htm`<input>` // element is not closed

Being used to write HTML and not having to close every element (especially inputs), i can write this sort of code
With htm, i get the following error: SyntaxError: missing ) after argument list
This errors seems non-intuitive to me

@developit
Copy link
Owner

This is something we gave up when moving from using the browser's HTML parser to a custom parser in 2.0. The tradeoffs of being able to run directly in Node.js and reducing the library size were good, but we have heard from a few people that some of the niceties of HTML like this would be pleasant to have back.

I'm not sure how feasible it is to implement void elements, since its a whitelist. Perhaps we could move validation into something like an editor plugin?

@developit developit added enhancement New feature or request help wanted Extra attention is needed question Further information is requested labels Dec 29, 2018
@DavidBruant
Copy link
Author

DavidBruant commented Feb 28, 2019

reducing the library size

I just realized that i don't understand why a small library size would be a goal of this library

My understanding is that for most libraries, the size of the library is a necessary cost to be paid for the functionnality it offers

However, for htm, if i understand correctly, babel-plugin-htm reduces the footprint of the library to literally zero regardless of its original size
So with an easy-to-setup opt-in, users can have maximum functionnality of the library (and even smaller runtime cost!) at the cost of zero bytes

Under these circumstances, i see using the htm library in the browser as a transitional path to the Babel plugin rather than something that has to stay forever (which is usually the case for libraries). In this context, keeping the library size small does not seem that relevant any longer

@developit
Copy link
Owner

I understand that for some use-cases, the library size is less important. However, there are potential performance reasons to use htm without transpiling in production - including some interesting tradeoffs for JS parsing time. At 400-500 bytes, those tradeoffs are often worthwhile. A 10kb implementation with pretty warnings and english messages would likely invalidate that.

@developit
Copy link
Owner

Just an addendum: I think it would be both possible and reasonable to add extended parser error messages to babel-plugin-htm, since it doesn't get loaded at runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debugging enhancement New feature or request proposal question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants