this post was submitted on 23 Jun 2023
879 points (100.0% liked)
Technology
37737 readers
347 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It sucks that a company as evil as Facebook also built and open sourced React.
React is incredibly popular because so many companies use it. They are banking on Facebook's continued support and development, and an assumption that if Facebook is doing it then it must be right. Being rich does not automatically make one right. Having worked at a company that forced React on its developers against their wishes I can unequivocally say it's bad.
In any system the right action should be the default action. Query parameters should be parameterized by default, variables in HTML templates should be contextually escaped by default, and so forth. "Don't make me think". React is the complete opposite of that: It requires you to constantly think about the render loop (aka "Component Function"), it hides the fact there is an object behind the scenes containing the component state, the documentation is littered with "don't worry about this feature until after you have a performance problem, then come back here for the solution", it's very neat and tidy for tiny example projects but does not scale well as the project grows.
Using useMemo and useCallback to Save the Past from React Langoliers + Thoughts on React vs Vue vs Everything Else in 2023
Compare that with a system like Vue or Lit, which is much more intuitive, does the right thing by default, and is easier for existing HTML/CSS/JS developers to grok at a glance.
Don't forget Svelte. That said, traction means more developers trained in any tech stack, that's why my previous company ditched Vue for React circa 2016, Vue seemed destined for oblivion and irrelevance at the time.
That is the primary argument my company used to justify forcing React. Do you know how many people we hired for their React experience? One. Everyone else was primarily backend or only had passing experience in React (not subject matter expert / does not know best practices). Meanwhile the rest of the team struggles to work in it (the frontend has become siloed) and very little of it follows best practice.
lmao I love that article, thanks for the link!
Ironically enough, I just got done troubleshooting some insane rendering problems that a
useMemofixedI've been meaning to scope out Vue and never heard of Lit - thanks for some weekend inspiration
@smokinjoe An interesting reaction to react is Svelte: https://svelte.dev/. Instead of sending an entire application to the browser and making the poor client run all of it, do a crap ton of compute and calculation at build time. Send minimal code and computation to the browser. Totally different paradigm.
The reactivity of Svelte leaves a lot to be desired. The only difference between a computed property and a mutable property is
let x =and$: x =, both of which are declared in the same top-level scope and doesn't provide much to distinguish them. The lack of reactivity on arrays and objects is a major foot-gun by default. The number of places they say "this looks weird, but don't worry it'll soon become second nature" in the docs shows that they acknowledge it's bad design to create code that is misleading or goes against the grain/standard for what behavior developers should expect (makes it confusing to work with and then use anything else, or vice versa).The
#awaittemplate directive is interesting; I'm not sure I agree it should be handled in the template instead of the script but if combined it would remove some boilerplateloading = true/falseanderror = 'message'variables from script scope.