PatternFly – a web UI framework by RedHat
patternfly.org
patternfly.org
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...
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!)
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>
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.
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 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...
And there's a difference?
That's a UI design thing. Nothing to do with the underlying framework.
Material design for instance is a piece of shit for enterprise apps.
I'd like something much lighter weight, but still opinionated, with well-defined components to take off the shelf.
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-...
With the exception of RHEL, it's just like most of Red Hat's products...purchased from someone else, half-baked, and a rather pathetic attempt to stay relevant. It seems that the only support is from internal RH devs and if you look at a lot of Red Hat's other products, even they can't really figure out how to use it (see ManageIQ).
That's because it's an internal RH framework. Red Hat happens to open source most of their stuff, so they put some effort into marketing PatternFly, but it's still mostly used by themselves.
That being said, the people on their Slack channel are extremely helpful!
The Bootstrap/Foundation abstractions are rarely "just right", always requiring you to change/fork/deviate from the norm. I like the idea of building the abstractions myself, exactly as I need them.
Thanks for sharing!
Native web components with shadow DOM styling are the way to go forward IMO. Otherwise stuff like this leads to namespace issues and horrible regressions caused when the inevitable need to override something occurs and your only option is to !important a property.
Frameworks like React and Angular are 10x more popular than "native web components".
So if "having to have another tab open the entire time with documentation making sure you spell every class name right and dont miss a single <div> tag" is your concern, it's misplaced. People will be more familiar with those others than with native web components.
(Disclaimer: I work for Red Hat, but doing low-level stuff)
I'd rather it was built around Bootstrap 4, but I didn't write it, can't be too choosy.
- the pattern library, a set of design guidelines (http://www.patternfly.org)
- Patternfly Core, the HTML+CSS implementations (Bootstrap-based)
- Framework integrations for React, Angular 1 and Angular-NG.
They're currently working on pf-next, which will no longer be based on Bootstrap and feature a new design.
(Disclaimer: not affiliated with Red Hat)
These are more common now because a few years ago a lot of folks drew the same conclusions at around the same time.
For example, PivotalUI[0] was developed in-house to provide a uniform toolkit and look-n-feel for Pivotal's various web interfaces (Pivotal Network, OpsMan, AppsMan, Healthcheck, Metrics etc). Other examples include JetBrains's RingUI[1] or Microsoft's ReactXP[2].
But by no means is PivotalUI intended to lock anyone into anything. To my knowledge our consulting division, Pivotal Labs, has undertaken approximately zero projects using Pivotal UI.
Disclosure: I work for Pivotal. We compete with Red Hat.
[0] https://styleguide.pivotal.io/
This has nothing to do with consultants and Red Hat is not telling their customers to use this framework, although they definitely could if they desired to.
Now, if they would so kind as to exit OS design and implementation, stage right, that would be awesome. The faster the better.
(I don’t hold such a grievance myself, but have seen enough systemd hate to understand the position)
They spend more time arguing with paying customers on bugzilla.redhat.com than fixing their code because it's easier to argue than to find out where the problem is, or to solve the problem properly.
systemd is windows-like in that it replaces a seperate and duplicate code in init, cron, atd, forever, and a billion init scripts with something actually designed.
Red Hat has supported XFS and paid it's maintainers for something like 15 years now.
I could discuss the rest but it honestly seems you're arguing from an emotional viewpoint rather than a technical one.
Try building RPM's between .el5, .el6 and .el7, the macro definitions are ripped out and (partially) put back in or modified for more often than every ten years. And that's just one example of many. Starting with .el6 they made their RPM backend scripts bust if -Wl,--build-id isn't used in CXXFLAGS, CFLAGS, and FFLAGS because they modified their castrated compiler to encode that automatically and rely on it instead, so if you roll your own fixed version of the compiler but don't implement that, all your RPM builds are suddenly broken. Now I have to put that work-around in my compilers. Should I go on? I've got plenty of technical details...
So yeah, they should go into web and not touch OS and kernel engineering ever again.
I've had production experience with all the major distros except SUSE, and Red Hat's QA is miles ahead anyone else's. Canonical/Ubuntu do a particularly bad job at it, for instance.
That's not to say there aren't any issues with it, and I've personally experienced a few (the devicemapper Docker driver, for example, caused a lot of trouble for me and I'm glad they did the right thing and built overlayfs), but overall, their engineering is very solid.
We might not find much common ground there :-)
I'll bite: I worked with a bunch of HP-UX systems before they got decommissioned a few years ago, so I can attest both to how well-built the operating system is, as well as how painful it was to get anything modern running on them. I also keep an eye on SmartOS/SmartDataCenter.
However, how does this make Red Hat's engineering bad?
hp's engineers never broke backward compatibility. The OS is lightning fast and rock solid. That takes a lot of insight and knowledge.
redhat constantly brakes things, I find things which work yetsterday that break tody, even in the same mainline release. They couldn't even get shutdown to work correctly, a couple of years back when we were working on integrating XFS (and they were still resisting it), the kernel was panicking because they were trying to write to an unmounted filesystem; that was 18 years into Linux's development.
SmartOS engineers would never do such a thing on purpose, as they are guided by the 'empathy is still a core engineering value', put in words in an answer by Keith Wesolowski, and in those very rare cases when they do, they fix it immediately.
With redhat we get constant finger pointing between them and the hardware vendor, they never act responsible for anything although we pay them lots of money. What the hell are we paying them for then? They can't even engineer proper code and drivers for their own OS for the hardware they officially support. That's not engineering, that's hacking!
The worst by far is their lack of architecture. Take Satellite for example, with their concept of channels: unbelievably confusing and complicated. Have you tried integrating your own RPM's into it? The needless complexity!
We had Satellite filling up an Oracle tablespace with irrelevant garbage log information even though we just installed it; I called redhat up and asked them how to lower the amount of information Satellite is generating so that it wouldn't constantly fill up the tablespace. Their support told me that I have to go talk to Oracle because it's an Oracle database problem! Yeah, they are that kind of experts!
As for \t not working in vfstab(4), it’s simply not true, as all my vfstab(4) files use the [TAB] characters to line up the fields.
I still use it today.
That seems really minor to me... Just because it takes a long time to find the root cause of a bug doesn't mean that the root cause was a stupid decision.
Disclaimer: I partially work as a developer/support engineer for a RHEL-derived OS, but use Debian at home.
They are relying on specific hacks in the GCC compilers' backends in order for their rpmbuild back-end tools not to bust. That's lack of insight and lack of architecture: what if I were using Sun Studio compilers for Linux, or intel compilers, or PGI compilers? rpmbuild will bust. They didn't think it through, and they never do. It's so stereotypical of them: for the past 20 years they've been haphazardly hacking, and never learned from their mistakes on how to actually engineer systems and how to architect solutions. Just take a look at the hacks they perform in their .src.rpm's, and it's crystal clear.
And "-Wl,--build-id" work-around I had to pull was just one example. I have many.
OpenShift is (arguably) the best PaaS Kubernetes distribution, and certainly the most enterprise-ready one. I use it in production and it's a great piece of engineering. They heavily contribute back to Kubernetes upstream instead of forking it. Red Hat is responsible for many important Kubernetes features like RBAC.
They acquired Ansible and, recently, CoreOS.
Software Collections make it really easy to run an up-to-date software stack on RHEL by decoupling it from the base OS (which is the way to go, IMO).
And of all the IdPs I recently evaluated, Keycloak sucks the least.
How does SmartOS solve this?
Also, does the Joyent stack have an OpenShift equivalent? Triton wants my credit card details to sign up with their public cloud, but I might grab a spare box and give it a try.
...if after reading that you still have specific questions, ask.
You don't need a credit card, if you don't want to run it on Joyent's servers, you can run Triton for free on your own at home, at work, (or someone else's) infrastructure. All of that technology is freely available at Github at no cost other than reading a little bit of documentation and investing some time to set it up following the instructions.
Out of curiosity, do Digital Ocean, Hetzner, Azure or AWS not ask for a credit card?