[norswap]

Frontend frameworks really do make things simpler once you go beyond small applications though. Automatically re-rendering when the data/model changes is the right thing to do.

We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.

[taeric]

I think there are assumptions here that are not shared?

First, there is an implication that the HTTP model is benign in the complications that we see in web applications. I don't think it would take a lot of arguments to bust this? Trying to hide it, also leads to several problems of its own.

Second, that the rest of the abstractions in a browser are benign in the complications most people complain about. The DOM, CORS, general document structure, CSS(!), and all of the extra APIs that browsers have added through the years are building on some rather awkward layers. I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world.

Now. I think an area we would have solid agreement on, is that I don't necessarily think we had better options along the way?

Bringing this back to frameworks, though, tooling is tough to ignore. The tooling that people used to have in easy application creation is tough to scoff at. I think it is safe to say that Dreamweaver was also not that bad, looking back. We had some odd purity tests on whether or not it should use tables for layout. Hard to really keep that complaint top of mind when I look at the absurd amount of markup that is in so many sites, nowadays.

[bobthepanda]

tables with layout wasn't really an issue of purity, but they were another layer of the cruft you described where we were abusing things not built to actually do that.

grid and flexbox are probably closer to actually being a one-stop easy-to-use paradigm with less nasty edge cases than tables, but all the table code stuff is still there if you really want to do it.

---

> I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world.

I actually think this is orthogonal. The power of frameworks like React is that nobody wants to write the same app five times (windows/mac/linux/ios/android) using sometimes wildly different native coding paradigms, and coordinating feature development across native platforms is like herding cats.

[taeric]

You can really only hang a claim on "abusing things not build to actually do that" on the same peg that "purity" hangs on, though?

I mostly agree with the point that this is orthogonal to frameworks. I'm just putting that in here for why people disagree with many common web frameworks. A lot of the complaints that many of us have, are ultimately rooted in what they are building on top of. CSS, in particular, is remarkably ill suited for interface design.

[bobthepanda]

Yeah, but it's the same thing as the "built on top of awkward layers" problem that you describe as a problem. it either is or isn't a problem, and then today you can still write it if you want.

People were doing things like making rounded buttons using tables, using things self-described as "clever hacks", and they mostly stopped working because as things like new viewport dimensions showed up you needed to paper over that too.

at least from what i've seen, the other strength of CSS is that it gets used for literally everything and so it's possible to build most conceivable layouts. A lot of the other layout frameworks either just use CSS, or you might run into edge cases because of the sheer amount of things in CSS that may not be well supported elsewhere or do not have a clear parallel.

[taeric]

CSS is easy to hate on, if only because of how much easier form builders were with VBA and such. Flash was also amazing, for content creation.

But I don't want to belabor examples. Fitting everything to the DOM is probably a worse part of the problem. Especially with how people insist on trying to rube Goldberg the layout on the regular behavior, which is clearly for a much more linear document. (Incidentally, no complaints on it to represent a document...)

Then you try to make things stateless for the HTTP nature. As well as largely pretending that the URLs are file system paths.

Both of those land you with frameworks on the frontend that are easy to complain about. We then add to the pain by trying to use the same framework for native.

[lmm]

We always had better options than CSS. The whole industry went in the wrong direction for years. But React is the opposite of that, it's someone finally bringing some sanity to the web.

[taeric]

I never hated css. I would struggle to really defend it, though. And looking back, I cannot understand how we wound up here.

[EternalFury]

You must have found a way to add more components, actions, properties, etc. automatically when your data models change. Otherwise, you are changing your UI every time those change. Except that now you have to maintain DTOs, models, actions, APIs, schemas, etc. in many places and across many teams.

Sorry, I have been around the block so many times, there’s now a moat around the block.