41–50 of 114 posts
Earlier quoted context omitted.
Functional Components are 10x easier and cleaner to use in React
Functional Components are not functional in the sense of functional programming. They are shared mutable state.
Earlier quoted context omitted.
It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch.…
That's not it. The core issue is AAA sites vs apps. Let me explain. Public sites need to load quickly and use progressive enhancement, work without JavaScript even. Next.js is driving this with server side rendering and hybrid approaches. They've done a great job so far. Then there are applications that have a browser UI. These typically use a JSON-based API (REST, RPC, or GraphQL doesn't matter). These apps don't re…
I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.
It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch.…
> My favorite way to do data fetching is as close to the place where I am using the data. React made it possible up until this change.
Well, yes, but we are nowadays in a situation where every component interacts directly with the state, or makes calls to the API (eg with the overuse of query), going against one of the architecture principles of react. It's like we're not building components, we're building component sized micro-ui.
What does that mean? (for someone not familiar with React)
It makes anything that does lazy loading in parallel noticeably worse by forcing waterfall-only loading, in order to make rendering and management of loading states slightly better.
I have a feeling it means 'generate html' in english.
Earlier quoted context omitted.
It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch.…
That's not it. The core issue is AAA sites vs apps. Let me explain. Public sites need to load quickly and use progressive enhancement, work without JavaScript even. Next.js is driving this with server side rendering and hybrid approaches. They've done a great job so far. Then there are applications that have a browser UI. These typically use a JSON-based API (REST, RPC, or GraphQL doesn't matter). These apps don't re…
I used React for a long time to build frontends for my REST APIs. When I started, CRA was the standard to get started with. CRA got deprecated and I wanted to shift to Next.JS since that seems to be a little more full-stack and I wanted built-in routing instead of relying on react-router. Once I got going on Next.JS everything turned out to be connected to Vercel. Even the tutorial at one stage expects you to sign up for a Vercel account. This really turned me off of React because there doesn't appear to be a single framework for people who want to build the latter category of web apps without either a) tying together multiple disparate modules/libs or b) signing up with 1 framework with 1 vendor. Either option doesn't appeal to me.
I shifted over to Angular (despite everything) because it seems to have finally stabilized and has a pretty good feature set for what I'm looking for. Plus build times on Amplify have really come down. Build times for similar sized apps take around 4 minutes(!) for React applications and routinely under and about 1 minute for Angular applications. I honestly just want a frontend framework where I can build a foundation fairly quickly and just get on with building features instead of worrying about if dependencies have suddenly been sunset or if the author made some breaking change to some key library I don't even interact with directly and right now this is Angular.
Earlier quoted context omitted.
The whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components. While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.
Hooks make it easy to compose logic and effects. The actual implementation has some serious warts but the fundamental idea is great. The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.
It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all))
Now the Compiler sounds nice, and sure there is going to be a lot less code. But, at what cost, it does sound like it's just more magic, moved further and further into the React internals. Which I think unfortunately gives the developer less understanding and power.
I'm just ranting, it's not like the React lib itself is yet entirely divorced from it's principles circa half a decade ago, but I fear it may. Perhaps, they could promote and support more sub packages of React itself e.g. rendering, state
Earlier quoted context omitted.
HTMX is the way forward.
Nothing is the way forward. It's programming, we make stuff that does stuff. Preferably with stuff that makes making stuff that does stuff easier and with stuff that will be supported for a long time. Maybe I'm too cynical, but whenever something is presented as some messianistic "way forward" I just think "ah yes, another way forward" but feel we're mostly moving laterally.
Because everything is a trade-off, new stuff creates new problems. Those are the problems complainers complain about, ignorant of their history.
The cycle then repeats.
Maybe I am not cynical enough but doing easy things from the past is completely trivial and doing unimaginable things from the past is not that hard anymore. Looks like the cycle has some forward momentum in the end!
Terrible shitshow. Web dev is all broken and horrible. Well at least the popular stuff is. No idea why anyone uses this outside resume building.
> when navigating to a new screen, it's better to show a loading state as soon as you can (often a skeleton UI), rather than delay the transition. In a better language, this would be the programmers choice on a case-by-case basis, with no need for the higher-ups to break or fix everyone's behaviour at once. Either return a Page(Future(Components)) or a Future(Page(Components)).
Yes there are cases where React is exactly what's needed but when each new version introduces new "best practices" based on how "bullish" Meta's developers feel about a given approach it removes a crucial advantage that helped these libraries become popular i.e. that it's easy to onboard new people on to a project because thewre's a consistent approach across code bases. Right now there's not a consistent approach across 2 or 3 years of React releases and that's before we come to the torrent of metaframeowrks designed to smooth over inconsitencies and deficiencies (state managment! styling!).
I don't know what the answer to this is but having spent a good portion of the last 7 years or so on and off React projects I would advise anyone to think carefully before investing time and /or money in the ecosystem. On balance the benefits aren't worth it the large majority of cases.
note: i've used library and framework carelessly and interchangably here, React has historically been keen to market itself as a library i.e. something you dip into when needed but in practice it bends the whole dev process around it so I feel framework is more apt