Hacker News Reader

Comment by hliyan | Hacker News Reader

Why is this so easy to read compared to React? https://github.com/HeyPuter/puter/blob/master/src/UI/PuterDi...

Despite being asynchronous it contains a single linear schedule and two callbacks. The obvious outcome is two layered constructors, and a single top level API object with two custom events.

You couldn't describe what was going on in an equivalent functional construction of a react version unless you first head off on a diatribe about signals/hooks/state-management-disaster-du-jour, the choice of use of which would have implications to both the event handlers in some way - though they likely couldn't be in-place here, they'd have to be passed down from parent context in a giant dance of inversion of control. At runtime the outcome would likely get parsed twice (once for shadow, once for insertion) if not more times under certain compositions. Here the jquery is almost incidental, and could be quickly replaced by something else - for example want to swap out htmx here, well, just add the markers to the DOM, delete the jquery lines and you're done. You'd probably need to spend at least an hour figuring out if you could fit something independent and platform-native into your react code base, hell I've seen people burn weeks on it.

The JSX syntax makes React hard to read due to multiple layers of nesting.

IMHO, Vue is superior for both maintainability and readability than React. Especially because CSS, JS anda HTML are largely in separate blocks of the same file.

You can see this in that Flutter didn't copy JSX and its usability seems better.

Not that I'm confident Flutter is worth the trade-offs.

narrator:

It's not.

I'm confused about what you mean by this. There's nothing about Flutter's API that encourages less nesting, In fact, it's the exact opposite. Plenty of layout and styling that takes a number of nested widgets in Flutter can be achieved using a single div in React.

I can understand some of the benefits of JSX, but compared to Vue SFC's, it's a mess to read.

React CSS modules feel so unwieldy compared to Vue SFC's inline `scoped` CSS.

Vue's approach to templating using `v-for` and `v-if` means that you won't end up with a big block of logic mixed in with the template (you can still do it, but Vue's nature steers you away from it).

Arguably they should all be in external files. HTML in one, CSS in another, and Javascript to load and cache them without any embedded strings. That's how I prefer to write. For one thing, it lets me choose which things I want to cache and which I don't. I can compile from SCSS and deploy without changing any JS or HTML files. Usually my rollups are just the JS.

That's a pretty small component and I think folks would find a comparable React component also pretty easy to read. Conversely: https://github.com/HeyPuter/puter/blob/master/src/UI/UIDeskt...

I'm sorry XD

Ha, I am not criticizing your work at all. It's nothing short of jaw-dropping.

I guess “React makes sense for more complex UIs” is not hard-and-fast rule. jQuery, apparently, is more than enough for clean working frontend code.

It is not about complex UI per se, it is about complex state. With jQuery, the State is duplicated in the DOM instead of mirrored and is very hard to keep in sync.

>"State is duplicated in the DOM instead of mirrored"

And the difference between duplicated and mirrored is ...

Fair question.

Mirrored means when you update state, your changes are reflected in the DOM, automagically.

Duplicated means when you change state, you also have to make the changes to the DOM, yourself.

Clear (mostly one-way) data binding is definitely one of React’s strengths.

It appears that Puter handles templating with a pattern like:

  let h = ``
  h += `<div>${exampleContent}</div>`
  h += `<div>${moreExampleContent}</div>`
  $(targetEl).append(h)

And handles events in the traditional way:

  $(targetEl).on('click', function () { /* do stuff */ });

Searching for “React” or “jQuery” in this thread, there are several other conversations with thoughtful comments about pros and cons. One curious tidbit that I learned is that Visual Studio Code doesn’t use a framework either and, like Puter, updates the DOM directly.

The main issue is that "$(targetEl).append(h)" is not idempotent.

This might seem like a small issue on the surface but as your application grows, this either becomes a big problem or you have reinvented React, Vue, or something similar, but without the extensive testing and developer/community availability. Which is essentially what VSCode does for example, using some sort of MVP* pattern.

Write state to DOM, read state from DOM.

In sounds nice in theory, but in practice, it doesn't work out. The example linked is a good one, a popover, the underlying DOM disappears, but the "state" behind it remains at least a bit longer.

I've practiced for decades and it works out fine. It's good to explore outside the React cargo cult from time to time.

Can you share some complex application you have worked on that doesn't use a framework or end-up inventing one internally like VSCode for example?

I did web not just before React but before jQuery and MooTools. So it is funny you ask I should explore outside "React cargo cult".

Out of curiosity, which is the internal framework used by VSCode ? Would like to take a look at that. According to Erich Gamma, there is no use of a UI framework just a conventional model-View-Presenter with JS/TS constructed HTMLElement components.

There is no such thing as "conventional" MVP, every implementation is slightly different.

It is not an official framework per se, but it is a framework nonetheless, except without comprehensive documentation and developer availability or much commercial value in investing your time to learn it.

The main point is that if you're arguing against React or any framework "because abstraction bad", you will end up with them anyways, enjoy:

https://github.com/microsoft/vscode/blob/release/1.87/src/vs...

Well, we will need to agree to disagree. I see some utility libraries in `base/common` for disposables management, eventing and actions that you are terming a "framework". I don't even know how I would use this as an independent framework outside vscode. Even if I could, the rendering and organization logic would be mine not delegated to fundamentally unique framework paradigms like React/Vue/Angular.

The creators of vscode also explicitly state they don't use UI frameworks. https://www.youtube.com/watch?v=gnKzJRr-rd0

Unless we are calling all libraries and packages as frameworks...

> I see some utility libraries in `base/common` for disposables management, eventing and actions that you are terming a "framework".

It is because you didn't look deep enough, VSCode for all intent and purposes has a "framework" that it is built on top of.

What is a frameworks anyways?

"Frameworks model a specific domain or an important aspect thereof. They represent the domain as an abstract design, consisting of abstract classes (or interfaces). The abstract design is more than a set of classes, because it defines how instances of the classes are allowed to collaborate with each other at runtime. Effectively, it acts as a skeleton, or a scaffolding, that determines how framework objects relate to each other."

If it walks like a duck, and quacks like a duck, it probably also Reacts like a duck.

> the rendering and organization logic would be mine.

This is cute and nice for a weekend project. But if you want to build commercially viable products or even a GA open-source software, "Mine" is of no value.

Good documentation, extensive testing, developer availability, on the other hand are far more important.

Why not use a state management library like xstate with jQuery ?

There is no sync if the state is the DOM.

Because it’s trivial?

This component has no state, no data fetch or transitions. It doesn't even have any dynamic part.

Reply on news.ycombinator.com