Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qite.js – Frontend framework for people who hate React and love HTML

qitejs.qount25.dev

Post reply on HN
Print view View original

91–100 of 168 posts

Re: Qite.js – Frontend framework for people who hate React and love HTML

#91

Post by shimman »

joeyguerra wrote: post #72

There are people who hate react?

I've been working as a frontend dev for about 11 years. I've only ever used react for a majority of projects, also doing all kinds of work: porting angular projects into react, refactoring legacy react projects into modern react, building complex data visualizations for network topologies, and your basic CRUD stuff.

I dislike react because it's long overstayed its welcome. The vast majority of react projects are bloated messes and it truly feels like the react community is being steered by dev influencers that have very little experience working on projects (this includes the react maintainers themselves IMO).

There are way better libraries to write maintainable code in (svelte, solid, and even vue is better FFS). There are other mental frameworks that allow for good engineering practices as well like htmx or hotwire.

React is only here for the same reason that Java Spring is here, it was one of the early adopters that has too much momentum where leadership across companies are actively hostile to devs so there's no time to actually create good stuff but rather stamp out garbage so billionaires can be slightly more rich.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#92

Post by monarchwadia »

applfanboysbgon wrote: post #17
hliyan wrote: post #14

I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…

I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forward: the game has state. The master Render() function draws all of the graphics according to the current state, called at framerate times per second. Nothing in Render() can change the state of the program. The program can be run headlessly with Render() pre-processed out completely.…

Well, in React specifically, you're describing the Flux architecture, which I've implemented manually back in the day. Its modern-day successor is Redux, which does exactly what you describe, but we found that it introduced more complexity rather than remove it.

I don't know about the other UIs, but on the web, some things impinge on the model you (and Redux) are proposing.

One thing is: you, in the gamedev world, have the luxury of having a frame buffer to write to. You fully control what gets rendered. Unfortunately, React and its cousins all have to deal with the idiosyncracies of the legacy browser environment. You have CSS, which applies and cascades styles to elements and their children in often non-obvious ways, and is a monster to deal with on any given day.

In addition to CSS, you have multiple potential sources of state. Every HTML slider, dropdown, input field, accordion, radio button, checkbox has its own browser-native state. You have to control for that.

On top of all of this, the browser application is usually just a frontend client that has to interact with a backend server, with asynchronous calls that require wait-state and failure-state management.

One thing that's in common with all of the above problems is: they're localized. All of these things I'm describing are specific to the rendering layer and therefore the component layer; they are not related to central state. A central state trying to capture all of these problems will fail, because component state has to be wrangled locally near where the HTML is; CSS also is component-level; and the network states are often very closely related to each component. If we maintain a central "game state", the data complexity just proliferates endlessly for each instance of the component.

So, the default these days is to keep state very close to each component, including network state, and often business logic also gets sucked into the mix. I try to avoid putting business logic in components, but people do it all the time unfortunately. But it does add to the complexity.

In other words, there is -real- complexity here, stemming from the fact that the web was never built to be a distribution+execution layer for rich applications, but evolved to become exactly that. It's not just bad application architecture or bad decisions by React maintainers.

Maybe I'm wrong, since I'm not a game developer and don't see what you're seeing on your side.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#93

Post by pfraze »

hliyan wrote: post #14

I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…

Reactivity isn’t the problem. Reactivity is one of the few things that helps reduce the complexity of state management. GUI state is just a complex thing. Frontend development doesn’t get enough cred for how deeply difficult it is.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#94

Post by pfraze »

_heimdall wrote: post #29
hliyan wrote: post #14

I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…

I'd argue that it was all downhill after we moved away from using HTML as the state representation. Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync. Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and conve…

Wasn’t that the Lit framework? It was okay. Like a slightly more irritating version of React.

I recall the property passing model being a nasty abstraction breaker. HTML attributes are all strings, so if you wanted to pass objects or functions to children you had to do that via “props” instead of “attributes.”

I also recall the tag names of web components being a pain. Always need a dash, always need to be registered.

None of these problems broke it; they just made it irritating by comparison. There wasn’t really much upside either. No real performance gain or superior feature, and you got fewer features and a smaller ecosystem.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#97

Post by applfanboysbgon »

monarchwadia wrote: post #92
applfanboysbgon wrote: post #17

Earlier quoted context omitted.

I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forward: the game has state. The master Render() function draws all of the graphics according to the current state, called at framerate times per second. Nothing in Render() can change the state of the program. The program can be run headlessly with Render() pre-processed out completely.…

Well, in React specifically, you're describing the Flux architecture, which I've implemented manually back in the day. Its modern-day successor is Redux, which does exactly what you describe, but we found that it introduced more complexity rather than remove it. I don't know about the other UIs, but on the web, some things impinge on the model you (and Redux) are proposing. One thing is: you, in the gamedev world, ha…

I'm sympathetic to "it's the browser's fault", to some degree. I understand that the browser locks you into certain constraints, and I understand that I don't understand much about those constraints, because most of the extent of my experience with web development is using a canvas and a couple of fundamental APIs to render my games via WASM as web is one of my build targets (and I do know that approach is undesirable for regular web pages). I can see how there might be unavoidable complexity there.

What I still don't understand is why the browser is that way in the first place, and why all of the native, not-browser GUI frameworks that people use are also that way. People opt into using React Native, even! But the regular run-of-the-mill frameworks that are widely used for native applications are also annoyingly complex to work with, so much so that I've repurposed my engine for when I want to create native applications and have been working on building a desktop UI framework within it that follows the same model I use for games (albeit nowhere near production-grade, just covering "the cases I need").

> the browser application is usually just a frontend client that has to interact with a backend server

I will note that this is a constraint that is shared with gamedev. Most multiplayer and even many singleplayer games these days are server-based.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#98

Post by spankalee »

pfraze wrote: post #94
_heimdall wrote: post #29

Earlier quoted context omitted.

I'd argue that it was all downhill after we moved away from using HTML as the state representation. Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync. Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and conve…

Wasn’t that the Lit framework? It was okay. Like a slightly more irritating version of React. I recall the property passing model being a nasty abstraction breaker. HTML attributes are all strings, so if you wanted to pass objects or functions to children you had to do that via “props” instead of “attributes.” I also recall the tag names of web components being a pain. Always need a dash, always need to be registered…

The point of Lit is not to compete with React itself, but to build interoperable web components. If your app (Hi Beaker!) is only using one library/framework, and will only ever one one in eternity, then interoperability might not be a big concern. But if you're building components for multiple teams, mixing components from multiple teams, or ever deal with migrations, then interoperability might be hugely important.

Even so, Lit is widely used to build very complex apps (Beaker, as you know, Photoshop, Reddit, Home Assistant, Microsoft App Store, SpaceX things, ...).

Property bindings are just as ergonomic as attributes with the .foo= syntax, and tag name declaration has rarely come up as a big friction point, especially with the declarative @customElement() decorator. The rest is indeed like a faster less proprietary React in many ways.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#99

Post by spankalee »

_heimdall wrote: post #29
hliyan wrote: post #14

I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…

I'd argue that it was all downhill after we moved away from using HTML as the state representation. Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync. Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and conve…

HTML simply can't represent the complex state of real apps. Moving state to HTML actually means keeping the state on the server and not representing it very well on the client.

That's an ok choice in some cases, but the web clearly moved on from that to be able to have richer interaction, and in a lot of cases, much easier development.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#100

Post by pfraze »

spankalee wrote: post #98
pfraze wrote: post #94

Earlier quoted context omitted.

Wasn’t that the Lit framework? It was okay. Like a slightly more irritating version of React. I recall the property passing model being a nasty abstraction breaker. HTML attributes are all strings, so if you wanted to pass objects or functions to children you had to do that via “props” instead of “attributes.” I also recall the tag names of web components being a pain. Always need a dash, always need to be registered…

The point of Lit is not to compete with React itself, but to build interoperable web components. If your app (Hi Beaker!) is only using one library/framework, and will only ever one one in eternity, then interoperability might not be a big concern. But if you're building components for multiple teams, mixing components from multiple teams, or ever deal with migrations, then interoperability might be hugely important.…

Dont get me wrong, I'm a pretty big believer in interop, but in practice I've rarely run into a situation where I need to mix components from multiple frameworks. Especially because React is so dominant.
Post reply on HN