Also - as the article mentioned - everybody knows react.
This are two reasons why picking react is almost every time the right choice.
How the internal rendering works and if it is a little faster or slower is just an implementation detail.
431–440 of 866 posts
Also - as the article mentioned - everybody knows react.
This are two reasons why picking react is almost every time the right choice.
How the internal rendering works and if it is a little faster or slower is just an implementation detail.
React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.
How much innovation is needed. often iteration is better and cheaper.
I do think that React in its history has been able to evolve quite meaningfully, and in a good way (lifecycle methods -> hooks), but in the more recent years, less so.
Earlier quoted context omitted.
React was innovative when it just appeared 12 years ago. But a few years after there were already many other frameworks doing similar things. And since then it has been good enough, but not the leading innovative frontend framework anymore. React has rather matured in dealing with it's own outdated Virtual DOM design, making it much more boiler platy than modern alternatives.
What metric would you use to define the leading frontend framework, and what is it? I'm familiar enough with Angular, React, Flutter, Vue, and Svelte as big names in the ecosystem, but have really only done scrappy development with React and not much with the others. Google trends seems to show React is still a leader [1], and React has more than double the amount of Github stars than any of the others I've mentioned…
This is mostly just a complaint about how good React is. It's so good that it's difficult for the technical benefits of alternatives to outweigh the social benefits of choosing React. Note that this is neither a major compliment to React's technical merits nor a criticism of React's competitors. In fact, I don't even disagree with the author on some of his claims, such as: > React is no longer winning by technical me…
Never heard, "man react is great!" It's always, "we can hire more easily". Unfortunately
Is this the synonym for cheaper workforce? You always get decent people if you pay enough.
Earlier quoted context omitted.
We should probably be making widget toolkits for the Canvas and using WebSockets for communication. DOM manipulation is a total hack-job. It's somewhat flexible, but the performance and dark-pattern cost is just too great. If you're making an interactive application, then treat it like an application and draw widgets to a canvas.
This is an insane take, show me a responsive button with hover state and a tooltip implemented in the canvas that outperforms a button rendered with React.
Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…
I'm wholly convinced that only people who have never tried to use web components for anything serious, and/or have basically no experience with web dev, are the only ones will make this argument. For example, a guy I know online who is an argumentative, boring backend dev that regularly has really bad and uninformed takes on things he has very limited experience with, he recently said he prefers web components. For a…
About once a year I give web components another shot and rediscover all the things I hate about them. They are not designed for what web developers consider components and they are full of footguns and bizarre limitations.
Sometimes you will hear this subtly acknowledged as “web components excel at leaf nodes”. What this means in practice is that you shouldn’t use them for things that have contents. They are fine for their original use case, form elements where you don’t want page styles to affect things like the drop-down arrow in the control. But they are a massive disappointment for the typical use case.
React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.
I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…
React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.
Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…
I worked on a business app made with lit web components and all properties being stringly typed was a real drag. It didn't compare to a realtime-first component library.
For instance, I have a project with a small web component that displays data from a duckdb wasm connection. The connection object is passed as a property and it works flawlessly.