It's pretty frustrating trying to compare the advocacy efforts in the wc community with what your team is blessed with.
Not quite sure what you meant by this, but I'd like to emphasize we don't currently have developer advocates working on React web. People you might talk to on Twitter are just JS engineers who happen to work on it and like open source.
But server-side rendering is beyond the scope of the question "what should be the web's component model" in my humble opinion.
Maybe. It's in the scope of "how to write a performant application" though, which is why a lot of people care about it. Since it's in the scope of what React does (and perhaps holistic thinking like this is part of the reason people don't hurry to ditch React), we need to consider any decisions there very carefully ā especially because they impact the web component communities too.
The same goes for all other things we consider our concerns (such as dynamic loading of UI code). They might not be low-level enough to be in the spec, but we think it's much easier to write product code when the component abstraction is aware of them. Which is why we think it's worthwhile to keep working on React.
Overall it doesn't seem like we disagree on many things? I wish these discussions were less polarized in general, as they keep being about how we need to ditch one and use the other whereas the tools are more complementary in nature. My personal impression has been that web components solve organizational problems more often than technology problems (e.g. how to share UI between teams that don't want to agree on a library). But those absolutely are valid problems, and it's great if we can have solutions to both spectrums.
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Overall it doesn't seem like we disagree on many things?
Yup
I wish these discussions were less polarized in general.
100%
we need to consider any decisions there very carefully ā especially because they impact the web component communities too.
My spidey-sense is tingling. The React team isn't the w3c or the whatwg. Big questions that affect the future of the web should be the purview of standards bodies, not library authors. I'm not against awesome JS that makes things work in lieu of agreed-upon standards, (and let me take a moment to praise your team for their technical accomplishments) but we have a standard component model now - one that's not just theoretically standardized but also universally implemented (!RemindMe 6 months or so when Edge releases support).
It happens to be that I prefer not to use React because of VDOM and JSX, which for my use cases are in my (very) humble opinion overengineered. I like hitting save and reloading. I like inspecting a custom element and seeing its DOM properties in the JS console instead of some custom dev tools plugin. I like working without source maps (and if I had my druthers lit-html would be written in JS not TS š). I like standards and I like the web. I don't like it when people think that "web developer" has to mean "react developer"
My main issues are that React's success has made babel and webpack de rigueur requirements (I just spent an hour with a mentee unscrewing babel for a one-file 700 LOC react js script for a wordpress site. Madness!), and that a lot of the advocacy for react has come as mud slinging against standards (and I hope it's clear that I'm not pointing the finger at you personally))
My spidey-sense is tingling. The React team isn't the w3c or the whatwg. Big questions that affect the future of the web should be the purview of standards bodies, not library authors. I'm not against awesome JS that makes things work in lieu of agreed-upon standards, (and let me take a moment to praise your team for their technical accomplishments) but we have a standard component model now - one that's not just theoretically standardized but also universally implemented
This is precisely my point. I think you're both asking that we do implement a tighter WC integration, and also that we don't make any decisions about how it should interop with React (and thus impact questions like server rendering). These are mutually exclusive requirements. And they're the reason we haven't historically been hurrying with this despite efforts like custom-elements-everywhere.com/.
React's success has made babel and webpack de rigueur requirements (I just spent an hour with a mentee unscrewing babel for a one-file 700 LOC react js script for a wordpress site. Madness!)
Re: Babel, fair, although you could use it as a JSX-only transform if you don't care about newer JS features. React doesn't force you to use ES6. I found it curious that people who complain a lot about JSX tend to also love SASS ā which, if you think about it ā is a transform just like JSX.
Re: webpack, this has nothing to do with React. People use it because they write more complex apps, and shipping them as a single bundle without code splitting (or as ES6 modules!) hurts the users. If you don't need bundling, you can use React as a script tag and not do any bundling: reactjs.org/docs/add-react-to-a-we...
a lot of the advocacy for react has come as mud slinging against standards
Let me know when you see it and I'd be happy to chime in! I've also seen a lot of unjustified stabs back at React which doesn't help either.
Can't believe im about to be 'that guy' on an internet forum saying this, but im running out of fingers to count the times I've shook my head after seeing a "use the platform LOL" jab from the React community.
Having said that, I really do appreciate the sentiment of your comments in this thread, and you taking the time to engage in (what feels like an actual fruitful) discussion!
Overall it doesn't seem like we disagree on many things?
I wish these discussions were less polarized in general.
So now that we've established this, perhaps we can all slow down with the mud throwing a bit?
im running out of fingers to count the times I've shook my head after seeing a "use the platform LOL" jab from the React community.
Sure and I'd like to see this fade away. But I think we also both know exactly where this sentiment comes from: the feeling of alienation. Some developer advocates shame developers for large bundles ā and in many ways, this is justified. But often there's a sense that they forget why we ended up here.
React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a <carousel> they get an <aside>. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (Iām not making this up).
Now again, I understand the other side to all of this. Standards are hard etc. But I think the aggressive anti-library message (while promoting a library on top of WCs) coupled with not listening to people's problems has somewhat poisoned the "use the platform" movement. That's why many people perceive it as sarcastic now, unfortunate as it is.
I'd like to see that change though! On the React team, recently we have been tightly working with browser vendors. There is a sense that people are more receptive to hearing things we learned, and we're very optimistic about this progress.
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Not quite sure what you meant by this, but I'd like to emphasize we don't currently have developer advocates working on React web. People you might talk to on Twitter are just JS engineers who happen to work on it and like open source.
Maybe. It's in the scope of "how to write a performant application" though, which is why a lot of people care about it. Since it's in the scope of what React does (and perhaps holistic thinking like this is part of the reason people don't hurry to ditch React), we need to consider any decisions there very carefully ā especially because they impact the web component communities too.
The same goes for all other things we consider our concerns (such as dynamic loading of UI code). They might not be low-level enough to be in the spec, but we think it's much easier to write product code when the component abstraction is aware of them. Which is why we think it's worthwhile to keep working on React.
Overall it doesn't seem like we disagree on many things? I wish these discussions were less polarized in general, as they keep being about how we need to ditch one and use the other whereas the tools are more complementary in nature. My personal impression has been that web components solve organizational problems more often than technology problems (e.g. how to share UI between teams that don't want to agree on a library). But those absolutely are valid problems, and it's great if we can have solutions to both spectrums.
Cheers!
Yup
100%
My spidey-sense is tingling. The React team isn't the w3c or the whatwg. Big questions that affect the future of the web should be the purview of standards bodies, not library authors. I'm not against awesome JS that makes things work in lieu of agreed-upon standards, (and let me take a moment to praise your team for their technical accomplishments) but we have a standard component model now - one that's not just theoretically standardized but also universally implemented (!RemindMe 6 months or so when Edge releases support).
It happens to be that I prefer not to use React because of VDOM and JSX, which for my use cases are in my (very) humble opinion overengineered. I like hitting save and reloading. I like inspecting a custom element and seeing its DOM properties in the JS console instead of some custom dev tools plugin. I like working without source maps (and if I had my druthers lit-html would be written in JS not TS š). I like standards and I like the web. I don't like it when people think that "web developer" has to mean "react developer"
My main issues are that React's success has made babel and webpack de rigueur requirements (I just spent an hour with a mentee unscrewing babel for a one-file 700 LOC react js script for a wordpress site. Madness!), and that a lot of the advocacy for react has come as mud slinging against standards (and I hope it's clear that I'm not pointing the finger at you personally))
This is precisely my point. I think you're both asking that we do implement a tighter WC integration, and also that we don't make any decisions about how it should interop with React (and thus impact questions like server rendering). These are mutually exclusive requirements. And they're the reason we haven't historically been hurrying with this despite efforts like custom-elements-everywhere.com/.
Re: Babel, fair, although you could use it as a JSX-only transform if you don't care about newer JS features. React doesn't force you to use ES6. I found it curious that people who complain a lot about JSX tend to also love SASS ā which, if you think about it ā is a transform just like JSX.
Re: webpack, this has nothing to do with React. People use it because they write more complex apps, and shipping them as a single bundle without code splitting (or as ES6 modules!) hurts the users. If you don't need bundling, you can use React as a script tag and not do any bundling: reactjs.org/docs/add-react-to-a-we...
Let me know when you see it and I'd be happy to chime in! I've also seen a lot of unjustified stabs back at React which doesn't help either.
Can't believe im about to be 'that guy' on an internet forum saying this, but im running out of fingers to count the times I've shook my head after seeing a "use the platform LOL" jab from the React community.
Having said that, I really do appreciate the sentiment of your comments in this thread, and you taking the time to engage in (what feels like an actual fruitful) discussion!
So now that we've established this, perhaps we can all slow down with the mud throwing a bit?
Sure and I'd like to see this fade away. But I think we also both know exactly where this sentiment comes from: the feeling of alienation. Some developer advocates shame developers for large bundles ā and in many ways, this is justified. But often there's a sense that they forget why we ended up here.
React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a
<carousel>they get an<aside>. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (Iām not making this up).Now again, I understand the other side to all of this. Standards are hard etc. But I think the aggressive anti-library message (while promoting a library on top of WCs) coupled with not listening to people's problems has somewhat poisoned the "use the platform" movement. That's why many people perceive it as sarcastic now, unfortunate as it is.
I'd like to see that change though! On the React team, recently we have been tightly working with browser vendors. There is a sense that people are more receptive to hearing things we learned, and we're very optimistic about this progress.
We got scroll-snap
developers.google.com/web/updates/...
developer.mozilla.org/en-US/docs/W...
Great stuff! I'm sure a lot of developers will appreciate this as a move in the right direction.