Live data from Hacker News

If not React, then what?

infrequently.org

301–310 of 756 posts

Re: If not React, then what?

#301
post #141

Earlier quoted context omitted.

Not parent, but I'll answer anyway: React was much much easier to learn back when Class Components were the thing. Nowadays there is layers upon layers of magic like Functional Components with State from Hooks.

> Nowadays there is layers upon layers of magic like Functional Components with State from Hooks. 1. you can still write class based components if you want, but if you are in a team everyone will hate you for that because... 2. the preferred and vastly more flexible and powerful way is functional components. That's it, there isn't any other way or any other mystical layer of magic. What everybody in this umpteenth om…

I didn't talk about any pipe dream, I named a very specific way of how those things were done before - in React! - and how it used to be simple and now it's not.

"Fucking deal with it?" What are you, a cultist? I answered a question here, fuck off.

Re: If not React, then what?

#302
post #136

Earlier quoted context omitted.

> The hooks API is just awful Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.

This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.

>you get weird stateful functions

This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.

Re: If not React, then what?

#303
post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device.

that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor.

if that isn't enough for your react powered site, you are doing something very wrong.

Re: If not React, then what?

#305
post #136

Earlier quoted context omitted.

> The hooks API is just awful Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.

This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.

1. Nobody said that classes are bad. Yes you can encapsulate logic and state in a singleton, that's not the issue, the issue is how you then "apply" it. There was a fantastic diagram that (most likely) Dan Abramov posted on Twitter a while ago (before it became the olympic pool of diarrhea that it is today) that was demonstrating the superiority of hooks in a beautiful and obvious way but I cannot find it anymore... :/

2. Sorry but if you keep using "weird", "hard" and "complicated" adjectives to define something that is quite honestly not so hard to grasp you make it hard to not go with "skill issues".

Re: If not React, then what?

#306

I hope that I’m not the only one who feels the anger emanating from these sort of blog posts. It’s stuff like the Qwik developers claiming things like “Hydration is pure overhead” as if it’s the mathematical proof that keeps their reality from crumbling. It’s the same thing on YouTube with people like Theo, gnashing their teeth at how Tailwind is incredible; You’re objectively stupid for not liking what I like; You’r…

I generally agree (that the React isn't the main culprit), but what does Tailwind have to do with templating? It's still just CSS classes, but with specific names. Also, I bet you could have strongly typed class name strings using TypeScript's template literal type somehow.

The gist is something like a new cohort of front-end developers and some begrudging back-end folks who never actually learned how anything worked are now trying to inscribe their influence as the new smart people with tools like Tailwind and HTMX.

Wanting to prove yourself isn’t a problem. It’s actually a sign that a developer is starting to form their own opinions. But it becomes toxic when the primary motivation comes from a desire to appear smart instead of actually solving a problem.

You’re absolutely right about typed classes and that’s how React Native does it. Writing and debugging CSS is hard for many of the same reasons that string-based templates exhibit. IMO the developers who push Tailwind are looking through the wrong end of the telescope. CSS is challenging because it’s a combination of declarative aesthetic UI and imperative state management. Choosing to represent that complexity with Tailwind guarantees what could have be a temporary ignorance into a more permanent crutch that retains the same faults of the underlying abstraction, tragically opting out of any of the benefits of embracing the system. Modern CSS is pretty great and learning how it works pays endless dividends.

Re: If not React, then what?

#307
post #266

Earlier quoted context omitted.

Have you heard of HTML, CSS and forms? They are even more boring, more mature, more stable, often faster, have a huge community, massive resources and ecosystem. React is even built on one of these technologies!

Which one of these technologies is React built on top of?

HTML, specifically react-dom. It’s built with JavaScript

Re: If not React, then what?

#308

Earlier quoted context omitted.

> React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents. The options you present are: "either use a JS framework or don't use JavaScript at all". That's a false dichotomy. I've built plenty of interactive apps with JavaScript without using frameworks.

For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion. Sure you can develop very large projects in JS, as long as you don't mind being 1% as efficient, and having 100x more bugs. In JS, refactoring a huge project is the biggest nightmare in the world and really no human is capable of doing a great job of it in a reasonable time, even if…

I don't share your opinion but I'm too tired to go into another JS vs TS debate

Re: If not React, then what?

#309

Earlier quoted context omitted.

By vanilla React I meant that I don't use the new Next.js / SSR stuff and instead build a JS file.

what do you use for routing? I built Routerino for just exactly this purpose, to use with vanilla React. maybe it'll be useful for you! https://www.npmjs.com/package/routerino

I actually use the history API. I've been thinking about modernizing by replacing it with React Router. I'll check out Routerino also.

Re: If not React, then what?

#310

Earlier quoted context omitted.

This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.

>you get weird stateful functions This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.

Again, you can still use class components today, feel free and have fun.
Post reply on HN