There’s probably more. In short problems arise because React implements different event and attribute bindings leading to unpredictability with browser API.
7) At times it seems like prominent members of the React community act like the web begins and ends with React. I don’t agree. I also don’t see this kind of attitude in other JavaScript framework communities. It matters how the people in a community act. Coding is as much about the people as it is the code.
If you use React and love it then keep using React. This isn’t about you. This is about why I avoid a popular framework. I’ve used React. When it first appeared on the scene I was really interested in why they would implement a front end framework this way. I even built a similar framework from scratch that implemented a virtual DOM. Then I realized well the DOM is already a tree. Why do I need to duplicate it? I rationalized that the whole premise for duplicating DOM was flawed. If DOM was not performant then shouldn’t it be the browsers that implement better performance? We don’t need JS frameworks to take up that mantle. A few years later that panned out and browsers have optimized several things. On top of that there are now several ways to declare a component and custom elements are the path forward in my opinion. That isn't to say a library like React still won't be useful. Custom elements still may require some pattern for managing state in your project. But that paradigm is much more for Redux to handle than React IMHO, or some other state pattern.
If DOM was not performant then shouldn’t it be the browsers that implement better performance
I think it comes down from the fact that there isn't yet an easy way to create reusable components natively in the browsers, which is why React and the likes were there in the first place. If we're going to wait until browsers catch up, I remember seeing Web Components specs a few years ago and it doesn't seem to be completing any time soon. I think people love implementing their own solutions when there isn't any available, at least I do.
But I hear you. I wish more efforts were there to improve the browsers or the specs instead, maybe by the community, but I think it's a different problem.
I'm curious tho, if you're not using React, what's your frontend framework of choice? Nevermind, saw your comment below mentioning Angular.
Have you looked at Stencil? It’s a library that compiles down to Custom Elements v1 and promises interop between all the major frameworks. With a 133 byte “Hello World” it relies heavily on browser spec. The browsers already caught up years ago. You can build reusable components solely with browser spec today.
Whoa, TIL! Thanks for the info. All I remember that it was stuck until the spec level, never got around being the official fully usable feature on the browsers. I guess I should look into it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
2)
There’s probably more. In short problems arise because React implements different event and attribute bindings leading to unpredictability with browser API.
7) At times it seems like prominent members of the React community act like the web begins and ends with React. I don’t agree. I also don’t see this kind of attitude in other JavaScript framework communities. It matters how the people in a community act. Coding is as much about the people as it is the code.
If you use React and love it then keep using React. This isn’t about you. This is about why I avoid a popular framework. I’ve used React. When it first appeared on the scene I was really interested in why they would implement a front end framework this way. I even built a similar framework from scratch that implemented a virtual DOM. Then I realized well the DOM is already a tree. Why do I need to duplicate it? I rationalized that the whole premise for duplicating DOM was flawed. If DOM was not performant then shouldn’t it be the browsers that implement better performance? We don’t need JS frameworks to take up that mantle. A few years later that panned out and browsers have optimized several things. On top of that there are now several ways to declare a component and custom elements are the path forward in my opinion. That isn't to say a library like React still won't be useful. Custom elements still may require some pattern for managing state in your project. But that paradigm is much more for Redux to handle than React IMHO, or some other state pattern.
I think it comes down from the fact that there isn't yet an easy way to create reusable components natively in the browsers, which is why React and the likes were there in the first place. If we're going to wait until browsers catch up, I remember seeing Web Components specs a few years ago and it doesn't seem to be completing any time soon. I think people love implementing their own solutions when there isn't any available, at least I do.
But I hear you. I wish more efforts were there to improve the browsers or the specs instead, maybe by the community, but I think it's a different problem.
I'm curious tho, if you're not using React, what's your frontend framework of choice?Nevermind, saw your comment below mentioning Angular.Have you looked at Stencil? It’s a library that compiles down to Custom Elements v1 and promises interop between all the major frameworks. With a 133 byte “Hello World” it relies heavily on browser spec. The browsers already caught up years ago. You can build reusable components solely with browser spec today.
Whoa, TIL! Thanks for the info. All I remember that it was stuck until the spec level, never got around being the official fully usable feature on the browsers. I guess I should look into it.