Unachievable dreams?
I am sure sometimes you lean back and wonder how we got to the status quo regarding the stacks we use. I mean, does it really make sense to let a server render my frontend just to execute JavaScript which in return turns around and asks that very server for data?
Can't mommy already pack my lunch when she knows where she is sending me to and what I'll need?
There is of course the trend of eliminating some of the pain with SSR solutions, but at the end of the day you still need to make complex decisions of when to render what information directly and how to integrate the backend you write in a more or less independent manner to something accessible as your reactive store.
Speaking of stores
Has there ever been anybody who didn't learn about Redux or Vuex and though: "Really? That's the best solution to address performant state management across components? Actions, Dispatch, Commit, what?"
And we might then have gotten used to it. Heck, we might have even become sufficient enough with it that we forgot about the pitfalls and learned to gain the freedom they provide. But is that really still necessary with solutions like hooks or the composition API?
The broken promise of SAAS & microservices
It sounded like a good idea, didn't it? Let's just quickly integrate an object based database like firestore and off we go building the user experience. In reality, we still don't have a solution that would actually enable us to "just write the app". We still need to secure via own endpoints, take care of potential oAuth integrations and worry about key exposure. We looked down on monolithic architecture and now long for the days were everything was under our control. But we don't miss the setup, writing transactions and debugging the models, do we?
In 2021, it's time to solve these problems
What I want - what I always wanted - is a "Fr(ontB)ackend".
A solution that is a glass, not a bottleneck but still opinionated and testable enough to enable bigger teams to securely work with it without making a mess. A "DWAI" (Don't worry about it) feeling when handling stores and data handling in general. Finally a declarative form of writing API interactions (Polymer tried and failed). Is it not possible to provide an ecosystem that is so rapidly fast to learn, develop in and deliver (looking at you, lighthouse) that a front-end developer could write full-stack applications while having the time to demystify SQL, SEO or reactive state while having tangible output?
In order to achieve that, such a system would have to guarantee
- no more race conditions
- no building process
- no coding of stores, endpoints, models and their interaction
- no complex lifecycle decisions
Well, I am working on it:
Top comments (19)
Hooks are great, but for me they don't come close to replacing redux. Redux is designed to make it easier to manage state. Some people don't like to manage state this way, and so hooks are great for them - but for those of us that do like redux as a state container, hooks aren't that.
Well see, then it failed. I tutor junior devs and stores are one of the topics most discussed.
Sorry, let me rephrase, I was wrong to say:
It is in fact designed to make it simpler. Handling state gets very complex very quickly. This problem scales with the size of an application. Redux lets us control state, to minimise it, and to manage it within a subset of the language. This ultimately makes it easier to reason about.
Junior devs may not pickup Redux straight away but I'm not entirely sure they should. Making something easy to understand in order to appeal to the lowest common denominator in terms on language experience doesn't really seem like a long term plan for building reliable applications.
On a personal level I actually think that redux is easy enough to learn, the problems are that people think it's for something it isn't (injecting props arbitrarily throughout a component tree) and that the concepts (immutable state, functional patterns) are so alien to people that they have a hard time moving past them to understanding the overriding concepts.
I agree with that. But that doesn't mean I can't derive the conclusion that if something has a huge learning curve and maintenance cost it might not be an ideal solution.
This certainly does not mean that I want to advocate for a passing down props/callbacks a gazillion levels and bubbling events up to grandparent's parents.
What I am saying is: I remember the feeling of being surprised that there isn't a better solution. And I am not alone with this. My approach for VueJS is a concept known to React devs from recoil
I didn't actually mean to disagree or pick holes in your original post, sorry if it came across that way. I just see a lot of people complaining about using Redux because it's a heavy-weight way to inject props, which seems slightly unfair to me.
I'm all for anyone advocating any approach that they've at least slightly thought through, so good luck to you with this approach.
Oh, don't worry, I didn't take it that way.
well then.., what thoughts do U have about usability 4 'state' within stateLESS env like API?
I'm not sure I understand the question - you're asking how state can be used in a stateless environment? I would imagine very little?
Redux does have a state && I'm not sure U do understand, do U?
I think that you guys have the issue that one is talking about the backend state (and then referring to stateless sessionless), and the other about the client side state.
There is no more backend && frontend 4 JS when single-4-all Node'd come 2 place || what do U MEAN by that?
D.R.Y fool anymore. but raise 2 full up D.I.Y stack.
Can you rephrase that? I read this comment multiple times without getting closer to its meaning.
{D.R.Y: en.wikipedia.org/wiki/Don%27t_repe...} fool anymore. but raise {2: to} {full up: en.wiktionary.org/wiki/full_up} {D.I.Y: en.wikipedia.org/wiki/Do_it_yourself} stack
Lol. Let me rephrase then: the acronyms in your comment aren't the issue: I don't know what you are trying to say with your comment.
Well, if acronyms is OK, then let me make a single friendly farewel K.I.S.S. As far as PHP @ backend is just a Preprocessor 4…, with advance of Node right time'd come 2 teach JS 2 do $IT @ backend but up 2 frontend
I give you that: I don't know if I am facing a language barrier, bot or troll
this kind of talk is not of my interests and moreover does not of my business. therefore this was my last comment for you. good luck.
K. Sorry, just really don't know what you are trying to input.