Recent searches
Search options
Administered by:
@develwithoutacause@techhub.socialI just started playing around with #Preact #SSR with #htm and the first thing I did was render the classic:
```
render(html`
<!DOCTYPE html>
<html>
<head>
<title>Preact</title>
<meta charset="utf8">
</head>
<body>
<h2>Hello, World!</h2>
</body>
</html>
`)
```
And this intuitively output:
```
html
<head>
<title>Preact</title>
<meta charset="utf8" >
<body>
<h2>Hello, World!</h2>
</body>
</head>
```
Lolwat?
* `<!DOCTYPE html>` is gone.
* `<html>` turned into `html` and lost its close tag.
* `<body>` got moved inside `<head>`.
Apparently you can't output a doctype at all (https://github.com/preactjs/preact-render-to-string/issues/201) and the `<meta>` tag is not self-closing in #JSX.
I'm willing to accept those constraints, but this is an utter failure of DX IMHO. If my template is wrong, TELL ME! Don't just generate what's effectively garbage for seemingly no reason. There's no obviously logical path from "bad output" to "the mistake in my code". Error messages, please!
@develwithoutacause HTM is not an HTML parser, it is effectively a JSX parser. JSX can only represent Element and Text nodes.
We could add error handling to HTM, but the performance impact is not worth the cost. A linter would be vastly preferable, but nobody has built one yet. If you want errors in your editor, use JSX (you can still compile to HTM if need be).
@develwithoutacause the body inside head thing is also because you're (intentionally?) passing invalid XML - the meta tag is unclosed, which is not valid in JSX and thus not valid in HTM.
@developit Could the error handling be done in some kind of dev mode? I know #Angular and #Lit both have the concept of "dev mode" for additional validation.
Personally I like the strict #XML approach, I just didn't realize #JSX was that strict (it's a new experience for me), and figuring that out took a solid 45 minutes of debugging which an error message would have cut down to 1.
@develwithoutacause in general, anyone who is looking for dev time errors should be using JSX, not HTM. None of this would have been possible in JSX (would have been syntax errors).
@developit By "dev time" do you mean "compile time"? I'm assuming the point of HTM is to skip the compile step required by JSX?
If so, I'd actually think it's even *more* important that HTM validate it's input, given that it's very likely nothing checked it statically. More of a product decision, certainly a linter or validation step could serve a similar purpose.
@develwithoutacause it would need to be a linter, because there is no such thing as "dev mode" except bundler-specific nonstandard conventions. A lot of folks use HTM from a CDN, so no dev mode is possible.
An observation though: HTML doesn't validate, it just parses "best effort" (effectively the same as HTM does) - folks seem to manage fine writing HTML.
@developit Agreed there's no standard definition of "dev mode". Angular has it's own bundler with knowledge of this, not sure how Lit handles given that they also don't have a compile step (they do have lit-analyzer which is their version of a linter).
True that devs have been writing unvalidated HTML for decades. I don't think that necessarily means we shouldn't try to improve safety in the ecosystem, but I can see how that might inform prioritization of such a feature (especially when you can point people like me who want it at JSX).
@develwithoutacause that's basically the conclusion we came to. I would *love* to build awesome linting and maybe a dev mode for HTM, but its used primarily for dynamic stuff where folks would be unlikely to use or benefit from those tools.
@developit I can definitely see that argument for linting. Though I think dev mode is something which can provide additional safety without extra tooling (at a performance cost ofc). Then, for users shipping to production, they are likely already using a bundler and can disable dev mode for improved performance.
I get that makes the production build a little more complicated, and that might be particularly relevant for SSR use cases where bundlers aren't as commonly used. I still think that's worth the trade off IMHO.
Ofc I'm only just playing around with Preact for the first time today, so my opinion is still quite uninformed. Just something for you to think about.