231–240 of 309 posts
I choose React for personal projects because it's easy. I'm not too concerned with performance. This article doesnt spend much time on developer experience.
Earlier quoted context omitted.
How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years. It's made me want to leave the industry completely and I honestly think I will after this project. It has single handedly slaughtered and destroyed my quarter century love affair with programming. It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy…
I have a really hard time relating to the conclusion of this. In a big React codebase there are certainly a lot of indirection and "artificial" barriers. The React ecosystem is indeed turbocharged and confusing, atleast if you are trying to follow the latest trends. However, there is atleast a method to the madness. Compared to the bowls of jQuery spaghetti that was used to bring SSR apps to life back in the days, th…
It's unfair to compare a highly over engineered React application vs a lazily built jQuery mess.
Earlier quoted context omitted.
React optimization problems are more than just CPU; React encourages lots of little requests in such a way that no amount of computing power can tackle. Coupled with other flawed but popular design antipatterns like skeleton screens, performances is abysmal. Not just long page loading times but browser and machine freezing slowdowns. BitBucket and Jira have gotten so much worse since they moved to React. With all my…
Proof of this: https://old.reddit.com/ vs https://reddit.com/
> unloved, unpopular, uncool things like Django, Rails, Laravel Oh they're loved all right, it's just that they're (all three) very mature, packed with features, easy to pick up and people who work with them don't have a reason to sit around and discuss the tools. I work for a smaller Rails shop and the atmosphere is just so nice there. We work on small (think $20k) projects for different niche customers, we absolute…
One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…
Earlier quoted context omitted.
> Most large companies are working on honest-to-god SPAs. Most devs don't work at large companies, at least not tech oriented large companies. I'm almost certain most projects don't come out from such companies either, statistically. In fact, most projects are not SPA, nor using any kind of AI, Big Data, or another buzzword. So I don't think that's it. I think that large companies are just the loudest, also creating/…
> Most devs don't work at large companies. that would be very surprising. Companies like IBM, Microsoft, ATOS, CapGemini ... employ literally hundreds of thousands of devs each
One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…
Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, the…
Earlier quoted context omitted.
That's true, but it seems like WinForms is basically a dead end at this point, not much maintenance work is put into it and you have to jump through some serious hoops to make basic stuff like DPI scaling work even last I checked. Completely agree though, the 3rd party component story is very good on .NET, but the applications you're producing don't exactly have a modern look and feel unless you're investing serious…
Coming off of an extremely disappointing Build - I don’t think any news even made it to HN this year, and not a peep about desktop - I agree that the future is unclear. WinUI is the future, but they’ve admitted it will be years before it reaches the maturity of UWP, which is embarrassingly bad even 5 years on. WPF, in my opinion, is the best choice for “native” windows apps. The actual best choice is Electron, as mos…
The migration wizard for .NET apps was a CLI script, really? In the land of "Developers, Developers,.." and GUI wizards.
Maybe if enough of us keep doubling down on Forms/WPF/Win32 and ignore the whole WinUI/Reunion reboot, they finally understand want we really want for desktop Windows.
Earlier quoted context omitted.
I don't think it makes sense to say "React is a library because you can forego using enough of its features to fall below some arbitrary line". Please note that I’m not arguing that React itself is or isn’t a framework. I’m simply saying that it can be used in multiple and qualitatively different ways, in contrast with your own position in the comment I originally replied to. In particular, nothing stops you from usi…
> it can be used in multiple and qualitatively different ways, in contrast with your own position I agree React can be used in different ways but as I already pointed out earlier, this is a not-particularly-notable characteristic shared by a variety of frameworks, so what you're saying is more of a tangent (i.e. that a tool within a class of flexible tools is itself flexible too) than a contrast to anything I said (i…
You originally wrote, in the comment that I first replied to:
- It "calls you" (i.e. you never explicitly call your React components, React does)
This is clearly true, but as we have established, merely having a library call back into your own code is not a defining characteristic of a framework, because we all agree that the sort and Lodash examples aren’t frameworks.
I don’t think you’ve ever properly addressed my point that calling ReactDOM.render may only differ from these examples in terms of scale. You gave an obviously contrived example of importing Ember and not doing anything, but you can import React and use it to render component trees usefully efficiently — its raison d’être — simply by calling render when you need to, without relying on tools like state or hooks to trigger updates.
When people talk about React not being a framework, I believe this is what they usually mean. You can use it as a library just for handling your view rendering — “the V in MVC” — and you can call that functionality on demand and handle any other responsibilities your application has somewhere else using whatever code or libraries you like.
- It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much)
I have migrated more than one substantial web UI from another rendering system to React. It was just like swapping out any other library. Most of the codebase didn’t know the previous rendering system existed before and didn’t know React existed afterwards.
I would like to emphasize that this is completely normal software development. Nothing I did during those migrations was novel or specific to front-end web development.
However, you can’t swap rendering libraries like that if you choose to tangle the other responsibilities of your application with your rendering logic, for example by doing other things inside your React components. In that situation, you are no longer separating concerns cleanly, and of course you will have more difficulty if you want to change your rendering library when you have you have tied the rest of your software architecture to it as well.
- It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc)
I have built and maintained more than one substantial web UI that used React and yet still had a clean separation of concerns along the lines of MV*. You use React for the V. You use the other parts to handle other responsibilities and to determine what data to pass into the V for rendering using React.
Obviously the “V in MVC” approach emphasizes using React for rendering, while managing other responsibilities like state and remote API calls in other ways. That means you’re not going to be using a lot of hooks, or class component state and lifecycle methods, because you won’t much need them. I’m not arguing that this is the only way you can use React, and clearly some people prefer to use those other React features more and their software designs will differ accordingly.
But contrary to your claim that I quoted above, React does not enforce a specific architecture. It does not stop you from adopting other strategies for designing applications and managing UI code that have proven to be effective elsewhere in the software world, and those strategies can be used as effectively with React as any other rendering library.
Those are the three specific claims you made that I first responded to because I don’t fully agree with them in the context of React. If your argument is that React is a framework because those claims are defining properties of a framework and React has them then evidently we disagree about that conclusion. But IMHO terminology isn’t as interesting as exploring different ways React can usefully be employed and the guarantees it gives and restrictions it imposes in each case, whatever we choose to call them.