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

31–40 of 168 posts

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

#31

Post by gr4vityWall »

yde_java wrote: post #26
tobyhinloopen wrote: post #23

Earlier quoted context omitted.

I use Preact without reactivity. That way we can have familiar components that look like React (including strong typing, Typescript / TSX), server-side rendering and still have explicit render calls using an MVC pattern.

How and when do your components update in such an architecture?

From what I can tell, they do full page reloads when visiting a different page, and use Preact for building UIs using components. Those components and pages then get rendered on the server as typical template engines.

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

#32

Post by yde_java »

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.

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

#34

Post by mpalmer »

applfanboysbgon wrote: post #30
mpalmer wrote: post #24

Earlier quoted context omitted.

[flagged]

Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo. [1] I loathe this term, by the wa…

[flagged]

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

#35

Post by Lerc »

croes wrote: post #22
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.…

UI is mostly static. Rendering everything at framerate per second is a huge waste of time and energy.

This was the case back in the days of the Amiga and 68000 Macs. Rendering everything every frame was impossible, the only way to make it work at all was to draw only what was absolutely necessary to depict changes.

Then computers got faster, much much faster. It became possible to redraw the whole UI from state every frame without it being a significant cost.

At the same time retained user interfaces managed to become more and more costly to do just about anything. I don't think for any particular reason other than computers were fast and they didn't need to do much better.

I find it really odd that there are user interfaces that take longer to rearrange their items than it takes for the same CPU to RayTrace a scene covering the same amount of screen area.

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

#37

Post by applfanboysbgon »

mpalmer wrote: post #34
applfanboysbgon wrote: post #30

Earlier quoted context omitted.

Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo. [1] I loathe this term, by the wa…

[flagged]

I guess I misinterpreted your comment? I do apologise if that's the case. I certainly didn't intend to "jump down your throat", I was asking you to explain your comment further because I don't understand what you're getting at.

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

#38

Post by [deleted] »

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

[deleted]

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

#40

Post by bryanrasmussen »

applfanboysbgon wrote: post #30
mpalmer wrote: post #24

Earlier quoted context omitted.

[flagged]

Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo. [1] I loathe this term, by the wa…

>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 modern web page only makes sense in the context of the modern web site, so some pages are almost everything on the page needs to update all the time, some pages are nothing here needs to update until the user does anything, some pages are nothing here needs to update at all, and other pages are just a couple components need to update all the time based on various things.

This context of what a web site is like is very much determined by the type of the site, where many e-commerce sites are affected by all sorts of data that occur outside of whatever page the user is on and need to update all sorts of different components on a page, many governmental sites are almost just static, with all sorts of variations in between.

Post reply on HN