OOHtml – Object-Oriented HTML Implementation | Hacker News Reader

OOHtml – Object-Oriented HTML Implementation

github.com

47 pointsambigious777763 comments

Maybe I am special, but this looks absolutely cursed to me. Logic in an HTML attribute string? Please no.

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

I’m no poet, but I’m pretty sure this is what going the distance is about.

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.

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.

Tbh this is basically jsx. Jsx is also cursed.

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

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

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

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

JSX props are just JavaScript expressions. This invents a new third thing.

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

I've been wondering recently if there could be a more generic JSX renderer that could be built into browser. <script type="jsx"> type thing.

I think it could work if it decoupled the reactivity layer and exported a "rerender me" hook that libraries like react/preact/vue/solid/etc could use to manage reactivity.

Because let's be real, `<ul render="@items: (name,index)` and `v-for` type things are terrible. JSX got a lot of things right. It's a pretty darn good marriage of HTML and javascript as far as syntax goes. Besides className, key and the curly syntax to drop into javascript, its pretty pure and straight forward.

but what about those if us who prefer other template engines?

vue/angular are better than jsx. Differences are minor, of course. But why should it be jsx?

Because JSX is essentially just JavaScript. However, this also opens the door to the question: What will then render / use the JSX element? After all, a JSX element is just a function call. What function is called how is the outcome of this function then rendered?

You cannot compare Vue/Angular (frameworks) to JSX (syntax extension for JavaScript). As a fact you could write your templates in Vue or Angular using JSX.

I am aware it's possible to use jsx with vue. It's trivial and can come in handy. It's just js until templating. To me, these differences barely matter because I can do all that stuff on my own without any frameworks in the first place.

Both are fine. It doesn't have to be a war.

Differences are major. Vue's templating is a haphazard collection of elements that grew organically as the author(s) realised that more stuff needed to be added for templating to work. There's the Javascript-like DSL, there's Javascript expressions, there are HTML-like attributes, there are HTML-like attributes with magical extensions, there are...

JSX is trivially converted to a Javascript function call which immediately explains everything about its capabilities and syntax.

Both template engines have to provide roughly the same be because the output is simple render functions that emit html. Sure, they are different but map to the same browser apis, so not that different.

I don't see how jsx is more trivial than html which is what cue templates are.

Vue templates are arguably much more removed from HTML than JSX (which doesn't map to HTML but to Javascript function calls).

This goes into more details: https://news.ycombinator.com/item?id=19199423

Have you looked at ECMAScript for XML (E4X) ?

I liked E4X a lot. It's really similar to JSX. Really too bad it was deprecated.

> I've been wondering recently if there could be a more generic JSX renderer that could be built into browser.

https://es.discourse.group/t/proposal-esx-as-core-js-feature...

When I read about object oriented anything, I can't stop that object is a poor fit for most things programming, mostly because encapsulation and inheritance.

Data and code should live separately.

OOP is the perfect fit for <10% of every codebase I've worked on. It is so good for that 10% that it encourages people to wonder if perhaps it should be applied everywhere else.

Many software engineers love consistency more than anything else, so when OOP works so well for that fraction, it looks "untidy" to have several different styles spread throughout. OOP apologists preach that it should be everywhere even if it doesn't make sense, so there's social pressure to force it all the places it's not needed.

For example: unit testing is almost impossibly hard with OOP. Encapsulation and OOP-flavored dependency injection add significant complexity when setting up a single function to unit test. You have to use extremely complex mocking libraries to test anything. On the other hand, pure static functions are trivial to test, just pass in the data and test the data coming back out. Yet OOP apologists still argue to this day that extremely difficult unit testing is worth it for the dubious benefit of having the whole codebase feel tidy.

Let's take the concept of interfaces in OOP as used for polymorphism. An interface is fantastic for swapping out multiple behaviors or strategies at runtime. Very handy. However, how many times in an average software project are they actually needed? A favorite trick I like to do with OOP codebases is count how many interfaces have more than one implementation (not counting unit tests). I recently helped a team with a project with ~4 million lines of C#. There were ~900 interfaces, and 6 of them had more than one implementation. The rest of the interfaces were just for unit test mocking. Not needed for polymorphism, just unit test cruft. Those 894 interfaces were mocked out only in unit tests. Each of their 10k unit tests was on average 60 lines of mocking logic. For the 6 places it was needed, a polymorphic interface was a great solution! The rest though, not needed at all, and if they'd reorganized the logic into pure static functions they could cut back most of those 60 line unit tests into 4-6 lines. Instead of 600,000 lines of unit test logic, they'd only have 60,000 lines. All that mocked out unit test logic was slowing them down considerably. Every tiny little change required fixing thousands of lines of brittle unit test logic.

This is just one dimension, but it's an important one. OOP is great in those few rare places it's needed, but the rest of the time it's a square peg in a round hole.

Great for all my cases where when my <cat> elements cleanly inherits from <animal>!

I could be misreading this, but it looks like this project is overriding the UA’s `querySelector` family of methods, which doesn’t quite sit right. I thought it was a best practice to level the built-in prototypes alone.

inherit* from

to leave* the built-in prototypes alone

Monkey-patching native DOM APIs is really how polyfills are made. This way, people are able to simulate an idea and have a more productive conversation around it. All with a view to having it succeeded by a native implementation.

Tag languages were a success because SGML. Once we past XML tag languages are not loved by many people. JSON, YAML, and a myriad of another languages are being teach and used today. Don’t get me wrong — I loved when the XML 1.0 spec was published but the broken promise that we would never need to write XML by hand was the cause of hate to tag languages. Object Orientation is hated these days by many people. Those are the challenges this kind of projects have ti overcome in order to be successful.

The comment-based data-binding syntax <?{ }?> proposed is not going to be PHP compatible.

Besides, I don't really want programming right in the HTML and never did. Your mind doesn't read text the same way it reads programming code; the HTML tags are enough. Put the code elsewhere.

PHP has supported a long tag syntax `<?php` since PHP 3 in order to be compatible with XML, and a short tag `<?` can be always turned off. As long as it doesn't conflict with `<?=` (which is now an always-available short tag syntax for `<?php echo`), `<?{ ... }?>` should be okay even for PHP.

To me, this is like designing a language with // as a division operator. You can do it, but it strongly signals that you're not interested in the relationship between your language and C. That's fine. But if you tell me this is a superset of C that uses // as a division operator, I assume you are not designing from a place of experience. That's what this says to me.

> But if you tell me this is a superset of C that uses // as a division operator, [...]

Just in case, you are referring to C89, right? (Such language can't be a superset of C99 or later.)

> That's what this says to me.

I haven't written any PHP for years, but I think `<?` was already heavily discouraged back when I was still doing PHP things. Any surviving PHP codebases should have a similar guideline (for example, [1] for WordPress).

[1] https://developer.wordpress.org/coding-standards/wordpress-c...

I remember it being discouraged 20 years ago.

Yep pretty much since it was released

The `<?` isn't the problem, it's the closing `}?>`. Processing instructions don't nest. They're also xml, not html, so jolly good luck getting WHATWG to put them into the HTML standard.

Are there websites built with this? I might expect it to be used for their own website, but currently webqit.io does not resolve.

Nice catch. But yes we're currently buying a Progressive Web App right now with OOHTML. I'm happy to share after we've made progress.

*building a Progressive Web App

There are some really interesting ideas here. I love how scoping works and is integrated with the other parts of the framework.

This is a great feedback and I'm sure that this conversation and some of the frustration around will help us get even better.

Sorry. There’s way too much complexity here. And too much shouting!

The namespace idea did seem interesting though.

This is a great feedback and I'm sure that this conversation and some of the frustration around will help us get even better.

Whenever I see OO[something] in the world of programming, I have that face my mother would be ashamed of.

I have jumped on and off of web development in the last 8 years. Everytime I jump back in there are changes.

I ended webdev around 2011 being pretty good with jquery, using ajax to load part of web pages. Did some cool stuff for its time.

Came back to webdev in 2014 using knockoutjs. Seemed like bloat but did not question decision outside my control. I did like the idea of changing a value and it automatically applied the change on screen.

Came back to webdev in 2018 using angular. This was my decision and only because "it was popular" so anyone could take over hte project. Felt like duplicating my work to be honest.

Now, its 2022 and back on web dev. React. npm. Seriously... WTF! One site was using npm and grunt JUST TO MINIFY FILES!! Again... WTF!

Maybe there is something good about this OOHtml and missing the point entirely. WOuld not be suprised using this requires over 1000 npm dependencies.

There's no reason why you can't still dev the "old" way.

It'd be nice to actually have a nice clean, fast site for once that doesn't present you with a load of spinners or other nonsense while the content actually loads. Before your face gets DDOSed with adverts.

The modern web is a disgrace. I sometimes wonder if some devs actualy use the sites they create.

> There's no reason why you can't still dev the "old" way.

Absolutely. It's just when you jump back in the webdev world and you see changes you end up learning them to keep yourself relevant.

As the years have passed, since starting with knockoutjs (for me) the back of my mind was slowly accepting the "old ways" are the best way to simplify and solve the actual problem.

I was slowly moving back to using jQuery.. and, in the last year, have been moving over to htmx.

Apart from some things, it's quite damning that a single person came up with better suggestions than the entire W3C/WHATWG. Namespacing; scoping; HTML Imports with lazy loading, inheritance and contexts...

The WHATWG was founded as a response to the push from the W3C to try and push everything to XHTML. HTML can never be improved, that belief is at the heart of the WHATWG, even if they don't openly admit it. The best you can hope for is endless Javascript that occasionally have angle brackets sprinkled in.

Your feedback really stands out here dude. I'm hoping that the whole conversation here and some of the frustration will lead to something even better for OOHTML.

Are they trying to reinvent XSLT again?

With only 1582 npm dependencies.

The scoped IDs are a good idea, and I'd love to see that make its way into the HTML standard. Not having to generate unique IDs to attach labels to is nice. The rest of this looks like it's trying to appropriate Vue or Angular's template languages, which ought to stay in Vue and Angular where they belong.

Feels good to know. It really already saves the day for me.

If I get you correctly, is it that the other features like scoped styles and scripts, or html imports, don't look as good?

For data binding, I can see peoples frustration: syntax! And that's to say we've got to have more extensive conversations around here.

Looks like author put in some serious time into this project. It’s a shame the last update was 10 months ago. Linked website does not resolve for me either.

I don’t know if I would use this for any serious project. Maybe a hobby project

Author here. Looks like you missed something about the last update thing. I do actively work on it and ever poised to incorporate feedback.

Don't hesitate to open an issue on project repo when you do use it on a hobby project.

Ohh I only looked at releases. Commits show a much diff story. Good luck!

Reminds me of Vue. I guess this would be the ”buildless” version of it, but with bizarre syntax.

I’m open for new ideas though, I might give this a try in a small project.

As if HTML wasn't bad enough.

LOL

Reply on news.ycombinator.com