[lloydatkinson]

I was going to say the same but I think you said it much more clearly than I would have. I see this meme a lot. "I hate X, don't learn X, Y is better because Y is fundamental to Z".

I have not once seen these same people suggesting "Don't learn the toolkit/framework/control library for your OS, instead use raw WinAPI or X System calls and push raw pixels to build applications".

Yet, they push for the same with HTML. How you arrive at the HTML is up to you. By saying, for example, don't learn React, you might as well be saying "don't do anything productively, do everything in the least maintainable and the most convoluted and unnecessary way possible, your customers and team will like that surely".

[zelphirkalt]

The difference is, that JS, CSD and HTML are evolving. They now offer way more than they used to. We can do so much with HTML 5 and CSS 3 already. The argument is to not use React or similar, when a simpler way using standard conform means is available.

It is hard to take a comment serious which compares not using React to not being able to do anything productively. It looks like a very junior React-only dev comment.

[lloydatkinson]

> The argument is to not use React or similar, when a simpler way using standard conform means is available.

Please show me which part of any current or future proposals show a declarative UI + state + input + template binding mechanism which React or even something like handlebars provide.

If you're going to mention three or four different API's and explaining combining them together, then you've just reinvented a worse X framework.

You can't just dismiss everything as "well you can do X with the native platform" which is literally what I'd already made an analogy for.

> It looks like a very junior React-only dev comment.

Personal attacks, nice. If you believe I'm a junior for my comments then you are free to believe what you want, it does not change reality.

[zelphirkalt]

You can buzzword all day long, but that doesn't make the typical React component any more declarative than the next script. Components reyling on internal state, querying that state and then munging some JS code into some HTML-like template and mutating the state again, when a user interaction happens -- That's hardly a declarative UI. It also does not become more declarative due to using an angle bracket notation for components.

One can look at some Prolog code to get an actual idea about what declarative means. In React you are not writing down constraints and logic rules, according to which React automatically figures things out. You are not working with relations, which need to be kept true. React is far from a configuration only kind of framework.

To claim something like one cannot be productive without using React or similar framework is really a silly thing to claim. Most websites do not even need to use any such framework, because in their nature, they are not interactive. They show information and that is it. Then there is a set of websites, which has here and there some small interactive widget, which one could argue to use a framework for, in parts, not for the whole friggin website. This still allows for people, who merely want to retrieve the information and leave without interacting. The third and smallest category is then the set of websites, which actually need interactivity and state in the frontend everywhere, where such a framework can be justified.

[dmitriid]

> We can do so much with HTML 5 and CSS 3 already. The argument is to not use React or similar, when a simpler way using standard conform means is available.

There are no simple ways to build UIs available in HTML5 and CSS3.

It has neither state handling, nor reactivity, nor any APIs that don't make you tear you hair out (or build another lib/framework).

It's a horrendously bad half-low-level half-high-level API with hundreds of one-off solutions and special cases that form no coherent whole.

You still can't reliably animate adding to and deleting items from a list without hacks because even if you so much as look at DOM, it will re-layout and re-draw the entire document.

It still has no collection of well-specified built-in controls beyond a few primitive ones. https://open-ui.org/ is about twenty years too late.

But sure, you can finally put items in grids now. I guess that's nice. But when you need a dialog element you need copious amounts of hacky Javascript to make it properly accessible. Go figure.

[zelphirkalt]

People have built "UIs" on websites for decades, without the current flavor of SPA web frameworks. It is actually very easy to put things like a navigation and forms and such things on a website. Most websites do not need more than that. They merely show some information. Maybe you can register through a form or login through a form to see some more information. Not every website needs to be a SPA. The use-case you are apparently relating to, the one of websites really needing a more complex desktop-like UI, is merely a small percentage of websites. If you find yourself building a SPA on every second project, then you are most likely just following hype.

If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web. Work on your assumptions of how things must be done and some problems will disappear without ever having to write gnarly code.

Aside from that, writing a dialog is really not that difficult. I've done that before and I didn't need any framework to do it. Just don't rely on its modality for security, obviously, because one does not rely on frontend code for security anyway. Element zapper will make short work out of any dialog, that tries to block the stuff underneath it.

Ultimately the browser is not the desktop. It has a different use-case. Too many people do not understand this and try to shoehorn things into being "like on the desktop". Write desktop programs, if you want the desktop (not Electron shit ...). Write websites, if you want the web and the browser. Both have their own quirks and complications. Trying to force one into the other will only lead to more complications. Good design pays attention to the medium.

[dmitriid]

> It is actually very easy to put things like a navigation and forms and such things on a website.

That's about 1% of 1% of what people want to build.

> Most websites do not need more than that.

That we can agree on

> If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web.

dialog is literally a web standard in the web platform you so ardently advocate for. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

> Aside from that, writing a dialog is really not that difficult.

Tell me you've never built a proper accessible dialog without telling you've never built one.

> Too many people do not understand this and try to shoehorn things into being "like on the desktop".

I can empathise with this sentiment because I've expressed it myself many times. However, that ship has sailed and the platform has not adjusted in the least.