Hacker News Reader

Comment by CipherThrowaway | Hacker News Reader

It 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.

View on HN

I 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.

>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.

I 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.

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?

My 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.

Thanks for your sharing your thoughts.

Yeah, after revisiting it again and also checking out your article I find my comments a bit too harsh and functional-approach-biased. But I'm in general no fan of Svelte or Vue approaches – for me as a lifelong React junkie this is all extra complexity i hate. Maybe my brain is now rooted and wired in the React so deeply it cannot accept anything else, but when I try to do something with Vue, it is just screaming: Too hard! Too many redundant entities spawned around! I just need my function, my reducer and my side-effects and I can do everything with these three! Like, I want to do this: https://codesandbox.io/p/sandbox/strange-hofstadter-kd59k6 It is a beautiful functional example of React's power. How do I even do it in OOHtml or Vue or Svelte? I still can not learn.

I love how we can talk about differences and preferences here like this. Now, I can't wait to put my thoughts further together on the pros and cons of a HTML-first approach like OOHTML's vs a JS-first approach like React's and why there seem to be strong opinions either way. I'm happy to share a link under here when I do put that together.

Reply on news.ycombinator.com