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

151–160 of 168 posts

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

#151

Post by spankalee »

_heimdall wrote: post #115
spankalee wrote: post #98

Earlier quoted context omitted.

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…

Lit is not opinionated about your build system You can write Lit components in plain JS, going back to ES2015.

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.

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

#152

Post by mexicocitinluez »

usrbinenv wrote: post #129
mexicocitinluez wrote: post #126

Earlier quoted context omitted.

But they're shilling a technical solution not an emotional one.

As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process. I didn't build Qite because I hate React, I built it because I knew exactly how I wanted things to work. But I do hate React and it's part of why I knew exactly how I wanted things to work.

> As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process

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.

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

#153

Post by threatofrain »

tobyhinloopen wrote: post #23
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 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.

Could you show an example?

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

#154

Post by _heimdall »

wonnage wrote: post #134
_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…

State in HTML is a horrible mistake. Now everything has to be constantly serialized/deserialized into strings.

If the state can't, or shouldn't, be serialized in the client I question whether that state belongs in the client at all.

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.

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

#155

Post by Izkata »

bryanrasmussen wrote: post #111
cluckindan wrote: post #52

Earlier quoted context omitted.

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

Wikipedia:

> In immediate mode, the scene (complete object model of the rendering primitives) is retained in the memory space of the client, instead of the graphics library. This implies that in an immediate mode application, the lists of graphical objects to be rendered are kept by the client and are not saved by the graphics library API. The application must re-issue all drawing commands required to describe the entire scene each time a new frame is required, regardless of actual changes.

React is simulating immediate mode by having the developer describe the full rendered result from the current data state. The developer / app code doesn't need to keep track of what changes need to be done to get the browser from its current state to the desired state, React does that for you.

Retained mode is where the developer / app does have to concern itself with the current browser state and issue the desired updates themselves, like how everything was done in the jquery era and earlier.

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

#156

Post by Izkata »

hungryhobbit wrote: post #146
ivanjermakov wrote: post #16

Earlier quoted context omitted.

I still believe immediate rendering is the only way for easy-to-reason-about UI building. And I believe this is why early React took off - a set of simple functions that take state and output page layout. Too bad DOM architecture is not compatible with direct immediate rendering. Shadow DOM or tree diffing shenanigans under the hood are needed.

Yes! I think there's a lot of armchair web developers in these comments who think they know better: they don't. 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.

Indeed.. Mostly-static pages with sprinkled-in interactivity were fine (like a table where you could sort the columns), but a full app? I dread having to touch the one page we have that uses Backbonejs+Mustachejs.

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.

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

#157

Post by codethief »

Jenk wrote: post #70
codethief wrote: post #66

Earlier quoted context omitted.

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

Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.

Isn't React pretty much a model-view-viewmodel architecture?

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

#158

Post by Jenk »

codethief wrote: post #157
Jenk wrote: post #70

Earlier quoted context omitted.

Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.

Isn't React pretty much a model-view-viewmodel architecture?

Yes but it is easy to abuse/misuse IME, in that I think it requires one to maintain your own sense of discipline for the principle separation rather than the library/framework guide you into it. The threshold between UI and state management is comically easy to confuse.

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.

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

#160

Post by codethief »

neya wrote: post #46
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…

Absolutely. Look at facebook today. Back in 2010, everything had just the right amount of interactivity. Because, separation of concerns existed at the language level - HTML for structure and CSS for presentation, JS for everything else. 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…

What makes React fundamentally worse than Vue or Svelte? In my experience, there are also plenty of crappy Vue-based sites and applications and I'm sure the same is true for Svelte.

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

Post reply on HN