481–490 of 756 posts
Earlier quoted context omitted.
Because it’s not and people hate these sites…I’m sorry…”apps” you make.
Right, and people would obviously love those same apps if they were written with Vue instead. Of course.
Earlier quoted context omitted.
Awfully funny considering our major security issues in code these days are from a type safe language.
Yeah because any systems or OS programming is done in type-safe languages. lol. And BTW correlation is not causation.
Earlier quoted context omitted.
I hate what "modern" web development has done to my UI experience. Eg. There's a delay between an Amazon.ca results page loading and it populating the search text box with the phrase you just searched for. As a result when I do two searches in rapid succession, it consistently interrupts my typing at exactly the right time to batter in incomprehensible text. AirCanada and WestJet are two other websites that became aw…
There's no React-ey style UI. Seriously. It's a UI framework not a collection of prebuilt UI components. You cannot tell if a site is using React or not without opening dev tools.
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.
How do you write a singleton service that can feed state back into the component that calls it when that state changes? For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change. EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call…
Earlier quoted context omitted.
That’s true. Just to note, I never claimed otherwise. See, useEffect is an evil remark. This is more based on my experience working with an average React codebase. As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?” I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encourag…
How do you fetch and persist server side data without useEffect? (Assuming vanilla react)
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. Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds) This is merely just to show something From what I have seen, its quite easy to have performance issues with React
Earlier quoted context omitted.
React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch…
> React Server Components strikes me as React solving a React-caused problem with yet more React. This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it woul…
I’m surprised to see people still misusing the word isomorphic.
Earlier quoted context omitted.
> React Server Components strikes me as React solving a React-caused problem with yet more React. This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it woul…
> Maybe you write isomorphic javascript I’m surprised to see people still misusing the word isomorphic.
Earlier quoted context omitted.
But there is a wide gulf between backend + JQuery and SPA. The frustration often shown is people treating the extremes as the only options available. Having a use case for which backend + jQuery doesn't cut it doesn't require reinventing navigation state and history in JS, or loading every stat on the page via JSON. There are middle grounds.
What middle ground do you propose that's as efficient to get rolling as React in 2024? You talk about not reinventing state and history in JS, but at this point the reinvention is already done and React is the pragmatic choice that you pick when you don't want to reinvent the frontend. There are a bunch of stacks that I prefer to work in for my own projects, but what I need at work is almost always the standard optio…