Hacker News Reader

Comment by LAC-Tech | Hacker News Reader

React.js is one of the leakiest abstractions I've ever seen. And the ecosystem is horrendous - it makes things slightly shorter to code at the cost of astronomical operational complexity.

I tried to drink the Kool Aid, and I got paid to write it, but it's just a bad idea to build a parallel abstraction, that leaks like a sieve, that needs its own browser tools, that pretends to be reactive but really isn't. I was so much more productive when I used vanilla js, plus the odd library as needed. And if you tell me react is "just a library" - great, remove it from your dependencies and tell me what % of files you now need to fix, because I've seen multiple react projects in the wild and they all look the same.

View on HN

What had always worked for me is that I write the web app as regular classes / objects, make it observable with mobx, then add React as essentially a template library — like as if it was mustache.js or something.

The non-React code works on its own and is super easy to understand. You could even extract the business logic and make it a CLI or a reusable library.

Shit, all my apps - Java, C++, whatever - have always been structured like this: domain logic + a decoupled frontend. I pretty much only adopt libraries that match my way. Redux did not match my way

My coworkers from past jobs tell me the way I structure my projects is so clear so I think I’m on the right track

I don’t understand why people moved away from this. It doesn’t even have to be mobx’d ideally, an informal emitter protocol would be fine, just as “rerender all reconcile the changes” mode for pages with 10k divs or less. People use a concept-heavy application framework and pretend it’s “just a thin ui library” because kilobytes. Absurdity.

I think that arch is the best and I've used it for low interactivity projects where the frontend is almost all display. Haven't tried it for complicated SPAs with lots of DOM interaction though.

Do you have any such experience? How do you architecture your models, events, processing, updating, etc? Do you have UI-less component-like pieces of code that you can compose? Or a fat root state manager that does everything?

Not sure if you work on any public repos, would love to have a look if you do for inspiration :)

Stores for everything. Modal stores; enforce open modal business logic app wide. Menu stores; allow customizing menus via config or plugins. Event store; app wide event bus now you can know when specific components/widgets rendered for the user. Theme store; wrap light/dark media query for system pref and user override in an observable.

Keep any and all business logic out of components if at all possible; that's my moto.

I don’t have a repo to show but I’ll try my best to explain

First I want to note that I do use React hooks. If I can some UI code in React, I will. DOM code would go in React

I just won’t put business logic in React ever. No non-UI side effects and no external state are allowed in my hooks

I still want my React components themselves to be a reusable library. My applications are basically a reusable logic library coupled with a reusable UI library. It’s that division that makes this style easy to read - your brain is either in UI mode or business logic mode. You never confuse yourself trying to figure out what it’s doing because you can just read one side and ignore the other

Whether you use a fat root state or not is honestly up to you. It’s really the separation that is key

I’d check out mobx examples

I know that’s not super specific and there are edge cases that you’ll run into, but my public repos are either Java and non-UI JS libraries ):

I've done similar! Worth checking out googles lit-html if you want just a template library.

Reply on news.ycombinator.com