7 ms·

I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different d

I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle. More importantly, I realized React is trying to tame Facebook level of problems and hence their design decision steams from those data points. I develop small/medium type of frontend apps which doesn't need to apply solutions developed for such a scale. These days I'm using Hotwire[1] (Turbo + Stimulus) with fair amount of vanilla javascript libraries in my apps. Occasionally, when I need to develop a reactive piece of UI I reach out for Svelte[2] I'm quite happy after making the move. My apps complexity has reduced drastically and there is huge boost in my overall productivity. [1] https://hotwired.dev https://hotwired.dev [2] https://svelte.dev https://svelte.dev

todotask 4y ago
I haven't got the ideas why many frontend jobs require experience in React whether it's for a new or existing projects, maybe I need enlightenment.
- mym1990 4y ago
  Probably because a large portion of their app is built in React?
- pas 4y ago
  Because HR (and IT strategy) nowadays is a farce, managers, decision-makers and the actual organizational units that do hiring rarely have the necessary systemic big-picture knowledge/information, foresight, experience, longitudinal thinking that would allow them to venture out of their preset suboptimal ways.
  - dntrkv 4y ago
    Are you suggesting that requiring React experience for a job where you will use React is not a reasonable ask?
    - pas 4y ago
      It's usually perfectly reasonable, but not really optimal. In this job market requiring React seems worse than hiring someone that is a good frontend developer and has the wits and eagerness to pick up React and whatever tools the team uses, and the job requires. This has the advantage that when - inevitably - tool1 gets deprecated and tool2 arrives you'll have someone that can adapt and learn, and likely you'll also have someone who can teach.
  - robswc 4y ago
    Talking with recruiters again and can agree. The worst experience so far was for a general full stack role. They sent me a 3 page long PDF of job "requirements" which was a lot of fluff and implicit stuff. I get it... but I think that can be reserved for later. Not the best offer, seemed like they were disorganized in general, etc. The best experience was for the best TC offer _and_ most relevant position for me... they sent over half a page that didn't waste a single character. Named a few frameworks but they had a crystal clear idea of what they needed. It was amazing, lol.
patcon 4y ago
> I realized React is trying to tame Facebook level of problems and hence their design decision steams from those data points. Strong agreement! There's a saying in community organizing and activist circles that goes something like: "Don't apply the solutions of the butterfly to the problems of the caterpillar." Imho it's a really important consideration when thinking about scale of movements (and nonprofits... and any community initiative...). This is especially true when "professional" people are always coming in and confidently over-applying their learnings in corporations to thinking about activism (which often, though not always, has very different incentive structures and lifecycles). I think about this parable often in regards how all these scaled tech companies end up stewarding the developer tools and therefore practices for everyone. And they tend to out-pace and out-broadcast other wonderful tools that could better serve the majority of developer niches.
AlwaysRock 4y ago
I don't have a strong opinion either way but if you left React because you are frustrated with code becoming obsolete and picked up Hotwire, a significantly smaller framework, arnt you likely to run into the same problem if Hotwire doesnt end up being the next big framework? In 5 years if no one else is using Hotwire then your code is obsolete, no? I liked working in next.js in the past but my company was already talking about Nuxt.js when we hadnt even fully converted to next. Feels like jumping ships from a ship with some major flaws, but will continue to float for x+ years, onto a lifeboat that may or may not make it another 500 feet before sinking.
- jibe 4y ago
  In 5 years if no one else is using Hotwire I think that's the opposite of what he is saying. Because React is updated and changes frequently, your code becomes obsolete unless you update to follow the latest changes. In theory, if everyone abandoned Hotwire, your code would never be obsolete or need changes, because Hotwire would never change. In reality, as browsers and web standards change, frameworks need updating.
  - frosted-flakes 4y ago
    React doesn't change frequently though, that's the point. And it has always had excellent backwards compatibility. Class components are still fully supported, for example.
    - ipaddr 4y ago
      React changes best practices every few years prompting many rewrites.
      - forgetfreeman 4y ago
        One has to question the sanity of a rewrite launched for the sake of notional orthodoxy. If it ain't broke...
      - AlwaysRock 4y ago
buscoquadnary 4y ago
Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn't designed to do. They start making "minor feature enhancements" to the tool so that it can fit more use cases. Alternative Step 4: Tool becomes "industry standard" so everyone starts using it because it is "the right way", regardless of whether or not it is a good fit. Step 5: The new tool becomes massive and bloated and overwhelmed with too many features, configurations, and options. Step 6: Return to step 1. > The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time. But it was a beginning.”
- bravura 4y ago
  This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?
  - knicholes 4y ago
    It's not a joke. It's reality. It gets mentioned repeatedly because of how true it is.
  - buscoquadnary 4y ago
    It's not a joke, it's intended to convey the wisdom of not thinking "the next big thing" will solve all your problems, it is intended to focus on the importance of fundamentals, and of relying on using engineering skill to solve problems rather than fancy gadgets, it is to point out the value of developing technical acumen rather than becoming a tool bound technician. If you define yourself by the technology you work with you aren't an engineer you're a technician.
andsoitis 4y ago
> I ditched React Did you rewrite your entire app?
jstummbillig 4y ago
> when I need to develop a reactive piece of UI I reach out for Svelte I never used Svelte, but I feel that "develop a reactive piece of UI" is basically Stimulus' job description. Can you explain a scenario/task where Stimulus does so poorly, that you flip the switch and use Svelte instead?
- earthboundkid 4y ago
  Stimulus was made by people who hate JavaScript and deliberately and pointlessly avoids JavaScript conventions. If you hate JS, you might like it, but I like JS, so I hate Stimulus. My preference is for Alpine.js, but Svelete is cool too.
lexx 4y ago
Amen
fud101 4y ago
my front end is 50k loc, is that medium or small or what?
hellohowareu 4y ago
I liked classes to-- their lifecycle methods were so clear to work with. That said, learning how useEffect replaces lifecycle methods is pretty quick to pickup. As is useState. The lesser known hooks are what are difficult for me to understand. useRef is pretty clear. useMemo? I'm not quite sure what it's for, but I imagine it's not too tough to figure out if I spend a bit of time learning & experimenting with it. So, although I liked the simplicity of class components, functional ones aren't too bad. They bring in some additional complications, but with a bit of effort it seems to all be learnable to me.
hinkley 4y ago
Howard Lewis Ship kept changing the paradigm for Tapestry every major release or two. He could have had something to take the spot that Spring eventually filled, but these big gear shifts I think left people with a lot of rework and at some point it seems like porting your code to something more architecturally stable is a better bet. It’s challenging though to keep supporting an API contract that you don’t believe in anymore. Or especially that you are causing you and others pain. I think sometimes maybe the thing to do is pass the baton and work on something else, but we also punish people for abandoning things. Like the author of Groovy, who hopped around from project to project and lost people.

todotask 4y ago

I haven't got the ideas why many frontend jobs require experience in React whether it's for a new or existing projects, maybe I need enlightenment.

mym1990 4y ago
Probably because a large portion of their app is built in React?
pas 4y ago
Because HR (and IT strategy) nowadays is a farce, managers, decision-makers and the actual organizational units that do hiring rarely have the necessary systemic big-picture knowledge/information, foresight, experience, longitudinal thinking that would allow them to venture out of their preset suboptimal ways.
- dntrkv 4y ago
  Are you suggesting that requiring React experience for a job where you will use React is not a reasonable ask?
  - pas 4y ago
    It's usually perfectly reasonable, but not really optimal. In this job market requiring React seems worse than hiring someone that is a good frontend developer and has the wits and eagerness to pick up React and whatever tools the team uses, and the job requires. This has the advantage that when - inevitably - tool1 gets deprecated and tool2 arrives you'll have someone that can adapt and learn, and likely you'll also have someone who can teach.
- robswc 4y ago
  Talking with recruiters again and can agree. The worst experience so far was for a general full stack role. They sent me a 3 page long PDF of job "requirements" which was a lot of fluff and implicit stuff. I get it... but I think that can be reserved for later. Not the best offer, seemed like they were disorganized in general, etc. The best experience was for the best TC offer _and_ most relevant position for me... they sent over half a page that didn't waste a single character. Named a few frameworks but they had a crystal clear idea of what they needed. It was amazing, lol.

patcon 4y ago

> I realized React is trying to tame Facebook level of problems and hence their design decision steams from those data points. Strong agreement! There's a saying in community organizing and activist circles that goes something like: "Don't apply the solutions of the butterfly to the problems of the caterpillar." Imho it's a really important consideration when thinking about scale of movements (and nonprofits... and any community initiative...). This is especially true when "professional" people are always coming in and confidently over-applying their learnings in corporations to thinking about activism (which often, though not always, has very different incentive structures and lifecycles). I think about this parable often in regards how all these scaled tech companies end up stewarding the developer tools and therefore practices for everyone. And they tend to out-pace and out-broadcast other wonderful tools that could better serve the majority of developer niches.

AlwaysRock 4y ago

I don't have a strong opinion either way but if you left React because you are frustrated with code becoming obsolete and picked up Hotwire, a significantly smaller framework, arnt you likely to run into the same problem if Hotwire doesnt end up being the next big framework? In 5 years if no one else is using Hotwire then your code is obsolete, no? I liked working in next.js in the past but my company was already talking about Nuxt.js when we hadnt even fully converted to next. Feels like jumping ships from a ship with some major flaws, but will continue to float for x+ years, onto a lifeboat that may or may not make it another 500 feet before sinking.

jibe 4y ago
In 5 years if no one else is using Hotwire I think that's the opposite of what he is saying. Because React is updated and changes frequently, your code becomes obsolete unless you update to follow the latest changes. In theory, if everyone abandoned Hotwire, your code would never be obsolete or need changes, because Hotwire would never change. In reality, as browsers and web standards change, frameworks need updating.
- frosted-flakes 4y ago
  React doesn't change frequently though, that's the point. And it has always had excellent backwards compatibility. Class components are still fully supported, for example.
  - ipaddr 4y ago
    React changes best practices every few years prompting many rewrites.
    - forgetfreeman 4y ago
      One has to question the sanity of a rewrite launched for the sake of notional orthodoxy. If it ain't broke...
    - AlwaysRock 4y ago

buscoquadnary 4y ago

Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn't designed to do. They start making "minor feature enhancements" to the tool so that it can fit more use cases. Alternative Step 4: Tool becomes "industry standard" so everyone starts using it because it is "the right way", regardless of whether or not it is a good fit. Step 5: The new tool becomes massive and bloated and overwhelmed with too many features, configurations, and options. Step 6: Return to step 1. > The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time. But it was a beginning.”

bravura 4y ago
This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?
- knicholes 4y ago
  It's not a joke. It's reality. It gets mentioned repeatedly because of how true it is.
- buscoquadnary 4y ago
  It's not a joke, it's intended to convey the wisdom of not thinking "the next big thing" will solve all your problems, it is intended to focus on the importance of fundamentals, and of relying on using engineering skill to solve problems rather than fancy gadgets, it is to point out the value of developing technical acumen rather than becoming a tool bound technician. If you define yourself by the technology you work with you aren't an engineer you're a technician.

andsoitis 4y ago

> I ditched React Did you rewrite your entire app?

jstummbillig 4y ago

> when I need to develop a reactive piece of UI I reach out for Svelte I never used Svelte, but I feel that "develop a reactive piece of UI" is basically Stimulus' job description. Can you explain a scenario/task where Stimulus does so poorly, that you flip the switch and use Svelte instead?

earthboundkid 4y ago
Stimulus was made by people who hate JavaScript and deliberately and pointlessly avoids JavaScript conventions. If you hate JS, you might like it, but I like JS, so I hate Stimulus. My preference is for Alpine.js, but Svelete is cool too.

lexx 4y ago

Amen

fud101 4y ago

my front end is 50k loc, is that medium or small or what?

hellohowareu 4y ago

I liked classes to-- their lifecycle methods were so clear to work with. That said, learning how useEffect replaces lifecycle methods is pretty quick to pickup. As is useState. The lesser known hooks are what are difficult for me to understand. useRef is pretty clear. useMemo? I'm not quite sure what it's for, but I imagine it's not too tough to figure out if I spend a bit of time learning & experimenting with it. So, although I liked the simplicity of class components, functional ones aren't too bad. They bring in some additional complications, but with a bit of effort it seems to all be learnable to me.

hinkley 4y ago

Howard Lewis Ship kept changing the paradigm for Tapestry every major release or two. He could have had something to take the spot that Spring eventually filled, but these big gear shifts I think left people with a lot of rework and at some point it seems like porting your code to something more architecturally stable is a better bet. It’s challenging though to keep supporting an API contract that you don’t believe in anymore. Or especially that you are causing you and others pain. I think sometimes maybe the thing to do is pass the baton and work on something else, but we also punish people for abandoning things. Like the author of Groovy, who hopped around from project to project and lost people.