I wish people would stop making UI frameworks in <some non-standard framework name>, and instead make it web components based with vanilla JS/very light lib dependency, so that everyone can enjoy the benefit. React is becoming a bubble of its own, and it's exclusive.
3 Different things. html, css & js are like raw materials, React is processing these raw materials, and a UI components or design systems are the result you get if you mix the React process with manual labor.
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.
I agree very much. However there are two points that make it difficult :
- Virtual Dom. It simplifies a lot the creation of components. And components that are made for a VDOM are very different from those made without VDOM in mind.
- Data Binding. There are multiple ways to bind data to your components, once again this might influence the way components are made.
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.
This is confusing. 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.
Not at all true. Where's your onClick? People want their buttons to actually do things, right?
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.
That uses React to attach onClick, so obviously yes. I'm saying without React. You said:
> 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.
I guess I see what you're saying that web components can seem be consumed as expected from a React app. I thought we were talking about not using React at all.
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.
Of course you can set props on a WC, it's just a DOM node. You can do everything you can do with any other standard node + exposed API. You could use jsx/vdom any other solution to set up props/events.
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.
I realize you can set properties, obviously. Those are not the same as using attributes, which is what React's props are more equivalent to. e.g. you can't do <my-button onClick={...some function here...} />. So using it does indeed suck the same way using normal DOM elements sucks: you need a reference to the created node, addEventListener, etc.
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.
You can with lit-html/stencil, but yes you need something to take care of that for you, which is very small dependancy. WC's are NOT supposed to be consumed directly unless you do very simple things.
Web components are not supported in many popular browsers. Until they are widely supported they are not a thing. And no, Polymer and co are not polyfills for them, they are their own incompatible frameworks.
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.
> Edge and Firefox are only missing Shadow DOM and Custom Elements,
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.
> Apparently you haven't read my comment as you missed "which they are already developing." part.
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.
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".
> As for Edge it is already in development, and to be honest it doesn't matter with its insignificant market share.
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.
According to netmarketshare[0], on desktop[1], Edge currently has 3.8% market share, more than Safari and Opera together. Combining mobile+desktop Edge has 2%.
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.
You are reading it wrong, it is not me that mandates the browsers.
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.
Hm, maybe I missed the context somewhere along the lines. Are you talking about something on the developer side only? I thought the discussion was about something that works or not for the end user.
Edge is implementing (updated the roadmap), Firefox ships enabled WC's in closest release (it is already in the beta) I think Firefox 63 will ship in a week?.
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.
I know that is not what HN likes to read, but iOS == Safari and Android == Chrome, and unless customer explicitly requires Firefox Mobile on the RFP, it gets ignored in acceptance testing for project delivery.
Yup, Polymer is "big" dependency, but with things like svelte, litelement or stencil you can build web components which have little overhead.
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.
This is especially frustrating for job seekers. I've seen so many job listings calling for extensive experience with Bootstrap, for example. Why would knowledge of CSS and the grid system not suffice there?
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?
> I've seen so many job listings calling for extensive experience with Bootstrap, for example. Why would knowledge of CSS and the grid system not suffice there?
Because their current system might already be using Bootstrap, so they need someone who understands it to be able to continue the work.
Yeah, I really dislike Polymer's approach of using Web Components as an architectural pattern, but this is the exact use case they're good at. Then again, I can understand that you don't whip something like this up in a day, and support for Web Components might not be as widespread yet as a UI framework author would like.
yes but real world applications often need to support more than safari and chrome, so until they are supported across the majority of them including older versions still in wide use then its still a no go for the majority of use cases.
Mobile is all about Safari and Chrome in what concerns Request For Proposals and delivery acceptance testing.
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.
That's radically inconsistent. Angular is not HTML, nor Javascript, rather it's its own thing -- precisely a "little platform on top of the web", to use your phrasing.
