7 ms·

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 dep

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.

blumomo 8y ago
I guess we're all looking forward to your open source web components library!
- krikou 8y ago
  This is already a start: https://www.webcomponents.org/ https://www.webcomponents.org/
bthornbury 8y ago
My first thought was that this is a UI Framework (Evergreen) built on UI Framework (React) built on a UI Framework (js + html). 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).
- deltron3030 8y ago
  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.
emixam 8y ago
I've been working on a tiny vanilla js lib focused around web components: https://github.com/maximebf/gousse.js https://github.com/maximebf/gousse.js. It includes a set of components using Bootstrap: https://github.com/maximebf/gousse.js/blob/master/examples/ui.html https://github.com/maximebf/gousse.js/blob/master/examples/u...
Vinnl 8y ago
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.
- pjmlp 8y ago
  There is 100% support on the mobile web across Safari and Chrome.
  - user1010198 8y ago
    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.
    - pjmlp 8y ago
      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.
      - Vinnl 8y ago
        Yes, so my point was that the authors of UI frameworks perhaps don't care about mobile only.
ernsheong 8y ago
Personally I like LitElement: https://github.com/Polymer/lit-element https://github.com/Polymer/lit-element 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-web-components https://github.com/material-components/material-components-w...
aikah 8y ago
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.
- pjmlp 8y ago
  Edge and Firefox are only missing Shadow DOM and Custom Elements, which they are already developing. On mobile Web 100% of the browsers support Web Components. https://www.webcomponents.org/ https://www.webcomponents.org/ So what are the many popular browsers you refer to? As anything else is meaningless.
  - aikah 8y ago
    > 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.
    - ergo14 8y ago
      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?. That leaves only IE11/Edge with polyfills.
      - aikah 8y ago
        > 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.
pjmlp 8y ago
I am on the same boat, hence why I am on Angular and Polymer side. Everything else that builds their little platform on top of the browser is not interesting to me.
- chrisweekly 8y ago
  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.
  - pjmlp 8y ago
    Not really, because Angular is in the migration process for Web Components adoption. And TypeScript is a JavaScript superset with optional type annotations, which can be ignored if one so chooses.
Natela 8y ago
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.
- Touche 8y ago
  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.
  - exogen 8y ago
    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.
    - Touche 8y ago
      Nope, you're wrong. onClick works with web components just the same way as it does with any other element. Proof: https://codesandbox.io/s/j3jmkr98pw https://codesandbox.io/s/j3jmkr98pw
      - exogen 8y ago
        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.
huehehue 8y ago
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?
- latexr 8y ago
  > 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.

blumomo 8y ago

I guess we're all looking forward to your open source web components library!

krikou 8y ago
This is already a start: https://www.webcomponents.org/ https://www.webcomponents.org/

bthornbury 8y ago

My first thought was that this is a UI Framework (Evergreen) built on UI Framework (React) built on a UI Framework (js + html). 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).

deltron3030 8y ago
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.

emixam 8y ago

I've been working on a tiny vanilla js lib focused around web components: https://github.com/maximebf/gousse.js https://github.com/maximebf/gousse.js. It includes a set of components using Bootstrap: https://github.com/maximebf/gousse.js/blob/master/examples/ui.html https://github.com/maximebf/gousse.js/blob/master/examples/u...

Vinnl 8y ago

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.

pjmlp 8y ago
There is 100% support on the mobile web across Safari and Chrome.
- user1010198 8y ago
  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.
  - pjmlp 8y ago
    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.
    - Vinnl 8y ago
      Yes, so my point was that the authors of UI frameworks perhaps don't care about mobile only.

ernsheong 8y ago

Personally I like LitElement: https://github.com/Polymer/lit-element https://github.com/Polymer/lit-element 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-web-components https://github.com/material-components/material-components-w...

aikah 8y ago

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.

pjmlp 8y ago
Edge and Firefox are only missing Shadow DOM and Custom Elements, which they are already developing. On mobile Web 100% of the browsers support Web Components. https://www.webcomponents.org/ https://www.webcomponents.org/ So what are the many popular browsers you refer to? As anything else is meaningless.
- aikah 8y ago
  > 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.
  - ergo14 8y ago
    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?. That leaves only IE11/Edge with polyfills.
    - aikah 8y ago
      > 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.

pjmlp 8y ago

I am on the same boat, hence why I am on Angular and Polymer side. Everything else that builds their little platform on top of the browser is not interesting to me.

chrisweekly 8y ago
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.
- pjmlp 8y ago
  Not really, because Angular is in the migration process for Web Components adoption. And TypeScript is a JavaScript superset with optional type annotations, which can be ignored if one so chooses.

Natela 8y ago

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.

Touche 8y ago
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.
- exogen 8y ago
  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.
  - Touche 8y ago
    Nope, you're wrong. onClick works with web components just the same way as it does with any other element. Proof: https://codesandbox.io/s/j3jmkr98pw https://codesandbox.io/s/j3jmkr98pw
    - exogen 8y ago
      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.

huehehue 8y ago

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?

latexr 8y ago
> 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.