Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this project safe to adopt? #1121

Closed
robertofabrizi opened this issue Apr 14, 2020 · 8 comments
Closed

Is this project safe to adopt? #1121

robertofabrizi opened this issue Apr 14, 2020 · 8 comments

Comments

@robertofabrizi
Copy link

robertofabrizi commented Apr 14, 2020

I don't want to sound disrespectful or anything, I see the commits, but the "card" being a staple of MD as it is, and not being completed in a year, raises some doubts.
The demo page referenced in the homepage is broken, also not a good sign...
What about components that are not even on the list, at least that I could see, like a date and time picker?
Thank you and be safe in these dark times.
Robert

@abraham
Copy link
Contributor

abraham commented Apr 14, 2020

From the top of the readme:

IMPORTANT: The Material Web Components are a work in progress and subject to major changes until 1.0 release.

@rwestlund
Copy link

For what it's worth, I'm using this code in production for my company's SaaS app. It's not perfect, and I've had to implement a lot of stuff myself. Also a bunch of hacks, and reading the source of these elements to find out what they actually do. But I really needed to get off the old polymer elements (which I've almost done!), and there's not much else out there. I've been slowly transitioning as the elements here reach a point of being less buggy than the old polymer ones.

Google lost interest after the web components spec was adopted, and left this repository abandoned for a year, which is a shame. I'm grateful to the devs who have picked this back up, and I love how lightweight these components are. I hope they reach a point of maturity soon, because that will make my life and my code base much better, but this is clearly not a top priority for them.

If you're starting a new project, I would recommend going with react just for the more mature ecosystem. If you're already in the polymer or lit-html ecosystem, then I do recommend adopting this now. Just do it gradually, and expect problems.

I think lit-html is technically superior, and has a brighter future than react if it gets some more serious backing and adoption. Again, much gratitude to the devs here for the progress they've made.

Just my 2 cents.

@e111077
Copy link
Contributor

e111077 commented Apr 14, 2020

Hello, reiterating what abraham said, these elements are currently in alpha. More info can be found in my reply to #1080.

@e111077
Copy link
Contributor

e111077 commented Apr 14, 2020

@rwestlund I'm sorry you feel this way. When we started the Polymer Elements we were new to web components just as any other developer since it was unexplored territory. Unfortunately the team made a bunch of mistakes with our first set and also had run into issues with maintaining such a large set of components with such a small team. When the web components v1 spec was released we continued to iterate on web components usability via spec.

Material 2.0 spec was then released and we started implementing the components, but soon after we learned that the material design team was going to implement them so we stopped working on the components. Unfortunately they had a team that did not have the same experience as the polymer team in building and maintaining an OS component set, so unfortunately they fell into the same pitfalls that we did with the Polymer Elements, so now we have gone through bureaucratic reorgs and are now working under the Material Design team to get first-class material design web components out there.

Sorry it's taking time, but we know what it was like to make mistakes building component sets and are trying not to fall into those pitfalls again. We are also working heavily to get web components to SSR with all SSR frameworks.

@e111077 e111077 closed this as completed Apr 14, 2020
@rwestlund
Copy link

@e111077 Thanks for the explanation! Many of us in the community felt abandoned, but it it's good to know it was mostly a communication issue and not a lack of interest. Thanks again for all your work -- the new components really are beautifully put together :)

@robertofabrizi
Copy link
Author

robertofabrizi commented Apr 14, 2020

@rwestlund that's exactly the kind of feedback I was hoping to get. I'd love to jump on board to the beauty of material design and a frameworkless approach that implements MD via native elements basically on par with standard html tags.
My main issues are:
If the elements are too basic and not customizable enough, then I'd end up spending more time reading their source code and modifying it myself rather than just adopting / learning a web framework, which makes one of the two biggest appeals of web components completely moot in my book. You confirmed that this fear is real
If the components are customizable, yet some extremely basic ones are missing (seen a complex form without a date picker in the past five years?), then I'd end up coupling the web components with a framework, again making one of their major benefits moot
It's Google, don't get me wrong I have the uttermost respect for its employees and I wish I was one, but the politics just mess too much with their own products, they have a habit of starting things and then make more clones and stop supporting stuff while moving on to similar (yet sometimes inferior) products for no apparent reason (the instant messaging apps is a joke of many articles of famour tech bloggers, and rightly so, just to name one)

@rwestlund
Copy link

@robertofabrizi It's definitely not at the point where it's plug and play, but if you know you want to be going this direction long-term, then don't let that stop you. You can write your own bare-bones card component in less than an hour If you only think about your own narrow use case and don't care if something's a few pixels off. Then swap it for the real one when it's ready. That's basically been my migration strategy. much of the appeal of web components for me is that they're very simple to write.

I'm using vaadin's date picker, and they have a couple other good free components as well. They're migrating from polymer to lit. I threw together a passable time picker component that uses dropdowns, etc.

Weightless has a few usable lit-based components, but it doesn't match material at all, and they're buggy and pretty much abandoned.

It could be a year before this repo is at the point where you want it to be, but I'm happy to deal with some short-term pain to avoid the long-term pain of being locked into someone's framework. Five years from now, this is what I want to be using.

If you need a beautiful and consistent UI from a plug and play library in production this year, then go somewhere else. But if it's for a personal project or you can tolerate some UI imperfections in the short term and are willing to write a few of your own components, then by all means use this.

@e111077
Copy link
Contributor

e111077 commented Apr 14, 2020

Hello, just to chime in again. The customizability issue is still a thing we are working on. We have a theming system under development (hence alpha).

And the beauty of this reorganization is that under Material Design, we get to work a lot closer with the incredibly talented designers and engineers on the team. Though, also working under Material Design that means that we have to adhere closely to the spec and balance customizability, spec, and maintainability.

There is currently no plan for a date picker just now, but I'll make sure to bring these concerns to our following meetings though SSR has taken precedence over new components right now.

Also the card one, we'd like to know what features you'd like in #442! Implementation was teetering between simply supplying plug and play styles, or a webcomponent that is essentially just a <slot>, to several webcomponents with multiple <slot>s and more functionality, but more annoying to use IMO as it would require you to use several of our vended web components which has historically proven to be unpopular.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants