Show HN: Brutal.js – a small framework for building brutalist web applications
github.com
github.com
I think a simple framework to provide the basics could be helpful, the one mentioned yesterday was http://tachyons.io.
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.
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.
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
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.
I think often of Frank Chimero's visual essay about this, titled "The Web's Grain": https://frankchimero.com/writing/the-webs-grain/
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 :)
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.
XSS demo 1: https://jsfiddle.net/hegLkz4s/2/
XSS demo 2: https://jsfiddle.net/hegLkz4s/4/
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.
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...
https://jsfiddle.net/hegLkz4s/22/
It's also already been reported:
https://github.com/jsfiddle/jsfiddle-issues/issues/963
You're right about there being an XSS vulnerability here though. But you can fix it pretty easily by escaping the HTML:
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.
// Safe version
const header = title => html`<h1>${title}</h1>`;
// Unsafe version, but it "works" as expected
const header = title => `<h1>${title}</h1>`;Let's consider a container where a function like `header` would be used:
const page = (title, body) => html`
${header(title)}
<p>${body}</p>
`;
<h1>Foo</h1>
<p>Bar</p>
<h1>Foo</h1>
<p>Bar</p>
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).
[0] blog post: https://brutalist-web.design/
[1] blog post: https://russell.ballestrini.net/capability-driven-presentati...
[2] (free online book): https://resilientwebdesign.com/
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!
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?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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) }"
Edit: I see - To me, brutalist means as close to the basic raw HTML/ JavaScript as possible.
Or have I overthought the joke? It's possible, I've done it before.
Its not a joke either. there are some big companies in that list I shared like Nike, Snapchat, Gucci, etc.
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.
Almost none of these sites follow that principle. Personally I think they look just awful, regardless of what principles they follow.
Sugarless sweetener now made from sugar cane!
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.
const ButtonWidget = ({name}) => (<button onClick={() => showModal(name)}>Show {name} Modal</button>);