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]
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.
>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? 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.
> 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.
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.
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.
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 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!)
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.
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.
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)
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.
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.
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've tried to use PatteryFly a few times, it's actually a pretty terrible system. the biggest drawback is the lack of documentation...as you click through what they call documentation it's full of missing content and 404's. Personally, it's just better to use adminLTE or Twitter Bootstrap.
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).
> It seems that the only support is from internal RH devs
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!
Wow, that is an interesting approach they got there.
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.
The problem with all these frameworks is you end up with a huge mess of markup unrelated to your application, and then have 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.
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.
>Native web components with shadow DOM styling are the way to go forward IMO
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.
I've never seen this before, but it looks kind of neat. Right now I use Material UI for React stuff, and it works well enough, but I picked it mostly because I think its API is cleaner than the other frameworks I've worked with. I see that PatternFly has a React library; can anyone speak to how it is to use?
I've had PatternFly on my to-do list to investigate a bit more for a while. However I'm at a loss, after reading the website, to understand what it is. Is it a set of styles? Design guidelines? Code for widgets?
(Disclaimer: I work for Red Hat, but doing low-level stuff)
RedHat lives and dies on value to the enterprise. Their consultants need to find a way to stop enterprise customers from just reaching for whatever FOSS is out there. By giving away their own framework, they can keep their clients in the redhat universe where redhat folks have expertise to offer.
I don't think this is true at all. Red Hat needed a web toolkit for their products and presumably decided that the available options weren't suitable for their purposes.
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.
VMware has something similar in clarity[0], and I guess they decided that bootstrap in a mobile first framework and what they wanted was desktop first, since that what their customers use. I guess what matters more than reactive are wizards, login screens and tables[1]. Incidentally whoever made these examples appears to love pokemon.
PatternFly isn't particularly new (commits back to 2014) and is mostly focused on shipping coherent and consistent product UIs from RedHat to their customers.
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.
Because, to achieve any semblance of scalability, and consistency, you need to use a UI framework. Otherwise, everything you create is either from scratch or ad hoc implementation. Neither alternatives reduce complexity.
I use debian for my own stuff, but always push for RHEL/CentOS at work. Why? Because it's easy to persuade people into keeping the damn systems updated. As long as you stay within the same major version, updates don't break builds or require new rounds of QA.
redhat couldn't engineer an operating system to save their life: systemd is a Windows-like system, they constantly break backwards compatibility, their compiler is purposely castrated to only produce 64-bit code, memory overcommit is still a thing and ships out of the box turned on, they can't get NFS to work correctly and haven't been able to for decades, they can't get fiberchannel to work correctly, they resisted and sabotaged XFS for decades only to now make it a default after having made their customers to suffer with ext2, 3, and 4 for twenty years, they resist ZFS, they've allowed netstat to be deprecated in favor of ss, both GFS and GFS 2 are disasters which they could never get to work correctly, Puppet is a disaster, Saltstack is a disaster, Cobbler is a disaster, Satellite / Spacewalk is a disaster... seriously, what can redhat do correctly?
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.
Red Hat break backwards compatibility every 10 years. the LTS approach has been copied by every other Linux distro.
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.
I'm merely answering the "what's wrong with Redhat Linux?" question: it's enough to go to bugzilla.redhat.com and pull the publicly open priority 1 critical bugs, read the exchange between users and redhat and a pattern emerges. Never mind what I wrote and what I suffer through on RHEL every day, let's ignore and discount that; it's the exchanges in the priority 1 bugs that tell the tale for themselves far better than I ever could.
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.
Looking at prio 1 bugs for a huge distro like RHEL is not going to paint an accurate picture.
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.
> There exist no words in any of the languages I speak which can express my hate of GNU and GNU/Linux.
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-UX was hard to get started on building software, but once one builds up a base of common libraries, it gets easier and easier, just like it did on Solaris.
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!
Only SMF uses XML and SQLite behind the scenes. While that is a poor choice of configuration format, SMF is considered the Golden standard which all others try to re-invent and re-implement (not invented here syndrome), because SMF has been working reliably for more than a decade, and all added capability doesn’t break backwards compatibility, so an SMF manifest you wrote ten years ago works without modifications on the latest and greatest nightly build of illumos. That’s system engineering as opposed to haphazard hacking. I use drivers in the latest illumos from 1995 and they run without recompilation or modification. I’d like to see GNU/Linux pull that one off.
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.
> Now I have to put that work-around in my compilers.
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.
It's a lot of engineering to roll out one's own compilers, especially if one wants to do it correctly.
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.
IMO Red Hat has been on top of recent developments.
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.
Legitimately curious: the main issue with running containers on Linux is the bad state of the Linux kernel as far as security is concerned. Even with SELinux, it's risky to run multi-tenant containers on Linux due to the massive attack surface, necessitating things like [1] or lightweight VMs.
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?
Well, one is forced to work with that inferior tooling and is not allowed to change it. This is excruciatingly painful and generates a lot of resent when one knows that there is far superior tooling available, gratis, with much higher quality support and way more competent engineers working on that tooling.
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...
4. https://github.com/patternfly/patternfly-react/pull/160
5. https://github.com/openshift/console/pull/34