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.
> How much innovation is needed
Enough to make it worth it to switch, but not so much that it's hard to switch
> often iteration is better and cheaper
Fortunately React has had major changes over its lifetime that iterating with React was/is the better and cheaper solution.
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…
Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the browser. I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.
> I promise writing applications for the browsers is not challenging.
Yeah it is. I don’t like React but I’ve been doing this since the days of MooTools all the way through Backbone to the libraries we have today. Once your app reaches a certain size and/or reaches a critical mass of contributors it does get challenging and modern frameworks reduce that challenge.
That can be taken way too far. Almost every time I’ve worked with Redux I’ve found it infuriatingly unnecessary. And React is far from the best framework out there. But it is a huge benefit all the same.
Many functions can only be called in a certain context. Calling them "not functions" is misleading imo because it implies those functions are compiled out or something, like `$state()` in Svelte.
Yeah they themselves are functions but how they're called are managed by a complicated system, I think treating them as a separate new concept is less misleading than calling them plain functions
Well they aren't plain functions, they're like lifecycle methods for the component with an implicit `this`. Perhaps that's how they should be described.
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.
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.
It's usually not the framework that causes apps/sites to be slow.
Not directly, but when you have devs who only know how to build with the framework and don’t have a grip on what’s going on under the hood or how it all interacts in the browser environment (increasingly common), performance is sure to take a hit.
It's not React's fault that people either don't know what they're doing, or don't care enough to make their software performant. This is not a new phenomenon, bad/rushed software has always existed.
Front-end has seen plenty of innovation, so much that it causes a lot of burnout. So many people seem to want to reinvent the wheel for various reasons - to get recognition, to do things their own way, etc., while the existing trending tech hardly sees the surface scratched and continues to work just fine for most workloads. >“But proven at scale!” jQuery was proven at scale too. Past success doesn’t guarantee future…
JQuery has plenty of good functionality, but you're going to have a really bad time building non-trivial applications as a team if that's all you are using. Because it's just a library, not an opinionated framework, keeping everything consistent across a development team of varied tenure and experience levels will be a herculean effort.
And yet people do it, and have no problems doing it - I know this for a fact as one project I work on is built on jQuery with a team of several developers. We do just fine with our medium-level non-trivial applications. React really doesn't make things that much easier, and often complicates things that should be simple. Just like with React, it entirely depends on how you approach building the thing. You can certainly fuck up a simple React project too.
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…
Not unless you can develop an equivalent to React Native. That's the rub here: browser tech is just way slower than what can be achieved with native code. React's primary value (now) is deduping GUI development across platforms.
It's ironic that the chorus of "frameworks come and go, everything will be replaced in 3-5 years" has turned into chiding people for choosing the stable option.
> React didn’t win purely on technical merit A sentence written by someone who clearly hasn't worked on a large Angular 1.x project.
Yes, this is probably the wrongest statement. When React was launched, it was one in a pool of thousands of web frameworks. For any axis you want to claim that React won by "default", there was another framework that dominated React in that axis and lost anyways. Some frameworks had more resources and lost (Angular), some of which were more popular and lost (jQuery, Backbone), and some of which were even more hyped t…
Upvoted despite your final sentence being incorrect. :-) You're absolutely right that React is miles better than Angular, but Svelte and Vue (which feel very similar to each other, I just switched from one project written in Svelte to a different project written in Vue and a lot of my knowledge is carrying over) are quite a lot easier than React. When I write in React I have to think about the hooks and when I'm initializing them; when I write in Svelte or Vue the $state/ref() systems just work and I don't have to think about them. I can even initialize a $state inside an if block if I need to; I admit I'm no React expert, so I should ask you. If you needed to create a piece of state inside an if block in React, how would you do it? Is the only answer "Move the hook call outside the if block, and just don't use it if the if block doesn't run"?
With Mint ( https://mint-lang.com/ ) I'm trying to move away from frameworks in a language to the language being the framework — having abstractions for things which are done by packages and frameworks like components, localization, routing, etc... done in the language itself. This means that in theory the backend/runtime can be replaced (and was replaced ones from React to Preact (0.7.0 -> 0.8.0) then to use hooks a…
I remember seeing Mint quite a few years ago. I love the idea, I really like the language design, but I agree 100% with your take on the drawback. It's hard to sell that to teams. What's surprising to me is how many alternatives exist in this space. Between elm, imba, svelte, and mint, and probably more that I don't know about, I wonder how many devs in the world are shipping to prod using them. edit: have you though…
> have you thought about including Form Validation to the core lib?
There is a module for that in the standard library (https://mint-lang.com/api/Validation). Moving the functionality into the language level is intriguing.