121–130 of 310 posts
I find it strange this is still such a hard problem to solve in an environment with a slew of options for key value global, local, and remote storage
After reading the "Grug Developer" article recently, I've been thinking of frontend development as "The Plane of Eternal Complexity Demons".
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…
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…
I think the same is true of 3D libraries. The real work of making an app that does 3D is not the 3D engine, it's everything else (UX or GameDev). The 3D part has well known goals and solutions so it feels like you're making a ton of progress, ie, it's fun to make. Much easier than deciding harder things like which features your app should have and how they should work.
Earlier quoted context omitted.
Link: https://grugbrain.dev/ It is universally worth your time to read it if you haven’t :)
Plain english translation: https://github.com/reidjs/grug-dev-translation I haven't read it, but wish I had seen it before struggling through the original
But with the translation, I just devoured and appreciated it.
Mobx solved all of the state problems properly a long time ago.
Can anyone parse that sentence please? Was this article written by GPT-3?
Absolutely great article. One thing I always see missing is why front-end applications can't use sessionStorage or localStorage? Why is this generally frowned upon?
Mobx solved all of the state problems properly a long time ago.
Agreed! I'm surprised at the comprehensive work going into researching the history of state management in this article while completely missing MobX. What problem does MobX not already solve?
I’d say the two biggest hazards with the reactive/declarative style are cyclic dependencies in the data model and remembering history.
Tools like MobX let you write quite elegant code in the right circumstances but they are less helpful if, for example, you have a complicated set of constraints and the effects of changing one value in your state can propagate in different directions depending on what first changed to start the cascade.
This style also tends to emphasise observing the current state of the system, so if you need a history as well (for undo, syncing with other user actions via a server, etc.) then you probably have to write a whole extra layer on top, which is more work with this kind of architecture than for example if you are using a persistent data structure and reducer-style updates (as popularised by Redux within the React ecosystem).
After reading the "Grug Developer" article recently, I've been thinking of frontend development as "The Plane of Eternal Complexity Demons".
Link: https://grugbrain.dev/ It is universally worth your time to read it if you haven’t :)