> Why did this horrible language become so popular? Why has it not been replaced?
Why indeed. I think the answer is because it's available everywhere (at least, on all Unix/Linux). I found myself writing yet another m4 macro only a couple of weeks ago and despairing, again.
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.
It's true. sassc(1) is a great step forward in terms of speed.
That said, Sass encourages practices that I consider bad. Nesting, @extend, etc.
Sass's design also makes it difficult to implement a basic feature like grouping all media queries for a single output. Check this issue from 2011: https://github.com/sass/sass/issues/116
Most importantly: it's very easy to end up with a huge CSS file that can't be compressed, and it makes everything more complicated.
Representing hierarchy in the class name makes the output shorter, in most cases, and makes the HTML and CSS code easier to understand. For instance, when you see <div class=title>, you need to go up to find context to understand what that "title" class is. If you have <div class=widget-title>, that's much better. Let alone that generic ("title") classes can lead to problems with conflicting rules depending on their specificity.
By the way, classes at the top level are faster to parse and apply.
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.
Agreed. This just comes off as the typical HN post, "I rewrote X program, using Y language, check it out!".
OP is learning Y language, wanted to make a project as a goal. Which is all well and good. But thinking its worthy to be shared seems like narcissism, especially when the description for the repository is, "Half-assed CSS preprocessor." And with 12 commits from the last 5 months, 3 of those being actual code, this isn't a serious project.
This is showing off homework. Though I suppose everyone seeks validation.
I don't think you read the top section of the README. It clearly says that I was first looking to write a simpler CSS preprocessor, and then came across M4.
I'm not saying the tool I wrote will replace all preprocessors. My point is: I wrote one with just enough features in around 30 LOC. Can we use that to start a discussion around the current state of the art regarding frontend tooling? Or software in general?
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.
I see what you mean. Generally node libraries are very small and do just one thing, which is why almost any project ends up having a large amount of (small) dependencies, or alternatively, like PostCSS, a whole bunch of plugins that have to be installed separately. It can look a bit silly at times, but then again, if that means each dependency is small, well-tested and of high quality, the number of dependencies is not necessarily indicative of bloat.
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.
I dunno, our sass codebase eventually got to a point where we couldn't watch it with the ruby-based compiler. It would take something like a minute to recompile all the files when a globally included file was edited. We ended up writing our own wrapper around sassc (the c-based sass compiler.)
Both Less and Sass implement features that I consider anti-patterns: nesting, @extend, etc. Sure, you can ignore them, but there's a lot of code in the tool to support that. The code needs maintenance and puts the barrier of entry higher for those wanting to contribute to it. Also, these are first-class features of the tool, they can't be disabled explicitly. So you'd need code reviews and other artifacts to make sure no programmer/designer ever tries to use them. Finally, why would you choose a tool that does 20x what you need, if there's an alternative that does just what you need? (As stated in other comments, I don't mean my solution is what will replace all preprocessors. PostCSS looks like a more modular approach and it allows you to effectively cherry-pick the features you need by means of plugins.)
Also, easy != simple. The fact that a tool is easy to install (after having installed another mega-dependency) shouldn't count as an advantage, in my opinion.
Nesting is the only reason I wish to use any of these preprocessors to be honest. I don't understand how people write plain css when things like less/sass exist. Writing and maintaining css selectors is a nightmare, but it's so simple and intuitive to just nest things inside parents.
I was going to say. How the heck is nesting an anti-pattern? It is SO useful for CSS. It should have been standard years ago. Variables are helpful too.
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/ through your README.md . Being stuck on OSX for work, this looks very handy. Thanks!
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?
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.
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.
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.
44 comments
[ 7.1 ms ] story [ 100 ms ] threadThat's a dealbreaker. Especially when you are working with a larger more complicated code base.
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?
Thanks!
> Why did this horrible language become so popular? Why has it not been replaced?
I don't know. Maybe just like other tools in POSIX systems -- it works :)
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.
Why indeed. I think the answer is because it's available everywhere (at least, on all Unix/Linux). I found myself writing yet another m4 macro only a couple of weeks ago and despairing, again.
EDIT 1: there are alternatives [1] but this is the most well-known. Now I'm intrigued by pyexpander.
[1] https://en.wikipedia.org/wiki/General-purpose_macro_processo...
Thank you!
libsass is amazingly fast. I generally see it churn through ~20k lines of CSS (don't ask) in 6ms.
That said, Sass encourages practices that I consider bad. Nesting, @extend, etc.
Sass's design also makes it difficult to implement a basic feature like grouping all media queries for a single output. Check this issue from 2011: https://github.com/sass/sass/issues/116
If you don't mind a bigger tool and the dependency on Node.js, then PostCSS looks very good: https://github.com/postcss/postcss
Representing hierarchy in the class name makes the output shorter, in most cases, and makes the HTML and CSS code easier to understand. For instance, when you see <div class=title>, you need to go up to find context to understand what that "title" class is. If you have <div class=widget-title>, that's much better. Let alone that generic ("title") classes can lead to problems with conflicting rules depending on their specificity.
By the way, classes at the top level are faster to parse and apply.
This articles expands on some of these issues: http://www.sitepoint.com/beware-selector-nesting-sass
OP is learning Y language, wanted to make a project as a goal. Which is all well and good. But thinking its worthy to be shared seems like narcissism, especially when the description for the repository is, "Half-assed CSS preprocessor." And with 12 commits from the last 5 months, 3 of those being actual code, this isn't a serious project.
This is showing off homework. Though I suppose everyone seeks validation.
I'm not saying the tool I wrote will replace all preprocessors. My point is: I wrote one with just enough features in around 30 LOC. Can we use that to start a discussion around the current state of the art regarding frontend tooling? Or software in general?
But to each his own, of course!
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
Also, easy != simple. The fact that a tool is easy to install (after having installed another mega-dependency) shouldn't count as an advantage, in my opinion.
I also learned about http://entrproject.org/ through your README.md . Being stuck on OSX for work, this looks very handy. Thanks!
0: https://github.com/paxswill/dotfiles
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?
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.
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.
Thanks for sharing this. Really made my day.