Unless I am misunderstanding “Brutalism”, shouldn’t a “brutalist web site” be something like a no- or minimal-css web page? The examples the article gives, while pretty in their own right, don’t appear (to me) to go counter to much of everyday web-design one tends to see.
I consider the two sites that you linked to more an example of design minimalism (only using as much as you need), as opposed to the minimalism of information that seems to typify “modern” design today.
I’d also be curious if y’all would consider something like my wiki as an example of brutalism
I would imagine that to draw a useful analog to architecture, we have to imagine what it is we’re saving or optimizing for under a digital brutalism (in the same way that architectural brutalism is cheaper, easier, faster, less specialized, in addition to its aesthetic impact). As a programmer, I would imagine therefore that digital brutalism would have to at least partially be motivated by a desire for simplicity in construction: avoiding a reliance external resources that might not be available, avoiding a reliance on technologies or techniques that require specialization, avoiding techniques that require complexity in order to be correct (in favor of technologies that, while maybe less rich, can be correct more simply), and optimizing resource usage for browser speed and compatibility.
I think it’s perfectly fair to associate the above motivations with a particular aesthetic if they happen to be accompanied by one (after all, when I think about architectural brutalism I don’t think about the equipment, specialized or un-, that was used to construct it). But to say anything useful or interesting with term, it can’t just be the way they look.
But to say anything useful or interesting with term, it can’t just be the way they look.
Isn’t look (legibility) in print/web design fundamental? If we’re talking about a brutalist web design, it’s certainly not brutalist because the author used tables for layout, though that might contribute to a look that has hard edges (defining sections/compartments, etc)–an element often associated with brutalism.
Legibility and aesthetic are not the same, though. As I said above, it’s not that aesthetics are irrelevant; but using modern whizbang web design and tech, and just replacing your full-screen white-people-typing-together background video with graphics and video of a different aesthetic, is just another flavor of the status quo.
Wikipedia has a nice passage which I think can be applied in spirit to websites:
Brutalist buildings are usually formed with repeated modular elements forming masses representing specific functional zones, distinctly articulated and grouped together into a unified whole. Concrete is used for its raw and unpretentious honesty, contrasting dramatically with the highly refined and ornamented buildings constructed in the elite Beaux-Arts style. Surfaces of cast concrete are made to reveal the basic nature of its construction, revealing the texture of the wooden planks used for the in-situ casting forms. Brutalist building materials also include brick, glass, steel, rough-hewn stone, and gabions. Conversely, not all buildings exhibiting an exposed concrete exterior can be considered Brutalist, and may belong to one of a range of architectural styles including Constructivism, International Style, Expressionism, Postmodernism, and Deconstructivism.
Another common theme in Brutalist designs is the exposure of the building’s functions—ranging from their structure and services to their human use—in the exterior of the building.
So don’t do elaborate styling, expose how the site was built, and organize the site into functional zones in ways visible to the user. A thoughtful version of non-CSS, non-Javascript, image-light design might be the best Web “version” of Brutalism, with visual grouping being the only organization. Getting people to give up CSS and Javascript might be a bit much, but in terms of basic construction, HTML is the equivalent of concrete (the “raw structural members” of the Web site) and Brutalism is very much about not hiding or ornamenting that.
Getting people to give up CSS and Javascript might be a bit much, but in terms of basic construction, HTML is the equivalent of concrete (the “raw structural members” of the Web site) and Brutalism is very much about not hiding or ornamenting that.
I have no trouble giving up JavaScript. I’d prefer to use mostly semantic HTML5, with just enough CSS to make the text more readable (because browser defaults are trash).
Great excerpt and follow up. I think you can keep CSS so long as what it’s doing is (a) visible in source behind the scenes, maybe even removable and (b) keeps the fundamental structure of the site or page. It might even give it the structure.
The Classic Geocities, with all of its animated GIFs and background images and using images as dividers, is too ornamented to be Brutalist. It’s best described as Vernacular, which Wikipedia describes as:
Vernacular architecture is an architectural style that is designed based on local needs, availability of construction materials and reflecting local traditions. At least originally, vernacular architecture did not use formally-schooled architects, but relied on the design skills and tradition of local builders. However, since the late 19th century many professional architects have worked in this style.
The Geocities Vernacular was definitely the “architecture from people who weren’t architects” Vernacular.
In fact, the Terabyte Of The Kilobyte Age describes Geocities as Vernacular:
More to the point, Vernacular design is bottom-up unplanned design, with no large-scale goals in mind, whereas Brutalism is top-down planned design, and capable of designing in the large.
I always thought of it as rococo (in the sense that it’s maximalist in the distribution of small decorative features), but I don’t really have a strong background in the history of architecture.
That would be in line with architectural brutalism, but the term came out of critiques of architectural brutalism (which basically came down to “it’s ugly because it breaks convention in non-decorative ways”). “Web brut” has been used as an insult for longer than its current (3-4 year) rehabilitation.
Use only the following tags: a, b, body, br, center, h1, head, i, li, ol, p, table, th, title, td, tr, ul. All other tags are unnecessary distractions. If, for some reason, you must include images, the img and align tags are also suitable.
what would your thoughts be on directly hostilng markdown, probably without literal html, instead of the “more powerful” full-html standards and deviations? Maybe protocols like Gopher could serve as a base for this?
I consider hosting markdown marginally more reasonable than hosting html, but to be honest I don’t think we, as writers, should be controlling how the text is formatted except in the rare cases when the formatting is truly necessary and part of the point (like, if we’re writing concrete poetry or something).
In other words, something like gophermaps-as-document-format seems ideal: we get jump links, but literally nothing else.
The alternate web design style guide, despite apparently looking pretty radical to a lot of web devs, was very much a compromise – in the vein of “oh, if we MUST have web standards at all, at least ditch everything other than HTML 1.0!”
The merits of minimalism aside, brutalism was a blight on architecture for decades, a cult of ugliness, and produced buildings which still ruin cities to this day. The examples of brutalism inspired web design in the article are highly aesthetic by comparison.
Also, I appreciated the Nine Inch Nails reference.
This article was posted on lobste.rs a while ago and it really opened my eyes to the point you’ve stated about brutalism. Here was the discussion around it.
“while in program design very little progress has been made at all since the invention of the subroutine”
That is so wrong in so many ways. If anything, we have so many different ways of tackling the conflicting goals of programming that I’m currently having a hard time of picking which subset to use in what ways for next, big project. That there’s ways to connect many of them makes it harder. Even Fortran, which most would consider the subroutine-oriented language, got extended for new models over time. I could see someone thinking programming innovation ended at subroutines if they spent their whole career maintaining legacy systems in JOVIAL or something.
The other problem with the article is it’s conflating the product of economic and social factors with technical ones. Both the improvements in hardware and the problems in mainstream projects are motivated by those. At least for software, there were always better technical approaches across every dimension. Sometimes for hardware but more tradeoffs to make. The non-technical factors prevailed with whole ecosystems and markets forming around inferior tech. Some have been sustained for over sixty years by these non-technical factors.
Here are some of the languages and platforms that were widely used at the time:
K&R C (ANSI C89 wasn’t universally available yet)
Pascal (Turbo Pascal was popular on the PC)
Fortran 77 (Fortran 90 wasn’t universally available yet)
assembly language
Windows 3.1 (cooperative multitasking)
MacOS classic (cooperative multitasking)
various UNIX derivatives with X-windows or something similar
If you didn’t have a Lisp machine or a NeXT workstation, I think it would be easy to conclude that little progress had been made since the 1970s. The authors also reject C++ as being too slow so a language with garbage collection would probably leave them frothing at the mouth.
JOVIAL was an excellent language for its time - the first version was from 1958. It has a couple of nice features that are omitted from most languages.
The following excerpt from an Air Force manual shows the FALLTHRU keyword.
CASE PROFIT; BEGIN
( DEFAULT ): ERROR(21);
(1000:9999): DIVIDEND(PROFIT); FALLTHRU
(500:999): BALANCE(PROFIT);
(100:499): REEVALUATE;
(0:99): CLOSEOUT;
END
The case for values between 1000 and 9999 will fall through to the next case.
Another unique JOVIAL feature is the PARALLEL qualifier for TABLEs (arrays).
Here is an example in an imaginary C derivative with a parallel qualifier.
You’re arguing against a different claim than it made:
“Computer hardware has realized performance increases of a factor of more than 200 in the last 20 years, while in program design very little progress has been made at all since the invention of the subroutine. We would like to see the science of programming advance as quickly as other fields of technology.”
The science of programming already delivered by mid-1990’s a diverse array of approaches including META II, LISP’s (including Chez w/ 8-bit version), Simula, Prolog, algebraic programming, Smalltalk, APL, Standard ML, Haskell, Flow-based Programming, and so on. A whole zoo of approaches with all kinds of strengths and weaknesses. Quite a few of these had been deployed commercially with supposed advantages. One set could do self-modifying code the author asks about later. Yet, the author says “very little progress has been made at all since the invention of the subroutine.” That’s only true if you ignore all that I just listed.
“We believe that undergraduate education spends too much time conveying dogma, instead of teaching a sound theory of program design that helps programmers create good programs. Universities should provide students with less religion, and much more practical experience in making and analyzing small, fast, useful and efficient programs.
We believe the result of the common academic approach is computer science graduates who make programs that are fat, slow, and incorrect. The present state of the art in programming discourages experimentation and formal analysis. This seems contrary to what we would expect from a “science”.”
Whereas these better paragraphs suggest the author is looking at just those institutions teaching the weaker stuff in dogmatic ways. There’s a lot of them. That would be a good gripe.
“Why have some departments stopped teaching assembly language programming?”
Why were some departments teaching assembly language programming if they had finite resources they needed to invest in classes that gave best bang for the buck in software engineers or computer scientists. Those wanting everyone to learn assembly by default even if they didn’t need it for goals or career track would have burden of proof. Author gets the requirements of science backward here.
“Where is the experimental evidence to support these actions?”
Ends on a good question which groups such as Quorum language are working on. Article just seems to be very hit and miss in presenting its ideas.
re JOVIAL
Ok, you got me. It wasn’t as boring as it appeared when I took a quick look at it. ;)
Unless I am misunderstanding “Brutalism”, shouldn’t a “brutalist web site” be something like a no- or minimal-css web page? The examples the article gives, while pretty in their own right, don’t appear (to me) to go counter to much of everyday web-design one tends to see.
That’s my understanding, too. My touchstones for web Brutalism are this motherfucking website and this other motherfucker.
There’s another school that considers the Instragram iOS app as an example of brutalism. Other examples:
Brutalist websites
Brutalism in UX
I consider the two sites that you linked to more an example of design minimalism (only using as much as you need), as opposed to the minimalism of information that seems to typify “modern” design today.
I’d also be curious if y’all would consider something like my wiki as an example of brutalism
I’d say it’s pretty brutalist. It probably wasn’t designed or implemented with accessibility in mind. :)
Those are just trivial documents. It would be like calling a lost pet poster an example of brutalist graphic design!
I would imagine that to draw a useful analog to architecture, we have to imagine what it is we’re saving or optimizing for under a digital brutalism (in the same way that architectural brutalism is cheaper, easier, faster, less specialized, in addition to its aesthetic impact). As a programmer, I would imagine therefore that digital brutalism would have to at least partially be motivated by a desire for simplicity in construction: avoiding a reliance external resources that might not be available, avoiding a reliance on technologies or techniques that require specialization, avoiding techniques that require complexity in order to be correct (in favor of technologies that, while maybe less rich, can be correct more simply), and optimizing resource usage for browser speed and compatibility.
I think it’s perfectly fair to associate the above motivations with a particular aesthetic if they happen to be accompanied by one (after all, when I think about architectural brutalism I don’t think about the equipment, specialized or un-, that was used to construct it). But to say anything useful or interesting with term, it can’t just be the way they look.
Isn’t look (legibility) in print/web design fundamental? If we’re talking about a brutalist web design, it’s certainly not brutalist because the author used tables for layout, though that might contribute to a look that has hard edges (defining sections/compartments, etc)–an element often associated with brutalism.
Legibility and aesthetic are not the same, though. As I said above, it’s not that aesthetics are irrelevant; but using modern whizbang web design and tech, and just replacing your full-screen white-people-typing-together background video with graphics and video of a different aesthetic, is just another flavor of the status quo.
I agree with this.
What I think you’re saying is that Brutalism is a philosophy that can’t simply be replicated by copying an aesthetic. Is that right?
Sure, that’s fair.
Wikipedia has a nice passage which I think can be applied in spirit to websites:
So don’t do elaborate styling, expose how the site was built, and organize the site into functional zones in ways visible to the user. A thoughtful version of non-CSS, non-Javascript, image-light design might be the best Web “version” of Brutalism, with visual grouping being the only organization. Getting people to give up CSS and Javascript might be a bit much, but in terms of basic construction, HTML is the equivalent of concrete (the “raw structural members” of the Web site) and Brutalism is very much about not hiding or ornamenting that.
I have no trouble giving up JavaScript. I’d prefer to use mostly semantic HTML5, with just enough CSS to make the text more readable (because browser defaults are trash).
Great excerpt and follow up. I think you can keep CSS so long as what it’s doing is (a) visible in source behind the scenes, maybe even removable and (b) keeps the fundamental structure of the site or page. It might even give it the structure.
Maybe GeoCities was brutalist? http://oneterabyteofkilobyteage.tumblr.com/
The Classic Geocities, with all of its animated GIFs and background images and using images as dividers, is too ornamented to be Brutalist. It’s best described as Vernacular, which Wikipedia describes as:
The Geocities Vernacular was definitely the “architecture from people who weren’t architects” Vernacular.
In fact, the Terabyte Of The Kilobyte Age describes Geocities as Vernacular:
http://blog.geocities.institute/archives/5983
More to the point, Vernacular design is bottom-up unplanned design, with no large-scale goals in mind, whereas Brutalism is top-down planned design, and capable of designing in the large.
I always thought of it as rococo (in the sense that it’s maximalist in the distribution of small decorative features), but I don’t really have a strong background in the history of architecture.
That would be in line with architectural brutalism, but the term came out of critiques of architectural brutalism (which basically came down to “it’s ugly because it breaks convention in non-decorative ways”). “Web brut” has been used as an insult for longer than its current (3-4 year) rehabilitation.
I think both senses are useful for different reasons. Web brutalism in the sense of avoiding bloated web standards that necessitate bloated browsers is important for usability and for minimizing waste, while web brutalism in the sense of rejecting faux-minimalist aesthetics in favor of direct & straightforward mapping of form to function is important as a UX concern. (I’ve argued for the latter in https://lobste.rs/s/cyopoi/against_ui_standardization and the former in https://hackernoon.com/on-the-web-size-matters-e52ac0f5fdbe and https://hackernoon.com/an-alternate-web-design-style-guide-1aae8d0b5df5)
Regarding your hackernoon article where you say
what would your thoughts be on directly hostilng markdown, probably without literal html, instead of the “more powerful” full-html standards and deviations? Maybe protocols like Gopher could serve as a base for this?
I consider hosting markdown marginally more reasonable than hosting html, but to be honest I don’t think we, as writers, should be controlling how the text is formatted except in the rare cases when the formatting is truly necessary and part of the point (like, if we’re writing concrete poetry or something).
In other words, something like gophermaps-as-document-format seems ideal: we get jump links, but literally nothing else.
The alternate web design style guide, despite apparently looking pretty radical to a lot of web devs, was very much a compromise – in the vein of “oh, if we MUST have web standards at all, at least ditch everything other than HTML 1.0!”
The merits of minimalism aside, brutalism was a blight on architecture for decades, a cult of ugliness, and produced buildings which still ruin cities to this day. The examples of brutalism inspired web design in the article are highly aesthetic by comparison.
Also, I appreciated the Nine Inch Nails reference.
This article was posted on lobste.rs a while ago and it really opened my eyes to the point you’ve stated about brutalism. Here was the discussion around it.
I dunno. I find brutalist architecture quite aesthetically pleasing.
Brutalist buildings in good repair are treasures.
By what measure? Taste/distaste for brutalist architecture is highly opinionated in my experience.
By the measure of my subjective experience, of course :)
At least you’re honest about it. :)
This reminds me of the Futurist Programmers website.
“while in program design very little progress has been made at all since the invention of the subroutine”
That is so wrong in so many ways. If anything, we have so many different ways of tackling the conflicting goals of programming that I’m currently having a hard time of picking which subset to use in what ways for next, big project. That there’s ways to connect many of them makes it harder. Even Fortran, which most would consider the subroutine-oriented language, got extended for new models over time. I could see someone thinking programming innovation ended at subroutines if they spent their whole career maintaining legacy systems in JOVIAL or something.
The other problem with the article is it’s conflating the product of economic and social factors with technical ones. Both the improvements in hardware and the problems in mainstream projects are motivated by those. At least for software, there were always better technical approaches across every dimension. Sometimes for hardware but more tradeoffs to make. The non-technical factors prevailed with whole ecosystems and markets forming around inferior tech. Some have been sustained for over sixty years by these non-technical factors.
This website was created in 1994.
Here are some of the languages and platforms that were widely used at the time:
If you didn’t have a Lisp machine or a NeXT workstation, I think it would be easy to conclude that little progress had been made since the 1970s. The authors also reject C++ as being too slow so a language with garbage collection would probably leave them frothing at the mouth.
JOVIAL was an excellent language for its time - the first version was from 1958. It has a couple of nice features that are omitted from most languages.
The following excerpt from an Air Force manual shows the FALLTHRU keyword.
The case for values between 1000 and 9999 will fall through to the next case.
Another unique JOVIAL feature is the PARALLEL qualifier for TABLEs (arrays). Here is an example in an imaginary C derivative with a parallel qualifier.
You’re arguing against a different claim than it made:
“Computer hardware has realized performance increases of a factor of more than 200 in the last 20 years, while in program design very little progress has been made at all since the invention of the subroutine. We would like to see the science of programming advance as quickly as other fields of technology.”
The science of programming already delivered by mid-1990’s a diverse array of approaches including META II, LISP’s (including Chez w/ 8-bit version), Simula, Prolog, algebraic programming, Smalltalk, APL, Standard ML, Haskell, Flow-based Programming, and so on. A whole zoo of approaches with all kinds of strengths and weaknesses. Quite a few of these had been deployed commercially with supposed advantages. One set could do self-modifying code the author asks about later. Yet, the author says “very little progress has been made at all since the invention of the subroutine.” That’s only true if you ignore all that I just listed.
“We believe that undergraduate education spends too much time conveying dogma, instead of teaching a sound theory of program design that helps programmers create good programs. Universities should provide students with less religion, and much more practical experience in making and analyzing small, fast, useful and efficient programs.
We believe the result of the common academic approach is computer science graduates who make programs that are fat, slow, and incorrect. The present state of the art in programming discourages experimentation and formal analysis. This seems contrary to what we would expect from a “science”.”
Whereas these better paragraphs suggest the author is looking at just those institutions teaching the weaker stuff in dogmatic ways. There’s a lot of them. That would be a good gripe.
“Why have some departments stopped teaching assembly language programming?”
Why were some departments teaching assembly language programming if they had finite resources they needed to invest in classes that gave best bang for the buck in software engineers or computer scientists. Those wanting everyone to learn assembly by default even if they didn’t need it for goals or career track would have burden of proof. Author gets the requirements of science backward here.
“Where is the experimental evidence to support these actions?”
Ends on a good question which groups such as Quorum language are working on. Article just seems to be very hit and miss in presenting its ideas.
re JOVIAL
Ok, you got me. It wasn’t as boring as it appeared when I took a quick look at it. ;)