Clojurians Log v2

@thheller Thank you for your help yesterday!

How to set polyfills for ResizeObserver in shadow-cljs? Or maybe in general how do you include polyfills?

not sure there are any for ResizeObserver in closure. you can always use https://polyfill.io/v3/ separately

Looking at the doc I don't think so, but is it possible to add metadata to a namespace to prevent caching? :cache-blockers works but it's not very user-friendly when it comes to libraries

why would you want that? there is ^:dev/always

@thheller Once again I was in a bit of an odd situation... I am messing a lot with doing side effects at compilation these days. Being able to force compilation from metadata might be a useful feature given how Shadow-CLJS is widely used. You wouldn't have to add defaults in :cache-blockers but then it's true that side-effecting on compilation is definitely not a widespread habit

its also a bad idea. if you share what you are working on I can maybe make some suggestions.

It's a somewhat novel CSS compiler that does many things. Essentially, this bit is about Garden rules declared in CLJC files being recompiled from Clojure (JVM) everytime a file is saved, which also triggers CLJS recompilation and does some syncing between those 2 environments. It works really well actually but there are a few problems that are tough to solve in order to provide a seamless experience. Slowly getting there 🙂 I'll let you know when I release an alpha version

But those problems are very specific and definitely not the kind of day to day work a Clojurist does, that's why I have been asking weird questions around a few channels lately :p

@adam678 Yo, I’m really interested in this CSS compiler. What are some other things it can do?

@c.westrom It leverages Garden but provides a whole dev experience as well as aggressive optimizations for production. In dev mode, it is about providing structure, documentation, and efficient live reloading. All names such as CSS classes are defined in an Clojure idiomatic way as Vars. Easy to consume, can hold docstrings, and even more importantly, this prevents any name collision. Any sets of CSS rules you write can be documented as well and when you hit save, are written to files in a two level directory tree mimicking your code (namespace > sym). Everything is always clear in code and you can always see the exact CSS it produces. Only rules that change are recompiled and live reloaded which doesn't put a burden on your dev environment. (The "recompile everything" at save is horrible for any real-world project). In release mode, it provides dead code elimination of CSS by detecting CSS names that survived advanced compilation and analyzing your rules. Then it will actually optimize everything and rewrite your classes! This is extra nice because you don't have to worry about efficiency. When I write rules for a class, everything is flat. I merge maps, don't care at all about CSS inheritance or whatever. It looks like common Clojure. It's the compiler's job to then detect common rules amongst classes, split and merge them as needed, create atomic rules and all those CSS buzzwords. That's it in a gist 🙂

And there is actually plenty more, it can lint your rules at dev time (eg. warn you if there is a typo in a property), warn you if your code uses CSS names which do not show up in your rules, and so one...

See the reason I asked is I’m working on something myself. I’m trying to use a java-based css parser to convert a CSS file and create garden syntax from it. The experience of trying to integrate npm, shadow-cljs, and all these crazy build steps just to use tailwind, has been pretty crusty.

A parser that supports all CSS is probably not that easy. The end goal is to not need frameworks like Tailwind or Tachyons. Anyway, as soon as you need something they don't provide, you are on your own... I don't believe they are that good of a solution

True. Tailwind was nice to start though. I really enjoyed putting a class in my HTML and immediately seeing a change. Even better that I can take a reagent component and all my styles stay with it. I would love to implement something like this using hiccup syntax, maybe leverage https://github.com/Jarzka/stylefy. How would you recommend handling CSS using nothing but hiccups?

I wrote https://github.com/thheller/shadow/wiki/shadow.markup a long time ago. sounds somewhat similar.

What I dislike about those solutions is that they are dynamic for things that should be static. It's another way of putting strain on JS. Everything is "blazing fast" in isolation but put together... That's why the web is slow 😛

I have exactly 0 runtime cost here and it's highly optimized... which I like!

it isn't dynamic.

but the thing I never bothered to write but all of this supports is extracting the css in a separate compile phase

anyways .. I'm not using it anymore either so wouldn't recommend anyone else to do it either.

@adam678 I wanna build static sites using ClojureScript, mostly because I could imagine templating would be easier using functions. I wanna have a multilingual site, also have dark mode/light mode as an option. Either way, can’t wait to see you release this.