71–80 of 318 posts
1) Nested selectors.
2) :has(...).
3) :is(...), before you had to write :not(:not(...)).
4) :where(...), similar to :is(...), but the selector weight inside :where becomes 0. Useful when you need deep/complex selectors without increasing the selector weight.
Earlier quoted context omitted.
Those are all stateless MVC over HTTP, which is a very different architecture from stateful MVC for long-lived UI. The latter was invented for Smalltalk by Trygve Reenskaug, and is far more relevant to front-end web. Stateful MVC uses Publisher/Subscriber (or Observer) to keep Views and Controllers up-to-date with changing Models over time, which is irrelevant for stateless MVC over HTTP. Plus, in stateful MVC the Vi…
Whether application state is short-lived (e.g., request/response CRUD) or long-lived (e.g., an in-memory interactive UI) is orthogonal to MVC. MVC is a structural separation of responsibilities between model, view, and control logic. The duration of state affects implementation strategy, not the applicability of the pattern itself.
Yes, but the “MVC” pattern used by various back-end web frameworks that borrowed the term a while back actually has very little to do with the original MVC of the Reenskaug era.
The original concept of MVC is based on a triangle of three modules with quite specific responsibilities and relationships. The closest equivalent on the back-end of a web application might be having a data model persisted via a database or similar, and then a web server providing a set of HTTP GET endpoints allowing queries of that model state (perhaps including some sort of WebSocket or Server-Sent Event provision to observe any changes) and a separate set of HTTP POST/PUT/PATCH endpoints allowing updates of the model state. Then on the back end, your “view” code handles any query requests, including monitoring the model state for changes and notifying any observers via WS/SSE, while your “controller” code handles any mutation requests. And then on the front end, you render your page content based on the back-end view endpoints, subscribe for notifications of changes that cause you to update your rendering, and any user interactions get sent to the back-end controller endpoints.
In practice, I don’t recall ever seeing an “MVC” back-end framework used anything like that. Instead, they typically have a “controller” in front of the “model” and have it manage all incoming HTTP requests, with “view” referring to the front-end code. This is fundamentally a tiered, linear relationship and it allocates responsibilities quite differently to the original, triangular MVC.
I'm confused, many of these examples state that they don't work in my browser (Firefox) - but the live demo works fine? Are the demos poly-filled?
Earlier quoted context omitted.
Is staying in one file supposed to be difficult or something?
this is grey text from tailwindcss.com, I wouldn't call it easy and readable. Because Tailwind is so low-level, it never encourages you to design the same site twice. Some of your favorite sites are built with Tailwind, and you probably had no idea.
CSS is the only thing from browsers we actually need. The rest can be done in a terminal. Contemporary terminals could even render the UI with way less memory. The browser is a nightmare because it wasn’t architected to run applications.
> The browser ... wasn’t architected to run applications. Could you explain this? What prevents the browser from running applications? How should it have been architected otherwise if running applications was the goal?
Earlier quoted context omitted.
> The browser ... wasn’t architected to run applications. Could you explain this? What prevents the browser from running applications? How should it have been architected otherwise if running applications was the goal?
I think the idea here is that the DOM was designed as a model for document presentation, not for GUI layout.
And 99% of what people here consider "web applications" are just documents meant to be read as documents that have any javascript in them at all.
This whole "document vs app" dichotomy is mostly a fantasy.
My top list of recent CSS improvements: 1) Nested selectors. 2) :has(...). 3) :is(...), before you had to write :not(:not(...)). 4) :where(...), similar to :is(...), but the selector weight inside :where becomes 0. Useful when you need deep/complex selectors without increasing the selector weight.
CSS in 2025: Let's write html inlined styles as if it was 2005 and separation of formatting/representation was never invented. I talk of tailwind, of course.
The deadest horse in web development is the myth of “separation of concerns”
I disagree. And that makes me the loser here
Earlier quoted context omitted.
> React/JSX now confuses presentation and business logic React was originally designed to be the "V in MVC". You can still use it that way. React becomes very simple when you only use it as the V in MVC.
What are the M and the C, and how do they talk to the V in this case?
The separation is already there
People have just failed to understand it
This looks generally good but sadly also stylistically is similar to the default "modern" output of Claude Code. Just a thought.