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.
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.
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.
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.
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.
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.
I.e. the emperor has too much kb.
(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.
It didn't sound personal, and I'm glad he did. I love to here first-hand experiences, regardless the relationship.
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!)