The best way to represent HTML is with HTML itself, not an HTML-like system that varies in subtle ways between languages and libraries that happens to be missing the one feature you need.

I'm a large fan of Embedded DSLs (Domain-Specific Languages) for these types of problems, as they allow using normal HTML syntax directly in the rest of your code. Combined with macros (for compile-time parsing/analysis) and interpolation (for safely templating values), DSLs can be safer, more performant, and overall more maintainable than other approaches. For languages like HTML and SQL that are standard and well-defined, this is undoubtedly a better approach in my mind.

I've been developing my own approach to Embedded DSLs as my thesis research with my own programming language Rhovas [0], which addresses concerns with syntax restrictions (e.g. string quotes), semantic analysis (AST/IR transformations), and most importantly tooling. Happy to answer any questions about work in this area.

[0]: https://blog.willbanders.dev/articles/introducing-syntax-mac...

I guess we have to confront whether we think that HTML fundamentally is a string that happens to contain tokens that could be interpreted as a data structure, or whether we see it as a data structure that has a string representation.

I think it just happens to be that the string representation is one of the most familiar and accessible formats to many people.

I don't subscribe to the idea that HTML somehow fundamentally is a string. However, even if we see it as a data structure, to many languages, data structures are not at hand, while objects with parochial APIs are. So you end up with a flurry of different libraries with their own way of doing things, instead of "this is just data, I'll use my language's generic data manipulation tools to deal with this".

I'd say it's definitely a data structure, but one with a canonical string representation. It may not be fundamentally a string, but that representation is critical to how we convey it's meaning to such extent that it's used across languages and browsers as the method of transport.

JSON is conceptually simpler and there's still a lot of quirks between libraries for that already (e.g. null/undefined, integer/decimal representation, and large numbers). XML has more going on to start, and then you get all the different libraries inventing their own abstractions as you said and it picks up a lot of pitfalls. FWIW; I've messed around a lot with configuration languages and it's definitely hard to get right so I understand how this differences accumulate.

I think this is actually a strong argument against HTML templating, if you saw someone templating JSON files with Jinja you would think them mad but we're somehow okay with it when it's HTML.

You bring up a good point that I never addressed the case where setting a property to a value and getting it could return a different value - this is something I overlooked, and I would say absolutely needs to be true. I also didn't do a good job restricting computation, selecting time complexity as a metric instead of literally anything else - there are far better ways of doing that.

There's more to properties than just syntax-sugar as I initially said (such as being a single unit), and I think I've built more of a case for why using property-based getters/setters over fields are better that working with fields directly. If the syntax sugar isn't your cup of tea but you agree with using methods over fields, I think that's the limit of my argument here.

> I also didn't do a good job restricting computation, selecting time complexity as a metric instead of literally anything else - there are far better ways of doing that.

A tricky one, saying something as tidy as no side effects clearly doesn't work; anything we do has to be a side effect, as our hands are tried regarding return values. I don't think it would be practical to come up with perfectly precise rules for what is appropriate, only guidelines. Even never throw an exception seems too strong, as you might want to do range checks. Never block would complicate logging.

> If the syntax sugar isn't your cup of tea but you agree with using methods over fields

Yes, I think that's where I'm going with this. The advantages of avoiding public fields seem clear enough, we just disagree about the merits of properties.

Direct field access sets the internal state of an object from outside of it's implementation. I would say the key underlying principle here is messaging passing - the object chooses how it responds to API requests it receives - and fields don't allow this to happen.

Fields prevent data validation, read-only fields, and polymorphic behavior. A particular edge case is that you can shadow a field in a subclass, and it can change the field which is accessed in other untouched code.

Getters/setters fix all of these limitations and others without considering API compatibility. IMO, the above are more important because they relate to the correctness of the code.

With the RgbColor example, a language that has mutability permissions (like Rhovas) resolves this easily. If you don't have mutable access to the object, setters can't be used.

Yes! I wanted to address this idea in the article, but it didn't make the final cut as I didn't think it added much to the points being made. Moving away from direct field access and only using functions is definitely in line with the Alan Kay OOP model.

This is an interesting question, I was not aware of this behavior in C#. It looks like the solution is to use annotations to specify a property as being ignored.

The intended behavior is to serialize all fields of an object (some properties have backing fields, others don't). You wouldn't serialize properties themselves for the same reason a getter/setter on it's own wouldn't be serialized - only the data stored.

Put simply, I would say C# has the wrong default behavior here.