I work at Red Hat (part of the CoreOS acquisition) and I have to say that PatternFly has not been useful to the project I work on.[1]
First, PatternFly is big. We were mandated to adopt it, and it tripled our CSS (from 45kB to 145kB). PatternFly also bundles Open Sans web fonts, which (depending on font format) add another 200kB to 4MB to the initial page load.[2]
Second, development is slow. There's a rewrite of PatternFly in the works, and its roadmap predicts a 1.0 release after April of 2019.[3] It's a CSS framework! How can it take over a year to make?! There will be two major releases of React in the same time.
Speaking of React... PatternFly-React has similar shortcomings. Their babel setup doesn't seem to support tree shaking, so if you use any PF-React component you'll have to bundle 2MB of JS. The speed and quality of development leaves much to be desired. For example: It took them five months to merge a TTY component.[4] We wrote a similar component in two days.[5]
1. https://github.com/openshift/console
2. https://github.com/openshift/console/pull/3
3. https://github.com/patternfly/patternfly-next/milestones?dir...
Why would you shit all over your colleagues’ work like that? An announcement post is not a place to air your grievances.
I don’t even understand why you’d compare a pattern library to a rendering framework. And comparing development speed for a component in a shared library against that for a single use case is completely unfair.
As this is a free giveaway from Red Hat and they don't derive any revenue from it, it's better people are aware of its design choices and limitations before diving into it and walking away disatisfied.
he's not shitting on them really he's helping people so that they don't get it in their mind that redhat is the next IBM when they use some crappy bloatfest
Whoever downvotes you probably never tried Bluemix. Just saying.
(I used it once at a hackathon several years ago and it was enough to make me want to not try again. I hope their current offerings are better. At the time, they had some utility which was supposed to compete approximately with Heroku workflow, and it was bad enough in the first 6 hours of the hackathon that we wound up spending an hour or more switching to Heroku instead of trying to figure it out.)
Git receive hooks were straight up broken, I had to wonder if anyone internally was even using the product, and there was no indication that it was in beta. The hackathon was sponsored by IBM and the gentleman who was on-site to rep the line was not very interested in our problems working with the platform, only seemed to note that we didn't try more of the whiz-bang AI and NLP features that could have helped the core functionality we were trying to build. I wish I had told him that what we needed firstly, was four walls and a roof.
I've had some better interactions with IBM Cloud team members at conferences since then, so it's fair to take my criticism with a grain of salt.
Probably because complaining isn't allowed at work. They mandated the usage so that's not a good sign especially when OPs complaints are deal breakers for anyone who isn't mandated to use it.
I.e. the emperor has too much kb.
> Why would you shit all over your colleagues’ work like that? An announcement post is not a place to air your grievances.
I know it's unkind to air dirty laundry, but there are no good options. Either I'm disloyal to some of my coworkers, or I let a bunch of developers to run into the same problems I did.
If the positions were reversed and I was considering a library, I'd want employees to chime in with their experience using it. That remains true even if those experiences were negative.
> I know it's unkind to air dirty laundry
The term "dirty laundry" implies personal issues or just politics. Your assessment seemed rational and centered around the product itself.
I'm not sure why you got that kind of reaction from OP.
>An announcement post is not a place to air your grievances
I didn't interpret it that way at all. Announcement posts for new frameworks never talk about the way frameworks suck. They never say what the use cases are for which you should not use the framework. They never discuss limitations and side-effects (such as increasing the size of the assets that you have to serve, increases in rendering time, etc). They never give an indication of the responsiveness of the dev team behind the framework to feature requests and bug reports.
I'm very happy to see a post discussing the downsides of the new framework, and I wish all announcement posts on Hacker News would have a similar top comment.
> Why would you shit all over your colleagues’ work like that?
Given that he was mandated to use it and it is, in his view, shit...maybe it'd be better to ask his colleagues why they've been shitting all over him?
I don't really see what loyalty he's meant to feel towards a project that some other part of a large company that recently acquired his company has developed.
I think it's terrific there's a debate on this. If this were a niche site for marketers, enterprise folks, etc, then there'd be zero question that GP is being the bad guy.
But since we're mostly hackers here, there's a tendency toward airing hard truths and measuring against real-world usage.
I don't have an opinion. If GP worked for me, I wouldn't be thrilled that one of my team members is berating a project that another of my teams worked hard on.
But as someone who came into this thread eager to try out PatternFly and possibly implement it on a new project, I'm pretty glad GP brought up these huge drawbacks.
It helped me, anyway.
> Why would you shit all over your colleagues’ work like that?
It didn't sound personal, and I'm glad he did. I love to here first-hand experiences, regardless the relationship.
I found this post (gp) extremely refreshing actually!
For context, I have participated in my fair share of Red Hat betas, and I have found the experience to be mostly uniform. That is, the product is labeled as beta because it has many (sometimes grave) issues remaining in it. If you are taking part in earnest, you will spend plenty of time reporting bugs. I'm talking about the OpenShift Online betas I was invited to try, but when I was having this experience I remember thinking "yep, it's exactly another RedHat beta!" strong sense of Deja Vu.
Don't get me wrong! I am a huge proponent of OpenShift and Kubernetes both, as well as RH, and I spent enough time collaborating with their excellent team and asking questions over IRC to get "the big idea," even if I haven't chosen those solutions to go to production with, or started development on them yet.
(As an aside, I didn't pass because of the bugs. I passed because their target market was apparently Java developer, and I am working in Ruby. I could have probably made it work, but all of the documentation I browsed through during my time evaluating the preview of Che and OpenShift hosted platforms indicated to me pretty clearly that I was not the target market, for the beta at least.)
I am personally excited but also apprehensive about the CoreOS acquisition because of those experiences.
I want CoreOS to bring exactly this kind of hard-hitting factual criticism to the RedHat team, because I don't have the time to spend in Beta programs doing it myself, and it's valuable work that needs to be done in order to guarantee quality in the finished product.
And as much as I may sound like I've shat on the OpenShift betas in similar fashion, when I go back and try again the finished product, or read the docs and install open-source release versions of the platform, I find they are all very good, and surely owing to those bug reports and the great developers who patiently follow them up without ceremony.
This part of the experience has also been fairly uniform, and it's likely that fact that has brought RedHat so much success in the market.
In contrast, I've used CoreOS Container Linux and earlier iterations in more depth (but usually not in betas, even if they were basically bleeding-edge), and found them to be uniformly rock-solid, almost without compromise!
As an end-user, this is a better experience, but as a developer I know and am reasonably sure that I still owe it to someone tracking alpha and beta channels, finding the issues when they manifested and reporting them for follow-up before they make it into stable releases.
If this comment was a sample of what the fusion of CoreOS and RH teams working together is going to look like, as a fan of both teams and their products, then I sincerely hope to see more of CoreOS in RH.
(and I also hope that I can still recognize CoreOS five years from now!)
Yeah, better to wait until everyone wastes their effort discovering for themselves what someone with extensive first-hand experience could have told them upfront.
I've used Patternfly for rapid prototyping for the last 1-2 years. I share all of your frustrations.
What makes Patternfly stand out for me is that incorporates opinions from enterprise dashboards/line of business apps. If it stays true to this and solves all of it's project management and code quality issues it could leap ahead of most other frameworks. I need whiz bang examples of composed components almost more than I need the component library itself.
As a back end developer here is the work flow that is eased by a library like Patternfly:
1) Someone develops or exposes an API. 2) A team wants to dog food a potential new solution built on top of that API and shop it around. 3) Someone gifts them a single developer and a bucket of hours to see what they can do.
In this instance I need a stable library that looks good and doesn't require me to wade through the front end too much. Patternfly fit that niche for awhile. However do to the slow dev cycles I've moved to Semantic UI and I'm just building my own component library out of that. Arguably the route I should have taken from the start but Patternfly let me ship stuff I wouldn't have otherwise in the time I was allowed.
</ramble>
Thanks for your insight. That’s pretty much what I was expecting in a web framework produced by Red Hat. (Not to completely disparage Red Hat - they do have some good stuff.)
How’s the CoreOS transition going? My buddy worked for CoreOS and it seems like he’s incredibly busy now. It’s upsetting to hear that they’re forcing shitty tech on y’all.
Out on a limb here, but have you vented this in a constructive way to your (new) coworkers? Splashing your discontent here is very enlightning for people not at RedHat, but maybe not the best way to move things forward. Complaining rarely is.
> tree shaking
They recently migrated their repo to lerna, so this will soon be fixed and you'll be able to import single components (@patternfly-react/console etc).
I appreciate the honesty, I was looking at this a bit seriously for a new project but now I think I’ll pass.
I'm not a Red Hat employee (though mostly working within the ecosystem), and I'm going to use PatternFly for an upcoming commercial project.
I also noticed that some PRs take a long time to merge, mostly due to there being a lot of review comments and fixes. For each PR that touches CSS/HTML, they also have a designer check for accessibility and usability issues. It's a feature, not a bug ;-)
The reason I like PatternFly is their emphasis on usability. I work on enterprise software, and people are going to rely on it for their day-to-day work. Most CSS frameworks are really fancy, but bad for usability (lots of white space, low contrast, hard to navigate using a keyboard). PatternFly is the opposite.
Here's the React storybook, for a quick overview: (React is what most RH products seem to use nowadays)
https://rawgit.com/patternfly/patternfly-react/gh-pages/inde...
What you are referring to is exactly why I wanted to use it, I’d like a good framework for enterprise apps. Most of the fancy CSS frameworks you see are for consumer apps.
>I’d like a good framework for enterprise apps. Most of the fancy CSS frameworks you see are for consumer apps.
And there's a difference?
A massive difference. Enterprise apps are all about getting as much information on screen as possible with clear boundaries between different elements and relationships. No optimistic actions either.
>Enterprise apps are all about getting as much information on screen as possible with clear boundaries between different elements and relationships.
That's a UI design thing. Nothing to do with the underlying framework.
Frameworks by design often discourage or make it cumbersome to design enterprise UI.
Material design for instance is a piece of shit for enterprise apps.
that storybook seems to have a small subset of what's cataloged in the OP's link. Partial implementation?
Same here. I wonder what I should use instead.
I'd like something much lighter weight, but still opinionated, with well-defined components to take off the shelf.
First, cograts on your work and your deal with red hat! Second: Did you use any other css framework in the project before? If so, which one? What are the differences / your resume? Third: How is working under red hat umbrella? I hope for using patternfly you at least force them to dump project atomic in favor of container linux ;)
> I hope for using patternfly you at least force them to dump project atomic in favor of container linux
Sounds like they're planning on rebasing it on top of Fedora/RHEL, and replacing Atomic Host with it: https://coreos.com/blog/coreos-tech-to-combine-with-red-hat-...