Might just be me, but it feels a little weird that brutalist design needs a framework. But perhaps I'm misconstruing the design/look of it to how it is actually built, in which case I would rather just do a brutalist design but do it with some more fleshed-out alternative like jquery+bulma.
Just because it's "brutalist" doesn't mean it should be hard to read. I guess the point is just to reduce it to the basics while still being nice to look at with proper line breaks, padding and line heights.
I think a simple framework to provide the basics could be helpful, the one mentioned yesterday was http://tachyons.io.
I kinda feel a js framework for building brutalist websites almost ironically misses the point.
Though brutalist doesn't per se imply a _technical_ reduction to barebones web pages, like in any design dicipline, a larger theory of design like this deginitely has a lot to say about underlying technology. Maybe it's just me, but kind of the point of brutalist design is to say: "you're overengineering it. Keep it raw to what it is, and as expressive as possible".
I wouldn't go as far to say this is all "wrong" to me, but it strongly feels like "stone washed designer jeans with holes in them" - just faking it.
It says it's for web applications, which is a slightly different goal that can justify the use of JS.
That said, "brutalist" strikes me as a pretty silly concept to apply to the web.
In the architecture of buildings, there can be a direct relationship between the technology used and the visual result. The same doesn't really apply to the web, unless for example you use pure HTML with no CSS or JS.
As soon as you introduce CSS, you're putting a "facade" on the system that's the equivalent of draping a brutalist building in, say, marble or glass. Deliberately using that styling to look "as if" it's something else turns brutalism into a facade itself.
And as you say, once you introduce JS, all bets are off.
So, the philosophical and artistic foundations here seem dubious, undermining the integrity behind the original idea, and making the whole exercise seem faddish.
This is another way to look at it, for sure - but the same would hold true of Google's "Materials", in the digital realms everything is just a metaphor.
But the idea of "barebones" in brutalism really means to embrace the scaffolding and raw form of what you build. The comparison of css to the facade or to "ornament" in architecture can't be made here, as css also takes up a big part in the actual "shape of the building".
The reference to brutalism in regards of css can therefore be understood as a directive to moderation, paint, not marble.
But what disturbs the concept of brutalism to me is building the dom with js - this is where we leave the "building block of the web" part of js and go off the original intention of the brutalist metaphor.
As i said, why not? But it does feel like a bandwagon thing, defiant of the general idea
> The comparison of css to the facade or to "ornament" in architecture can't be made here, as css also takes up a big part in the actual "shape of the building".
CSS didn't even used to exist on the web. One of its primary purposes is to provide ornament. It also does provide structure - so I suppose you could impose some artificial limits on how you use it, focusing on the structural and limiting the ornament, but that highlights the problem: you're not using some technology and living with its capabilities and limitations, you're using a much more advanced technology with somewhat arbitrary constraints to simulate the design and look of a less complex technology.
> The reference to brutalism in regards of css can therefore be understood as a directive to moderation
Yeah. It seems like a weak analogy to me, though.
> building the dom with js - this is where we leave the "building block of the web" part of js
That seems arbitrary to me. The same moderation you can apply to using CSS can be applied to building the dom with js.
There are certainly important benefits to using moderation in one's choice of how to use technology. But the comparison to brutalism seems to me force-fitting an idea that doesn't really fit well - unless one took the concept seriously, in which case the results would not be likely to be well received.
Even with elaborate CSS in play, I think the web has deep characteristics that you can either lean into or struggle against. For example, there's the simple fact of scrolling; does your web page embrace that default behavior, or override it with fancy scroll effects, or replace it entirely with, say, some kind of horizontal page-flipping simulation?
> I think the web has deep characteristics that you can either lean into or struggle against.
I completely agree with that, but I don't get the impression that this is what most brutalist web approaches are really going for.
Besides, I've followed a version of the leaning into principle for all my technology work for many years, because I'm "lazy" in the programmer sense and impatient - struggling to achieve some specific vision of a solution when I can achieve the same end goal more pragmatically and much more quickly is a no-brainer choice for me. I've often successfully convinced clients of this, too. I don't plan to start calling this brutalism :)
I think you're assuming that HTML (and maybe CSS) is the foundation layer of the web. I would argue that JS is part of that foundation. Sure, historically, JS came (much) later, but things change over time. E.g. Java was originally designed for television, but, love it or hate it, JEE is a completely different animal.
All that is to say that I think it's a bit unfair to say that a non-fake brutalist implementation must not use JS.
I think this is kind of missing the point. The movement toward brutalism tries to bring back the uniqueness of sites on the early web in all their bizarre diversity. It's also about just using HTML and CSS, which used to be written by hand and which give sites an off-the-beaten-track personality.
Agreed. Not to sound too harsh, but this "framework" (actually a library) smells very strongly of bandwagon. Why should I use this when I could use something like Hyperapp or Preact, and what does Brutal.js have anything to do with specifically brutalism?
Yes, could not agree more, Brutalism is quite hot right now (although HN seems to hold a bit of an alternative definition about what Brutalism entails) which really seems like the only reason this exists in its current form. A framework for Brutalism almosts sounds like an oxymoron to be honest.
I don't think it's about bringing back the 'uniqueness' of early web sites. They aren't advocating putting visitor counters and unfolding envelope gifs on every page.
I tried making something like this (JSX with Template Literals) few times, they are languishing in unfinished JSFiddles. The main issue was making it XSS-safe by default, which as I see this hasn't achieved at all!
So, please do not use this, use React or similar well-tested libraries instead. There might be a way to make something like this that is XSS-safe by default (I got pretty close), but brutal.js does not seem to be it.
There are a number of HTML attributes and properties that can result in redirects, HTTP requests, and evaluation of arbitrary code.
If the developer uses databinding with untrusted input into any of these attributes or properties, their site may be exploitable. A databinding engine can do some things to protect against this. One way of handling this is to treat strings as untrusted by default, and require explicit wrapping types for trusted content, e.g. https://google.github.io/closure-library/api/goog.html.SafeU...
lit-html, a similar HTML templating with template literals library, achieves /mostly/ XSS-safe by default by never interpolating dynamic data before parsing, but interpolating after parsing and DOM construction and then using textContent, not innerHTML.
That means that user-provided text can't inject markup into the page.
There are still a number of sensitive attributes that we want to be automatically sanitized for you, like src/href/on*, but we have the hooks needed for that and just need to add the contextual sanitizer.
Does it throw if a template returns a string? While it's a cool feature to be able to do this, it's also quite dangerous (specially when dealing with beginners for this library) to have these two behaving almost the same but one being safe and the other not:
// Safe version
const header = title => html`<h1>${title}</h1>`;
// Unsafe version, but it "works" as expected
const header = title => `<h1>${title}</h1>`;
Seems to me that "brutalism" is two separate things that don't necessarily need to be mixed together. There's brutalist design, which is about keeping the design as simple and straightforward as possible. Then there's brutalist coding philosophy, which is keeping the code as simple and straightforward as possible.
I like the ideas behind "Brutalist Web Design" [0] and "minimalist web design", and flat design aesthetics where content is treated as most important over presentation.
Personally I'm more in favor of what I term "Capability Driven Development" [1], known by others others as "Resilient Web Design"[2].
I think good "visual design" should often be minimal or even abstract, just enough to invoke a feeling or emotion related to the content. True to form or materials, like a brutalist.
I think "web design" should work for the lowest common denominator and level up depending on the capabilities of the end user. This means using real HTML form submissions instead of AJAX. The page should work without Javascript, but the user experience may be enhanced with AJAX if Javascript is present. Web pages are built out of HTML elements, it should work that way from bottom up. From my perspective a Javascript only websites (AngularJS) is the same as a Flash only website (which the industry has formally shunned).
Actually, in the current project I am working on, I have been using Stimulus JS and VanillaJS™ exclusively and it is like a breath of fresh air. Shit just works as expected and setup was easy. I'd definitely recommend anyone who doesn't need a full frontend but rather just to add a bit of JS functionality to their site, without it becoming noodle soup that they check out Stimulus. If Brutal.js is going in that direction, props to it!
I. Every once in a while, a new fad appears that is described by the infatuated as not a fad, just the way things are innately or intuitively supposed to be.
They never live up to this promise; the creative destruction along the way does pave the way for new and often better things, but it also destroys good tenets.
II. Why is it that those who make the best works of a certain style are usually the ones who are least willing to associate themselves with the "movement" around that style?
Your second point is especially salient to me. I think you see it in all creative fields, from development to painting. People who are religious about a style—viewing the style's doctrine as an ends in and of itself, as opposed to a tool to help achieve their vision—tend to be the creatives no one remembers.
I was wondering how they pulled of the R`` expressions because I didn't realize that JS added "tagged templates" like this [1]. So if nothing I learned something new by reading this tiny bit of code.
It's ironic that this is being used in a "brutalist" framework, because tagged templates seem really poorly designed and overcomplex - using a monolithic function to process an entire template, instead of compositionally building it from components that can be independent (but don't have to be.)
The example in your link could easily be implemented by a much simpler templating feature in which you just call functions to transform the parameters, e.g.:
"That ${ person } is a ${ characterize(age) }"
If you want shared state between your template expansions, you can create an object that exposes the required transformations, and it'll still be better designed than that example.
I would say most of the pages from your link, contradict everything (pointless JS all over place, useless images and animations, fonts with no purpose) that is written in previously discussed brutalist manifesto :
I'm inclined to say if that article/manifesto on brutalist design that hit the front page yesterday is even remotely authoritative then some of these sites are breaking what I assumed to be fundamental tenents of brutalist web design already.
Or have I overthought the joke? It's possible, I've done it before.
no i've been following this design style for about 6 months now, and its not something to be boiled down to that manifesto from yesterday. Its actually been a style for a while as seen in the intro for A Clockwork Orange ( https://vimeo.com/49553745 )
Its not a joke either. there are some big companies in that list I shared like Nike, Snapchat, Gucci, etc.
I recognized the style, it wasn't until said manifesto that I even learned it had a name. Or rather that I learned what the name was.
Would you say the manifesto is missing concepts and explanations of the style or are there inaccuracies and in your opinion what are they? You've got a captive audience in me on the affair, I'm not a designer but I oddly like the language of design and hearing specialists discuss it.
Looking at the code, lit-html should be more efficient at rendering, much more efficient at updating, and safer.
Lit-html parses each JS template only once, before interpolation, then caches the resulting HTML template. It clones that template for each new instance, then critically, finds the dynamic parts and directly updates the instance DOM on re-renders.
This library looks like even though it uses HTML templates, it creates a new one for each render and update. Not only will that be slower (from parsing, DOM manipulation, layout and paint) because it recreates all the DOM nodes it won't play nice with anything stateful like forms, or many custom elements. It also looks like it might have XSS vulnerabilities from interpolating data before parsing.
I'm happy to see more libraries use tagged template literals though. They're purpose-built for embedding DSLs like HTML, their cachability means you can get amazing performance from them, and they're not non-standard syntax extensions like JSX, so don't require a custom compiler.
Brutalism is about avoiding all kinds of front-end frameworks that ruined the web. It’s about writing vanilla JS/HTML/CSS and rendering most of the site server side.
