Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "reactivity"
-
Manager: Could you create the UI for the new feature? The client wants to test it. We need it in 3 days.
*1 week later*
Client: IT DOESNT WORK
Me: This is just a visual demo... but everything will work when we realse the feature.
Client: okay but can I see what it will do?
Of course you can! Just wait until we relase it!
*2 weeks later*
Manager: What are you doing?
Me: Working on the UI for the new feature.
Manager: Wait, hadn't you already done it for the demo?
Me: That UI didn't really work. It was basically a bunch of HTML, without reactivity or abstraction or any functionality.
Manager: Okay, how much where you able to re-use?
Me: almost nothing.
Manager: So... you wasted those 3 days?
Oh so I'm the one who wasted 3 days.
Me: Kinda, yeah
Manager: Why couldn't you have done this when I asked you to do the UI?
You can't expect good quality code in 3 days. Pls stop wasting it on demos.3 -
It seems like I'm going on an assignment to a company working with Angular. Reading through the documentation I just want to ask all Java developers to get their greasy hands out of JavaScript. It feels like GWT all over again with Google reinventing core JS technologies just so that it looks like Java. Dependency injections? Observable wrappers? RxJS in general? WHAT IS THE POINT? Why can't I do this in a way adhering to web standards? Why can't I simply use fetch() or axios or whatever? Why can't you support reactivity without forcing me to write more boilerplate than I had on my central heating boiler? I just want to code and not be forced to discover what Google developers think web should be like.
Please, let me out of this hell.
Fortunately, it's not gonna be a long assignment.3 -
React's useMemo, useCallback are just sad attempts at patching up a bad reactivity model. We should seriously move on from this hot pile of garbage.4
-
I fucking hate it that "front end developer" came to mean "data flow for react engineer". It seems most frontenders now don't understand shit about HTML and its standards, don't know anything about basic accessibility and proper content structuring.
It's even worse with the styling. Cascade? The fuck is cascade? Scope everything! And, of course, write that CSS as a JS object because how else. Fluid typography? If by fluid you mean 16px, sure. Any more advanced techniques? Lol forget you're getting rounded boxes with a shadow and you're gonna like them.
But yeah, I'm glad they're overengineering Redux again because their reactivity model is fundamentally broken. That's exactly what """frontend""" should be about.10 -
Once a React aficionado, twice the frustration we endure,
In the realm of libraries, React's problems seem impure.
With Svelte's elegance and grace in our sight,
Let's vent about React, as day turns into night.
Boilerplate Overload, a monotonous affair,
Classes, constructors, lifecycle steps we declare.
In Svelte's simplicity, we find a breath of fresh air,
Just markup and magic – a coder's love affair.
Complex State Management, React's Achilles' heel,
Redux, Mobx, and their massive code appeal.
Svelte's state handling is a cinch, for real,
No more tangled webs of logic to conceal.
Unnecessary Re-Renders, React's performance woe,
Countless updates, like a never-ending show.
Svelte updates what's needed, like a pro,
Efficiency and speed, in its radiant glow.
Verbose Syntax, JSX's verbosity on display,
HTML in JavaScript, causing dismay.
Svelte's concise template syntax lights our way,
No more endless tags, just code that's here to stay.
Lack of Truly Reactive Behavior, React's hurdle high,
Hooks to wrangle, state to satisfy.
Svelte's reactivity, no need to question why,
It just works, oh my, oh my.
Ecosystem Complexity, React's sprawling sprawl,
Choices galore, making us bawl.
In Svelte's world, simplicity is the call,
A coherent ecosystem, it has it all.
Learning Curve, React's mountain to climb,
Classes, hooks, context, a hill of time.
Svelte's gentle curve feels sublime,
A smoother path to code, so fine.
Tooling Overkill, React's complex array,
Build tools, linters, configs in disarray.
Svelte's streamlined setup leads the way,
No more intergalactic code buffet.
Debugging Headaches, React's mysterious realm,
Complex state, intricate components overwhelm.
Svelte's predictable model, a soothing helm,
Debugging becomes a peaceful realm.
In the end, React, a complex labyrinth we explore,
Svelte's elegance and simplicity we adore.
If only React could learn, its problems to deplore,
A brighter future, for React we'd implore.3 -
It's so frustrating to explain rxjs pitfalls to the manager.
To avoid the diamond problems and glitches caused by combineLatest and debounceTime(0), I decided to use single stream with nested reactivity.
Then the manager asked me to use withLatestFrom instead of combineLatest.
Sure withLatestFrom makes sense to the original author, when the original author is able to remember the reactive graph and put proper dependencies to combineLasted/withLatestFrom accordingly, but anyone else who touches the component later needs to retrace the reactive graph to avoid the glitch. Sometimes it's just impossible when many dependencies are derived from combineLatest+debounceTime(0). When no one is trained to code reactively, I don't expect people to know where to put a dependency. After many trials and errors, the only way to avoid the diamond problem is to use nested reactivity where child streams are created within root stream each time root stream emits.
The mentioned manager put all sorts of side effects in observable chains. The manager keeps saying the stream is too large when their subscription functions (sometimes nested) are way worse with litered mutations everywhere. Anything in observable can be traced by go to definition but tracing side effects usually requires global searches.
Recently, he put startWith to the end of a synced stream to fix a bug where button would collapse when there is no content (initial null emission). Rather than fixing the default height, he thinks using startWith(defaultLabel) is a good idea. Of course, he doesn't know that a synced stream should only emit 1 value on new subscription and that extra emitted value will cause rxjs glich down the pipe.
I hate corporate jobs