Qite.js – Frontend framework for people who hate React and love HTML(qitejs.qount25.dev) |
Qite.js – Frontend framework for people who hate React and love HTML(qitejs.qount25.dev) |
I'll just stick with a $5 vps with lamp and jjquery
Then some bunch of geniuses decided it would be awesome to put everything together in the name of components. Today, you open facebook, the creators of React - normal drop-down with just a list of barely 5-6 items is a fucking component that makes 10 different requests. I would even argue this unnecessary forced interactivity is what perhaps annoyed users the most as everything always has to "load" with a spinner to the point of the platform being unusable.
Same goes for instagram. It's not just that, React is a hot ball of mess. It's not opinionated, so anyone can use anything to do anything. This means if you work with multiple teams, each one uses their own code organisation, state management library and general coding paradigm. Eventually the engineers leave and the new guy decides to do things his own way. I've honestly never seen a company with a great product run over React. Everything always is being re-written, migrated every 3 weeks or straight up is buggy or doesn't work.
React is the worst thing to happen to the Javascript ecosystem. The idea is good, but the execution is just piss poor. I mean look at Vue and Svelte, they managed to do it right.
> Today, you open facebook, the creators of React - normal drop-down with just a list of barely 5-6 items is a fucking component that makes 10 different requests. I would even argue this unnecessary forced interactivity is what perhaps annoyed users the most as everything always has to "load" with a spinner to the point of the platform being unusable.
That's a design decision, though. Sure, your point is basically that React is not opinionated enough and allows you to do anything. But in the same way you could criticize JavaScript or Python because they allow you to do "anything" and some people write shitty code.
As a previously big React dev I agree 100%. If anyone feels this way please spend some time on doing Sveltekit project (e.g. rewrite a personal React project).
It's a breath of fresh air.
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.
This bottleneck could be alleviated if browsers shipped native dom morphing or even some kind of native vdom but we're stuck with userland js solutions.
To an extent this is how react works internally. There is a function which takes state and produces UI. In order not to have to re-render the whole UI if only a small part of the state changes, there is a diffing algorithm and "virtual dom" that is diffed against. Maybe it doesn't work exactly like that anymore but that's the gist of it.
I can't really think of a statement that resonates with me less.
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.
This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.
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 convention, usually declaratively.
If I had to do it all again though, DOM would still be the source of truth and any custom components in JS would always be working with DOM directly. Custom elements are a great fit for that approach if you stick to using them for basic lifecycle hooks, events, and attribute getters/setters.
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.
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.
Meanwhile, those of us that were building web apps with JQuery and other tools prior to React know just how painful "web development without reactivity" actually was.
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.
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.
And then said developer does what they think feels right: "I have my state and I simply want all the fields to reflect my state". So they try and rewrite the component into some sort of mini immediate-mode style component. All of the event handlers get wired up a single "layoutComponent" method that tries to call all the UI component setters based on the current state with all the problems you alluded to. I know I've done this type of things numerous times before going back all the way to my first internship, well before React was even a thing.
I think modern frameworks solve the reactivity issue this well enough, that it really doesn't matter if the underlying framework is not natively reactive. I will say though that I've primarily used Vue.js where most state is relatively local and we don't try to re-render the world on every input. I think part of the problem with modern dev is likely that React has become the default instead of a simpler framework like Vue.
UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)
Is there really a difference? Angular uses RxJS in a pub-sub scheme. (At least it did when I last used it.)
But yes, React is a mess. JSX was the original sin of mixing HTML inside JS. And those bundlers and tree-shaking at build time? Ugh.
What if you had this instead: https://community.qbix.com/t/loading-at-runtime-the-web-fram...
That of course led to developers building much more complex UIs. Which offset the gains from reactivity. Hence the mess and we're basically where we started.
Maybe focus on a use-case? Something like, "No-build, no-NPM, SSR-first JavaScript framework specializing in Time-to-interactive" - maybe?
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.
Anyway, interesting approach for up to medium pages (not apps!). Totally not replacement for react.
There's nothing wrong with either of these if used correctly. Thus "hate" is a rather shallow argument.
In order to do the JS that I have to do with an SSR app I went with Alpine.js. It reduces the JS I have to write and that fits my SSR approach.
It feels a bit like a modern jQuery to be honest: you cannot build whole apps with it, but just to sprinkle on top of an SSR it does really well.
[0]: https://github.com/statelyai/xstate?tab=readme-ov-file#super...
You can build similar things with Alpine/htmx, but once things grow, you end up reinventing structure. Qite just bakes that in from the start.
Most of the time, it's enough to build in a simple, clean, and lightweight way. Just like in the old days. Your server's resources will also thank you. Furthermore, the simplicity of web pages is also rewarded by search engines.
If it were up to me, I'd build sites exclusively in .md format :)
Oh my. If it works just like Ajax from >10-15 years ago, then I will be super happy. :D
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...
It's not a great language for it.
total: (c,v) => v > 1000
See also: HTMX and possibly even jQuery
https://code.qount25.dev/qite/qite-js/src/branch/master/src/...
https://code.qount25.dev/qite/qite-js/src/branch/master/test...
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.
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.
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.
Also, things like unidrectional data flow are generally considered normal now, but back in that era it was rare. Two-way binding was much more popular, with constant bugs as the app grew. Around 2013 or so I was trying to switch a new page we were building to a very simple form of unidirectional data flow to deal with constant issues (ours issues were mostly losing state, we were all ad-hoc and not using two-way binding) and the other devs just did not at all understand it, constantly sidestepping it without even thinking because jquery made it so easy to touch everything.
Model knows nothing about controller or views, so they're independently testable. Models and views are composed of a tree of entities (model) and components (views). Controller is the glue. Also, API calls are done by the controller.
So it is more of an Entity-Boundary-Control pattern.
I'm sure you could find counterexamples so that isn't a hard line I'm proposing, but it is my opinion that nearly all website or web app built today over uses client state.
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.
The previous Remix was rebranded into React Router. Remix 3 will not use React and will apparently not use reactivity either.
There was a presentation last year:
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.
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.
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.
Our decorators aren't required - you can use the static properties block. If you think the DX is better with decorators... that's why we support them!
And we support TypeScript's "experimental" decorators and standard TC39 decorators, which are supported in TypeScript, Babel, esbuild, and recently SWC and probably more.
Regarding state: Lit makes it easier to write web components. How you architect those web components and where they store their state is up to you. You can stick to attributes and DOM if that's what you want. Some component sets out there make heavy use of data-only elements: something of a DSL in the DOM, like XML.
It just turns out that most developer and most apps have an easier time of presenting state in JS, since JS has much richer facilities for that.
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 keypress, your component must be uncontrolled, store its state internally (in the DOM) and update it to a parent store e.g. when the user stops typing (debounced) or moves focus out of the field. These are not trivial things either, and as a result, components get more boilerplate to handle the UX complexity. And of course, there are now UX pitfalls.
Indeed, these are reasons why reactive patterns exist. Now, if they just managed to abstract away the tedium.
Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.
"just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial cases.)
Not dismissing it, mind, that inherent guidance is not something that is easy to achieve and I much prefer working with the likes of React than without.
And yet, plenty of people all around the world are able to get traction for their products without mentioning the hate of another.
> I didn't build Qite because I hate React,
I get that React being the most popular front-end framework means it's going to get it's fair share of criticism, but it's become pathetic the degree to which people have made hating it their personality. Even going so far as to market their own frameworks in terms of their personal feelings towards it.
Nobody is saying humans aren't emotional, you're trying to deflect from being unable to disconnect your emotions from another library.
It's React Derangement Syndrome.
I really think autism has a lot to do with the necessity of large frameworks. They provide a vanity layer to hide behind for people who cannot introspect and cannot measure.
You're personal opinion is irrelevant to the point I'm making. And that's exactly my point. For whatever reason people can't stop talking about their dislike for it. Going so far as to literally have it be your framework's tagline.
You can't even read a comment about Svelte without their need to bring React up.
> I really think autism has a lot to do with the necessity of large framework
No it's because the needs of the web have dramatically changed in the last 20 years. That's why people reach for things to help them build front-end apps. It's almost comical how different it is.