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

111–120 of 168 posts

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

#111

Post by bryanrasmussen »

cluckindan wrote: post #52
bryanrasmussen wrote: post #40

Earlier quoted context omitted.

>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI the problem is that the typical modern web page is considered as a combination of immediate-mode and retained-mode. therefore, as it is wasteful to update all the page when only a few components on the page change, people want to only update parts of the page immediately when changes happen. furthermore the typical…

Which part of a web page is immediate mode, exactly? Maybe if you clear it on every frame.

I was just responding to the usage that the parent commenter had which was

>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI

which I interpreted as the only possible meaning, in relation to React, being UI components that must rerender as close to immediately as possible vs. UI components that do not need immediate rerendering when the underlying data has changed.

I realize that is not a particularly correct use of the phrases, but then that is what happens when you use a concept from one type of development metaphorically in another type of development, memetic slippage as it were.

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

#112

Post by pier25 »

olivermuty wrote: post #109
pier25 wrote: post #104

Earlier quoted context omitted.

> I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity I've always maintained that no reactivity is a much simpler mental model. Mithril and Imba do this with better than good enough performance. I think Remix 3 will be following this approach too.

Is this a satire thing or will it really be remix3? Didnt they just rebrand to react router FROM remix??

No, I'm serious.

The previous Remix was rebranded into React Router. Remix 3 will not use React and will apparently not use reactivity either.

https://remix.run/

There was a presentation last year:

https://www.youtube.com/watch?v=iZl0IKj0HHc

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

#114

Post by tmanderson »

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.…

lol this is why so many game UIs are awful (how much they lack in terms of OS accessibility, keyboard controls/shortcuts, etc)

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

#115

Post by _heimdall »

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.…

Kind of? Lit does add some of the types of patterns I'm talking about but they add a lot more as well. I always avoided it due to the heavy use of typescript decorators required to get a decent DX, the framework is pretty opinionated on your build system in my experience.

I also didn't often see Lit being used in a way that stuck to the idea that the DOM should be your state. That could very well be because most web devs are coming to it with a background in react or similar, but when I did see Lit used it often involved a heavy use of in-memory state tracked inside of components and never making it into the DOM.

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

#116

Post by _heimdall »

spankalee wrote: post #99
_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…

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.

I'm sure you could find examples to prove me wrong here so I'm definitely not saying this is a hard line, but I've always found that if app state is too complex to represent in the UI or isn't needed in the UI at all, that's state that belongs on the back end rather than the frontend.

My usual go-to rule is that business logic belongs where the state lives - almost always on the back end for state of any real complexity.

With true web apps like Figma I consider those entirely different use cases. They're really building what amounts to a native app that leverage the web as a distribution platform, it has nothing to do with HTML at all really.

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

#117

Post by AlienRobot »

nogridbag wrote: post #101
AlienRobot wrote: post #60

Earlier quoted context omitted.

In my view, the problem isn't specifically reactivity but the fact that reactivity isn't actually native of the UI toolkit. Instead of HTML, think about GTK or Swing. To add React-style "reactivity" to it, instead of just making a dialog to change the "title" of a document and committing the change when you press OK, you'd need a top-level "App" class that holds all the state, a class for state properties with IDs ac…

I believe every UI developer that has used frameworks like Swing has reached a point where specific user interfaces, even those that look trivial, become too complex primarily due to things like event handlers. Trying to figure out a simple thing like why a radio box is enabled and is marked dirty may require long debugging sessions where one event handler for component A triggers another event handler for component…

That's true. Events are the WORST thing about GUI programming. They're so convenient and so undebuggable it almost feels like a trap.

Ironically, in most cases events are only used by one object, but you always want to consider the possibility that two objects will want to observe the same event, so now you need an entire event dispatching class, and then you'll want observable properties, and the nail on the coffin is going to be observable lists. When you reach that point, one event triggers another, which changes a property, triggering another event, and so on and so on. You are 5 layers deep into event callbacks. The call tree just has the same "callCallbacks()" method over and over again.

Bugs start happening because of the order in which callbacks are called becomes important, so now you need a way to give some callbacks priority over others, or make them happen after all normal callbacks were called. One callback destroys an object which has callback on the event that destroyed it, so you're going to need a wrapper around your callbacks that gets notified when callback's object is destroyed to change its reference to null in order to avoid executing code on the destroyed object if this happens while iterating the callbacks in the event dispatcher. Sometimes calling callbacks in wrong order is a performance hit, when it doesn't just get stuck into an infinite loop and you run out of stack.

I wonder if there is GUI programming paradigm that solves all of this or that you can call the "best" one. Maybe it's reactivity, maybe not. Who knows.

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

#118

Post by potsandpans »

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.…

> I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forwar

I can't really think of a statement that resonates with me less.

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

#119

Post by bikeshaving »

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’ve written about how Svelte, Vue, and Solid are all reactive and share common pitfalls due to their reactive solutions. My theory is that they all cause worse bugs than they prevent.

https://crank.js.org/blog/why-be-reactive/

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

#120

Post by tkzed49 »

yde_java wrote: post #32
egeozcan wrote: post #6

IMHO, you shouldn't make "hate" part of your tagline. Maybe focus on a use-case? Something like, "No-build, no-NPM, SSR-first JavaScript framework specializing in Time-to-interactive" - maybe?

Why self-censoring for using "hate" when it gets the message across quickly? Everyone understands that we use "hate" and "love" with huge levels of nuances. I personally said today to a colleague "I hate working from home" but it's clear that I'm not a racist against people who "love" remote work. We do work with a very lax work-from-philosophy.

from my perspective--I have to use React, Lit, and all kinds of other creative solutions at my day job--I'm going to immediately devalue someone's argument if it starts with "I hate React".

React is not popular simply because engineers hate themselves or enjoy pain. There are problems it solves, and problems it creates. Explain what problems your solution solves, and feel free to dunk on React while you're at it, but write a tagline like this and I'm not gonna take you seriously.

Post reply on HN