Hacker News Reader

Comment by brlewis | Hacker News Reader

From the article,

   <Card>
     <Avatar />
   </Card>

This is talking declaratively at a high level about the kind of interface to render. Lots of component frameworks look like this example. Thinking "how sad it is that we haven't progressed beyond the state of gluing together low level divs and spans" sounds like a preconceived idea rather than a response to this article.

By the way, I come from mid-80's BASIC on 8-bit home computers. You get off my lawn.

View on HN

Not OP but at the end of the day, custom components like this still have to be rendered down to primitive HTML and CSS, and are plagued by all sorts of browser-specific issues and conventions that make higher level abstraction way more difficult than they need to be.

As a random example, HTML specifies that clicking a `<button>` inside a `<form>` automatically submits a POST request to the current URL. We can't change that because it will break a lot of webpages that rely on this default behavior, so now every component system built on top of <form> or <button> needs to prevent the default browser behavior, and there are so many more examples of things like this.

You can make the calling interface look like that (that’s definitely good), but the implementations in the example were still very document centric inline html. It all just seems like it’s a lot more low level work than it ought to be. I feel much the same way when using a (bad) orm: there’s just a vague feeling that the solution isn’t quite an appropriate fit to the problem. Maybe this gets better when you’re composing from a library of core components, I don’t know. Again, I’m very much an outsider here.

I’m not saying that old GUI component frameworks are vastly superior either. I just imagined that we’d have progressed well past the kind of approach the article is mentioning.

It’s a side rant, but I don’t think it’s entirely without merit.

Reply on news.ycombinator.com