
Show HN: Hasp – A minimal CSS preprocessor using the M4 macro language - djanowski
https://github.com/djanowski/hasp
======
mmastrac
Cool hack!

M4 gives me flashbacks to nightmares trying to deal with sendmail and
configure scripts.

Why did this horrible language become so popular? Why has it not been
replaced?

~~~
vezzy-fnord
_Why did this horrible language become so popular?_

I wouldn't call m4 "popular" in the slightest, it's generally used by only a
few well-known programs like autoconf, sendmail and SELinux.

It's used because it's a standardized way to bolt on substitution macros to a
system without having it be intrinsically aware of them.

------
bluetidepro
> " _What about sourcemaps? ¯\\_(ツ)_ /¯_"

That's a dealbreaker. Especially when you are working with a larger more
complicated code base.

~~~
djanowski
You're right. I didn't mean to say sourcemaps are useless. For now, they were
a trade-off. It'd be interesting to see if they can be added using M4.

------
stdbrouw
I usually partake of the "faster, lighter, less bloated" kool aid, but I have
to say I don't really see the bloat in less/sass/stylus. They're fast, you can
just ignore the features you don't need, and they're an `npm install` away.

~~~
eatonphil
I don't really have a great reason for it - but my impression of working with
code bases that require node (when the code is not node code) is that they
quickly start bringing in a ridiculous amount of dependencies. I have no
reason to think the 100s of dependencies I need to install is a necessary part
of using less or sass. But in the projects that I've worked on, this has been
the case. My impression of node as a community is a culture of bloat. So if I
can get less involved, that is appealing to me. I'm speaking only from what
I've seen, so I could certainly have a wrong impression.

~~~
benesch
It depends how you define bloat. If you define bloat strictly as number of
dependencies, then sure, the Node ecosystem encourages more "bloat" than any
other mainstream ecosystem.

But if you define bloat as "inclusion of features I'm not using," the Node
ecosystem is lean and mean. If I only need 15 of the 250 functions that Lodash
provides, I can include each of those 15 functions as an individual package.
Yes, it increases disk space, because each dependency ships a package.json and
a README and subdependencies aren't shared, but disk space is cheap.
Decreasing the surface area of my library dependencies is worth it for my
development happiness.

I think the criticism you want is "ultra-modular." You can make an argument
that Node's proliferation of tiny, one-function packages is a maintenance
burden and causes discoverability problems. Personally, I disagree: any effort
to move towards a world where you never have to write a line of code someone
else already has is well worth it. And from an end-user perspective, it
shouldn't matter at all. `npm install` on average takes no longer than `gem
install` for me, despite NPM pulling in orders of magnitude more packages.

( _Python_ might be bloated; have you ever looked at the complete stdlib?
There are some horrifying pieces: urllib2, email, turtle (?!).)

P.S. Check out libsass [0], a re-implementation of Sass in C with [probably]
bindings to your favorite programming language.

[0]: [https://github.com/sass/libsass](https://github.com/sass/libsass)

~~~
Nullabillity
Then again, not being noticeably slower than gem install doesn't mean a lot.

------
todd8
Around 1966, two notable programming languages were developed around the
notion of macro expansion. One of these was Christopher Strachey's GPM
(General Purpose Macrogenerator) and Calvin Moore's Trac(tm) system. GPM,
perhaps because of Strachey's academic reputation (he taught at Oxford and is
well known for _denotational semantics_ ), seems to have had a greater
influence in Computer Science.

Trac(tm), on the other hand, had an important booster, it was promoted in Ted
Nelson's 1974 cult classic _Computer Lib_ , one of my treasured historical CS
books that I bought in grad school the first time around. Nelson (famous for
inventing hypertext, the notion of embedded active links decades before HTML)
wrote that "You can and must understand computers now." He suggested learning
three languages: BASIC, TRAC, and APL--all languages that he felt you could
learn on your own. Trac, and the remarkably similar GPM, are very simple. I've
implemented Trac-like systems several times. It's a fun project to implement
in an afternoon when learning a new programming language.

What made these two languages interesting is that they are equivalent to a
Turing machine and hence capable of arbitrary computations. Furthermore, they
really aren't impractical to use (but see my comments below). If locked in a
dungeon by an evil genie and forced to write a real program on bare hardware
before I could be released, I would certainly consider developing TRAC or GPM
as the first step (or maybe FORTH).

m4, developed by Kernighan and Ritchie in 1977, looks like it was inspired by
GPM. It's been a useful tool for me a number of times, but it is good to not
let it's generality and flexibility suck you into outsmarting yourself.

The power of these macro systems (and TeX's as well) comes from the arbitrary
rewriting that they enable, a bit like Chompsky's Type 0 (unrestricted)
grammars in his hierarchy. These macro systems, once popular, have now fallen
out of favor. Although almost trivial to implement, programming in them is a
bit like playing Othello, it's hard to see very far ahead: what will unfold
when a macro that will be expanded is passed arguments that will be re-
expanded.

Sendmail's configuration files are processed by m4--seemed like a cool idea in
the early 1980's--but that made it hard for non-experts to understand what was
happening.

------
kevin
It's very rare that I laugh out loud while reading documentation. I'd never
use this, but it did make me want to show this to all my frontend friends. A
lot of people can learn from just that one skill.

Thanks for sharing this. Really made my day.

~~~
futhey
“It's very rare that I laugh out loud while reading documentation” – I visited
on this recommendation alone. Also laughed out loud. Kudos.

~~~
djanowski
Thank you!

------
philsnow
I don't write any CSS but clicked through because you're using m4, which I use
in my 'dotfiles' git repo to specialize things according to what host/platform
I deploy it on. Nice to see another human user of m4.

I also learned about [http://entrproject.org/](http://entrproject.org/)
through your README.md . Being stuck on OSX for work, this looks very handy.
Thanks!

~~~
paxswill
Is your dotfiles repo public? I also use m4 for my dotfiles [0] and am
interested in seeing how others use it.

0:
[https://github.com/paxswill/dotfiles](https://github.com/paxswill/dotfiles)

------
bartbes
I just started using it (for nothing serious). I'm going to have so much fun
when I rediscover this in a year or so.

~~~
djanowski
That's awesome. Let's keep in touch :)

------
yellowapple
Looks awesome. I'll certainly be putting this to some use :)

That said.

> Anyway, they all require Node.js, a huge dependency for this simple problem,
> in my opinion.

While I personally agree with this opinion, isn't it typically the case that a
frontend dev's workflow already heavily relies on Node? It's probably already
installed for all that Wangular.js nonsense, so it being tacked on to one of
the heavier CSS preprocessors probably doesn't make much of a difference, no?

~~~
djanowski
Yes, you're right that most frontend developers already rely on Node for
various tasks.

This would be most helpful for those who still haven't introduced Node as a
dependency and trying hard to get away without it :)

In any case, as I mentioned in another comment, the fact that one can write a
minimal preprocessor in ~30 LOC could be useful to start a conversation about
the current state of the art regarding frontend development.

------
cmaher
> "Tired of all the slow and bloated preprocessors..."

libsass is amazingly fast. I generally see it churn through ~20k lines of CSS
(don't ask) in 6ms.

~~~
AstroJetson
Just as I can not rip my bleeding eyes away from Honey Boo Boo, I can't not
ask how you got 20K lines of CSS. Families live under the covers of ~5-6K of
CSS. Major click bait sites exist with 10-15K of CSS. Help all of us here. You
only have 6 lines of HTML and the 20K of CSS does all the work?!? I feel the
iterwebtubes are doomed.

~~~
ricardobeat
Look at major websites. You can easily reach 50k to 200k+ lines of CSS in a
large project.

------
citeguised
Looks nice, but how do I install this?

~~~
djanowski
That's... a really good question. I added instructions in the README:
[https://github.com/djanowski/hasp#installation](https://github.com/djanowski/hasp#installation)

Thank you!

~~~
citeguised
Thanks a lot!

