No real point here, but I do find it curious that there is this tendency to build new UI frameworks all the time.
Personally, I still like html + js (and I have used React).
The're frameworks and design systems. A React UI framework refines or enhances the React process to build UI components or design systems.
Bootstrap e.g. is 2 things in 1, it's a process/framework and design system that sits directly on top of html, css & js.
Those are not standard, some people like VDOM other not, and not everybody want to bind data the same way. So if we all contributed components in vanilla JS / Web Components, this still doesn't solve what should the API of those webcomponent look like.
With Web Components you're back in the land of saving element references, querySelector, addEventListener, and string-only attributes. It sucks. If you want something more like what React provides, where attributes (props) can be objects, functions, other React elements, etc. then you need to use a library (e.g. Polymer) that's just as non-standard as React is.
> The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of `<Button appearance="primary">` they would do `<evergreen-button appearance="primary">`.
If you're not using React, you obviously can't do `onClick={...some function here...}` with Web Components, you have to use the shitty DOM APIs.
But I would expect this still would not work as expected with props like `children` or other props that accept React elements. It seems like the web component would be expecting Node instances, not React elements. Since components can decide whether or not to render their children, they wouldn't be backed by Nodes yet when the web component received them. So it seems like it'd have to know whether it's dealing with React and use ReactDOM.render directly.
IMO saying 60kb of react+vdom code vs 6kb of templating library that builds on top of template literals is equally non-standard is not a fair comparison.
That's what makes the grandparent's statement incorrect:
> The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of `<Button appearance="primary">` they would do `<evergreen-button appearance="primary">`. That's it.
^ wrong.
I agree in principle but it's up to browser vendors to implement specs, and it is always the same offender that is dragging his feet.
On mobile Web 100% of the browsers support Web Components.
https://www.webcomponents.org/
So what are the many popular browsers you refer to? As anything else is meaningless.
Your statement makes no sense whatsoever, they are "only missing" 2 of the most fundamental features of web components? that would actually help getting rid of all these incompatible UI toolkits? I don't call that supporting Web Components at all if you can't write custom elements natively. You obviously do not understand how the lack of support for custom element and shadow DOM affects Web Components adoption.
Not supporting 2/3 of a spec is not being compliant with that spec, obviously.
That leaves only IE11/Edge with polyfills.
what polyfills are you talking about? And no, Polymer is not a polyfill for custom element. Please link me to a library that will polyfill the entire shadow DOM and Custom Element spec so that I can write the same code without polyfills on platforms that support both specs and only load the polyfills on platforms that do not.
Quote from the readme.
" A suite of polyfills supporting the Web Components specs:
Custom Elements v1: allows authors to define their own custom tags (spec, tutorial, polyfill).
Shadow DOM v1: provides encapsulation by hiding DOM subtrees under shadow roots (spec, tutorial, shadydom polyfill, shadycss polyfill). "
https://github.com/vuejs/vue-web-component-wrapper
"You will also need the Shady DOM + Custom Elements polyfill." from Vue docs. Same polyfills are used by svelte etc.
Plus there are polyfills available for the meantime.
So what other browsers are many popular?
Apparently you haven't read my first comment either, since you can't tell the difference between "a spec is implemented" and "planning to implement a spec" which you obviously count as "a spec is implemented" for you or you would have refrained from making your first comment.
And no, there is no polyfills for shadow DOM or Custom Element, that's a lie. Polymer is not a Polyfill for Web Components, it's his own framework.
As for your question, I'm talking about browsers that do not support Custom Elements right now. Edge does not.
Firefox already on beta.
As for Edge it is already in development, and to be honest it doesn't matter with its insignificant market share.
When Microsoft employees use only Chrome at BUILD to show Azure and .NET Core MVC features, the writing is on the wall how relevant the browser is on the market.
Still you keep running away to clarify what "many browsers" means.
Maybe it is my lack of native English skills, but Edge being a single browser is far away from being "many browsers", even if we include Firefox until they get out of beta, two still does not make "many browsers".
Market shares are not the same across countries, clients or even industries. That's the first mistake you are making. If I develop a product, I target whatever browser my customers use, not some world wide statistic that has very little local significance.
You just don't get to ignore what goes against your point just to feel that you are winning an argument, that's childish.
> 100% on mobile Web.
Which is False, Firefox on Android doesn't support web components.
> Firefox already on beta.
Which doesn't matter if support has not shipped. "will ship" is not "has shipped". I am only interested in current support, as we speak, I was never talking about "will eventually ship" since I don't work with eventual features, obviously.
Mobile web is all about Safari and Chrome.
Again you keep avoiding to explain what "many browsers" means.
Edge cannot be ignored if one is serious about any kind of business: that's 3-4 out of every 100 desktop users (existing or potential customers), or 'just' 2/100 if one includes mobile.
— Honestly, it seems that you are trolling. But I post the above stats in case you are not. But I also back it up with my own personal 'anecdata': I build business-to-business ecommerce, in our specific market our users are primarily (>95%) using desktop browsers, we have many thousands of existing business relationships, we cannot mandate which browsers they use — we draw the line at having the site simply work in all "modern browsers", which obviously includes Edge.
It doesn't really matter whether it's "many browsers" that don't support Web Components, or whether it's just one major browser. For many businesses, choosing WC is simply not a viable option for the foreseeable future.
[0] No affiliation, just googled it. [1] https://netmarketshare.com/browser-market-share.aspx
I have written already in multiple answers, it is the customers that decide which browsers should a given project support, by explicitly stating them on the project delivery contract.
So your customers care about EDGE, fine. Many don't.
Er, really? I use Edge. It's just what's standard on the Windows machine I bought. I can't imagine that it has insignificant market share...
As for actual market share, http://gs.statcounter.com/browser-market-share
If it doesn't make the list, it is a nice to have only, in case someone on the team bothers with it.
Microsoft by using mostly Chrome at BUILD 2018 has given the sign to many businesses that it isn't worthwhile to list EDGE as a requirement.
So Edge is the only browser missing 100% native support right now.
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
> On mobile Web 100% of the browsers support Web Components.
Wait. Which is it? Or are you ignoring Firefox Mobile?
Also polyfills are separate thing from polymer - they are reused by ALL other frameworks including vuejs for example, so I'm not sure what you meant by that comment.
It's a super-lightweight base class for web components, and a descendant of the Polymer framework.
A Material Design framework uses this: https://github.com/material-components/material-components-w...
It's a bit disheartening to see titles like "Ember ninja" and "Angular guru", if only because recruiters don't know that both of those things are just JavaScript frameworks.
I'm excited for Web Components but I wonder how it will play out practically. Do people put "HTML Expert" on their resumes today?
Because their current system might already be using Bootstrap, so they need someone who understands it to be able to continue the work.
So real world customers don't care about anything else. If it happens to work, or a team member decides to go at it on their own outside project budget, it is a nice to have feature that's it.
Everything else that builds their little platform on top of the browser is not interesting to me.
And TypeScript is a JavaScript superset with optional type annotations, which can be ignored if one so chooses.