4 ms·
<!-- The loop --> <ul render="@items: (name,index) of ['dog','cat','ram'] / 'item';"></ul> Maybe I am special, but this looks absolutely cursed to me. Logic i
by gloosx 3y ago
<!-- The loop -->
<ul render="@items: (name,index) of ['dog','cat','ram'] / 'item';"></ul>
Maybe I am special, but this looks absolutely cursed to me. Logic in an HTML attribute string? Please no.
- MilStdJunkie 3y agoDo you know the line in that one Cake song, "bowel shaking earthquakes/of doubt . ."? I don't have a quantitative reason for this feeling[1], but the idea of combining OOP principles - class, object, inheritance - with document markup gives me that feeling. [1] I'd need to think about it for a second, but I am pretty sure that the root of this dread is the potential of a deep, deep pit-trap, where a class system runs parallel - but discrete - to the inherent semantics of HTML. But I'm not a big fancy-pants programmer. I'm sure my gut feelings can be safely discounted if this idea truly has some legs. I dunno. I like HTMX fine, but that's a different kettle of fish, isn't it? It's not got the same underlying notion of reification like OOP does. It's like the difference between a car with an automatic transmission option versus a car that has modular functionality that toggles whether or not a transmission is a thing or not, which may contain the quality of "automatic".
- onionisafruit 3y agoI’m no poet, but I’m pretty sure this is what going the distance is about.
- CipherThrowaway 3y agoIt looks cursed because it is cursed. It's the classic "back to the basics" web technology nonsense that is hello world optimized and completely unsuited to any real world business purpose. These seemingly simple template languages that promise an escape from the "unnecessary" bloat and complexity of the modern web are doomed to fail. Any level of adoption will drive deeper usage, which will drive more complex use cases, which will force more bolted-on general programming language features. Eventually your users discover (the hard way) why all the complexity in modern web frameworks exists, but now they're stuck programming in a shitty template language that is underbaked, awkward to use, has no ecosystem, shitty tooling and some rancid expression DSL you have to memorize. Cursed indeed.
- phrasecode 3y agoI might have done of lot of hating on DSL just like this. In fact, if you had followed the progress of OOHTML, there was never data binding. But there's something you find when you follow a practice driven process, and the realisation that brought data binding in OOHTML is one of them. I'm happy to write a post about this when I have more time. But thanks for your feedback.
- CipherThrowaway 3y ago>I might have done of lot of hating on DSL just like this. And now you go down the same path. If you are building real applications with this then you will find that OOHTML will need to be repeatedly extended in order to fit the more complex use cases that come with deeper usage. You will end up reinventing the wheel but worse. That's a great outcome if the project is a hobby or learning experience. But if you're trying to deliver real commercial outcomes with this tech I would start rethinking things now.
- phrasecode 3y agoI do understand the frustration with syntax. The good thing is, none of that is finalised and we are in fact seeking people's idea of whats best. But one thing that always holds on this subject is "tradeoffs"! It's an inconvenient word but we wouldn't do anything on the web without it. See also Evan You's talk on seeking that balance: https://youtu.be/ANtSWq-zI0s?si=fDbJLfA9T5VLvgsZ https://youtu.be/ANtSWq-zI0s?si=fDbJLfA9T5VLvgsZ. I'm happy to incorporate constructive feedback on this project, and it's early age affords us a great opportunity to do just that. So what's your thought on the challenge?: a native way to bind an element's css properties, class list, attributes, etc. to application data?
- gloosx 3y agoMy thought is that it is a dead-end. You don't need to extend HTML with data binding. You need functions, and you need an appropriate language to write functions, it can be PHP, JS, but not weird HTML attributes.
- trilbyglens 3y agoTbh this is basically jsx. Jsx is also cursed.
- tentacleuno 3y agoIf a DSL is "cursed", then JSX is a lot less cursed than that -- it's basically just XML-like shorthand for JS, as opposed to a whole new language.
- phrasecode 3y agoWhy not we think in terms of "tradeoffs"? You'll find that there a million alternative syntaxes that could work but which would require seeking the right balance. Evan You's on this comes to mind again: https://youtu.be/ANtSWq-zI0s?si=fDbJLfA9T5VLvgsZ https://youtu.be/ANtSWq-zI0s?si=fDbJLfA9T5VLvgsZ. Meanwhile, I am happy to put up a quick post regarding the thinking over here. I might have done a bit of that in the introductory article: https://dev.to/oxharris/revisiting-the-html-problem-space-and-introducing-oohtml-3oh5 https://dev.to/oxharris/revisiting-the-html-problem-space-an...
- CipherThrowaway 3y agoSay what you want about JSX, but this is the opposite of the JSX approach. JSX embeds markup in your logic rather than logic in your markup.
- phrasecode 3y ago[dead]
- bastawhiz 3y agoJSX props are just JavaScript expressions. This invents a new third thing.
- gloosx 3y agoNo. JSX doesn't try to stay HTML syntax. JSX is actually just syntactic sugar around pure functions. If you remove the babel transform it will be just a wall of nested functions which output the DOM.