13 ms·
Because people are taught to think in strings. And programming languages coddle them with tools like concatenation and string formatting. And because we let peo
by jameshart 3y ago
Because people are taught to think in strings. And programming languages coddle them with tools like concatenation and string formatting. And because we let people think they can do useful things with strings as a result.
But what people actually need are grammars.
The exact same reason why parsing HTML with a regex unleashes Zalgo is why generating HTML with string templates is bad. Because both treat HTML as a string, not a grammatically restricted language.
- bruce343434 3y agoWhat is your suggestion besides string templates? Writing out the html syntax tree? No thanks!
- psychoslave 3y agoSomething like Pug[1] is really nice to avoid all the xml cluttering. [1] https://pugjs.org/ https://pugjs.org/
- marcomourao 3y agoAs a mediocre developer at best, I love PUG but I'm a bit afraid about the lack of updates.
- psychoslave 3y agoIndeed https://github.com/pugjs/pug/issues/3339 https://github.com/pugjs/pug/issues/3339
- gdprrrr 3y agoMany frameworks do exactly that, including React and https://github.com/vanjs-org/van https://github.com/vanjs-org/van
- naasking 3y agoI think Mithril was the first one to pioneer this.
- hparadiz 3y agoLol. I saw PHP libraries doing this 15 years ago. Literally cringing as I read the readme. We decided over a decade ago that writing HTML with code is rediculous but somehow it comes up again and again. A designer shouldn't need to code JavaScript to edit your design.
- naasking 3y agoPioneer this in the JS/client-side rendering world of course. Mithril is about 10 years old, so in the same ballpark. Web applications aren't just HTML though, that's why code might be a more appropriate format. You can argue that designers need better tools to edit structured markup in other formats, but that doesn't entail that HTML should be the default format. For instance, something like repl.it for mithril or similar that immediately renders the output so you can see the results would be useful.
- chrismorgan 3y agoNah, it’s waaaaay older than that. It’s been done from the beginning of machine-produced HTML. The probably slightly newer aspect is producing an intermediate representation that is then serialised to HTML, though I think that’s still going to be back in the ’90s. But the oldest examples I know of (while I was yet a small child) used functions and methods to produce serialised HTML strings directly, which was more efficient (at least in the languages in question) and also allowed you to mingle with string templating. Perl’s CGI.pm let this example be written no later than 1997 (no idea when it was actually written, can’t be bothered searching harder for older than CGI.pm 2.32): https://github.com/Perl/perl5/blob/54310121b442974721115f93666234a200f5c7e4/eg/cgi/nph-clock.cgi https://github.com/Perl/perl5/blob/54310121b442974721115f936... For stuff that worked on the frontend, it’s still way older, though it tended more to XML-based stuff like XSLT (… which still works in browsers now, e.g. https://chrismorgan.info/blog/tags/meta/feed.xml https://chrismorgan.info/blog/tags/meta/feed.xml is an Atom feed but the <?xml-stylesheet?> processing instruction is basically a pointer to the file for the browser to use to convert it to HTML which it then renders). But there were definitely things in this vein even on the frontend in active use more than five years before Mithril, though I can’t be specific as my memory is fuzzy as I wasn’t paying much attention to it all back then.
- PurpleRamen 3y agoA generic solution for handling structures, built into the language's themselves, not just some hidden lib that mostly nobody knows. I mean most modern languages come with some XML-parsers, and often they also come with some more or less useful XML-generator. Add them as a first class-citizen, pimp them up and allow them to barf out all kind of tree-like structure which are similar enough and shove it in peoples faces to animate them to use it. I mean it basically worked with JSON too.
- jimbokun 3y agoS-expressions!
- jameshart 3y agoThis amounts to saying ‘but I want to be able to generate invalid HTML!’
- theamk 3y agoNo, this amounts to saying "I don't care enough about accidentally generating HTML, I want to use faster + more convenient method instead"
- mananaysiempre 3y ago> [P]eople are taught to think in strings[, b]ut what people actually need are grammars. I don’t actually disagree with you for the most part, but I feel that an important caveat has gone unacknowledged. Grammar formalisms have the same weakness compared to dealing with raw strings as sound static type systems do compared with dynamic typing: there are small, mostly isolated islands of feasibility in a sea of intractable (often undecidable) generality, and if your problem doesn’t fit inside those borders things start to get nasty (cf how even GCC’s handwritten rec-descent parser didn’t get its lexer hack interactions correct in all cases[1]). I still agree that we spend criminally little time on syntax. Starting with the simplest cases: with how much time is spent in school on “order of operations” you’d think we could take a moment to draw[2] a damn syntax tree! But nooo. There are in fact working mathematicians who don’t know what that is. (On the other hand, there are mathematicians who can explain that, in a sense, the core of Gödel’s incompleteness is not being able to reason about arithmetic—it’s being able to reason about CONS[3], which arithmetic happens to be able to very awkwardly do.) [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 [2] https://mlochbaum.github.io/BQN/tutorial/expression.html https://mlochbaum.github.io/BQN/tutorial/expression.html [3] https://dx.doi.org/10.1215/00294527-2008-028 https://dx.doi.org/10.1215/00294527-2008-028
- compressedgas 3y agoSo you have heard about StringBorg: https://edolstra.github.io/pubs/injections-gpce07-final.pdf https://edolstra.github.io/pubs/injections-gpce07-final.pdf It knows when to do escaping and how. It also can detect, though dynamically, when fragments have been combined into an illegal sequence which would be rejected by the full grammar. It can not however guarantee that the result will parse only that it can not detect that it would fail.
- mananaysiempre 3y agoWas that a question? In that case, now I have :) The authors include both of the Eelcos I’ve ever heard of no less! The ugly quasiquoting seems unfortunate (I’ve a half-serious suspicion the reason Template Haskell never got popular is that it looks so bad), and the GLR sledgehammer precludes ever having a lightweight implementation, but otherwise it seems like a interesting entry in the extensible languages story.
- capableweb 3y ago> people think they can do useful things with strings as a result Besides not "being proper" or whatever your argument boils down to, people (arguably) are doing useful things by just manipulating strings. I'd argue most of the web is probably built with just strings and duct tape holding all the pieces together.
- jameshart 3y agoDoing useful things that are riddled with bugs and security holes and fail to handle people whose name is O’Reilly. It would be better if programming languages discouraged people away from those mistakes and prodded them towards the pit of success by making string concatenation harder and providing better tools for constructing grammatically sound structures.
- theamk 3y agoOr we can use type systems to automatically escape. No more XSS injections _and_ still as easy as string concatenation. Python's MarkupSafe (used in jinja) and go's html/template are good examples.
- jameshart 3y agoThat would be in the category of ‘better tools for making grammatical structures’.
- wombatpm 3y agoPeople with wrong names should be encouraged to change them to something correct.
- Izkata 3y ago> The exact same reason why parsing HTML with a regex unleashes Zalgo For anyone who hasn't seen it yet, top answer from https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags https://stackoverflow.com/questions/1732348/regex-match-open...
- CrazyStat 3y agoAn amusing answer, but see https://www.cargocultcode.com/solving-the-zalgo-regex/ https://www.cargocultcode.com/solving-the-zalgo-regex/
- jameshart 3y agoAnd more pedantry than you can handle on whether or not that is correct can be found, of course, at https://news.ycombinator.com/item?id=27094085 https://news.ycombinator.com/item?id=27094085
- HelloNurse 3y agoHTML is text. Using something other than strings to process text is unnatural, so even systems that care about correct syntax and correct escaping tend to go from syntax tree to actual HTML eagerly. Moreover, important parts of HTML processing would be significantly more brittle and complicated and less powerful with objects: "escape some completely arbitrary text to valid PCDATA or a CDATA section, whatever is shorter" is strictly more general, robust and principled than "render a Street Address to a fragment that isn't supposed to contain markup".
- jameshart 3y agoHTML isn’t arbitrary text. HTML is a grammatically restricted subset of text. I can take arbitrary text and embed it in HTML by escaping characters within it. That produces a grammatical fragment of HTML that represents the arbitrary text, but it is not the text.
- ngneer 3y agoExactly. HTML has structure. It is not the same as flat text, although you can flatten and edit it as such. As an example sentence, take the following: "The French equivalent for the English "Good Evening!" is "Bonsoir!", whereas Italians might say "Buonasera!" to one another for similar effect." There are four languages in that sentence, two of which are English. You may need three editors to deal with them, or you can flatten the sentence and simply edit everything assuming you knew all three.
- fnordsensei 3y agoI guess this is true of all formal languages, then. Since we sit in front of text editors most of the time, the fundamental truth of all languages is that they are strings. This is not even true of natural language, which has a vocal representation that is at least as important as the written representation. Though I agree that representing HTML as objects is a poor substitute.
- HelloNurse 3y agoIt's a bit deeper: since HTML is defined as text markup, text is the truth of HTML documents and the standard of their users, while any sort of object representation of HTML documents is someone's idiosyncratic and possibly limited implementation, necessarily specialized and necessarily harder to use.
- dimmke 3y agoInterpolation should have been added to the HTML specification over a decade ago. It's one of the many things the standards body has gotten wrong. This is something that literally every single framework, front-end and back-end has had to deal with in some way since the 90s. From chucking ugly <?php tags to more elegant solutions like curly braces. Having one standard in the spec would standardize something that is currently done a million different ways.
- theamk 3y agoBut string interpolation is a small part of it. Think about formatting a shopping cart: you need interpolation, yes. But also a "for" loop (for iterating over item list), and "if" statements (to show "cart is empty" or item notes), and functions, like money pretty-printing, would be nice too. And don't forget the nested function-like blocks so one can embed standard design elements... This gets complex fast, I cannot imagine having something like this as a slow-moving spec.
- dimmke 3y agoI agree with you. I think Svelte and the syntax it uses to do everything you're describing, from iterating to interpolation should be part of the HTML spec.
- regularfry 3y agoIt's a standards producer/consumer disconnect. XSLT on XHTML documents was always the Right Way(tm), but XML got such a backlash it never stood a chance once HTML5 landed. Also, XSLT is horrible.
- wombatpm 3y agoXSLT is just XML with pattern matching and no side effects. Lisp-ish in a way That said XML is like violence, if it’s not solving you problems you need to use more.
- regularfry 3y ago
- VikingCoder 3y agoHi, we use a grammar - but it looks exactly like HTML strings. If you were naive, you'd think our system treated the strings as naked strings. But we get compile-time errors if our HTML fragments are ill-formed. Fields we pass in get automatically escaped. Best of all worlds, I think. Well, other than the fact ours isn't open source. I mean, I can imagine some improvements to the system we use, but they're all incremental improvements.
- jimbokun 3y agoIn Lisp the templating systems are S-expression based instead of string interpolation based, which at least models the tree structure of HTML documents.
- jameshart 3y agoI mean, in Lisp everything is S-expression based. That this models the tree structure of HTML documents is convenient and not entirely coincidental (SGML, plus the deep truth that trees are fundamental to structure, and S-expressions being the language in which The Word was spoken and all) But if we were talking about outputting CSV data you wouldn’t be able to say In lisp the templating systems are S-expression based instead of string interpolation based, which at least models the tabular structure of CSV documents Because hierarchies don’t model tables especially well. So the suitability of lisp for outputting HTML feels slightly coincidental.
- deleted 3y ago[deleted]
- overengineer 3y agoIn the age of LLMs everything is text
- stjohnswarts 3y ago"we let people think they can do useful things in strings". okay? But my counter point is that people have been doing useful things with strings for a very very long time and it kinda works.