Recently I started to work on a very simple tool to do this with a single command: it'll start all your projects in a given directory and expose them via HTTPS on https://[project].localhost
I've been using it for myself so it's lacking documentation and features. For example, it expects to run each project using `npm run dev`, but I want to add Procfile support.
Hopefully other people find it useful. Contributions very much welcome!
I'm surprised such an in-depth article doesn't even mention promises. Upcoming async/await (already available via transpilation) will make error handling in Node sane again.
I happened to be reading The Design of Everyday Things at the same time as Understanding Air France 447. It was surprising to see how the concepts explained in the book by Don Norman applied perfectly to explain the errors made by the pilots -- even though airplanes are not everyday things.
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.
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.
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.
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?
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
I would say that Disque follows the minimalistic philosophy of Redis. However, Disque is a specialization of one of the most common use cases of Redis: queues. So I wouldn't expect so many primitives--Disque knows about jobs and queues, so you don't have to build those yourself like people have been doing on top of Redis.
No daemons, and the only piece of configuration is adding a file to /etc/resolvers: https://github.com/djanowski/hostel
I've been using it for myself so it's lacking documentation and features. For example, it expects to run each project using `npm run dev`, but I want to add Procfile support.
Hopefully other people find it useful. Contributions very much welcome!