241–250 of 301 posts
Earlier quoted context omitted.
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...
That is true, but it not just the lack the humor, it is the pretentiousness and the faux-politeness.
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…
this has been my experience too, I'm a full stack engineer playing a devops role right now on a greenfield govt project. Getting our CI/CD pipeline going within our environment constraints with react has been a pain in the ass. Every time something goes wrong the front end dev just kinda throws his hands up and basically tells me its my problem. I ended up having to go through all the issues opened on github to find solutions and implement them myself. I'm no javascript expert but to me the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.
I was on a project supporting legacy code for a long time before this, and was quite looking forward to working with newer js frameworks but this left a sour taste in my mouth. And I already had a bad impression of react prior. I might look into pushing for some of the alternate frameworks out there.
React isn't a library. You can't drop a bit of it into your project. It distorts how you build the webapp. jQueryUI is a library. You can add it in and your code is still vaguely the same. React is a framework pretending to be a library so people can't say "Oh, what? another framework?" As soon as you use React, you're in the react universe, not the normal webdev universe. With a normal webapp, I can just import an e…
(I don’t disagree with anything else you said)
Earlier quoted context omitted.
But what good are classes if you're not doing object-oriented programming? React classes are just stateful wrappers around a pure render function. It's not idiomatic and frankly dangerous to do anything you would with a regular ES6 class with a React.Component.
Can you clarify on that last point a bit? Not that I extend React.Component these days, but far as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended. I guess, yes, there's different semantics between the constructor and componentDidMount, but it's UI library, this is common that "when a constructor is call there is no guarantee the component has actually mount…
Earlier quoted context omitted.
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…
> If you call `ReactDOM.render` in multiple places Nobody uses React that way. Besides, React is still very much the one calling you when you're dealing w/ lifecycle methods, useEffect/useCallback, suspense, etc.
Hi. I make complicated web UIs. I call React that way sometimes, because sometimes you don't want your entire UI to be one big React component.
Earlier quoted context omitted.
Is React Native performance really good? Compared to what? I've found RN performance passable but underwhelming. It seems generally worse than a good native UI, and no better than a mobile web UI. I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and le…
> Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.) My experience was that RN was way more helpful on Android than on iOS, in general. But that has more to do with Android than RN, which achieves its utility on that platform by papering over a pile of bad decisions, inexplicable awkwardness, and half-finished-apparent…
The tools are starting to get fairly good on Android. There’s a lot to like about Android Studio. But the actual platform APIs are still a mess.
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?
Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.
React isn't a library. You can't drop a bit of it into your project. It distorts how you build the webapp. jQueryUI is a library. You can add it in and your code is still vaguely the same. React is a framework pretending to be a library so people can't say "Oh, what? another framework?" As soon as you use React, you're in the react universe, not the normal webdev universe. With a normal webapp, I can just import an e…
You can just add the bootstrap CDN in the head of your index.html and use bootstrap without installing ‘react-bootstrap’ (I don’t disagree with anything else you said)
Earlier quoted context omitted.
Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge…
I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest. For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manuall…
The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.