101–110 of 310 posts
Earlier quoted context omitted.
> You can’t represent that state on the server without making the UI unusably slow. And that's why you use a client-side cache.
And once that cache is sufficiently complex, it's just a state store like redux.
I've used Redux but I've never heard of any of these alternatives. I have no doubt they're popular, but what is it about frontend that makes everyone reinvent the wheel every five years? Everything from the tooling to the tiny details somehow expires and gets recreated in a similar-but-not-similar-enough way that keeps the ecosystem in a constant state of flux. Is it the lack of platform API support? Is it the commun…
"What's wrong with frontend?" This is the age-old question. You're using Redux now, but I'm sure some JQuery/Angular/Knockout/etc dev said the same thing about what you're using back then. The front-end is crazy and I don't think there's an obvious answer of why it's such a developmental disaster. It's easy to say it's run by script kiddies or the barrier to entry is too easy, but there are a lot of smart devs workin…
The people-software interfaces for many of the commonly used pieces of software will always be complex as we will always demand a lot of our software, up to the limit that can be provided by the available tools for building these apps. As our capabilities for building better software grow, so too will the demands of the users.
If you aren't buying this argument, sit down and map out every single possible state and every possible event (user interactions, etc) of a moderately-sized app that you use regularly. Or even just one page of that app. There's a lot going on. It feels simpler than it is when we are using it because well-designed applications become invisible to the users, especially as we become familiar with them. They "just work".
TL;DR Reality is messy and complicated. And so is the software we build as well.
Most of these new client side state management libraries are incompatible with any form of SSR. If you see the documentation for Jotai/Zustand/Valtio, the solution is to avoid using with Next.js at all, or fall back to hacks using context+provider at which point the state manager becomes effectively redundant.
Isn’t SSR only really relevant when you need to optimize for SEO (which only applies to a subset of apps)? Seems like it doesn’t confer any other significant benefit.
SSR (by which I mean Next.js) is the most over-invested in JS tech of all time. It introduces a bunch of crummy DX which never pays for itself from a business standpoint.
SSR is only potentially useful for landing pages. In which case you should be using Wordpress or something like Wordpress so you aren't wasting dev resources on something a marketing team should be doing. (If your argument is that SSR is necessary for speed, I'm pretty sure exporting your Wordpress site to static HTML + CSS and using Cloudflare could more than make up for the difference.)
The one asterisk I'll add to this is that SSR in the form of the Remix framework may justify its own existence as it removes the need for an explicit API layer, which lets you skip a ton of boilerplate code. This is a big win. The fact that Remix uses SSR is just an implementation detail -- it's the DX that's actually valuable (although SSR fetishists will probably still like it, too.)
Earlier quoted context omitted.
This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input de…
We went to the moon some +50 years ago. We ought to have solved "UI programming" already, no? Something is not working
Not to mention, as an example touch became a widespread new UI paradigm in the last 10-20 years.
Earlier quoted context omitted.
Context and Redux are somewhat different tools and context doesn't necessarily solve the same problems as Redux. This article by the maintainer of Redux (acemarke) goes over why (looks like he replied to you as well) [0]. Have you tried Redux Toolkit as well? It cleans up a lot of the complexity of Redux and works well with TypeScript [1]. [0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff... [1] https:…
Basically I’m not saying redux is bad. Just that after years of using it for production software I concluded it’s still overkill for my needs. IIRC Redux is also just an abstraction on top of Context. Fundamentally it gives you pseudo-global access to application state by being able to interact with it anywhere in the component tree below the context manager.
No, this is a very common but incorrect misunderstanding of how Redux works.
It's true that React-Redux does use context internally... but only to pass down the Redux store instance, _not_ the current state value.
Also, because Redux itself is separate from React, there's a lot of things you can do with it that are completely different than what Context does. _One_ bit of overlap is that both can be used to access state across the component tree, but Redux does much more than that.
See my post here for more details:
https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
Earlier quoted context omitted.
I don't know why but front-end terminology always makes me cringe. I know it's useful jargon. I don't know why I have a visceral distaste for them. Maybe because it feels like taking a small, simple thing and making it seem like it's something more. But you're right. I haven't done much front-end at large scales. Only at one employer for a short while.
> Maybe because it feels like taking a small, simple thing and making it seem like it's something more. Perhaps it makes more sense to treat frontend engineering as thick client desktop development of yore. Websites are no longer small, simple things, they are now the primary apps that many people use (through the broswer and especially through Electron), so there needs to be sufficient tooling around managing that c…
Earlier quoted context omitted.
> Your cache emits events that each UI element has to listen to? It doesn't. How often do you have the same information redundantly displayed in multiple places, on the same screen?
It's not even necessarily the same information, but small pieces of one bigger piece that need to be updated once some of the other smaller pieces change
Earlier quoted context omitted.
This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input de…
We went to the moon some +50 years ago. We ought to have solved "UI programming" already, no? Something is not working
[flagged]
These libs are at 4.7k, 8.9k and 17.1k stars on GitHub...
> discuss the deep inner workings of things
The article is a few thousand words and there are a few interesting reflections...
> of things that already exist
The point of the article is to actually talk about "new wave stuff"...
You are arguably incorrect on many fronts, but more importantly, did you have to spend this many words being an utter dick to the author?