The Bootstrapping Mindset

Eric Normand on March 16, 2017

I'm on a campaign to find a solution to the web: Eric Normand @ericnormand Folks, I'm repeating this every month until I see some progress:... [Read Full]
markdown guide

I think Elm in general and elm-style-elements in particular is a solid and hopeful partial solution. Elm-style-elements abstracts away selectors and provides a cleaner interface to the rest of CSS (notably completely ignoring some parts of CSS).


I don't know if this is exactly what you had in mind, and in hindsight I realize it's a little React-y but I made a quick demo of a thing that takes in a single object and produces an HTML view

In the future I want to research and see if I can use a Proxy to build in data binding off of having the user code manipulate the master object.


The CSS-in-JS projects are exploring a very different approach to CSS:

This has a number of interesting properties that aren't available in normal CSS, such as proper namespacing.


I am using Hoplon + Hoplon UI. I found it (and Clojurescript), coming from front end design, after years of searching for a way out of the tarpit of css (minimal graphical semantics, buggy incomplete browser implementations, object declarations redundant with html structure).

Hoplon provides all the normal semantics of HTML + CSS, but unified in a responsive evaluation environment with javascript/clojurescript. So for example, you can use any programming logic or page state to modify your css, real-time (kind of like SASS, but instead of the SASS DSL, you have the full language power of clojurescript, and it's also available in the runtime state of page). Thus CSS is liberated from a static design declaration, off to the side, to a finely-grained design semantic that can be woven more directly into your living page.

With the walls between CSS/HTML/JS broken down, you are free to build up your own abstractions that leverage any or all of these pillars... And your abstractions will likely carry the semantics of their purpose, rather than their implementation in said CSS/HTML/JS. So per the article, you have bootsrapped a LISP onto the browser, which allows more articulate and robust languages for design.

Hoplon UI takes the Hoplon (Clojurescript-DOM) platform, and starts building more sane design components on top. It is a palette of logical design primitives, that goes as far as developing a custom box-model to ensure that these primitives perform as expected. You can tune DOM elements directly with a full suite of attributes that currently include most of the CSS and Jquery properties. This makes it trivial, for example, to do rather sophisticated conditional styling (for responsive design, etc). It further encourages you to regard CSS as an assembly under-layer, and speak design experimentation in a richer, higher-level markup.

Hoplon UI is not the end of the road. It aims to merely provide better design primitives. Those primitives will be used, along with other clojurescript code to do things like gss cassowary constraint solving (clojure has some neat logic-programming libraries), and bootstrap (built-out libraries of opinionated ui components).

Sorry for the longish rant, but this article echoed a deep resentment I also felt, about the punishing and castrating nature of browser-based web designed I experienced since the IE6 debacle, having come from a print-based graphic design background where the tools mostly just worked, and you could get on with your creativity without becoming a heroic hacker. Clojure and Hoplon still have some sharp edges, but after a long search and trial phase, I found them to promise salvation for me as a creatively minded web designer.


I agree with you that CSS is broken. 14 years ago I was told to stop using tables for layout, then given a partial replacement, and now 14 years later we have Flexbox which finally provides similar layout control.

However, I would also say that modern dev is more akin to system integration than bootstrapping.


Yeah, as Alan Kay has said, there hasn't been a new computing invention since 1980. We're not bootstrapping anymore, just piling rocks.


you cant fix css! css is human by design. humanity is subject to a very strangely unpredictable but deterministic way of things evolving over time. the best you can do is find something that works in a small, not-universal scope, such as what people are doing with LESS, SASS, css-in-js, jsx, whatever.

if you "fix" css, youre essentially applying subjective standards to about 20 years of work. think of all that time people spent, trying to determine who to subjectively make facts


Maybe I'm missing something but doesn't CSS Grid Layout solve your problem?


I'm not sure. Does it mean that one day I won't have to write CSS the way I don't have to write machine code?


It depends, CSS isn't going away.

If you combine the CSS layout grids (or any other CSS) with web components you're effectively creating a reusable object, you can pass values to it programmatically or directly, you can even generate the entire WC programmatically.

Semantically, everything has more meaning and it's completely modular.


Great article, but I can not stop thinking about GWT. Where does it play in all of this?

code of conduct - report abuse