Why use JS at all for SSR?
It's not a great language for it.
Qite.js – Frontend framework for people who hate React and love HTML
51–60 of 168 posts
Re: Qite.js – Frontend framework for people who hate React and love HTML
#52Earlier 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…
>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.
Re: Qite.js – Frontend framework for people who hate React and love HTML
#53I'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.…
Isn't that what reactive ui trying to achieve? To only have a render function and have ui state sync according to the data?
Re: Qite.js – Frontend framework for people who hate React and love HTML
#54Earlier quoted context omitted.
Just because computer got much faster doesn’t mean it’s a good idea to make wasteful rerenderings of things that didn’t change.
No but calculation becoming more efficient than recall might not make it a good idea to make wasteful fetches.
Nothing id more effective than doing nothing.
Re: Qite.js – Frontend framework for people who hate React and love HTML
#55Earlier quoted context omitted.
> The master Render() function draws all of the graphics according to the current state What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source". React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves. T…
>components should be simple and not store data in themselves. That is a ”controlled component” model which is bad for interactivity, especially text inputs. If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues. Without a rerender, it must now use a reactive binding to update the field value. If you don’t want to update state on every keypr…
[deleted]
Re: Qite.js – Frontend framework for people who hate React and love HTML
#56Why have ` ` instead of using a ` ` element?
this! it is absolutely nuts having everything in div/span elements and then assigning data/class attributes so they could behave like form or any other interactable element..
Re: Qite.js – Frontend framework for people who hate React and love HTML
#57Why use JS at all for SSR? It's not a great language for it.
Where does the article say anything about js for ssr?
Re: Qite.js – Frontend framework for people who hate React and love HTML
#58Have tried multiple approaches. Sevelte. HTMX. Everything in between.
And came to conclusion that after certain complexity of UI - React kind of components are unavoidable if you want to be able to reason about your code.
Think of Shopify admin panel with product variations each variation having different pictures and what not.
Not saying not doable in plain JS.
But then Chrome can be written in NASM too, C++ is just...
Re: Qite.js – Frontend framework for people who hate React and love HTML
#59Earlier quoted context omitted.
Why is that a bad argument? The author strongly dislikes React and so wrote an alternative that is radically more simple, which sounds like a perfectly sane argument.
Does the author dislike react? How about preact? Or maybe simply jsx? Or nextjs? There's nothing wrong with either of these if used correctly. Thus "hate" is a rather shallow argument.
I will safely assume the author dislikes all that overly complex bloat bullshit and leave it at that. I am not going to autism this, as in invent a bunch of straw men to attack because there is some singular obsession silo of react-like fixations.
Re: Qite.js – Frontend framework for people who hate React and love HTML
#60I'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…
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 accessible at runtime which probably would be a variant (accepts any primitive type), a binding class to bind the toolkit's textbox to the App's state "title" property (because you'll probably want to bind a lot of textboxes, so it's easier to separate the code into classes), and then every time the user types something into the textbox, instead of using the toolkit's code that is already written for you which updates the textbox' state directly, you block the state change in an event handler, send the state change to the App class, let the App class figure out the differences between the current state and the new state, and then it calls some callback in the binding class that is responsible for actually changing the text in the textbox to reflect the new App state. You'll probably run into a ton of issues (selections resetting, assistive technologies bugging, etc.) that you'll have to deal with externally somehow. All just to make it do exactly the same thing it would have done anyway.
It's like you have a fully autonomous robot and you want to add marionette strings to make it move.