Live data from Hacker News

React I love you, but you're bringing me down

marmelab.com

431–440 of 574 posts

Re: React I love you, but you're bringing me down

#431
post #272

Earlier quoted context omitted.

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.

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.

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.

Re: React I love you, but you're bringing me down

#432

Earlier quoted context omitted.

People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason. The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned fr…

woah woah hold on there young one This isn't that. My hostile working definition of a framework is something that . breaks core assumptions about a language or system . limits what a user is permitted to do . increases complexities by adding new abstractions . has non-specific specifications by using unclear and imprecise language At the end you are hardly writing software. Instead you're deep into a world of new abs…

Give us the doc

Re: React I love you, but you're bringing me down

#433

Hardly any mention of Ember in the comments. Is it no longer considered a viable alternative to React?

I’ve been using React ever since that David Nolan article and ridiculed Ember all the way. Now I’m wondering if maybe I need to give it another look.

Re: React I love you, but you're bringing me down

#434

Hardly any mention of Ember in the comments. Is it no longer considered a viable alternative to React?

I’ve been using React ever since that David Nolan article and ridiculed Ember all the way. Now I’m wondering if maybe I need to give it another look.

I haven't had the opportunity use Ember much, but I like the philosophy that it's built on (and its original author, Yehuda Katz has a pretty good rep as a solid thinker).

Re: React I love you, but you're bringing me down

#435
post #80

Earlier quoted context omitted.

Good point. But then again, if the engineer is good, switching between say React, Vue and Svelte shouldn’t be too hard. EDIT: To clarify, I mean picking up one of the three if you already know another one.

I 100% agree. I find it troubling that people are 'hiring for React'. How does a developer possibly learn React without learning the core concepts of HTML, CSS, Javascript and thus adapt to any library? It doesn't make sense to me at all.

That would seem so right? I thought so exactly too. This works when your engineering team is small. But once you go beyond the first level of engineering and its mostly maintenance and updates, the people who apply for the job are not interested in learning new things. They have learnt one thing and want to apply that skill 9-5 and go home. For those roles hiring for react is easier.

Re: React I love you, but you're bringing me down

#436

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…

I completely agree. And the thing with different frameworks is they let you scale to varying heights of complexity before you reach those high-level problems. For example, I find that functional components can have more complexity in terms of logic than class components before they become a complete mess. React itself allowed us to go way beyond jQuery before becoming a complete mess. I don’t think there will ever be a framework that saves us from that as long as managers keep doing what managers do.

Re: React I love you, but you're bringing me down

#437

Earlier quoted context omitted.

What's worse, they have interesting "rules" that one really needs to use a linter so their IDE/Text editor gives them friendly reminders. One cannot conditionally call useEffect. One needs to add all dependencies to useEffect's dependency array - BUT that has potential to cause infinite re-renders (especially when using a getter/setter pattern with useState). They encourage DEFINING functions inside of other function…

I agree with the others. I've started using hooks since they were introduced and I've only hit the re-render issue only a few times, which I promptly fixed as they were caused by carelessness. My strategy is to not use a single useEffect, but multiple ones for each (which reduce greatly the dependencies). Also, avoiding dependency circles between useState and useEffect. I've used class components and I think hooks ar…

>Also defining functions inside other functions is very much the staple of functional programming.

Isn't the difference that JavaScript runtimes don't compile them away unlike functional runtimes?

Re: React I love you, but you're bringing me down

#438

The thing that has kept me tied to React is the support for native mobile and desktop development. Expo has been a really nice environment for mobile development compared to some other things I have used in the past. EAS is also pretty handy. It looks like Svelte has improved in this area, but my past experiences with NativeScript were not very inspiring. Is anyone using Svelte for production mobile or desktop develo…

I’ve tried Svelte, but it seemed a lot harder to work with than React. Solid on the other hand is very straightforward. It has a hooks-like appearance, but it’s quite different as functional components are executed only once, so you don’t have silly dependency tracking issues. If I had the time, I’d throw myself into a Solid project.

Re: React I love you, but you're bringing me down

#439
I know it's not the point, but you can generalize the input handler in the first example by using the name of the input field as a key — in most simple forms, at least:

```

const Form = () => {

  const [formData, setFormData] = useState({ firstName: '', lastName: '' });

  function handleChange(event) {
    const { target } = event;
    const { name, value } = target; // Destructuring in steps to make it easier to figure out where values come from.

    setFormData({
      ...formData,
      [name]: value
    });
  }
  

  return (
    
      
      
    
  )
}

```

Re: React I love you, but you're bringing me down

#440
post #428

Earlier quoted context omitted.

Because the dependencies for hooks have to do with re-rendering the component or recomputing the value, not with the usage of the dependencies themselves. That cannot be inferred by the framework without taking a one-size-fits-all approach that probably fits no one particularly well.

Huh? react-hooks/exhaustive-deps does exactly that: it statically infers dependencies and is very noisy if you forget one, and the React team recommends that you always have it on. In fact, the React docs have this to say, right in the documentation for useEffect ( https://reactjs.org/docs/hooks-reference.html#conditionally-... ): The array of dependencies is not passed as arguments to the effect function. Conceptual…

The useEffect dependency array defines the values for which you want the effect function to trigger any time those values change.

It is not always the case that you want an effect to trigger for every value used inside of an effect. Sometimes you only want an effect to run once (i.e. the empty array passed as deps). Sometimes a value changes too frequently to list as a dependency: https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...

Post reply on HN