2 ms·

From the article, <Card> <Avatar /> </Card> This is talking declaratively at a high level about the kind of interface to render. Lots of component

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.

switchbak 3y ago
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.
jacobsimon 3y ago
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.

switchbak 3y ago

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.

jacobsimon 3y ago

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.