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?
What I wish I knew about React
191–200 of 301 posts
Re: What I wish I knew about React
#192I 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…
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
#193I 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.
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
#194Earlier 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?
Re: What I wish I knew about React
#195I 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.
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
#196Earlier 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…
Re: What I wish I knew about React
#197React 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 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
#198I 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.
Re: What I wish I knew about React
#199I 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…
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
#200React 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…
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".