Live data from Hacker News

What I wish I knew about React

bitsofco.de

191–200 of 301 posts

Re: What I wish I knew about React

#191

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

I've been considering the jump into TS, but I don't want to end up in a coffeescript situation (i.e. language is dead, but code lingers on and has to be converted back to JS at some point, rather painfully). Do you think it's worth it?

Yes. It’s built by Microsoft and has huge adoption. Typescript is here to stay.

Re: What I wish I knew about React

#192
post #190
post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

> so you can scrap that entire connect() stuff alltogether To me that "entire stuff" is about the only thing that is good about redux (barely does dependency injection). See people need to understand that hook is a good API from the library authoring point of view (the react team's and react component library authors') it's not such a clean abstraction for people to write application on top of while unneccesarily mak…

Hi, I'm a Redux maintainer.

Hooks definitely lead you towards a different approach for writing components with a different set of tradeoffs. I talked about this in my post "Thoughts on React Hooks, Redux, and Separation of Concerns" [0], and my ReactBoston 2019 talk on "Hooks, HOCs, and Tradeoffs".

For React-Redux specifically, `connect` still works fine and we will be supporting it indefinitely. However, we're now recommending that people use our hooks API as the default approach, because it's typically simpler to work with and there's less indirection.

[0] https://blog.isquaredsoftware.com/2019/07/blogged-answers-th...

[1] https://blog.isquaredsoftware.com/2019/09/presentation-hooks...

Re: What I wish I knew about React

#193
post #131
post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

HN is a pretty hateful place in general.

If you're coming from Reddit, Imgur or YouTube it seems like hate, but I've found it's simply a lack of humor...

Any jokes, memes or puns are frowned upon the community 99% of the time. I suppose it's considered redundant or not-constructive...

Re: What I wish I knew about React

#194

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

I've been considering the jump into TS, but I don't want to end up in a coffeescript situation (i.e. language is dead, but code lingers on and has to be converted back to JS at some point, rather painfully). Do you think it's worth it?

I just switched a pretty huge project into TS, and I'm seeing for this team and project, probably 4 units of saved time in the PRO column, and 3 units of lost time in the CON column. Still worth it, but you'll need to learn and maintain a new thing, and sometimes doing a totally normal JavaScript thing would force you to write some pretty eldrich type signatures.

Re: What I wish I knew about React

#195

I love React. In fact I recently gave plain vanilla JavaScript a go and it was so painful that I was glad to get back to React's way of organising a large application. I don't use Redux or server side rendering - they're not needed. The only thing that I think it should do differently is leave styles to be handled natively.

Well, for me it was the opposite. Trying vanilla js was empowering!

There was no; tool chain, bundling, virtual DOM, render function, countless layers of library abstraction, sourcemaps, node_modules... etc. Just a simple index.html file

Some projects don't require a state of the art virtual-DOM-diffing-machine, just to display a list of ToDo items...

Re: What I wish I knew about React

#196
post #166

Earlier quoted context omitted.

I love React and write it, in Typescript, on a daily basis. However: - It starts you off with about 40kB of minified gzipped javascript; some developers feel that it's too much. - It is not and probably never will be the most performant framework out there, which upsets quite a few people (although the work that the React core team is doing with Concurrent Mode probably means that from the end user's perspective Reac…

Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm w…

Personally, I'm super wary of any ____ developer. It's a fixed (vs growth) mindset that tells me they are specialists. I think specialists are best to be consulted by generalists, but not trusted with larger decisions outside their scope.

Re: What I wish I knew about React

#197

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as bo…

> I've always found the best distinction between a framework and the library lies in who-calls-who?

I've heard this referred as the 'Hollywood principle', as in 'Don't call us, we'll call you'.

Re: What I wish I knew about React

#198
post #169

I write a lot of enterprise apps and I’ve seen many many frameworks come and go over the years. I personally am not impressed with React and don’t get what all the fuss is about. We’ve had Angular, jQuery and a whole bunch of stuff over the years and each one managed to become a ‘a thing’ for a while

The mental model for a react component is very much simplified and consistent. You declare how your view looks like, wire up the state and user interaction stuff and you have a self contained puece of code. People doing UI stuff, before the advent of React usually highly appreciate it because they know how much work it takes to actually build a usable UI in vanilla JS.

React introduced this concept into the mainstream but it wasn’t at all new.

Re: What I wish I knew about React

#199
post #169

I write a lot of enterprise apps and I’ve seen many many frameworks come and go over the years. I personally am not impressed with React and don’t get what all the fuss is about. We’ve had Angular, jQuery and a whole bunch of stuff over the years and each one managed to become a ‘a thing’ for a while

React introduced a whole new way of writing GUI's. I come from a game development background, and there we had Immediate GUI's for some time now ( https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutor... ). React basically translates this concept to the web, and does some optimizations to not rebuild the entire DOM from scratch, and only rebuild when state changes and not every frame. Writing a 'render functio…

React introduced this concept ‘to you’ perhaps but it wasn’t the first. The framework I used has been doing this in the very early 2000s.

Don’t get me wrong it has a lot to like about it - but the only revolution is that Facebook’s might propelled this in the minds of developers all over.

Re: What I wish I knew about React

#200

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

I think the "library" vs "framework" argument irt react is pretty silly.

At the end of the day, what difference does it make? React may not be as opinionated as other application frameworks, but it's also non completely un-opionionated.

If you write a full ui in React, whats the level of effort involved to port it back to vanilla js, or even another framework? It's certainly not trivial. IMO that's the only qualifier needed.

But I agree, it's all about marketing.

I do think the "win" that React has here is that it's easy to introduce React into an existing project with minimal overhead. In that sense I think its closer to library than framework, but after enough time you will inevitably end up with a "React app" and not a "web app with some React".

Post reply on HN