Comment by curtisblaine
7 hours ago
> Isn't html/css enough?
No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do you need a database? Aren't files enough? And so on.
Shadcn is a framework for developers who develop highly interactive web apps. If all you need is a static form that submits data to a web service, you probably don't need a framework (except when you need it - for example, selects are not yet fully styleable in all browsers).
Next objection usually is: do you need complex apps on the client? Can't they be reduced to a series of simple forms controlled by the server? Sometimes they can and sometimes they can't, but of course I will decide the shape, behaviour, complexity and look of the applications I build (or have others build for me), thank you very much.
That said, radio buttons have been styleable in all non-legacy browsers for at least 5-6 years, there's no excuse for rewriting them from scratch with svgs.
>If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough.
>Next objection usually is: do you need complex apps on the client?
It's not even an objection, it's a question I ask and almost never hear a coherent answer to. The vast majority of web applications I use every day (online banking, github, forums, social media, admin interfaces of various developer tools, etc.) don't really need to be dynamic and frontend-rich. I don't care if submitting a form refreshes the page. Funnily enough, full page refresh with a full round trip with "old school websites" is often faster than dynamic SPA interaction.
I don't care that when I click "delete", the item may not disappear from the screen immediately. I don't want to see some in-between state descriptions like "Deleting..." because I know it's a lie in a distributed, eventually consistent system. Just tell me the truth: the request has been sent. I can then refresh the page and see the new current state, whatever it is.
I really don't understand this desire to make websites behave like local apps while in reality they aren't.
> it's a question I ask and almost never hear a coherent answer to.
There are a lot of coherent answers though.
One is that responding with HTML encumbers the server with brittle UI over the wire when it could instead be a simpler API server that any client can talk to.
Returning data instead of UI from the server is a clean separation of concerns.
There's nothing incoherent about that.
That's the theory. In practice, if your UI is changing a lot, the data your UI needs is also changing a lot, meaning that your data API will either have a lot of churn or you'll allow a lot of flexibility in how untrusted clients can use it, which introduces it's own pile of issues.
Immediate feedback informs the visual language in order to convey meaning in a easier way to a larger public. You may know what an eventually consistent system is, but many users don't, and they want visual information abstracted to something they can understand. It's reassuring.
Also, not everything can be reduced to static forms. Charts with knobs, drag and drop interfaces, interactive diagrams are all useful visual aids that you would like to erase because... they don't conform with your naive views on how things should look like?
Most web apps are a combination of static pages, simple forms and highly interactive content though. That's what makes the choice so hard.
That’s why I use React, though. It’s much nicer (as a developer— not necessarily UX) to have a single paradigm and approach to building your app vs using one approach for the simple pages and a different approach for the handful of highly interactive pages. Inevitably, your simple pages get complex interactive edge cases and you wish you’d written those in React from the start, etc.
I know many will disagree with me and will point to livewire, etc as alternative approaches, and that’s valid. I’ve simply settled on React because it fits my mental model, I like functional programming, and I dislike that bifurcation problem.
No, you're right. Livewire, Phoenix LiveView and all the others are a couple levels removed from the browser and you have to suffer the whole indirection chain when something goes wrong. React is a good compromise - it still has indirection, but not so much, and it's much easier to use at scale than state managing and direct DOM manipulation.