Doesn't make sense to me.
Chrome V8 needs zero outside help either declaritively or imperatively.
There's nothing rect does better than V8 to my k kwledge.
Do we write front end apis in front of existing apis to make things faster? If we do then that's bad architecture. That's you argument here. React sits in front of V8.
The entire React, Angular and Vue phenomenon has hit their peak reason for adoption other than legacy continuation and familiarity. This is known as 'Golden Handcuffs' Being chained to yesterday's architecture. It's not all bad as Cobol has shown. But Cobol today has little space in Greenfield projects.
As new DOM And ECMA standards arrive, 3rd party magic outside of the web component architecture diminishes.
They will not be cutting edge, like Jquery due to one single tech spec like QuerySelectorAll.
You’re not just writing code that will be visited on v8. You’re writing for a dozen different browsers of varying compatibility with modern javascript and react’s ecosystem allows for many build chains right out of the box (cra, gatsby, next... they all handle webpack/Babel config that works perfectly 99% of the time). No such ecosystem exists or will ever exist for web components.
Yes we write apis on top of apis on top of apis on top of apis. That’s software
Btw- comparing react to v8 is apples to oranges. V8 is an engine. Saying react doesn’t do anything better than v8 makes no sense at all. V8 provides an api for our javascript to move machine code through the browser, basically. React is a tool to write that javascript that the engine will consume. React does a lot of things v8 doesn’t and v8 does a lot of things that react doesn’t. In fact, they don’t do anything that the other one does. In fact v8 is written in c++ and react is javascript.
Why put react in front of a browser API? That's just one more layer.
No speed improvement, No faster processing
Means that React takes no time to process anything, simply not true.
EC2 containers
Have nothing to do with this discussion. Bare metal means direct interface with ECMA standards and in my case, Google's V8 engine. I never mentioned what hardware or software that it runs on. I'm talking about the direct interface to V8. React does nothing for V8 that V8 doesn't already do.
Web components will never replace React
That's true, just like C++, C# and Java never replaced Cobol. All four supporting imperative and declarative styles. Each claimed they were better, faster etc. Cobol (just like everything else) is it's own domain, it's own legacy framework, it's too big to die. Same is true for React.
Let's not forget that there are dozens of frameworks built on top.
I never said anything regarding this point; however there's probably 100,000 times more just plain old Javascript libraries available now than React components. Just because they are there means nothing except for picking React or any other [just because the eco system appears rich and there's something there desired]. One of the things I've found is that many of the open source offerings are rife with bad architecture, terrible api discoverability and even have large NPM liabilities. None of that part is discovered until after the component is prototyped.
React will live forever, for sure. I'm not saying it will die, I'm only saying that Web Components are a direct interface to V8 which to me is better! Remember, simple things like the new QuerySelectorAll killed JQuery in one day. But do you know that JQuery is still the #1 Framework in 2020? It's just living on it's legacy, just like Cobol.
The ECMA standards are beginning to catch up to the 3rd party solutions. When they do those solutions are self sunsetting except for those locked into the "adopted" framework of 5 years ago.
Saying react doesn’t do anything better than v8 makes no sense at all.
Let me try to understand this: We have a V8 engine, Fined tuned to the max, and but we know that there are better things React does, merely by using the V8 Api's differently in some fashion? I don't believe that, what I believe though is that React wanted and did create it's own opinionated way of doing things. It covered the V8 Api to it's adopters to implement it's architecture. One of them being Custom Elements ala React way.
I don’t think you have a very good understanding of how a browser works. You brought up “closer to metal” which is a term for servers that are not containerized or partitioned.
You are right about ecma standards sun setting some features of libraries and frameworks, which is what happened to ember with their ember object.
But that’s not comparable to react as react doesn’t provide features you’d ever want in a browser engine. State management and/or integration with state management. Build tool chains. DOM updating. These are all things that will never be a part of javascript as a language because they aren’t language problems. They are problems that happen when you start building complexity.
Doesn't make sense to me.
Chrome V8 needs zero outside help either declaritively or imperatively.
There's nothing rect does better than V8 to my k kwledge.
Do we write front end apis in front of existing apis to make things faster? If we do then that's bad architecture. That's you argument here. React sits in front of V8.
The entire React, Angular and Vue phenomenon has hit their peak reason for adoption other than legacy continuation and familiarity. This is known as 'Golden Handcuffs' Being chained to yesterday's architecture. It's not all bad as Cobol has shown. But Cobol today has little space in Greenfield projects.
As new DOM And ECMA standards arrive, 3rd party magic outside of the web component architecture diminishes.
They will not be cutting edge, like Jquery due to one single tech spec like QuerySelectorAll.
You’re not just writing code that will be visited on v8. You’re writing for a dozen different browsers of varying compatibility with modern javascript and react’s ecosystem allows for many build chains right out of the box (cra, gatsby, next... they all handle webpack/Babel config that works perfectly 99% of the time). No such ecosystem exists or will ever exist for web components.
Yes we write apis on top of apis on top of apis on top of apis. That’s software
Btw- comparing react to v8 is apples to oranges. V8 is an engine. Saying react doesn’t do anything better than v8 makes no sense at all. V8 provides an api for our javascript to move machine code through the browser, basically. React is a tool to write that javascript that the engine will consume. React does a lot of things v8 doesn’t and v8 does a lot of things that react doesn’t. In fact, they don’t do anything that the other one does. In fact v8 is written in c++ and react is javascript.
We’re waaaaay out in left field here
Why put react in front of a browser API? That's just one more layer.
Means that React takes no time to process anything, simply not true.
Have nothing to do with this discussion. Bare metal means direct interface with ECMA standards and in my case, Google's V8 engine. I never mentioned what hardware or software that it runs on. I'm talking about the direct interface to V8. React does nothing for V8 that V8 doesn't already do.
That's true, just like C++, C# and Java never replaced Cobol. All four supporting imperative and declarative styles. Each claimed they were better, faster etc. Cobol (just like everything else) is it's own domain, it's own legacy framework, it's too big to die. Same is true for React.
I never said anything regarding this point; however there's probably 100,000 times more just plain old Javascript libraries available now than React components. Just because they are there means nothing except for picking React or any other [just because the eco system appears rich and there's something there desired]. One of the things I've found is that many of the open source offerings are rife with bad architecture, terrible api discoverability and even have large NPM liabilities. None of that part is discovered until after the component is prototyped.
React will live forever, for sure. I'm not saying it will die, I'm only saying that Web Components are a direct interface to V8 which to me is better! Remember, simple things like the new QuerySelectorAll killed JQuery in one day. But do you know that JQuery is still the #1 Framework in 2020? It's just living on it's legacy, just like Cobol.
The ECMA standards are beginning to catch up to the 3rd party solutions. When they do those solutions are self sunsetting except for those locked into the "adopted" framework of 5 years ago.
Best of All
Web Components do not rely on NPM!
Not true for us, we are writing only for Chrome and Edge currently both are V8.
Let me try to understand this: We have a V8 engine, Fined tuned to the max, and but we know that there are better things React does, merely by using the V8 Api's differently in some fashion? I don't believe that, what I believe though is that React wanted and did create it's own opinionated way of doing things. It covered the V8 Api to it's adopters to implement it's architecture. One of them being Custom Elements ala React way.
I don’t think you have a very good understanding of how a browser works. You brought up “closer to metal” which is a term for servers that are not containerized or partitioned.
You are right about ecma standards sun setting some features of libraries and frameworks, which is what happened to ember with their ember object.
But that’s not comparable to react as react doesn’t provide features you’d ever want in a browser engine. State management and/or integration with state management. Build tool chains. DOM updating. These are all things that will never be a part of javascript as a language because they aren’t language problems. They are problems that happen when you start building complexity.
This conversation is over from my side. Good day!
I think this statement is ridiculous.
Browsers manage their own state perfectly, in particular DOM updating. As far a build tools there are many other options unrelated to React.
Ok.