Pantsuit: The Hillary Clinton UI Pattern Library | Hacker News Reader

Pantsuit: The Hillary Clinton UI Pattern Library

medium.com

41 pointsrimunroe23 comments

When I saw the title, I assumed this was satirical. By the time I reached the end, I became entirely uncertain. Is this a genuine post that happens to be a bit amusingly self-aware, or full-blown Poe's law satire?

I think it's the former, but I'm really not sure.

Seems to be genuine and amusingly self-aware. Specifically see the animated gif towards the top referring to decision to use the name "Pantsuit" for the framework.

It is legit - Mina (author) is a former coworker of mine. Miss working with her!

I don't get it. They used CSS with some naming conventions -- what's interesting about this? There's not even a link to code.

They link to DevProgress, which links to https://github.com/devprogress/ but I don't see the code there.

It sounds like they're fishing for volunteers, but aren't aiming to be open source yet. Assuming this is all real and not some kind of joke.

Read the title of the post - it's about their UI pattern library.

Her UI components look good, plus the tech choices she made around HTML+CSS may be valuable to copy for anyone doing a high-accessibility content-oriented site.

As a professional web developer this article was free of any useful insights -- if there's something interesting about Pantsuit I'm failing to see it.

It might help if they put some stuff on GitHub, but as it stands this is article seems to be just PR.

I'm a professional web developer too. Sure code would be nice, but I learned these lessons: (1) kss-node exists and looks like a great documentation tool, (2) campaigns need to design around accessibility which means they care extra about making their rendered HTML+CSS semantic, (3) an input form is a good example of something that you can skin with different stylesheets without too much headache.

I had a horrifying flashback to millions of lines of Hungarian Notation in Fortran and C++ when she described the prefixing for CSS classes.

I'm not a frontend developer, but is that really a good practice?

It's a common practice, particularly because CSS doesn't have easy to use namespaces or modules.

Maybe not a "good" practice, because yeah so much as anything it's a sign that maybe we've reached the natural bounds of the CSS language and it's time to look into making it better.

The reason Hungarian Notation is considered bad practice is that it encodes in a variable name what is already, or at least ought to be, encoded in the variable’s type.

CSS is not really a programming language, and it doesn't really have types.

I never really understood the resistance to Hungarian notation. It greatly helps when you have large numbers of variables where their declaration is disconnected from their use (especially useful in languages like C++). That the information is redundant isn't a knock against it, it greatly reduces the friction in obtaining critical information about the variable. It certainly made reading windows code a 100x easier.

The resistance has as much to do with the idea that the need to use something like hungarian notation in the first place is a failure of your tools/libraries. If that type information is so important, why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration and jump you to the declaration or provide tooltips/color-coding/"auto-hungarian"?

It's easy to posit that the general prevalence of hungarian notation in early C/C++ is something of a clear indicator of deficiencies in the C/C++ languages themselves at the time. Why solve coding problems with cultural conventions and human dogma, when you can automate it or make a better language with a more formal type system?

In addition Hungarian notation requires refactoring entire code bases whenever the type of something would change instead of the declaration point. Or become out of date as the type change but the variable name wouldn't. It also hinders legibility in my view but that's a personal opinion.

>why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration

The strength of the type system is really an orthogonal concern here. Why jump around in your code when that information could be contained in its name? Why do we use descriptive names at all when we can just analyze how the variable is used to understand its meaning? Clearly, more descriptive names are almost always a benefit. The type of the variable also provides a significant portion of its meaning. It's a matter of having as much contextual information presented with the least amount of friction. Hungarian notation does this for strongly typed languages.

I don't think that the strength of a type system is an orthogonal concern at all. I think there's a very distinct causation from the strength of the type system in C/C++ and hungarian notation. Much "weaker" dynamically typed languages typically don't see a need for it (Python, JS) and much stronger typed languages don't see a need for it (C#, ML family, Haskell). Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns but not strong enough that the type system and compiler design provides you the tools/safeties to catch for you most cases when you are building a footgun.

(With outliers like some BASIC variants whose typing system is a part of the variable naming system.)

If anything, I think Hungarian notation is orthogonal to descriptive names. Sure, sometimes the type of something is useful descriptive information (though I'd argue rarely, even in strongly typed languages), but typically it's answers to the question "what is this variable for?" or "why does this variable exist at all?" I, at least, find more usefully descriptive. (Type information is pretty much never an answer to either question, it's much more to do with the mechanics of how the variable might accomplish its goals than what said goals actually are [1].)

Certainly Hungarian notation has its places, and I'm not going to argue that it hasn't been useful in the history of languages, but I will argue that it's place in history is more as a historic tooling-related footnote than anything else.

[1] The very rare exceptions that I know of are as you get into the deep end of super-strongly typed (mostly Haskell) stuff like type witnesses where knowing the type tells you everything and the type is almost more important than any actual variables of that type as the type has kind of suddenly "become" the algorithm.

>Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns

I agree, but I think this has less to do with the type system and more do to with the immaturity of our API design ethos at the time. Certainly the weak static typing of C++ lead to lots of booby traps, and I agree that tooling should be able to mitigate the need for hungarian notation for this case. So for this aspect, the type system is central to the issue.

But I see the power of hungarian notation in reading code and reasoning about how different pieces fit together. For languages like C/C++, owing to the conventions at the time and the relatively anemic facilities for abstraction, lower and higher level abstractions were often mixed together which made keeping the implementation details at the forefront a necessity. Having the type information carried along with a variable made this process a lot easier. Hungarian notation isn't needed anymore in modern languages (or even modern C++) because we've become so much better at following good design principles and our languages are much more powerful tools for abstraction.

This is a bit offtopic but perhaps interesting: Joel Spolsky wrote an article, Making Wrong Code Look Wrong[0], which includes a defense of the original Hungarian notation--called Apps Hungarian--that I find rather convincing.

Essentially, the original intent was not to encode the type in the variable name, but the kind. One example given is from the Excel codebase, where ints are used for tracking both rows and columns, but it doesn't make sense to assign values between them (save for rare circumstances like transposition). This is made explicit by prefixing rows with "rw" and columns with "col". If you ever saw something like "rwMax = colCurrent" it sticks out immediately as being wrong since you know that those two kinds of variables shouldn't mix. The assignment is legal and the compiler won't help you; the semantic naming scheme will.

Encoding the type, like "ul" prefix for "unsigned long", is of course awful and unnecessary and deserves all the derision it has gotten over the years.

[0]http://www.joelonsoftware.com/articles/Wrong.html

The only alternatives I can think of are (1) have the filename of the stylesheet reveal what type of style it is, and (2) stop acting like stylesheets are a better way to factor out UI code than React's JS-based component-oriented styling patterns.

I personally do #2 but Pantsuit seems reasonable for sites that are relatively simple content + UI affairs (e.g. Wordpress) without a complex state-space (e.g. a T-shirt designer app).

There's nothing in this article. Name spacing CSS? Ok... thanks? Feels like an attempt at the Hillary camp to reach out to the developer voters.

All I got from this is Hillary needs Trump(s).

Reply on news.ycombinator.com